From 59024c936561090d766370e839a880dd42232c33 Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Tue, 10 Nov 2020 21:59:23 +0200 Subject: [PATCH 01/59] pinctrl: jasperlake: Unhide SPI group of pins If the group of pins is hidden in the pin list it affects the register offset calculation despite fixed GPIO base. Hence, the offsets of all pins after the hidden group are broken. Instead we have to unhide the group and use a flag to exclude it from GPIO number space. Fixes: e278dcb7048b ("pinctrl: intel: Add Intel Jasper Lake pin controller support") Reported-by: Divagar Mohandass Signed-off-by: Andy Shevchenko Acked-by: Mika Westerberg --- drivers/pinctrl/intel/pinctrl-jasperlake.c | 450 +++++++++++---------- 1 file changed, 230 insertions(+), 220 deletions(-) diff --git a/drivers/pinctrl/intel/pinctrl-jasperlake.c b/drivers/pinctrl/intel/pinctrl-jasperlake.c index 9bd0e8e6310c..c5e204c8da9c 100644 --- a/drivers/pinctrl/intel/pinctrl-jasperlake.c +++ b/drivers/pinctrl/intel/pinctrl-jasperlake.c @@ -65,252 +65,263 @@ static const struct pinctrl_pin_desc jsl_pins[] = { PINCTRL_PIN(17, "EMMC_CLK"), PINCTRL_PIN(18, "EMMC_RESETB"), PINCTRL_PIN(19, "A4WP_PRESENT"), + /* SPI */ + PINCTRL_PIN(20, "SPI0_IO_2"), + PINCTRL_PIN(21, "SPI0_IO_3"), + PINCTRL_PIN(22, "SPI0_MOSI_IO_0"), + PINCTRL_PIN(23, "SPI0_MISO_IO_1"), + PINCTRL_PIN(24, "SPI0_TPM_CSB"), + PINCTRL_PIN(25, "SPI0_FLASH_0_CSB"), + PINCTRL_PIN(26, "SPI0_FLASH_1_CSB"), + PINCTRL_PIN(27, "SPI0_CLK"), + PINCTRL_PIN(28, "SPI0_CLK_LOOPBK"), /* GPP_B */ - PINCTRL_PIN(20, "CORE_VID_0"), - PINCTRL_PIN(21, "CORE_VID_1"), - PINCTRL_PIN(22, "VRALERTB"), - PINCTRL_PIN(23, "CPU_GP_2"), - PINCTRL_PIN(24, "CPU_GP_3"), - PINCTRL_PIN(25, "SRCCLKREQB_0"), - PINCTRL_PIN(26, "SRCCLKREQB_1"), - PINCTRL_PIN(27, "SRCCLKREQB_2"), - PINCTRL_PIN(28, "SRCCLKREQB_3"), - PINCTRL_PIN(29, "SRCCLKREQB_4"), - PINCTRL_PIN(30, "SRCCLKREQB_5"), - PINCTRL_PIN(31, "PMCALERTB"), - PINCTRL_PIN(32, "SLP_S0B"), - PINCTRL_PIN(33, "PLTRSTB"), - PINCTRL_PIN(34, "SPKR"), - PINCTRL_PIN(35, "GSPI0_CS0B"), - PINCTRL_PIN(36, "GSPI0_CLK"), - PINCTRL_PIN(37, "GSPI0_MISO"), - PINCTRL_PIN(38, "GSPI0_MOSI"), - PINCTRL_PIN(39, "GSPI1_CS0B"), - PINCTRL_PIN(40, "GSPI1_CLK"), - PINCTRL_PIN(41, "GSPI1_MISO"), - PINCTRL_PIN(42, "GSPI1_MOSI"), - PINCTRL_PIN(43, "DDSP_HPD_A"), - PINCTRL_PIN(44, "GSPI0_CLK_LOOPBK"), - PINCTRL_PIN(45, "GSPI1_CLK_LOOPBK"), + PINCTRL_PIN(29, "CORE_VID_0"), + PINCTRL_PIN(30, "CORE_VID_1"), + PINCTRL_PIN(31, "VRALERTB"), + PINCTRL_PIN(32, "CPU_GP_2"), + PINCTRL_PIN(33, "CPU_GP_3"), + PINCTRL_PIN(34, "SRCCLKREQB_0"), + PINCTRL_PIN(35, "SRCCLKREQB_1"), + PINCTRL_PIN(36, "SRCCLKREQB_2"), + PINCTRL_PIN(37, "SRCCLKREQB_3"), + PINCTRL_PIN(38, "SRCCLKREQB_4"), + PINCTRL_PIN(39, "SRCCLKREQB_5"), + PINCTRL_PIN(40, "PMCALERTB"), + PINCTRL_PIN(41, "SLP_S0B"), + PINCTRL_PIN(42, "PLTRSTB"), + PINCTRL_PIN(43, "SPKR"), + PINCTRL_PIN(44, "GSPI0_CS0B"), + PINCTRL_PIN(45, "GSPI0_CLK"), + PINCTRL_PIN(46, "GSPI0_MISO"), + PINCTRL_PIN(47, "GSPI0_MOSI"), + PINCTRL_PIN(48, "GSPI1_CS0B"), + PINCTRL_PIN(49, "GSPI1_CLK"), + PINCTRL_PIN(50, "GSPI1_MISO"), + PINCTRL_PIN(51, "GSPI1_MOSI"), + PINCTRL_PIN(52, "DDSP_HPD_A"), + PINCTRL_PIN(53, "GSPI0_CLK_LOOPBK"), + PINCTRL_PIN(54, "GSPI1_CLK_LOOPBK"), /* GPP_A */ - PINCTRL_PIN(46, "ESPI_IO_0"), - PINCTRL_PIN(47, "ESPI_IO_1"), - PINCTRL_PIN(48, "ESPI_IO_2"), - PINCTRL_PIN(49, "ESPI_IO_3"), - PINCTRL_PIN(50, "ESPI_CSB"), - PINCTRL_PIN(51, "ESPI_CLK"), - PINCTRL_PIN(52, "ESPI_RESETB"), - PINCTRL_PIN(53, "SMBCLK"), - PINCTRL_PIN(54, "SMBDATA"), - PINCTRL_PIN(55, "SMBALERTB"), - PINCTRL_PIN(56, "CPU_GP_0"), - PINCTRL_PIN(57, "CPU_GP_1"), - PINCTRL_PIN(58, "USB2_OCB_1"), - PINCTRL_PIN(59, "USB2_OCB_2"), - PINCTRL_PIN(60, "USB2_OCB_3"), - PINCTRL_PIN(61, "DDSP_HPD_A_TIME_SYNC_0"), - PINCTRL_PIN(62, "DDSP_HPD_B"), - PINCTRL_PIN(63, "DDSP_HPD_C"), - PINCTRL_PIN(64, "USB2_OCB_0"), - PINCTRL_PIN(65, "PCHHOTB"), - PINCTRL_PIN(66, "ESPI_CLK_LOOPBK"), + PINCTRL_PIN(55, "ESPI_IO_0"), + PINCTRL_PIN(56, "ESPI_IO_1"), + PINCTRL_PIN(57, "ESPI_IO_2"), + PINCTRL_PIN(58, "ESPI_IO_3"), + PINCTRL_PIN(59, "ESPI_CSB"), + PINCTRL_PIN(60, "ESPI_CLK"), + PINCTRL_PIN(61, "ESPI_RESETB"), + PINCTRL_PIN(62, "SMBCLK"), + PINCTRL_PIN(63, "SMBDATA"), + PINCTRL_PIN(64, "SMBALERTB"), + PINCTRL_PIN(65, "CPU_GP_0"), + PINCTRL_PIN(66, "CPU_GP_1"), + PINCTRL_PIN(67, "USB2_OCB_1"), + PINCTRL_PIN(68, "USB2_OCB_2"), + PINCTRL_PIN(69, "USB2_OCB_3"), + PINCTRL_PIN(70, "DDSP_HPD_A_TIME_SYNC_0"), + PINCTRL_PIN(71, "DDSP_HPD_B"), + PINCTRL_PIN(72, "DDSP_HPD_C"), + PINCTRL_PIN(73, "USB2_OCB_0"), + PINCTRL_PIN(74, "PCHHOTB"), + PINCTRL_PIN(75, "ESPI_CLK_LOOPBK"), /* GPP_S */ - PINCTRL_PIN(67, "SNDW1_CLK"), - PINCTRL_PIN(68, "SNDW1_DATA"), - PINCTRL_PIN(69, "SNDW2_CLK"), - PINCTRL_PIN(70, "SNDW2_DATA"), - PINCTRL_PIN(71, "SNDW1_CLK"), - PINCTRL_PIN(72, "SNDW1_DATA"), - PINCTRL_PIN(73, "SNDW4_CLK_DMIC_CLK_0"), - PINCTRL_PIN(74, "SNDW4_DATA_DMIC_DATA_0"), + PINCTRL_PIN(76, "SNDW1_CLK"), + PINCTRL_PIN(77, "SNDW1_DATA"), + PINCTRL_PIN(78, "SNDW2_CLK"), + PINCTRL_PIN(79, "SNDW2_DATA"), + PINCTRL_PIN(80, "SNDW1_CLK"), + PINCTRL_PIN(81, "SNDW1_DATA"), + PINCTRL_PIN(82, "SNDW4_CLK_DMIC_CLK_0"), + PINCTRL_PIN(83, "SNDW4_DATA_DMIC_DATA_0"), /* GPP_R */ - PINCTRL_PIN(75, "HDA_BCLK"), - PINCTRL_PIN(76, "HDA_SYNC"), - PINCTRL_PIN(77, "HDA_SDO"), - PINCTRL_PIN(78, "HDA_SDI_0"), - PINCTRL_PIN(79, "HDA_RSTB"), - PINCTRL_PIN(80, "HDA_SDI_1"), - PINCTRL_PIN(81, "I2S1_SFRM"), - PINCTRL_PIN(82, "I2S1_TXD"), + PINCTRL_PIN(84, "HDA_BCLK"), + PINCTRL_PIN(85, "HDA_SYNC"), + PINCTRL_PIN(86, "HDA_SDO"), + PINCTRL_PIN(87, "HDA_SDI_0"), + PINCTRL_PIN(88, "HDA_RSTB"), + PINCTRL_PIN(89, "HDA_SDI_1"), + PINCTRL_PIN(90, "I2S1_SFRM"), + PINCTRL_PIN(91, "I2S1_TXD"), /* GPP_H */ - PINCTRL_PIN(83, "GPPC_H_0"), - PINCTRL_PIN(84, "SD_PWR_EN_B"), - PINCTRL_PIN(85, "MODEM_CLKREQ"), - PINCTRL_PIN(86, "SX_EXIT_HOLDOFFB"), - PINCTRL_PIN(87, "I2C2_SDA"), - PINCTRL_PIN(88, "I2C2_SCL"), - PINCTRL_PIN(89, "I2C3_SDA"), - PINCTRL_PIN(90, "I2C3_SCL"), - PINCTRL_PIN(91, "I2C4_SDA"), - PINCTRL_PIN(92, "I2C4_SCL"), - PINCTRL_PIN(93, "CPU_VCCIO_PWR_GATEB"), - PINCTRL_PIN(94, "I2S2_SCLK"), - PINCTRL_PIN(95, "I2S2_SFRM"), - PINCTRL_PIN(96, "I2S2_TXD"), - PINCTRL_PIN(97, "I2S2_RXD"), - PINCTRL_PIN(98, "I2S1_SCLK"), - PINCTRL_PIN(99, "GPPC_H_16"), - PINCTRL_PIN(100, "GPPC_H_17"), - PINCTRL_PIN(101, "GPPC_H_18"), - PINCTRL_PIN(102, "GPPC_H_19"), - PINCTRL_PIN(103, "GPPC_H_20"), - PINCTRL_PIN(104, "GPPC_H_21"), - PINCTRL_PIN(105, "GPPC_H_22"), - PINCTRL_PIN(106, "GPPC_H_23"), + PINCTRL_PIN(92, "GPPC_H_0"), + PINCTRL_PIN(93, "SD_PWR_EN_B"), + PINCTRL_PIN(94, "MODEM_CLKREQ"), + PINCTRL_PIN(95, "SX_EXIT_HOLDOFFB"), + PINCTRL_PIN(96, "I2C2_SDA"), + PINCTRL_PIN(97, "I2C2_SCL"), + PINCTRL_PIN(98, "I2C3_SDA"), + PINCTRL_PIN(99, "I2C3_SCL"), + PINCTRL_PIN(100, "I2C4_SDA"), + PINCTRL_PIN(101, "I2C4_SCL"), + PINCTRL_PIN(102, "CPU_VCCIO_PWR_GATEB"), + PINCTRL_PIN(103, "I2S2_SCLK"), + PINCTRL_PIN(104, "I2S2_SFRM"), + PINCTRL_PIN(105, "I2S2_TXD"), + PINCTRL_PIN(106, "I2S2_RXD"), + PINCTRL_PIN(107, "I2S1_SCLK"), + PINCTRL_PIN(108, "GPPC_H_16"), + PINCTRL_PIN(109, "GPPC_H_17"), + PINCTRL_PIN(110, "GPPC_H_18"), + PINCTRL_PIN(111, "GPPC_H_19"), + PINCTRL_PIN(112, "GPPC_H_20"), + PINCTRL_PIN(113, "GPPC_H_21"), + PINCTRL_PIN(114, "GPPC_H_22"), + PINCTRL_PIN(115, "GPPC_H_23"), /* GPP_D */ - PINCTRL_PIN(107, "SPI1_CSB"), - PINCTRL_PIN(108, "SPI1_CLK"), - PINCTRL_PIN(109, "SPI1_MISO_IO_1"), - PINCTRL_PIN(110, "SPI1_MOSI_IO_0"), - PINCTRL_PIN(111, "ISH_I2C0_SDA"), - PINCTRL_PIN(112, "ISH_I2C0_SCL"), - PINCTRL_PIN(113, "ISH_I2C1_SDA"), - PINCTRL_PIN(114, "ISH_I2C1_SCL"), - PINCTRL_PIN(115, "ISH_SPI_CSB"), - PINCTRL_PIN(116, "ISH_SPI_CLK"), - PINCTRL_PIN(117, "ISH_SPI_MISO"), - PINCTRL_PIN(118, "ISH_SPI_MOSI"), - PINCTRL_PIN(119, "ISH_UART0_RXD"), - PINCTRL_PIN(120, "ISH_UART0_TXD"), - PINCTRL_PIN(121, "ISH_UART0_RTSB"), - PINCTRL_PIN(122, "ISH_UART0_CTSB"), - PINCTRL_PIN(123, "SPI1_IO_2"), - PINCTRL_PIN(124, "SPI1_IO_3"), - PINCTRL_PIN(125, "I2S_MCLK"), - PINCTRL_PIN(126, "CNV_MFUART2_RXD"), - PINCTRL_PIN(127, "CNV_MFUART2_TXD"), - PINCTRL_PIN(128, "CNV_PA_BLANKING"), - PINCTRL_PIN(129, "I2C5_SDA"), - PINCTRL_PIN(130, "I2C5_SCL"), - PINCTRL_PIN(131, "GSPI2_CLK_LOOPBK"), - PINCTRL_PIN(132, "SPI1_CLK_LOOPBK"), + PINCTRL_PIN(116, "SPI1_CSB"), + PINCTRL_PIN(117, "SPI1_CLK"), + PINCTRL_PIN(118, "SPI1_MISO_IO_1"), + PINCTRL_PIN(119, "SPI1_MOSI_IO_0"), + PINCTRL_PIN(120, "ISH_I2C0_SDA"), + PINCTRL_PIN(121, "ISH_I2C0_SCL"), + PINCTRL_PIN(122, "ISH_I2C1_SDA"), + PINCTRL_PIN(123, "ISH_I2C1_SCL"), + PINCTRL_PIN(124, "ISH_SPI_CSB"), + PINCTRL_PIN(125, "ISH_SPI_CLK"), + PINCTRL_PIN(126, "ISH_SPI_MISO"), + PINCTRL_PIN(127, "ISH_SPI_MOSI"), + PINCTRL_PIN(128, "ISH_UART0_RXD"), + PINCTRL_PIN(129, "ISH_UART0_TXD"), + PINCTRL_PIN(130, "ISH_UART0_RTSB"), + PINCTRL_PIN(131, "ISH_UART0_CTSB"), + PINCTRL_PIN(132, "SPI1_IO_2"), + PINCTRL_PIN(133, "SPI1_IO_3"), + PINCTRL_PIN(134, "I2S_MCLK"), + PINCTRL_PIN(135, "CNV_MFUART2_RXD"), + PINCTRL_PIN(136, "CNV_MFUART2_TXD"), + PINCTRL_PIN(137, "CNV_PA_BLANKING"), + PINCTRL_PIN(138, "I2C5_SDA"), + PINCTRL_PIN(139, "I2C5_SCL"), + PINCTRL_PIN(140, "GSPI2_CLK_LOOPBK"), + PINCTRL_PIN(141, "SPI1_CLK_LOOPBK"), /* vGPIO */ - PINCTRL_PIN(133, "CNV_BTEN"), - PINCTRL_PIN(134, "CNV_WCEN"), - PINCTRL_PIN(135, "CNV_BT_HOST_WAKEB"), - PINCTRL_PIN(136, "CNV_BT_IF_SELECT"), - PINCTRL_PIN(137, "vCNV_BT_UART_TXD"), - PINCTRL_PIN(138, "vCNV_BT_UART_RXD"), - PINCTRL_PIN(139, "vCNV_BT_UART_CTS_B"), - PINCTRL_PIN(140, "vCNV_BT_UART_RTS_B"), - PINCTRL_PIN(141, "vCNV_MFUART1_TXD"), - PINCTRL_PIN(142, "vCNV_MFUART1_RXD"), - PINCTRL_PIN(143, "vCNV_MFUART1_CTS_B"), - PINCTRL_PIN(144, "vCNV_MFUART1_RTS_B"), - PINCTRL_PIN(145, "vUART0_TXD"), - PINCTRL_PIN(146, "vUART0_RXD"), - PINCTRL_PIN(147, "vUART0_CTS_B"), - PINCTRL_PIN(148, "vUART0_RTS_B"), - PINCTRL_PIN(149, "vISH_UART0_TXD"), - PINCTRL_PIN(150, "vISH_UART0_RXD"), - PINCTRL_PIN(151, "vISH_UART0_CTS_B"), - PINCTRL_PIN(152, "vISH_UART0_RTS_B"), - PINCTRL_PIN(153, "vCNV_BT_I2S_BCLK"), - PINCTRL_PIN(154, "vCNV_BT_I2S_WS_SYNC"), - PINCTRL_PIN(155, "vCNV_BT_I2S_SDO"), - PINCTRL_PIN(156, "vCNV_BT_I2S_SDI"), - PINCTRL_PIN(157, "vI2S2_SCLK"), - PINCTRL_PIN(158, "vI2S2_SFRM"), - PINCTRL_PIN(159, "vI2S2_TXD"), - PINCTRL_PIN(160, "vI2S2_RXD"), - PINCTRL_PIN(161, "vSD3_CD_B"), + PINCTRL_PIN(142, "CNV_BTEN"), + PINCTRL_PIN(143, "CNV_WCEN"), + PINCTRL_PIN(144, "CNV_BT_HOST_WAKEB"), + PINCTRL_PIN(145, "CNV_BT_IF_SELECT"), + PINCTRL_PIN(146, "vCNV_BT_UART_TXD"), + PINCTRL_PIN(147, "vCNV_BT_UART_RXD"), + PINCTRL_PIN(148, "vCNV_BT_UART_CTS_B"), + PINCTRL_PIN(149, "vCNV_BT_UART_RTS_B"), + PINCTRL_PIN(150, "vCNV_MFUART1_TXD"), + PINCTRL_PIN(151, "vCNV_MFUART1_RXD"), + PINCTRL_PIN(152, "vCNV_MFUART1_CTS_B"), + PINCTRL_PIN(153, "vCNV_MFUART1_RTS_B"), + PINCTRL_PIN(154, "vUART0_TXD"), + PINCTRL_PIN(155, "vUART0_RXD"), + PINCTRL_PIN(156, "vUART0_CTS_B"), + PINCTRL_PIN(157, "vUART0_RTS_B"), + PINCTRL_PIN(158, "vISH_UART0_TXD"), + PINCTRL_PIN(159, "vISH_UART0_RXD"), + PINCTRL_PIN(160, "vISH_UART0_CTS_B"), + PINCTRL_PIN(161, "vISH_UART0_RTS_B"), + PINCTRL_PIN(162, "vCNV_BT_I2S_BCLK"), + PINCTRL_PIN(163, "vCNV_BT_I2S_WS_SYNC"), + PINCTRL_PIN(164, "vCNV_BT_I2S_SDO"), + PINCTRL_PIN(165, "vCNV_BT_I2S_SDI"), + PINCTRL_PIN(166, "vI2S2_SCLK"), + PINCTRL_PIN(167, "vI2S2_SFRM"), + PINCTRL_PIN(168, "vI2S2_TXD"), + PINCTRL_PIN(169, "vI2S2_RXD"), + PINCTRL_PIN(170, "vSD3_CD_B"), /* GPP_C */ - PINCTRL_PIN(162, "GPPC_C_0"), - PINCTRL_PIN(163, "GPPC_C_1"), - PINCTRL_PIN(164, "GPPC_C_2"), - PINCTRL_PIN(165, "GPPC_C_3"), - PINCTRL_PIN(166, "GPPC_C_4"), - PINCTRL_PIN(167, "GPPC_C_5"), - PINCTRL_PIN(168, "SUSWARNB_SUSPWRDNACK"), - PINCTRL_PIN(169, "SUSACKB"), - PINCTRL_PIN(170, "UART0_RXD"), - PINCTRL_PIN(171, "UART0_TXD"), - PINCTRL_PIN(172, "UART0_RTSB"), - PINCTRL_PIN(173, "UART0_CTSB"), - PINCTRL_PIN(174, "UART1_RXD"), - PINCTRL_PIN(175, "UART1_TXD"), - PINCTRL_PIN(176, "UART1_RTSB"), - PINCTRL_PIN(177, "UART1_CTSB"), - PINCTRL_PIN(178, "I2C0_SDA"), - PINCTRL_PIN(179, "I2C0_SCL"), - PINCTRL_PIN(180, "I2C1_SDA"), - PINCTRL_PIN(181, "I2C1_SCL"), - PINCTRL_PIN(182, "UART2_RXD"), - PINCTRL_PIN(183, "UART2_TXD"), - PINCTRL_PIN(184, "UART2_RTSB"), - PINCTRL_PIN(185, "UART2_CTSB"), + PINCTRL_PIN(171, "GPPC_C_0"), + PINCTRL_PIN(172, "GPPC_C_1"), + PINCTRL_PIN(173, "GPPC_C_2"), + PINCTRL_PIN(174, "GPPC_C_3"), + PINCTRL_PIN(175, "GPPC_C_4"), + PINCTRL_PIN(176, "GPPC_C_5"), + PINCTRL_PIN(177, "SUSWARNB_SUSPWRDNACK"), + PINCTRL_PIN(178, "SUSACKB"), + PINCTRL_PIN(179, "UART0_RXD"), + PINCTRL_PIN(180, "UART0_TXD"), + PINCTRL_PIN(181, "UART0_RTSB"), + PINCTRL_PIN(182, "UART0_CTSB"), + PINCTRL_PIN(183, "UART1_RXD"), + PINCTRL_PIN(184, "UART1_TXD"), + PINCTRL_PIN(185, "UART1_RTSB"), + PINCTRL_PIN(186, "UART1_CTSB"), + PINCTRL_PIN(187, "I2C0_SDA"), + PINCTRL_PIN(188, "I2C0_SCL"), + PINCTRL_PIN(189, "I2C1_SDA"), + PINCTRL_PIN(190, "I2C1_SCL"), + PINCTRL_PIN(191, "UART2_RXD"), + PINCTRL_PIN(192, "UART2_TXD"), + PINCTRL_PIN(193, "UART2_RTSB"), + PINCTRL_PIN(194, "UART2_CTSB"), /* HVCMOS */ - PINCTRL_PIN(186, "L_BKLTEN"), - PINCTRL_PIN(187, "L_BKLTCTL"), - PINCTRL_PIN(188, "L_VDDEN"), - PINCTRL_PIN(189, "SYS_PWROK"), - PINCTRL_PIN(190, "SYS_RESETB"), - PINCTRL_PIN(191, "MLK_RSTB"), + PINCTRL_PIN(195, "L_BKLTEN"), + PINCTRL_PIN(196, "L_BKLTCTL"), + PINCTRL_PIN(197, "L_VDDEN"), + PINCTRL_PIN(198, "SYS_PWROK"), + PINCTRL_PIN(199, "SYS_RESETB"), + PINCTRL_PIN(200, "MLK_RSTB"), /* GPP_E */ - PINCTRL_PIN(192, "ISH_GP_0"), - PINCTRL_PIN(193, "ISH_GP_1"), - PINCTRL_PIN(194, "IMGCLKOUT_1"), - PINCTRL_PIN(195, "ISH_GP_2"), - PINCTRL_PIN(196, "IMGCLKOUT_2"), - PINCTRL_PIN(197, "SATA_LEDB"), - PINCTRL_PIN(198, "IMGCLKOUT_3"), - PINCTRL_PIN(199, "ISH_GP_3"), - PINCTRL_PIN(200, "ISH_GP_4"), - PINCTRL_PIN(201, "ISH_GP_5"), - PINCTRL_PIN(202, "ISH_GP_6"), - PINCTRL_PIN(203, "ISH_GP_7"), - PINCTRL_PIN(204, "IMGCLKOUT_4"), - PINCTRL_PIN(205, "DDPA_CTRLCLK"), - PINCTRL_PIN(206, "DDPA_CTRLDATA"), - PINCTRL_PIN(207, "DDPB_CTRLCLK"), - PINCTRL_PIN(208, "DDPB_CTRLDATA"), - PINCTRL_PIN(209, "DDPC_CTRLCLK"), - PINCTRL_PIN(210, "DDPC_CTRLDATA"), - PINCTRL_PIN(211, "IMGCLKOUT_5"), - PINCTRL_PIN(212, "CNV_BRI_DT"), - PINCTRL_PIN(213, "CNV_BRI_RSP"), - PINCTRL_PIN(214, "CNV_RGI_DT"), - PINCTRL_PIN(215, "CNV_RGI_RSP"), + PINCTRL_PIN(201, "ISH_GP_0"), + PINCTRL_PIN(202, "ISH_GP_1"), + PINCTRL_PIN(203, "IMGCLKOUT_1"), + PINCTRL_PIN(204, "ISH_GP_2"), + PINCTRL_PIN(205, "IMGCLKOUT_2"), + PINCTRL_PIN(206, "SATA_LEDB"), + PINCTRL_PIN(207, "IMGCLKOUT_3"), + PINCTRL_PIN(208, "ISH_GP_3"), + PINCTRL_PIN(209, "ISH_GP_4"), + PINCTRL_PIN(210, "ISH_GP_5"), + PINCTRL_PIN(211, "ISH_GP_6"), + PINCTRL_PIN(212, "ISH_GP_7"), + PINCTRL_PIN(213, "IMGCLKOUT_4"), + PINCTRL_PIN(214, "DDPA_CTRLCLK"), + PINCTRL_PIN(215, "DDPA_CTRLDATA"), + PINCTRL_PIN(216, "DDPB_CTRLCLK"), + PINCTRL_PIN(217, "DDPB_CTRLDATA"), + PINCTRL_PIN(218, "DDPC_CTRLCLK"), + PINCTRL_PIN(219, "DDPC_CTRLDATA"), + PINCTRL_PIN(220, "IMGCLKOUT_5"), + PINCTRL_PIN(221, "CNV_BRI_DT"), + PINCTRL_PIN(222, "CNV_BRI_RSP"), + PINCTRL_PIN(223, "CNV_RGI_DT"), + PINCTRL_PIN(224, "CNV_RGI_RSP"), /* GPP_G */ - PINCTRL_PIN(216, "SD3_CMD"), - PINCTRL_PIN(217, "SD3_D0"), - PINCTRL_PIN(218, "SD3_D1"), - PINCTRL_PIN(219, "SD3_D2"), - PINCTRL_PIN(220, "SD3_D3"), - PINCTRL_PIN(221, "SD3_CDB"), - PINCTRL_PIN(222, "SD3_CLK"), - PINCTRL_PIN(223, "SD3_WP"), + PINCTRL_PIN(225, "SD3_CMD"), + PINCTRL_PIN(226, "SD3_D0"), + PINCTRL_PIN(227, "SD3_D1"), + PINCTRL_PIN(228, "SD3_D2"), + PINCTRL_PIN(229, "SD3_D3"), + PINCTRL_PIN(230, "SD3_CDB"), + PINCTRL_PIN(231, "SD3_CLK"), + PINCTRL_PIN(232, "SD3_WP"), }; static const struct intel_padgroup jsl_community0_gpps[] = { JSL_GPP(0, 0, 19, 320), /* GPP_F */ - JSL_GPP(1, 20, 45, 32), /* GPP_B */ - JSL_GPP(2, 46, 66, 64), /* GPP_A */ - JSL_GPP(3, 67, 74, 96), /* GPP_S */ - JSL_GPP(4, 75, 82, 128), /* GPP_R */ + JSL_GPP(1, 20, 28, INTEL_GPIO_BASE_NOMAP), /* SPI */ + JSL_GPP(2, 29, 54, 32), /* GPP_B */ + JSL_GPP(3, 55, 75, 64), /* GPP_A */ + JSL_GPP(4, 76, 83, 96), /* GPP_S */ + JSL_GPP(5, 84, 91, 128), /* GPP_R */ }; static const struct intel_padgroup jsl_community1_gpps[] = { - JSL_GPP(0, 83, 106, 160), /* GPP_H */ - JSL_GPP(1, 107, 132, 192), /* GPP_D */ - JSL_GPP(2, 133, 161, 224), /* vGPIO */ - JSL_GPP(3, 162, 185, 256), /* GPP_C */ + JSL_GPP(0, 92, 115, 160), /* GPP_H */ + JSL_GPP(1, 116, 141, 192), /* GPP_D */ + JSL_GPP(2, 142, 170, 224), /* vGPIO */ + JSL_GPP(3, 171, 194, 256), /* GPP_C */ }; static const struct intel_padgroup jsl_community4_gpps[] = { - JSL_GPP(0, 186, 191, INTEL_GPIO_BASE_NOMAP), /* HVCMOS */ - JSL_GPP(1, 192, 215, 288), /* GPP_E */ + JSL_GPP(0, 195, 200, INTEL_GPIO_BASE_NOMAP), /* HVCMOS */ + JSL_GPP(1, 201, 224, 288), /* GPP_E */ }; static const struct intel_padgroup jsl_community5_gpps[] = { - JSL_GPP(0, 216, 223, INTEL_GPIO_BASE_ZERO), /* GPP_G */ + JSL_GPP(0, 225, 232, INTEL_GPIO_BASE_ZERO), /* GPP_G */ }; static const struct intel_community jsl_communities[] = { - JSL_COMMUNITY(0, 0, 82, jsl_community0_gpps), - JSL_COMMUNITY(1, 83, 185, jsl_community1_gpps), - JSL_COMMUNITY(2, 186, 215, jsl_community4_gpps), - JSL_COMMUNITY(3, 216, 223, jsl_community5_gpps), + JSL_COMMUNITY(0, 0, 91, jsl_community0_gpps), + JSL_COMMUNITY(1, 92, 194, jsl_community1_gpps), + JSL_COMMUNITY(2, 195, 224, jsl_community4_gpps), + JSL_COMMUNITY(3, 225, 232, jsl_community5_gpps), }; static const struct intel_pinctrl_soc_data jsl_soc_data = { @@ -336,7 +347,6 @@ static struct platform_driver jsl_pinctrl_driver = { .pm = &jsl_pinctrl_pm_ops, }, }; - module_platform_driver(jsl_pinctrl_driver); MODULE_AUTHOR("Andy Shevchenko "); From cdd8fc2dd64e3f1b22a6636e242d0eff49c4ba22 Mon Sep 17 00:00:00 2001 From: Evan Green Date: Wed, 11 Nov 2020 15:17:28 -0800 Subject: [PATCH 02/59] pinctrl: jasperlake: Fix HOSTSW_OWN offset GPIOs that attempt to use interrupts get thwarted with a message like: "pin 161 cannot be used as IRQ" (for instance with SD_CD). This is because the HOSTSW_OWN offset is incorrect, so every GPIO looks like it's owned by ACPI. Fixes: e278dcb7048b1 ("pinctrl: intel: Add Intel Jasper Lake pin controller support") Cc: stable@vger.kernel.org Signed-off-by: Evan Green Acked-by: Mika Westerberg Signed-off-by: Andy Shevchenko --- drivers/pinctrl/intel/pinctrl-jasperlake.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pinctrl/intel/pinctrl-jasperlake.c b/drivers/pinctrl/intel/pinctrl-jasperlake.c index c5e204c8da9c..ec435b7ab392 100644 --- a/drivers/pinctrl/intel/pinctrl-jasperlake.c +++ b/drivers/pinctrl/intel/pinctrl-jasperlake.c @@ -16,7 +16,7 @@ #define JSL_PAD_OWN 0x020 #define JSL_PADCFGLOCK 0x080 -#define JSL_HOSTSW_OWN 0x0b0 +#define JSL_HOSTSW_OWN 0x0c0 #define JSL_GPI_IS 0x100 #define JSL_GPI_IE 0x120 From 03a61f11c00213394e3c7ac62ae416d034dc728f Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Wed, 11 Nov 2020 14:06:05 +0200 Subject: [PATCH 03/59] pinctrl: merrifield: Set default bias in case no particular value given When GPIO library asks pin control to set the bias, it doesn't pass any value of it and argument is considered boolean (and this is true for ACPI GpioIo() / GpioInt() resources, by the way). Thus, individual drivers must behave well, when they got the resistance value of 1 Ohm, i.e. transforming it to sane default. In case of Intel Merrifield pin control hardware the 20 kOhm sounds plausible because it gives a good trade off between weakness and minimization of leakage current (will be only 50 uA with the above choice). Fixes: 4e80c8f50574 ("pinctrl: intel: Add Intel Merrifield pin controller support") Depends-on: 2956b5d94a76 ("pinctrl / gpio: Introduce .set_config() callback for GPIO chips") Signed-off-by: Andy Shevchenko Acked-by: Mika Westerberg --- drivers/pinctrl/intel/pinctrl-merrifield.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/pinctrl/intel/pinctrl-merrifield.c b/drivers/pinctrl/intel/pinctrl-merrifield.c index e4ff8da1b894..3ae141e0b421 100644 --- a/drivers/pinctrl/intel/pinctrl-merrifield.c +++ b/drivers/pinctrl/intel/pinctrl-merrifield.c @@ -745,6 +745,10 @@ static int mrfld_config_set_pin(struct mrfld_pinctrl *mp, unsigned int pin, mask |= BUFCFG_Px_EN_MASK | BUFCFG_PUPD_VAL_MASK; bits |= BUFCFG_PU_EN; + /* Set default strength value in case none is given */ + if (arg == 1) + arg = 20000; + switch (arg) { case 50000: bits |= BUFCFG_PUPD_VAL_50K << BUFCFG_PUPD_VAL_SHIFT; @@ -765,6 +769,10 @@ static int mrfld_config_set_pin(struct mrfld_pinctrl *mp, unsigned int pin, mask |= BUFCFG_Px_EN_MASK | BUFCFG_PUPD_VAL_MASK; bits |= BUFCFG_PD_EN; + /* Set default strength value in case none is given */ + if (arg == 1) + arg = 20000; + switch (arg) { case 50000: bits |= BUFCFG_PUPD_VAL_50K << BUFCFG_PUPD_VAL_SHIFT; From 5f714771d01e0e0d410f06d4d192fb27b1ca0edd Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Thu, 12 Nov 2020 21:03:01 +0200 Subject: [PATCH 04/59] pinctrl: baytrail: Avoid clearing debounce value when turning it off Baytrail pin control has a common register to set up debounce timeout. When a pin configuration requested debounce to be disabled, the rest of the pins may still want to have debounce enabled and thus rely on the common timeout value. Avoid clearing debounce value when turning it off for one pin while others may still use it. Fixes: 658b476c742f ("pinctrl: baytrail: Add debounce configuration") Depends-on: 04ff5a095d66 ("pinctrl: baytrail: Rectify debounce support") Depends-on: 827e1579e1d5 ("pinctrl: baytrail: Rectify debounce support (part 2)") Signed-off-by: Andy Shevchenko Acked-by: Mika Westerberg --- drivers/pinctrl/intel/pinctrl-baytrail.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/pinctrl/intel/pinctrl-baytrail.c b/drivers/pinctrl/intel/pinctrl-baytrail.c index d49aab3cfbaa..394a421a19d5 100644 --- a/drivers/pinctrl/intel/pinctrl-baytrail.c +++ b/drivers/pinctrl/intel/pinctrl-baytrail.c @@ -1049,7 +1049,6 @@ static int byt_pin_config_set(struct pinctrl_dev *pctl_dev, break; case PIN_CONFIG_INPUT_DEBOUNCE: debounce = readl(db_reg); - debounce &= ~BYT_DEBOUNCE_PULSE_MASK; if (arg) conf |= BYT_DEBOUNCE_EN; @@ -1058,24 +1057,31 @@ static int byt_pin_config_set(struct pinctrl_dev *pctl_dev, switch (arg) { case 375: + debounce &= ~BYT_DEBOUNCE_PULSE_MASK; debounce |= BYT_DEBOUNCE_PULSE_375US; break; case 750: + debounce &= ~BYT_DEBOUNCE_PULSE_MASK; debounce |= BYT_DEBOUNCE_PULSE_750US; break; case 1500: + debounce &= ~BYT_DEBOUNCE_PULSE_MASK; debounce |= BYT_DEBOUNCE_PULSE_1500US; break; case 3000: + debounce &= ~BYT_DEBOUNCE_PULSE_MASK; debounce |= BYT_DEBOUNCE_PULSE_3MS; break; case 6000: + debounce &= ~BYT_DEBOUNCE_PULSE_MASK; debounce |= BYT_DEBOUNCE_PULSE_6MS; break; case 12000: + debounce &= ~BYT_DEBOUNCE_PULSE_MASK; debounce |= BYT_DEBOUNCE_PULSE_12MS; break; case 24000: + debounce &= ~BYT_DEBOUNCE_PULSE_MASK; debounce |= BYT_DEBOUNCE_PULSE_24MS; break; default: From c0a2074ac575fff2848c8ef804bdc8590466c36c Mon Sep 17 00:00:00 2001 From: Wenbin Mei Date: Wed, 18 Nov 2020 14:34:05 +0800 Subject: [PATCH 05/59] mmc: mediatek: Fix system suspend/resume support for CQHCI Before we got these errors on MT8192 platform: [ 59.153891] Restarting tasks ... [ 59.154540] done. [ 59.159175] PM: suspend exit [ 59.218724] mtk-msdc 11f60000.mmc: phase: [map:fffffffe] [maxlen:31] [final:16] [ 119.776083] mmc0: cqhci: timeout for tag 9 [ 119.780196] mmc0: cqhci: ============ CQHCI REGISTER DUMP =========== [ 119.786709] mmc0: cqhci: Caps: 0x100020b6 | Version: 0x00000510 [ 119.793225] mmc0: cqhci: Config: 0x00000101 | Control: 0x00000000 [ 119.799706] mmc0: cqhci: Int stat: 0x00000000 | Int enab: 0x00000000 [ 119.806177] mmc0: cqhci: Int sig: 0x00000000 | Int Coal: 0x00000000 [ 119.812670] mmc0: cqhci: TDL base: 0x00000000 | TDL up32: 0x00000000 [ 119.819149] mmc0: cqhci: Doorbell: 0x003ffc00 | TCN: 0x00000200 [ 119.825656] mmc0: cqhci: Dev queue: 0x00000000 | Dev Pend: 0x00000000 [ 119.832155] mmc0: cqhci: Task clr: 0x00000000 | SSC1: 0x00001000 [ 119.838627] mmc0: cqhci: SSC2: 0x00000000 | DCMD rsp: 0x00000000 [ 119.845174] mmc0: cqhci: RED mask: 0xfdf9a080 | TERRI: 0x0000891c [ 119.851654] mmc0: cqhci: Resp idx: 0x00000000 | Resp arg: 0x00000000 [ 119.865773] mmc0: cqhci: : =========================================== [ 119.872358] mmc0: running CQE recovery From these logs, we found TDL base was back to the default value. After suspend, the mmc host is powered off by HW, and bring CQE register to the default value, so we add system suspend/resume interface, then bring CQE to deactivated state before suspend, it will be enabled by CQE first request after resume. Signed-off-by: Wenbin Mei Link: https://lore.kernel.org/r/20201118063405.24906-1-wenbin.mei@mediatek.com Fixes: 88bd652b3c74 ("mmc: mediatek: command queue support") Cc: stable@vger.kernel.org [Ulf: Renamed functions] Signed-off-by: Ulf Hansson --- drivers/mmc/host/mtk-sd.c | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c index a704745e5882..b40ec966288e 100644 --- a/drivers/mmc/host/mtk-sd.c +++ b/drivers/mmc/host/mtk-sd.c @@ -2681,11 +2681,29 @@ static int msdc_runtime_resume(struct device *dev) msdc_restore_reg(host); return 0; } + +static int msdc_suspend(struct device *dev) +{ + struct mmc_host *mmc = dev_get_drvdata(dev); + int ret; + + if (mmc->caps2 & MMC_CAP2_CQE) { + ret = cqhci_suspend(mmc); + if (ret) + return ret; + } + + return pm_runtime_force_suspend(dev); +} + +static int msdc_resume(struct device *dev) +{ + return pm_runtime_force_resume(dev); +} #endif static const struct dev_pm_ops msdc_dev_pm_ops = { - SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, - pm_runtime_force_resume) + SET_SYSTEM_SLEEP_PM_OPS(msdc_suspend, msdc_resume) SET_RUNTIME_PM_OPS(msdc_runtime_suspend, msdc_runtime_resume, NULL) }; From 903a72eca4abf241293dcc1385896fd428e15fe9 Mon Sep 17 00:00:00 2001 From: yong mao Date: Thu, 19 Nov 2020 11:02:37 +0800 Subject: [PATCH 06/59] mmc: mediatek: Extend recheck_sdio_irq fix to more variants The SDIO recheck fix is required for more of the supported variants. Let's add it to those that needs it. Reported-by: Fabien Parent Reported-by: Mattijs Korpershoek Signed-off-by: Yong Mao Link: https://lore.kernel.org/r/20201119030237.9414-1-yong.mao@mediatek.com Fixes: 9e2582e57407 ("mmc: mediatek: fix SDIO irq issue") Cc: stable@vger.kernel.org [Ulf: Clarified commitmsg ] Signed-off-by: Ulf Hansson --- drivers/mmc/host/mtk-sd.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c index b40ec966288e..7eb99255ae3d 100644 --- a/drivers/mmc/host/mtk-sd.c +++ b/drivers/mmc/host/mtk-sd.c @@ -446,7 +446,7 @@ struct msdc_host { static const struct mtk_mmc_compatible mt8135_compat = { .clk_div_bits = 8, - .recheck_sdio_irq = false, + .recheck_sdio_irq = true, .hs400_tune = false, .pad_tune_reg = MSDC_PAD_TUNE, .async_fifo = false, @@ -485,7 +485,7 @@ static const struct mtk_mmc_compatible mt8183_compat = { static const struct mtk_mmc_compatible mt2701_compat = { .clk_div_bits = 12, - .recheck_sdio_irq = false, + .recheck_sdio_irq = true, .hs400_tune = false, .pad_tune_reg = MSDC_PAD_TUNE0, .async_fifo = true, @@ -511,7 +511,7 @@ static const struct mtk_mmc_compatible mt2712_compat = { static const struct mtk_mmc_compatible mt7622_compat = { .clk_div_bits = 12, - .recheck_sdio_irq = false, + .recheck_sdio_irq = true, .hs400_tune = false, .pad_tune_reg = MSDC_PAD_TUNE0, .async_fifo = true, @@ -524,7 +524,7 @@ static const struct mtk_mmc_compatible mt7622_compat = { static const struct mtk_mmc_compatible mt8516_compat = { .clk_div_bits = 12, - .recheck_sdio_irq = false, + .recheck_sdio_irq = true, .hs400_tune = false, .pad_tune_reg = MSDC_PAD_TUNE0, .async_fifo = true, @@ -535,7 +535,7 @@ static const struct mtk_mmc_compatible mt8516_compat = { static const struct mtk_mmc_compatible mt7620_compat = { .clk_div_bits = 8, - .recheck_sdio_irq = false, + .recheck_sdio_irq = true, .hs400_tune = false, .pad_tune_reg = MSDC_PAD_TUNE, .async_fifo = false, @@ -548,6 +548,7 @@ static const struct mtk_mmc_compatible mt7620_compat = { static const struct mtk_mmc_compatible mt6779_compat = { .clk_div_bits = 12, + .recheck_sdio_irq = false, .hs400_tune = false, .pad_tune_reg = MSDC_PAD_TUNE0, .async_fifo = true, From a42a7ec9bb99a17869c3b9f3d365aaf2bdb1a554 Mon Sep 17 00:00:00 2001 From: Muhammad Husaini Zulkifli Date: Wed, 18 Nov 2020 20:01:20 +0800 Subject: [PATCH 07/59] mmc: sdhci-of-arasan: Fix clock registration error for Keem Bay SOC The commit 16ada730a759 ("mmc: sdhci-of-arasan: Modify clock operations handling") introduced support for platform specific clock operations. Around the same point in time the commit 36c6aadaae86 ("mmc: sdhci-of-arasan: Add support for Intel Keem Bay") was also merged. Unfortunate it was not really tested on top of the previously mentioned commit, which causes clock registration failures for Keem Bay SOC devices. Let's fix this, by properly declaring the clock operation for Keem Bay SOC devices. Fixes: 36c6aadaae86 ("mmc: sdhci-of-arasan: Add support for Intel Keem Bay") Signed-off-by: Muhammad Husaini Zulkifli Reviewed-by: Adrian Hunter Link: https://lore.kernel.org/r/20201118120120.24908-2-muhammad.husaini.zulkifli@intel.com Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson --- drivers/mmc/host/sdhci-of-arasan.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c index d25a4b50c2f3..3b8d456e857d 100644 --- a/drivers/mmc/host/sdhci-of-arasan.c +++ b/drivers/mmc/host/sdhci-of-arasan.c @@ -1186,16 +1186,19 @@ static struct sdhci_arasan_of_data sdhci_arasan_versal_data = { static struct sdhci_arasan_of_data intel_keembay_emmc_data = { .soc_ctl_map = &intel_keembay_soc_ctl_map, .pdata = &sdhci_keembay_emmc_pdata, + .clk_ops = &arasan_clk_ops, }; static struct sdhci_arasan_of_data intel_keembay_sd_data = { .soc_ctl_map = &intel_keembay_soc_ctl_map, .pdata = &sdhci_keembay_sd_pdata, + .clk_ops = &arasan_clk_ops, }; static struct sdhci_arasan_of_data intel_keembay_sdio_data = { .soc_ctl_map = &intel_keembay_soc_ctl_map, .pdata = &sdhci_keembay_sdio_pdata, + .clk_ops = &arasan_clk_ops, }; static const struct of_device_id sdhci_arasan_of_match[] = { From 0ac22098de6f9fd460ac1b1cbf6dbd324312161c Mon Sep 17 00:00:00 2001 From: Zheng Liang Date: Tue, 24 Nov 2020 11:06:06 +0800 Subject: [PATCH 08/59] gpio: arizona: disable pm_runtime in case of failure pm_runtime_enable will increase power disable depth. Thus a pairing decrement is needed on the error handling path to keep it balanced. Fixes:27a49ed17e224(gpio: arizona: Add support for GPIOs that) Reported-by: Hulk Robot Signed-off-by: Zheng Liang Signed-off-by: Bartosz Golaszewski --- drivers/gpio/gpio-arizona.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpio/gpio-arizona.c b/drivers/gpio/gpio-arizona.c index 5bda38e0780f..2bc173c352ce 100644 --- a/drivers/gpio/gpio-arizona.c +++ b/drivers/gpio/gpio-arizona.c @@ -192,6 +192,7 @@ static int arizona_gpio_probe(struct platform_device *pdev) ret = devm_gpiochip_add_data(&pdev->dev, &arizona_gpio->gpio_chip, arizona_gpio); if (ret < 0) { + pm_runtime_disable(&pdev->dev); dev_err(&pdev->dev, "Could not register gpiochip, %d\n", ret); return ret; From 60593df667e087b009ee0fc20d92e9c4c096a9b5 Mon Sep 17 00:00:00 2001 From: Luo Jiaxing Date: Fri, 27 Nov 2020 16:50:02 +0800 Subject: [PATCH 09/59] gpio: dwapb: fix NULL pointer dereference at dwapb_gpio_suspend() Following Calltrace is found when running echo freeze > /sys/power/state. [ 272.755506] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 [ 272.755585] Call trace: [ 272.755587] dwapb_gpio_suspend+0x18/0x318 [ 272.755588] pm_generic_suspend+0x2c/0x48 [ 272.755595] acpi_subsys_suspend+0x60/0x70 [ 272.755599] dpm_run_callback.isra.18+0x40/0xe0 [ 272.755601] __device_suspend+0xf4/0x360 The reason is platform_set_drvdata() is deleted, and dwapb_gpio_suspend() get *gpio by dev_get_drvdata(). Fixes: feeaefd378ca ("gpio: dwapb: Use resource managed GPIO-chip add data method") Signed-off-by: Luo Jiaxing Acked-by: Serge Semin Reviewed-by: Andy Shevchenko Signed-off-by: Bartosz Golaszewski --- drivers/gpio/gpio-dwapb.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c index 2a9046c0fb16..4275c18a097a 100644 --- a/drivers/gpio/gpio-dwapb.c +++ b/drivers/gpio/gpio-dwapb.c @@ -724,6 +724,8 @@ static int dwapb_gpio_probe(struct platform_device *pdev) return err; } + platform_set_drvdata(pdev, gpio); + return 0; } From 6dbbf84603961d4e8eaea46e3530373c8cffee67 Mon Sep 17 00:00:00 2001 From: Edmond Chung Date: Mon, 30 Nov 2020 22:47:53 +0000 Subject: [PATCH 10/59] gpiolib: Don't free if pin ranges are not defined A similar check was added in gpiochip_generic_request, but not in free. This has caused an imbalance count of request vs. free calls to the pinctrl driver. This patch is targeted to fix that issue. Fixes: 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges") Signed-off-by: Edmond Chung Signed-off-by: Andrew Chant Signed-off-by: Will McVicker Signed-off-by: Bartosz Golaszewski --- drivers/gpio/gpiolib.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index 089ddcaa9bc6..6e3c4d7a7d14 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -1806,6 +1806,11 @@ EXPORT_SYMBOL_GPL(gpiochip_generic_request); */ void gpiochip_generic_free(struct gpio_chip *gc, unsigned offset) { +#ifdef CONFIG_PINCTRL + if (list_empty(&gc->gpiodev->pin_ranges)) + return; +#endif + pinctrl_gpio_free(gc->gpiodev->base + offset); } EXPORT_SYMBOL_GPL(gpiochip_generic_free); From 7f57b295f990c0fa07f96d51ca1c82c52dbf79cc Mon Sep 17 00:00:00 2001 From: Qinglang Miao Date: Fri, 27 Nov 2020 17:44:45 +0800 Subject: [PATCH 11/59] gpio: zynq: fix reference leak in zynq_gpio functions pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in a reference leak here. A new function pm_runtime_resume_and_get is introduced in [0] to keep usage counter balanced. So We fix the reference leak by replacing it with new funtion. [0] dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter") Fixes: c2df3de0d07e ("gpio: zynq: properly support runtime PM for GPIO used as interrupts") Reported-by: Hulk Robot Signed-off-by: Qinglang Miao Signed-off-by: Bartosz Golaszewski --- drivers/gpio/gpio-zynq.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpio/gpio-zynq.c b/drivers/gpio/gpio-zynq.c index 0b5a17ab996f..3521c1dc3ac0 100644 --- a/drivers/gpio/gpio-zynq.c +++ b/drivers/gpio/gpio-zynq.c @@ -574,7 +574,7 @@ static int zynq_gpio_irq_reqres(struct irq_data *d) struct gpio_chip *chip = irq_data_get_irq_chip_data(d); int ret; - ret = pm_runtime_get_sync(chip->parent); + ret = pm_runtime_resume_and_get(chip->parent); if (ret < 0) return ret; @@ -942,7 +942,7 @@ static int zynq_gpio_probe(struct platform_device *pdev) pm_runtime_set_active(&pdev->dev); pm_runtime_enable(&pdev->dev); - ret = pm_runtime_get_sync(&pdev->dev); + ret = pm_runtime_resume_and_get(&pdev->dev); if (ret < 0) goto err_pm_dis; From 7ee1a01e47403f72b9f38839a737692f6991263e Mon Sep 17 00:00:00 2001 From: Baruch Siach Date: Wed, 2 Dec 2020 09:15:32 +0200 Subject: [PATCH 12/59] gpio: mvebu: fix potential user-after-free on probe When mvebu_pwm_probe() fails IRQ domain is not released. Move pwm probe before IRQ domain allocation. Add pwm cleanup code to the failure path. Fixes: 757642f9a584 ("gpio: mvebu: Add limited PWM support") Reported-by: Andrew Lunn Signed-off-by: Baruch Siach Signed-off-by: Bartosz Golaszewski --- drivers/gpio/gpio-mvebu.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c index 433e2c3f3fd5..2f245594a90a 100644 --- a/drivers/gpio/gpio-mvebu.c +++ b/drivers/gpio/gpio-mvebu.c @@ -1197,6 +1197,13 @@ static int mvebu_gpio_probe(struct platform_device *pdev) devm_gpiochip_add_data(&pdev->dev, &mvchip->chip, mvchip); + /* Some MVEBU SoCs have simple PWM support for GPIO lines */ + if (IS_ENABLED(CONFIG_PWM)) { + err = mvebu_pwm_probe(pdev, mvchip, id); + if (err) + return err; + } + /* Some gpio controllers do not provide irq support */ if (!have_irqs) return 0; @@ -1206,7 +1213,8 @@ static int mvebu_gpio_probe(struct platform_device *pdev) if (!mvchip->domain) { dev_err(&pdev->dev, "couldn't allocate irq domain %s (DT).\n", mvchip->chip.label); - return -ENODEV; + err = -ENODEV; + goto err_pwm; } err = irq_alloc_domain_generic_chips( @@ -1254,14 +1262,12 @@ static int mvebu_gpio_probe(struct platform_device *pdev) mvchip); } - /* Some MVEBU SoCs have simple PWM support for GPIO lines */ - if (IS_ENABLED(CONFIG_PWM)) - return mvebu_pwm_probe(pdev, mvchip, id); - return 0; err_domain: irq_domain_remove(mvchip->domain); +err_pwm: + pwmchip_remove(&mvchip->mvpwm->chip); return err; } From 47a0001436352c9853d72bf2071e85b316d688a2 Mon Sep 17 00:00:00 2001 From: Coiby Xu Date: Wed, 25 Nov 2020 21:03:19 +0800 Subject: [PATCH 13/59] pinctrl: amd: remove debounce filter setting in IRQ type setting Debounce filter setting should be independent from IRQ type setting because according to the ACPI specs, there are separate arguments for specifying debounce timeout and IRQ type in GpioIo() and GpioInt(). Together with commit 06abe8291bc31839950f7d0362d9979edc88a666 ("pinctrl: amd: fix incorrect way to disable debounce filter") and Andy's patch "gpiolib: acpi: Take into account debounce settings" [1], this will fix broken touchpads for laptops whose BIOS set the debounce timeout to a relatively large value. For example, the BIOS of Lenovo AMD gaming laptops including Legion-5 15ARH05 (R7000), Legion-5P (R7000P) and IdeaPad Gaming 3 15ARH05, set the debounce timeout to 124.8ms. This led to the kernel receiving only ~7 HID reports per second from the Synaptics touchpad (MSFT0001:00 06CB:7F28). Existing touchpads like [2][3] are not troubled by this bug because the debounce timeout has been set to 0 by the BIOS before enabling the debounce filter in setting IRQ type. [1] https://lore.kernel.org/linux-gpio/20201111222008.39993-11-andriy.shevchenko@linux.intel.com/ 8dcb7a15a585 ("gpiolib: acpi: Take into account debounce settings") [2] https://github.com/Syniurge/i2c-amd-mp2/issues/11#issuecomment-721331582 [3] https://forum.manjaro.org/t/random-short-touchpad-freezes/30832/28 Signed-off-by: Coiby Xu Reviewed-by: Andy Shevchenko Cc: Hans de Goede Cc: Andy Shevchenko Cc: Benjamin Tissoires Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-gpio/CAHp75VcwiGREBUJ0A06EEw-SyabqYsp%2Bdqs2DpSrhaY-2GVdAA%40mail.gmail.com/ BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1887190 Link: https://lore.kernel.org/r/20201125130320.311059-1-coiby.xu@gmail.com Signed-off-by: Linus Walleij --- drivers/pinctrl/pinctrl-amd.c | 7 ------- 1 file changed, 7 deletions(-) diff --git a/drivers/pinctrl/pinctrl-amd.c b/drivers/pinctrl/pinctrl-amd.c index 4aea3e05e8c6..899c16c17b6d 100644 --- a/drivers/pinctrl/pinctrl-amd.c +++ b/drivers/pinctrl/pinctrl-amd.c @@ -429,7 +429,6 @@ static int amd_gpio_irq_set_type(struct irq_data *d, unsigned int type) pin_reg &= ~BIT(LEVEL_TRIG_OFF); pin_reg &= ~(ACTIVE_LEVEL_MASK << ACTIVE_LEVEL_OFF); pin_reg |= ACTIVE_HIGH << ACTIVE_LEVEL_OFF; - pin_reg |= DB_TYPE_REMOVE_GLITCH << DB_CNTRL_OFF; irq_set_handler_locked(d, handle_edge_irq); break; @@ -437,7 +436,6 @@ static int amd_gpio_irq_set_type(struct irq_data *d, unsigned int type) pin_reg &= ~BIT(LEVEL_TRIG_OFF); pin_reg &= ~(ACTIVE_LEVEL_MASK << ACTIVE_LEVEL_OFF); pin_reg |= ACTIVE_LOW << ACTIVE_LEVEL_OFF; - pin_reg |= DB_TYPE_REMOVE_GLITCH << DB_CNTRL_OFF; irq_set_handler_locked(d, handle_edge_irq); break; @@ -445,7 +443,6 @@ static int amd_gpio_irq_set_type(struct irq_data *d, unsigned int type) pin_reg &= ~BIT(LEVEL_TRIG_OFF); pin_reg &= ~(ACTIVE_LEVEL_MASK << ACTIVE_LEVEL_OFF); pin_reg |= BOTH_EADGE << ACTIVE_LEVEL_OFF; - pin_reg |= DB_TYPE_REMOVE_GLITCH << DB_CNTRL_OFF; irq_set_handler_locked(d, handle_edge_irq); break; @@ -453,8 +450,6 @@ static int amd_gpio_irq_set_type(struct irq_data *d, unsigned int type) pin_reg |= LEVEL_TRIGGER << LEVEL_TRIG_OFF; pin_reg &= ~(ACTIVE_LEVEL_MASK << ACTIVE_LEVEL_OFF); pin_reg |= ACTIVE_HIGH << ACTIVE_LEVEL_OFF; - pin_reg &= ~(DB_CNTRl_MASK << DB_CNTRL_OFF); - pin_reg |= DB_TYPE_PRESERVE_LOW_GLITCH << DB_CNTRL_OFF; irq_set_handler_locked(d, handle_level_irq); break; @@ -462,8 +457,6 @@ static int amd_gpio_irq_set_type(struct irq_data *d, unsigned int type) pin_reg |= LEVEL_TRIGGER << LEVEL_TRIG_OFF; pin_reg &= ~(ACTIVE_LEVEL_MASK << ACTIVE_LEVEL_OFF); pin_reg |= ACTIVE_LOW << ACTIVE_LEVEL_OFF; - pin_reg &= ~(DB_CNTRl_MASK << DB_CNTRL_OFF); - pin_reg |= DB_TYPE_PRESERVE_HIGH_GLITCH << DB_CNTRL_OFF; irq_set_handler_locked(d, handle_level_irq); break; From 32a9e0c445fa5abfd8730461c3ae0be1860bc6b2 Mon Sep 17 00:00:00 2001 From: Wolfram Sang Date: Wed, 25 Nov 2020 21:49:53 +0100 Subject: [PATCH 14/59] mmc: tmio: improve bringing HW to a sane state with MMC_POWER_OFF Further testing of error cases revealed that downgrade is not enough, so we need to reset the SCC which is done by calling the custom reset function. This reset function can distinguish between the various SDHI variants, so protecting the call with MIN_RCAR2 is enough here. Fixes: 24ce2d7b8bea ("mmc: tmio: bring tuning HW to a sane state with MMC_POWER_OFF") Reported-by: Yoshihiro Shimoda Signed-off-by: Wolfram Sang Reviewed-by: Yoshihiro Shimoda Tested-by: Yoshihiro Shimoda Link: https://lore.kernel.org/r/20201125204953.3344-1-wsa+renesas@sang-engineering.com Signed-off-by: Ulf Hansson --- drivers/mmc/host/tmio_mmc_core.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c index cb4149fd12e0..ac4e7874a3f1 100644 --- a/drivers/mmc/host/tmio_mmc_core.c +++ b/drivers/mmc/host/tmio_mmc_core.c @@ -927,9 +927,9 @@ static void tmio_mmc_set_ios(struct mmc_host *mmc, struct mmc_ios *ios) switch (ios->power_mode) { case MMC_POWER_OFF: tmio_mmc_power_off(host); - /* Downgrade ensures a sane state for tuning HW (e.g. SCC) */ - if (host->mmc->ops->hs400_downgrade) - host->mmc->ops->hs400_downgrade(host->mmc); + /* For R-Car Gen2+, we need to reset SDHI specific SCC */ + if (host->pdata->flags & TMIO_MMC_MIN_RCAR2) + host->reset(host); host->set_clock(host, 0); break; case MMC_POWER_UP: From 6246d7c9d15aaff0bc3863f67900c6a6e6be921b Mon Sep 17 00:00:00 2001 From: Bean Huo Date: Wed, 2 Dec 2020 21:23:20 +0100 Subject: [PATCH 15/59] mmc: block: Fixup condition for CMD13 polling for RPMB requests The CMD13 polling is needed for commands with R1B responses. In commit a0d4c7eb71dd ("mmc: block: Add CMD13 polling for MMC IOCTLS with R1B response"), the intent was to introduce this for requests targeted to the RPMB partition. However, the condition to trigger the polling loop became wrong, leading to unnecessary polling. Let's fix the condition to avoid this. Fixes: a0d4c7eb71dd ("mmc: block: Add CMD13 polling for MMC IOCTLS with R1B response") Cc: stable@vger.kernel.org Reported-by: Zhan Liu Signed-off-by: Zhan Liu Signed-off-by: Bean Huo Link: https://lore.kernel.org/r/20201202202320.22165-1-huobean@gmail.com Signed-off-by: Ulf Hansson --- drivers/mmc/core/block.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c index 8d3df0be0355..42e27a298218 100644 --- a/drivers/mmc/core/block.c +++ b/drivers/mmc/core/block.c @@ -580,7 +580,7 @@ static int __mmc_blk_ioctl_cmd(struct mmc_card *card, struct mmc_blk_data *md, memcpy(&(idata->ic.response), cmd.resp, sizeof(cmd.resp)); - if (idata->rpmb || (cmd.flags & MMC_RSP_R1B)) { + if (idata->rpmb || (cmd.flags & MMC_RSP_R1B) == MMC_RSP_R1B) { /* * Ensure RPMB/R1B command has completed by polling CMD13 * "Send Status". From c0d638a03bc5dfdb08fb95d0a79ecada25f40da8 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann Date: Thu, 3 Dec 2020 23:29:16 +0100 Subject: [PATCH 16/59] mmc: mediatek: mark PM functions as __maybe_unused The #ifdef check for the suspend/resume functions is wrong: drivers/mmc/host/mtk-sd.c:2765:12: error: unused function 'msdc_suspend' [-Werror,-Wunused-function] static int msdc_suspend(struct device *dev) drivers/mmc/host/mtk-sd.c:2779:12: error: unused function 'msdc_resume' [-Werror,-Wunused-function] static int msdc_resume(struct device *dev) Remove the #ifdef and mark all four as __maybe_unused to aovid the problem. Fixes: c0a2074ac575 ("mmc: mediatek: Fix system suspend/resume support for CQHCI") Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20201203222922.1067522-1-arnd@kernel.org Signed-off-by: Ulf Hansson --- drivers/mmc/host/mtk-sd.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c index 7eb99255ae3d..004fbfc23672 100644 --- a/drivers/mmc/host/mtk-sd.c +++ b/drivers/mmc/host/mtk-sd.c @@ -2604,7 +2604,6 @@ static int msdc_drv_remove(struct platform_device *pdev) return 0; } -#ifdef CONFIG_PM static void msdc_save_reg(struct msdc_host *host) { u32 tune_reg = host->dev_comp->pad_tune_reg; @@ -2663,7 +2662,7 @@ static void msdc_restore_reg(struct msdc_host *host) __msdc_enable_sdio_irq(host, 1); } -static int msdc_runtime_suspend(struct device *dev) +static int __maybe_unused msdc_runtime_suspend(struct device *dev) { struct mmc_host *mmc = dev_get_drvdata(dev); struct msdc_host *host = mmc_priv(mmc); @@ -2673,7 +2672,7 @@ static int msdc_runtime_suspend(struct device *dev) return 0; } -static int msdc_runtime_resume(struct device *dev) +static int __maybe_unused msdc_runtime_resume(struct device *dev) { struct mmc_host *mmc = dev_get_drvdata(dev); struct msdc_host *host = mmc_priv(mmc); @@ -2683,7 +2682,7 @@ static int msdc_runtime_resume(struct device *dev) return 0; } -static int msdc_suspend(struct device *dev) +static int __maybe_unused msdc_suspend(struct device *dev) { struct mmc_host *mmc = dev_get_drvdata(dev); int ret; @@ -2697,11 +2696,10 @@ static int msdc_suspend(struct device *dev) return pm_runtime_force_suspend(dev); } -static int msdc_resume(struct device *dev) +static int __maybe_unused msdc_resume(struct device *dev) { return pm_runtime_force_resume(dev); } -#endif static const struct dev_pm_ops msdc_dev_pm_ops = { SET_SYSTEM_SLEEP_PM_OPS(msdc_suspend, msdc_resume) From 6247e31b75308c51476e157c9964823aeefbf5dc Mon Sep 17 00:00:00 2001 From: Dong Aisheng Date: Mon, 30 Nov 2020 16:46:24 +0800 Subject: [PATCH 17/59] clk: imx: scu: fix MXC_CLK_SCU module build break This issue can be reproduced by having a kernel config with CONFIG_IMX_MBOX=m and CONFIG_MXC_CLK_SCU=m. It's caused by the Makefile wanting to build clk-scu.o and clk-imx8qxp.o as different targets but that doesn't work (e.g. MXC_CLK_SCU = y while CLK_IMX8QXP = n) "obj-$(CONFIG_MXC_CLK_SCU) += clk-imx-scu.o clk-imx-lpcg-scu.o clk-imx-scu-$(CONFIG_CLK_IMX8QXP) += clk-scu.o clk-imx8qxp.o" Having MXC_CLK_SCU=y/m while CLK_IMX8QXP=n will cause a linker problem like below: LD [M] drivers/clk/imx/clk-imx-scu.o arm-poky-linux-gnueabi-ld: no input files Make MXC_CLK_SCU be un-selectable by users so it can only be selected by the CLK_IMX8QXP option, ensuring the two symbols are built together. Drop COMPILE_TEST too because this option isn't selectable anymore. We can remove it from MXC_CLK_SCU because CLK_IMX8QXP selects MXC_CLK_SCU which already has COMPILE_TEST. Fixes: e0d0d4d86c766 ("clk: imx8qxp: Support building i.MX8QXP clock driver as module") Acked-by: Sebastian Andrzej Siewior Signed-off-by: Dong Aisheng Link: https://lore.kernel.org/r/20201130084624.21113-1-aisheng.dong@nxp.com [sboyd@kernel.org: Rework commit text] Signed-off-by: Stephen Boyd --- drivers/clk/imx/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/clk/imx/Kconfig b/drivers/clk/imx/Kconfig index 3b393cb07295..3061896503f3 100644 --- a/drivers/clk/imx/Kconfig +++ b/drivers/clk/imx/Kconfig @@ -5,8 +5,8 @@ config MXC_CLK depends on ARCH_MXC || COMPILE_TEST config MXC_CLK_SCU - tristate "IMX SCU clock" - depends on ARCH_MXC || COMPILE_TEST + tristate + depends on ARCH_MXC depends on IMX_SCU && HAVE_ARM_SMCCC config CLK_IMX1 From ceabbf94c317c6175dee6e91805fca4a6353745a Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Mon, 30 Nov 2020 09:57:43 +0100 Subject: [PATCH 18/59] clk: renesas: r9a06g032: Drop __packed for portability The R9A06G032 clock driver uses an array of packed structures to reduce kernel size. However, this array contains pointers, which are no longer aligned naturally, and cannot be relocated on PPC64. Hence when compile-testing this driver on PPC64 with CONFIG_RELOCATABLE=y (e.g. PowerPC allyesconfig), the following warnings are produced: WARNING: 136 bad relocations c000000000616be3 R_PPC64_UADDR64 .rodata+0x00000000000cf338 c000000000616bfe R_PPC64_UADDR64 .rodata+0x00000000000cf370 ... Fix this by dropping the __packed attribute from the r9a06g032_clkdesc definition, trading a small size increase for portability. This increases the 156-entry clock table by 1 byte per entry, but due to the compiler generating more efficient code for unpacked accesses, the net size increase is only 76 bytes (gcc 9.3.0 on arm32). Reported-by: Stephen Rothwell Fixes: 4c3d88526eba2143 ("clk: renesas: Renesas R9A06G032 clock driver") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20201130085743.1656317-1-geert+renesas@glider.be Tested-by: Stephen Rothwell # PowerPC allyesconfig build Acked-by: Stephen Boyd Signed-off-by: Stephen Boyd --- drivers/clk/renesas/r9a06g032-clocks.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/renesas/r9a06g032-clocks.c b/drivers/clk/renesas/r9a06g032-clocks.c index d900f6bf53d0..892e91b92f2c 100644 --- a/drivers/clk/renesas/r9a06g032-clocks.c +++ b/drivers/clk/renesas/r9a06g032-clocks.c @@ -55,7 +55,7 @@ struct r9a06g032_clkdesc { u16 sel, g1, r1, g2, r2; } dual; }; -} __packed; +}; #define I_GATE(_clk, _rst, _rdy, _midle, _scon, _mirack, _mistat) \ { .gate = _clk, .reset = _rst, \ From 7aeb353802611a8e655e019f09a370ff682af1a6 Mon Sep 17 00:00:00 2001 From: Andrew Jeffery Date: Thu, 26 Nov 2020 17:03:37 +1030 Subject: [PATCH 19/59] pinctrl: aspeed: Fix GPIO requests on pass-through banks Commit 6726fbff19bf ("pinctrl: aspeed: Fix GPI only function problem.") fixes access to GPIO banks T and U on the AST2600. Both banks contain input-only pins and the GPIO pin function is named GPITx and GPIUx respectively. Unfortunately the fix had a negative impact on GPIO banks D and E for the AST2400 and AST2500 where the GPIO pass-through functions take similar "GPI"-style names. The net effect on the older SoCs was that when the GPIO subsystem requested a pin in banks D or E be muxed for GPIO, they were instead muxed for pass-through mode. Mistakenly muxing pass-through mode e.g. breaks booting the host on IBM's Witherspoon (AC922) platform where GPIOE0 is used for FSI. Further exploit the names in the provided expression structure to differentiate pass-through from pin-specific GPIO modes. This follow-up fix gives the expected behaviour for the following tests: Witherspoon BMC (AST2500): 1. Power-on the Witherspoon host 2. Request GPIOD1 be muxed via /sys/class/gpio/export 3. Request GPIOE1 be muxed via /sys/class/gpio/export 4. Request the balls for GPIOs E2 and E3 be muxed as GPIO pass-through ("GPIE2" mode) via a pinctrl hog in the devicetree Rainier BMC (AST2600): 5. Request GPIT0 be muxed via /sys/class/gpio/export 6. Request GPIU0 be muxed via /sys/class/gpio/export Together the tests demonstrate that all three pieces of functionality (general GPIOs via 1, 2 and 3, input-only GPIOs via 5 and 6, pass-through mode via 4) operate as desired across old and new SoCs. Fixes: 9b92f5c51e9a ("pinctrl: aspeed: Fix GPI only function problem.") Signed-off-by: Andrew Jeffery Tested-by: Joel Stanley Reviewed-by: Joel Stanley Cc: Billy Tsai Cc: Joel Stanley Link: https://lore.kernel.org/r/20201126063337.489927-1-andrew@aj.id.au Signed-off-by: Linus Walleij --- drivers/pinctrl/aspeed/pinctrl-aspeed.c | 74 +++++++++++++++++++++++-- drivers/pinctrl/aspeed/pinmux-aspeed.h | 7 ++- 2 files changed, 72 insertions(+), 9 deletions(-) diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed.c b/drivers/pinctrl/aspeed/pinctrl-aspeed.c index d6b849552a1e..9c65d560d48f 100644 --- a/drivers/pinctrl/aspeed/pinctrl-aspeed.c +++ b/drivers/pinctrl/aspeed/pinctrl-aspeed.c @@ -286,14 +286,76 @@ int aspeed_pinmux_set_mux(struct pinctrl_dev *pctldev, unsigned int function, static bool aspeed_expr_is_gpio(const struct aspeed_sig_expr *expr) { /* - * The signal type is GPIO if the signal name has "GPI" as a prefix. - * strncmp (rather than strcmp) is used to implement the prefix - * requirement. + * We need to differentiate between GPIO and non-GPIO signals to + * implement the gpio_request_enable() interface. For better or worse + * the ASPEED pinctrl driver uses the expression names to determine + * whether an expression will mux a pin for GPIO. * - * expr->signal might look like "GPIOB1" in the GPIO case. - * expr->signal might look like "GPIT0" in the GPI case. + * Generally we have the following - A GPIO such as B1 has: + * + * - expr->signal set to "GPIOB1" + * - expr->function set to "GPIOB1" + * + * Using this fact we can determine whether the provided expression is + * a GPIO expression by testing the signal name for the string prefix + * "GPIO". + * + * However, some GPIOs are input-only, and the ASPEED datasheets name + * them differently. An input-only GPIO such as T0 has: + * + * - expr->signal set to "GPIT0" + * - expr->function set to "GPIT0" + * + * It's tempting to generalise the prefix test from "GPIO" to "GPI" to + * account for both GPIOs and GPIs, but in doing so we run aground on + * another feature: + * + * Some pins in the ASPEED BMC SoCs have a "pass-through" GPIO + * function where the input state of one pin is replicated as the + * output state of another (as if they were shorted together - a mux + * configuration that is typically enabled by hardware strapping). + * This feature allows the BMC to pass e.g. power button state through + * to the host while the BMC is yet to boot, but take control of the + * button state once the BMC has booted by muxing each pin as a + * separate, pin-specific GPIO. + * + * Conceptually this pass-through mode is a form of GPIO and is named + * as such in the datasheets, e.g. "GPID0". This naming similarity + * trips us up with the simple GPI-prefixed-signal-name scheme + * discussed above, as the pass-through configuration is not what we + * want when muxing a pin as GPIO for the GPIO subsystem. + * + * On e.g. the AST2400, a pass-through function "GPID0" is grouped on + * balls A18 and D16, where we have: + * + * For ball A18: + * - expr->signal set to "GPID0IN" + * - expr->function set to "GPID0" + * + * For ball D16: + * - expr->signal set to "GPID0OUT" + * - expr->function set to "GPID0" + * + * By contrast, the pin-specific GPIO expressions for the same pins are + * as follows: + * + * For ball A18: + * - expr->signal looks like "GPIOD0" + * - expr->function looks like "GPIOD0" + * + * For ball D16: + * - expr->signal looks like "GPIOD1" + * - expr->function looks like "GPIOD1" + * + * Testing both the signal _and_ function names gives us the means + * differentiate the pass-through GPIO pinmux configuration from the + * pin-specific configuration that the GPIO subsystem is after: An + * expression is a pin-specific (non-pass-through) GPIO configuration + * if the signal prefix is "GPI" and the signal name matches the + * function name. */ - return strncmp(expr->signal, "GPI", 3) == 0; + return !strncmp(expr->signal, "GPI", 3) && + !strcmp(expr->signal, expr->function); } static bool aspeed_gpio_in_exprs(const struct aspeed_sig_expr **exprs) diff --git a/drivers/pinctrl/aspeed/pinmux-aspeed.h b/drivers/pinctrl/aspeed/pinmux-aspeed.h index f86739e800c3..dba5875ff276 100644 --- a/drivers/pinctrl/aspeed/pinmux-aspeed.h +++ b/drivers/pinctrl/aspeed/pinmux-aspeed.h @@ -452,10 +452,11 @@ struct aspeed_sig_desc { * evaluation of the descriptors. * * @signal: The signal name for the priority level on the pin. If the signal - * type is GPIO, then the signal name must begin with the string - * "GPIO", e.g. GPIOA0, GPIOT4 etc. + * type is GPIO, then the signal name must begin with the + * prefix "GPI", e.g. GPIOA0, GPIT0 etc. * @function: The name of the function the signal participates in for the - * associated expression + * associated expression. For pin-specific GPIO, the function + * name must match the signal name. * @ndescs: The number of signal descriptors in the expression * @descs: Pointer to an array of signal descriptors that comprise the * function expression From 352ded44fbd8622670ff95e90ca732a5b036ce79 Mon Sep 17 00:00:00 2001 From: Dan Carpenter Date: Thu, 3 Dec 2020 11:45:17 +0300 Subject: [PATCH 20/59] drm/i915/gem: Check the correct variable in selftest There is a copy and paste bug in this code. It's supposed to check "obj2" instead of checking "obj" a second time. Fixes: 80f0b679d6f0 ("drm/i915: Add an implementation for i915_gem_ww_ctx locking, v2.") Signed-off-by: Dan Carpenter Reviewed-by: Chris Wilson Reviewed-by: Andi Shyti Signed-off-by: Chris Wilson Link: https://patchwork.freedesktop.org/patch/msgid/8ilneOcJAjwqU4t@mwand (cherry picked from commit 14f2d7604f7ce4cb3d303aea17292d119dfafa75) Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/selftests/i915_gem.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/selftests/i915_gem.c b/drivers/gpu/drm/i915/selftests/i915_gem.c index 23a6132c5f4e..412e21604a05 100644 --- a/drivers/gpu/drm/i915/selftests/i915_gem.c +++ b/drivers/gpu/drm/i915/selftests/i915_gem.c @@ -211,8 +211,8 @@ static int igt_gem_ww_ctx(void *arg) return PTR_ERR(obj); obj2 = i915_gem_object_create_internal(i915, PAGE_SIZE); - if (IS_ERR(obj)) { - err = PTR_ERR(obj); + if (IS_ERR(obj2)) { + err = PTR_ERR(obj2); goto put1; } From 0e124e19ce52d20b28ee9f1d5cdb22e2106bfd29 Mon Sep 17 00:00:00 2001 From: Chris Wilson Date: Thu, 3 Dec 2020 10:34:32 +0000 Subject: [PATCH 21/59] drm/i915/gem: Propagate error from cancelled submit due to context closure In the course of discovering and closing many races with context closure and execbuf submission, since commit 61231f6bd056 ("drm/i915/gem: Check that the context wasn't closed during setup") we started checking that the context was not closed by another userspace thread during the execbuf ioctl. In doing so we cancelled the inflight request (by telling it to be skipped), but kept reporting success since we do submit a request, albeit one that doesn't execute. As the error is known before we return from the ioctl, we can report the error we detect immediately, rather than leave it on the fence status. With the immediate propagation of the error, it is easier for userspace to handle. Fixes: 61231f6bd056 ("drm/i915/gem: Check that the context wasn't closed during setup") Testcase: igt/gem_ctx_exec/basic-close-race Signed-off-by: Chris Wilson Cc: # v5.7+ Reviewed-by: Tvrtko Ursulin Link: https://patchwork.freedesktop.org/patch/msgid/20201203103432.31526-1-chris@chris-wilson.co.uk (cherry picked from commit ba38b79eaeaeed29d2383f122d5c711ebf5ed3d1) Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c index 1904e6e5ea64..b07dc1156a0e 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c @@ -3097,7 +3097,7 @@ static void retire_requests(struct intel_timeline *tl, struct i915_request *end) break; } -static void eb_request_add(struct i915_execbuffer *eb) +static int eb_request_add(struct i915_execbuffer *eb, int err) { struct i915_request *rq = eb->request; struct intel_timeline * const tl = i915_request_timeline(rq); @@ -3118,6 +3118,7 @@ static void eb_request_add(struct i915_execbuffer *eb) /* Serialise with context_close via the add_to_timeline */ i915_request_set_error_once(rq, -ENOENT); __i915_request_skip(rq); + err = -ENOENT; /* override any transient errors */ } __i915_request_queue(rq, &attr); @@ -3127,6 +3128,8 @@ static void eb_request_add(struct i915_execbuffer *eb) retire_requests(tl, prev); mutex_unlock(&tl->mutex); + + return err; } static const i915_user_extension_fn execbuf_extensions[] = { @@ -3332,7 +3335,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, err = eb_submit(&eb, batch); err_request: i915_request_get(eb.request); - eb_request_add(&eb); + err = eb_request_add(&eb, err); if (eb.fences) signal_fence_array(&eb); From 5419d93ffd774127b195b8543b063b2b4fa5aea9 Mon Sep 17 00:00:00 2001 From: Chris Wilson Date: Fri, 4 Dec 2020 15:12:31 +0000 Subject: [PATCH 22/59] drm/i915/gt: Ignore repeated attempts to suspend request flow across reset Before reseting the engine, we suspend the execution of the guilty request, so that we can continue execution with a new context while we slowly compress the captured error state for the guilty context. However, if the reset fails, we will promptly attempt to reset the same request again, and discover the ongoing capture. Ignore the second attempt to suspend and capture the same request. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1168 Fixes: 32ff621fd744 ("drm/i915/gt: Allow temporary suspension of inflight requests") Signed-off-by: Chris Wilson Cc: # v5.7+ Reviewed-by: Mika Kuoppala Link: https://patchwork.freedesktop.org/patch/msgid/20201204151234.19729-1-chris@chris-wilson.co.uk (cherry picked from commit b969540500bce60cf1cdfff5464388af32b9a553) Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/gt/intel_lrc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c index 0952bf157234..03fd1fa42a75 100644 --- a/drivers/gpu/drm/i915/gt/intel_lrc.c +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c @@ -2788,6 +2788,9 @@ static void __execlists_hold(struct i915_request *rq) static bool execlists_hold(struct intel_engine_cs *engine, struct i915_request *rq) { + if (i915_request_on_hold(rq)) + return false; + spin_lock_irq(&engine->active.lock); if (i915_request_completed(rq)) { /* too late! */ From 0fe8bf4d3edce7aad6c14b9d5d92ff54dc19f0ba Mon Sep 17 00:00:00 2001 From: Chris Wilson Date: Fri, 4 Dec 2020 15:12:32 +0000 Subject: [PATCH 23/59] drm/i915/gt: Cancel the preemption timeout on responding to it We currently presume that the engine reset is successful, cancelling the expired preemption timer in the process. However, engine resets can fail, leaving the timeout still pending and we will then respond to the timeout again next time the tasklet fires. What we want is for the failed engine reset to be promoted to a full device reset, which is kicked by the heartbeat once the engine stops processing events. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1168 Fixes: 3a7a92aba8fb ("drm/i915/execlists: Force preemption") Signed-off-by: Chris Wilson Cc: # v5.5+ Reviewed-by: Mika Kuoppala Link: https://patchwork.freedesktop.org/patch/msgid/20201204151234.19729-2-chris@chris-wilson.co.uk (cherry picked from commit d997e240ceecb4f732611985d3a939ad1bfc1893) Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/gt/intel_lrc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c index 03fd1fa42a75..724b2cb897d3 100644 --- a/drivers/gpu/drm/i915/gt/intel_lrc.c +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c @@ -3172,8 +3172,10 @@ static void execlists_submission_tasklet(unsigned long data) spin_unlock_irqrestore(&engine->active.lock, flags); /* Recheck after serialising with direct-submission */ - if (unlikely(timeout && preempt_timeout(engine))) + if (unlikely(timeout && preempt_timeout(engine))) { + cancel_timer(&engine->execlists.preempt); execlists_reset(engine, "preemption time out"); + } } } From 88c52d805eb61da99aa4607fb5131f41c0ff6bd4 Mon Sep 17 00:00:00 2001 From: Colin Ian King Date: Fri, 2 Oct 2020 18:03:54 +0100 Subject: [PATCH 24/59] drm/i915: fix size_t greater or equal to zero comparison Currently the check that the unsigned size_t variable i is >= 0 is always true because the unsigned variable will never be negative, causing the loop to run forever. Fix this by changing the pre-decrement check to a zero check on i followed by a decrement of i. Addresses-Coverity: ("Unsigned compared against 0") Fixes: bfed6708d6c9 ("drm/i915: use vmap in shmem_pin_map") Signed-off-by: Colin Ian King Reviewed-by: Chris Wilson Signed-off-by: Chris Wilson Link: https://patchwork.freedesktop.org/patch/msgid/20201002170354.94627-1-colin.king@canonical.com (cherry picked from commit e70956a2498dc81d8f2522cba074f55ae910e13c) Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/gt/shmem_utils.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/shmem_utils.c b/drivers/gpu/drm/i915/gt/shmem_utils.c index 463af675fadd..5982b62f913d 100644 --- a/drivers/gpu/drm/i915/gt/shmem_utils.c +++ b/drivers/gpu/drm/i915/gt/shmem_utils.c @@ -73,7 +73,7 @@ void *shmem_pin_map(struct file *file) mapping_set_unevictable(file->f_mapping); return vaddr; err_page: - while (--i >= 0) + while (i--) put_page(pages[i]); kvfree(pages); return NULL; From f6cbe49be65ed800863ac5ba695555057363f9c2 Mon Sep 17 00:00:00 2001 From: Manasi Navare Date: Fri, 4 Dec 2020 12:58:04 -0800 Subject: [PATCH 25/59] drm/i915/display/dp: Compute the correct slice count for VDSC on DP This patch fixes the slice count computation algorithm for calculating the slice count based on Peak pixel rate and the max slice width allowed on the DSC engines. We need to ensure slice count > min slice count req as per DP spec based on peak pixel rate and that it is greater than min slice count based on the max slice width advertised by DPCD. So use max of these two. In the prev patch we were using min of these 2 causing it to violate the max slice width limitation causing a blank screen on 8K@60. Fixes: d9218c8f6cf4 ("drm/i915/dp: Add helpers for Compressed BPP and Slice Count for DSC") Cc: Ankit Nautiyal Cc: Jani Nikula Cc: # v5.0+ Signed-off-by: Manasi Navare Reviewed-by: Ankit Nautiyal Link: https://patchwork.freedesktop.org/patch/msgid/20201204205804.25225-1-manasi.d.navare@intel.com (cherry picked from commit d371d6ea92ad2a47f42bbcaa786ee5f6069c9c14) Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/display/intel_dp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index bf1e9cf1c0f3..9bc59fd2f95f 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -573,7 +573,7 @@ static u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp, return 0; } /* Also take into account max slice width */ - min_slice_count = min_t(u8, min_slice_count, + min_slice_count = max_t(u8, min_slice_count, DIV_ROUND_UP(mode_hdisplay, max_slice_width)); From 7c5c15dffe1e3c42f44735ce9552afb7207f1584 Mon Sep 17 00:00:00 2001 From: Chris Wilson Date: Fri, 27 Nov 2020 10:25:40 +0000 Subject: [PATCH 26/59] drm/i915/gt: Declare gen9 has 64 mocs entries! We checked the table size against a hardcoded number of entries, and that number was excluding the special mocs registers at the end. Fixes: 777a7717d60c ("drm/i915/gt: Program mocs:63 for cache eviction on gen9") Signed-off-by: Chris Wilson Cc: # v4.3+ Reviewed-by: Tvrtko Ursulin Link: https://patchwork.freedesktop.org/patch/msgid/20201127102540.13117-1-chris@chris-wilson.co.uk (cherry picked from commit 444fbf5d7058099447c5366ba8bb60d610aeb44b) Signed-off-by: Rodrigo Vivi [backported and updated the Fixes sha] --- drivers/gpu/drm/i915/gt/intel_mocs.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c b/drivers/gpu/drm/i915/gt/intel_mocs.c index 4f74706967fd..413dadfac2d1 100644 --- a/drivers/gpu/drm/i915/gt/intel_mocs.c +++ b/drivers/gpu/drm/i915/gt/intel_mocs.c @@ -59,8 +59,7 @@ struct drm_i915_mocs_table { #define _L3_CACHEABILITY(value) ((value) << 4) /* Helper defines */ -#define GEN9_NUM_MOCS_ENTRIES 62 /* 62 out of 64 - 63 & 64 are reserved. */ -#define GEN11_NUM_MOCS_ENTRIES 64 /* 63-64 are reserved, but configured. */ +#define GEN9_NUM_MOCS_ENTRIES 64 /* 63-64 are reserved, but configured. */ /* (e)LLC caching options */ /* @@ -328,11 +327,11 @@ static unsigned int get_mocs_settings(const struct drm_i915_private *i915, if (INTEL_GEN(i915) >= 12) { table->size = ARRAY_SIZE(tgl_mocs_table); table->table = tgl_mocs_table; - table->n_entries = GEN11_NUM_MOCS_ENTRIES; + table->n_entries = GEN9_NUM_MOCS_ENTRIES; } else if (IS_GEN(i915, 11)) { table->size = ARRAY_SIZE(icl_mocs_table); table->table = icl_mocs_table; - table->n_entries = GEN11_NUM_MOCS_ENTRIES; + table->n_entries = GEN9_NUM_MOCS_ENTRIES; } else if (IS_GEN9_BC(i915) || IS_CANNONLAKE(i915)) { table->size = ARRAY_SIZE(skl_mocs_table); table->n_entries = GEN9_NUM_MOCS_ENTRIES; From 0e830d2872cf6e75ef6619edd23050ddf3673358 Mon Sep 17 00:00:00 2001 From: Alex Deucher Date: Tue, 1 Dec 2020 17:44:58 -0500 Subject: [PATCH 27/59] drm/amdgpu/powerplay: parse fan table for CI asics Set up all the parameters required for SMU fan control if supported. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=201539 Acked-by: Evan Quan Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org --- .../amd/pm/powerplay/hwmgr/processpptables.c | 103 +++++++++++++++++- 1 file changed, 102 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/processpptables.c b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/processpptables.c index 719597c5d27d..6606511891e3 100644 --- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/processpptables.c +++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/processpptables.c @@ -24,6 +24,8 @@ #include #include #include +#include + #include #include "processpptables.h" #include @@ -984,6 +986,8 @@ static int init_thermal_controller( struct pp_hwmgr *hwmgr, const ATOM_PPLIB_POWERPLAYTABLE *powerplay_table) { + struct amdgpu_device *adev = hwmgr->adev; + hwmgr->thermal_controller.ucType = powerplay_table->sThermalController.ucType; hwmgr->thermal_controller.ucI2cLine = @@ -1008,7 +1012,104 @@ static int init_thermal_controller( ATOM_PP_THERMALCONTROLLER_NONE != hwmgr->thermal_controller.ucType, PHM_PlatformCaps_ThermalController); - hwmgr->thermal_controller.use_hw_fan_control = 1; + if (powerplay_table->usTableSize >= sizeof(ATOM_PPLIB_POWERPLAYTABLE3)) { + const ATOM_PPLIB_POWERPLAYTABLE3 *powerplay_table3 = + (const ATOM_PPLIB_POWERPLAYTABLE3 *)powerplay_table; + + if (0 == le16_to_cpu(powerplay_table3->usFanTableOffset)) { + hwmgr->thermal_controller.use_hw_fan_control = 1; + return 0; + } else { + const ATOM_PPLIB_FANTABLE *fan_table = + (const ATOM_PPLIB_FANTABLE *)(((unsigned long)powerplay_table) + + le16_to_cpu(powerplay_table3->usFanTableOffset)); + + if (1 <= fan_table->ucFanTableFormat) { + hwmgr->thermal_controller.advanceFanControlParameters.ucTHyst = + fan_table->ucTHyst; + hwmgr->thermal_controller.advanceFanControlParameters.usTMin = + le16_to_cpu(fan_table->usTMin); + hwmgr->thermal_controller.advanceFanControlParameters.usTMed = + le16_to_cpu(fan_table->usTMed); + hwmgr->thermal_controller.advanceFanControlParameters.usTHigh = + le16_to_cpu(fan_table->usTHigh); + hwmgr->thermal_controller.advanceFanControlParameters.usPWMMin = + le16_to_cpu(fan_table->usPWMMin); + hwmgr->thermal_controller.advanceFanControlParameters.usPWMMed = + le16_to_cpu(fan_table->usPWMMed); + hwmgr->thermal_controller.advanceFanControlParameters.usPWMHigh = + le16_to_cpu(fan_table->usPWMHigh); + hwmgr->thermal_controller.advanceFanControlParameters.usTMax = 10900; + hwmgr->thermal_controller.advanceFanControlParameters.ulCycleDelay = 100000; + + phm_cap_set(hwmgr->platform_descriptor.platformCaps, + PHM_PlatformCaps_MicrocodeFanControl); + } + + if (2 <= fan_table->ucFanTableFormat) { + const ATOM_PPLIB_FANTABLE2 *fan_table2 = + (const ATOM_PPLIB_FANTABLE2 *)(((unsigned long)powerplay_table) + + le16_to_cpu(powerplay_table3->usFanTableOffset)); + hwmgr->thermal_controller.advanceFanControlParameters.usTMax = + le16_to_cpu(fan_table2->usTMax); + } + + if (3 <= fan_table->ucFanTableFormat) { + const ATOM_PPLIB_FANTABLE3 *fan_table3 = + (const ATOM_PPLIB_FANTABLE3 *) (((unsigned long)powerplay_table) + + le16_to_cpu(powerplay_table3->usFanTableOffset)); + + hwmgr->thermal_controller.advanceFanControlParameters.ucFanControlMode = + fan_table3->ucFanControlMode; + + if ((3 == fan_table->ucFanTableFormat) && + (0x67B1 == adev->pdev->device)) + hwmgr->thermal_controller.advanceFanControlParameters.usDefaultMaxFanPWM = + 47; + else + hwmgr->thermal_controller.advanceFanControlParameters.usDefaultMaxFanPWM = + le16_to_cpu(fan_table3->usFanPWMMax); + + hwmgr->thermal_controller.advanceFanControlParameters.usDefaultFanOutputSensitivity = + 4836; + hwmgr->thermal_controller.advanceFanControlParameters.usFanOutputSensitivity = + le16_to_cpu(fan_table3->usFanOutputSensitivity); + } + + if (6 <= fan_table->ucFanTableFormat) { + const ATOM_PPLIB_FANTABLE4 *fan_table4 = + (const ATOM_PPLIB_FANTABLE4 *)(((unsigned long)powerplay_table) + + le16_to_cpu(powerplay_table3->usFanTableOffset)); + + phm_cap_set(hwmgr->platform_descriptor.platformCaps, + PHM_PlatformCaps_FanSpeedInTableIsRPM); + + hwmgr->thermal_controller.advanceFanControlParameters.usDefaultMaxFanRPM = + le16_to_cpu(fan_table4->usFanRPMMax); + } + + if (7 <= fan_table->ucFanTableFormat) { + const ATOM_PPLIB_FANTABLE5 *fan_table5 = + (const ATOM_PPLIB_FANTABLE5 *)(((unsigned long)powerplay_table) + + le16_to_cpu(powerplay_table3->usFanTableOffset)); + + if (0x67A2 == adev->pdev->device || + 0x67A9 == adev->pdev->device || + 0x67B9 == adev->pdev->device) { + phm_cap_set(hwmgr->platform_descriptor.platformCaps, + PHM_PlatformCaps_GeminiRegulatorFanControlSupport); + hwmgr->thermal_controller.advanceFanControlParameters.usFanCurrentLow = + le16_to_cpu(fan_table5->usFanCurrentLow); + hwmgr->thermal_controller.advanceFanControlParameters.usFanCurrentHigh = + le16_to_cpu(fan_table5->usFanCurrentHigh); + hwmgr->thermal_controller.advanceFanControlParameters.usFanRPMLow = + le16_to_cpu(fan_table5->usFanRPMLow); + hwmgr->thermal_controller.advanceFanControlParameters.usFanRPMHigh = + le16_to_cpu(fan_table5->usFanRPMHigh); + } + } + } + } return 0; } From e8873c0afd34beb67ec492cd648dd0095b911f65 Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Tue, 8 Dec 2020 20:24:03 +0200 Subject: [PATCH 28/59] pinctrl: intel: Actually disable Tx and Rx buffers on GPIO request Mistakenly the buffers (input and output) become enabled together for a short period of time during GPIO request. This is problematic, because instead of initial motive to disable them in the commit af7e3eeb84e2 ("pinctrl: intel: Disable input and output buffer when switching to GPIO"), the driven value on the pin, which might be used as an IRQ line, brings firmwares of some touch pads to an awkward state that needs a full power off to recover. Fix this, as stated in the culprit commit, by disabling the buffers. Fixes: af7e3eeb84e2 ("pinctrl: intel: Disable input and output buffer when switching to GPIO") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=210497 Reported-by: Pierre-Louis Bossart Signed-off-by: Andy Shevchenko Acked-by: Mika Westerberg Tested-by: Pierre-Louis Bossart Tested-by: Kai-Heng Feng Link: https://lore.kernel.org/r/20201208182403.40435-1-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij --- drivers/pinctrl/intel/pinctrl-intel.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/pinctrl/intel/pinctrl-intel.c b/drivers/pinctrl/intel/pinctrl-intel.c index 1c10ab184783..b6ef1911c1dd 100644 --- a/drivers/pinctrl/intel/pinctrl-intel.c +++ b/drivers/pinctrl/intel/pinctrl-intel.c @@ -442,8 +442,8 @@ static void intel_gpio_set_gpio_mode(void __iomem *padcfg0) value |= PADCFG0_PMODE_GPIO; /* Disable input and output buffers */ - value &= ~PADCFG0_GPIORXDIS; - value &= ~PADCFG0_GPIOTXDIS; + value |= PADCFG0_GPIORXDIS; + value |= PADCFG0_GPIOTXDIS; /* Disable SCI/SMI/NMI generation */ value &= ~(PADCFG0_GPIROUTIOXAPIC | PADCFG0_GPIROUTSCI); From 263ade7166a2e589c5b605272690c155c0637dcb Mon Sep 17 00:00:00 2001 From: Chunyan Zhang Date: Wed, 9 Dec 2020 13:51:06 +0800 Subject: [PATCH 29/59] gpio: eic-sprd: break loop when getting NULL device resource EIC controller have unfixed numbers of banks on different Spreadtrum SoCs, and each bank has its own base address, the loop of getting there base address in driver should break if the resource gotten via platform_get_resource() is NULL already. The later ones would be all NULL even if the loop continues. Fixes: 25518e024e3a ("gpio: Add Spreadtrum EIC driver support") Signed-off-by: Chunyan Zhang Link: https://lore.kernel.org/r/20201209055106.840100-1-zhang.lyra@gmail.com Signed-off-by: Linus Walleij --- drivers/gpio/gpio-eic-sprd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpio/gpio-eic-sprd.c b/drivers/gpio/gpio-eic-sprd.c index ad61daf6c212..865ab2b34fdd 100644 --- a/drivers/gpio/gpio-eic-sprd.c +++ b/drivers/gpio/gpio-eic-sprd.c @@ -598,7 +598,7 @@ static int sprd_eic_probe(struct platform_device *pdev) */ res = platform_get_resource(pdev, IORESOURCE_MEM, i); if (!res) - continue; + break; sprd_eic->base[i] = devm_ioremap_resource(&pdev->dev, res); if (IS_ERR(sprd_eic->base[i])) From 578b6c487899179fed730e710ffec0b069917971 Mon Sep 17 00:00:00 2001 From: Alex Deucher Date: Thu, 3 Dec 2020 16:06:26 -0500 Subject: [PATCH 30/59] drm/amdgpu/disply: set num_crtc earlier To avoid a recently added warning: Bogus possible_crtcs: [ENCODER:65:TMDS-65] possible_crtcs=0xf (full crtc mask=0x7) WARNING: CPU: 3 PID: 439 at drivers/gpu/drm/drm_mode_config.c:617 drm_mode_config_validate+0x178/0x200 [drm] In this case the warning is harmless, but confusing to users. Fixes: 0df108237433 ("drm: Validate encoder->possible_crtcs") Bug: https://bugzilla.kernel.org/show_bug.cgi?id=209123 Reviewed-by: Daniel Vetter Reviewed-by: Nicholas Kazlauskas Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 9b6809f309f4..0f7749e9424d 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -1058,9 +1058,6 @@ static int amdgpu_dm_init(struct amdgpu_device *adev) goto error; } - /* Update the actual used number of crtc */ - adev->mode_info.num_crtc = adev->dm.display_indexes_num; - /* create fake encoders for MST */ dm_dp_create_fake_mst_encoders(adev); @@ -3251,6 +3248,10 @@ static int amdgpu_dm_initialize_drm_device(struct amdgpu_device *adev) enum dc_connection_type new_connection_type = dc_connection_none; const struct dc_plane_cap *plane; + dm->display_indexes_num = dm->dc->caps.max_streams; + /* Update the actual used number of crtc */ + adev->mode_info.num_crtc = adev->dm.display_indexes_num; + link_cnt = dm->dc->caps.max_links; if (amdgpu_dm_mode_config_init(dm->adev)) { DRM_ERROR("DM: Failed to initialize mode config\n"); @@ -3312,8 +3313,6 @@ static int amdgpu_dm_initialize_drm_device(struct amdgpu_device *adev) goto fail; } - dm->display_indexes_num = dm->dc->caps.max_streams; - /* loops over all connectors on the board */ for (i = 0; i < link_cnt; i++) { struct dc_link *link = NULL; From 2343e9d2c5a94459b9de92649f1650e36eb79a10 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann Date: Fri, 4 Dec 2020 00:06:43 +0100 Subject: [PATCH 31/59] drm/amdgpu: fix debugfs creation/removal, again There is still a warning when CONFIG_DEBUG_FS is disabled: drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1145:13: error: 'amdgpu_ras_debugfs_create_ctrl_node' defined but not used [-Werror=unused-function] 1145 | static void amdgpu_ras_debugfs_create_ctrl_node(struct amdgpu_device *adev) Change the code again to make the compiler actually drop this code but not warn about it. Fixes: ae2bf61ff39e ("drm/amdgpu: guard ras debugfs creation/removal based on CONFIG_DEBUG_FS") Reviewed-by: Tao Zhou Signed-off-by: Arnd Bergmann Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 13 +++++-------- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h | 6 ------ 2 files changed, 5 insertions(+), 14 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c index 4e36551ab50b..82cd8e55595a 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c @@ -1172,7 +1172,7 @@ static void amdgpu_ras_debugfs_create_ctrl_node(struct amdgpu_device *adev) con->dir, &con->disable_ras_err_cnt_harvest); } -void amdgpu_ras_debugfs_create(struct amdgpu_device *adev, +static void amdgpu_ras_debugfs_create(struct amdgpu_device *adev, struct ras_fs_if *head) { struct amdgpu_ras *con = amdgpu_ras_get_context(adev); @@ -1194,7 +1194,6 @@ void amdgpu_ras_debugfs_create(struct amdgpu_device *adev, void amdgpu_ras_debugfs_create_all(struct amdgpu_device *adev) { -#if defined(CONFIG_DEBUG_FS) struct amdgpu_ras *con = amdgpu_ras_get_context(adev); struct ras_manager *obj; struct ras_fs_if fs_info; @@ -1203,7 +1202,7 @@ void amdgpu_ras_debugfs_create_all(struct amdgpu_device *adev) * it won't be called in resume path, no need to check * suspend and gpu reset status */ - if (!con) + if (!IS_ENABLED(CONFIG_DEBUG_FS) || !con) return; amdgpu_ras_debugfs_create_ctrl_node(adev); @@ -1217,10 +1216,9 @@ void amdgpu_ras_debugfs_create_all(struct amdgpu_device *adev) amdgpu_ras_debugfs_create(adev, &fs_info); } } -#endif } -void amdgpu_ras_debugfs_remove(struct amdgpu_device *adev, +static void amdgpu_ras_debugfs_remove(struct amdgpu_device *adev, struct ras_common_if *head) { struct ras_manager *obj = amdgpu_ras_find_obj(adev, head); @@ -1234,7 +1232,6 @@ void amdgpu_ras_debugfs_remove(struct amdgpu_device *adev, static void amdgpu_ras_debugfs_remove_all(struct amdgpu_device *adev) { -#if defined(CONFIG_DEBUG_FS) struct amdgpu_ras *con = amdgpu_ras_get_context(adev); struct ras_manager *obj, *tmp; @@ -1243,7 +1240,6 @@ static void amdgpu_ras_debugfs_remove_all(struct amdgpu_device *adev) } con->dir = NULL; -#endif } /* debugfs end */ @@ -1291,7 +1287,8 @@ static int amdgpu_ras_fs_init(struct amdgpu_device *adev) static int amdgpu_ras_fs_fini(struct amdgpu_device *adev) { - amdgpu_ras_debugfs_remove_all(adev); + if (IS_ENABLED(CONFIG_DEBUG_FS)) + amdgpu_ras_debugfs_remove_all(adev); amdgpu_ras_sysfs_remove_all(adev); return 0; } diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h index 6b8d7bb83bb3..ec398ed7deb8 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h @@ -607,14 +607,8 @@ int amdgpu_ras_sysfs_create(struct amdgpu_device *adev, int amdgpu_ras_sysfs_remove(struct amdgpu_device *adev, struct ras_common_if *head); -void amdgpu_ras_debugfs_create(struct amdgpu_device *adev, - struct ras_fs_if *head); - void amdgpu_ras_debugfs_create_all(struct amdgpu_device *adev); -void amdgpu_ras_debugfs_remove(struct amdgpu_device *adev, - struct ras_common_if *head); - int amdgpu_ras_error_query(struct amdgpu_device *adev, struct ras_query_if *info); From c2ffe78b8b1354603a7d5afb719b2a6dfbb582da Mon Sep 17 00:00:00 2001 From: Chris Park Date: Tue, 24 Nov 2020 20:11:25 -0500 Subject: [PATCH 32/59] drm/amd/display: Prevent bandwidth overflow [Why] At very high pixel clock, bandwidth calculation exceeds 32 bit size and overflow value. This causes the resulting selection of link rate to be inaccurate. [How] Change order of operation and use fixed point to deal with integer accuracy. Also address bug found when forcing link rate. Signed-off-by: Chris Park Reviewed-by: Wenjing Liu Acked-by: Eryk Brol Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/display/dc/core/dc_link.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c b/drivers/gpu/drm/amd/display/dc/core/dc_link.c index fec87a2e210c..5b0cedfa824a 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c @@ -3394,10 +3394,13 @@ uint32_t dc_bandwidth_in_kbps_from_timing( { uint32_t bits_per_channel = 0; uint32_t kbps; + struct fixed31_32 link_bw_kbps; if (timing->flags.DSC) { - kbps = (timing->pix_clk_100hz * timing->dsc_cfg.bits_per_pixel); - kbps = kbps / 160 + ((kbps % 160) ? 1 : 0); + link_bw_kbps = dc_fixpt_from_int(timing->pix_clk_100hz); + link_bw_kbps = dc_fixpt_div_int(link_bw_kbps, 160); + link_bw_kbps = dc_fixpt_mul_int(link_bw_kbps, timing->dsc_cfg.bits_per_pixel); + kbps = dc_fixpt_ceil(link_bw_kbps); return kbps; } From 369b7ebe1792b620b7a9404e7b71daaae13ebfd6 Mon Sep 17 00:00:00 2001 From: Sung Lee Date: Mon, 23 Nov 2020 15:38:54 -0500 Subject: [PATCH 33/59] drm/amd/display: Add wm table for Renoir [Why] Without additional HostVM Latency, Renoir takes 2us longer to exit self-refresh. This causes underflow in certain cases. [How] Add table for Renoir with updated sr exit latencies for WM set A. Signed-off-by: Sung Lee Reviewed-by: Yongqiang Sun Reviewed-by: Roman Li Acked-by: Eryk Brol Signed-off-by: Alex Deucher --- .../amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c | 93 ++++++++++++++++++- 1 file changed, 89 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c index c001307b0a59..6b431db146cd 100644 --- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c +++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c @@ -579,7 +579,7 @@ static struct clk_bw_params rn_bw_params = { }; -static struct wm_table ddr4_wm_table = { +static struct wm_table ddr4_wm_table_gs = { .entries = { { .wm_inst = WM_A, @@ -616,7 +616,7 @@ static struct wm_table ddr4_wm_table = { } }; -static struct wm_table lpddr4_wm_table = { +static struct wm_table lpddr4_wm_table_gs = { .entries = { { .wm_inst = WM_A, @@ -690,6 +690,80 @@ static struct wm_table lpddr4_wm_table_with_disabled_ppt = { } }; +static struct wm_table ddr4_wm_table_rn = { + .entries = { + { + .wm_inst = WM_A, + .wm_type = WM_TYPE_PSTATE_CHG, + .pstate_latency_us = 11.72, + .sr_exit_time_us = 9.09, + .sr_enter_plus_exit_time_us = 10.14, + .valid = true, + }, + { + .wm_inst = WM_B, + .wm_type = WM_TYPE_PSTATE_CHG, + .pstate_latency_us = 11.72, + .sr_exit_time_us = 10.12, + .sr_enter_plus_exit_time_us = 11.48, + .valid = true, + }, + { + .wm_inst = WM_C, + .wm_type = WM_TYPE_PSTATE_CHG, + .pstate_latency_us = 11.72, + .sr_exit_time_us = 10.12, + .sr_enter_plus_exit_time_us = 11.48, + .valid = true, + }, + { + .wm_inst = WM_D, + .wm_type = WM_TYPE_PSTATE_CHG, + .pstate_latency_us = 11.72, + .sr_exit_time_us = 10.12, + .sr_enter_plus_exit_time_us = 11.48, + .valid = true, + }, + } +}; + +static struct wm_table lpddr4_wm_table_rn = { + .entries = { + { + .wm_inst = WM_A, + .wm_type = WM_TYPE_PSTATE_CHG, + .pstate_latency_us = 11.65333, + .sr_exit_time_us = 7.32, + .sr_enter_plus_exit_time_us = 8.38, + .valid = true, + }, + { + .wm_inst = WM_B, + .wm_type = WM_TYPE_PSTATE_CHG, + .pstate_latency_us = 11.65333, + .sr_exit_time_us = 9.82, + .sr_enter_plus_exit_time_us = 11.196, + .valid = true, + }, + { + .wm_inst = WM_C, + .wm_type = WM_TYPE_PSTATE_CHG, + .pstate_latency_us = 11.65333, + .sr_exit_time_us = 9.89, + .sr_enter_plus_exit_time_us = 11.24, + .valid = true, + }, + { + .wm_inst = WM_D, + .wm_type = WM_TYPE_PSTATE_CHG, + .pstate_latency_us = 11.65333, + .sr_exit_time_us = 9.748, + .sr_enter_plus_exit_time_us = 11.102, + .valid = true, + }, + } +}; + static unsigned int find_dcfclk_for_voltage(struct dpm_clocks *clock_table, unsigned int voltage) { int i; @@ -771,6 +845,11 @@ void rn_clk_mgr_construct( struct dc_debug_options *debug = &ctx->dc->debug; struct dpm_clocks clock_table = { 0 }; enum pp_smu_status status = 0; + int is_green_sardine = 0; + +#if defined(CONFIG_DRM_AMD_DC_DCN) + is_green_sardine = ASICREV_IS_GREEN_SARDINE(ctx->asic_id.hw_internal_rev); +#endif clk_mgr->base.ctx = ctx; clk_mgr->base.funcs = &dcn21_funcs; @@ -811,10 +890,16 @@ void rn_clk_mgr_construct( if (clk_mgr->periodic_retraining_disabled) { rn_bw_params.wm_table = lpddr4_wm_table_with_disabled_ppt; } else { - rn_bw_params.wm_table = lpddr4_wm_table; + if (is_green_sardine) + rn_bw_params.wm_table = lpddr4_wm_table_gs; + else + rn_bw_params.wm_table = lpddr4_wm_table_rn; } } else { - rn_bw_params.wm_table = ddr4_wm_table; + if (is_green_sardine) + rn_bw_params.wm_table = ddr4_wm_table_gs; + else + rn_bw_params.wm_table = ddr4_wm_table_rn; } /* Saved clocks configured at boot for debug purposes */ rn_dump_clk_registers(&clk_mgr->base.boot_snapshot, &clk_mgr->base, &log_info); From 6896887b8676d8fb445c85ea56333b9661a6a8aa Mon Sep 17 00:00:00 2001 From: "Stanley.Yang" Date: Mon, 7 Dec 2020 14:38:33 +0800 Subject: [PATCH 34/59] drm/amdgpu: fix sdma instance fw version and feature version init each sdma instance fw_version and feature_version should be set right value when asic type isn't between SIENNA_CICHILD and CHIP_DIMGREY_CAVEFISH Signed-off-by: Stanley.Yang Reviewed-by: Tao Zhou Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org --- drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c b/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c index 9f3952723c63..2a485052e3ab 100644 --- a/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c +++ b/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c @@ -186,7 +186,7 @@ static int sdma_v5_2_init_microcode(struct amdgpu_device *adev) if (err) goto out; - err = sdma_v5_2_init_inst_ctx(&adev->sdma.instance[0]); + err = sdma_v5_2_init_inst_ctx(&adev->sdma.instance[i]); if (err) goto out; } From ab6e4e9de8dd7febfdf6719741f10dc6693d8ce9 Mon Sep 17 00:00:00 2001 From: Felix Kuehling Date: Tue, 8 Dec 2020 12:23:15 -0500 Subject: [PATCH 35/59] drm/amdkfd: Fix leak in dmabuf import Release dmabuf reference before returning from kfd_ioctl_import_dmabuf. amdgpu_amdkfd_gpuvm_import_dmabuf takes a reference to the underlying GEM BO and doesn't keep the reference to the dmabuf wrapper. Signed-off-by: Felix Kuehling Reviewed-by: Kent Russell Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c index 222f1df1a6b6..8cc51cec988a 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c @@ -1736,6 +1736,7 @@ static int kfd_ioctl_import_dmabuf(struct file *filep, } mutex_unlock(&p->mutex); + dma_buf_put(dmabuf); args->handle = MAKE_HANDLE(args->gpu_id, idr_handle); @@ -1745,6 +1746,7 @@ static int kfd_ioctl_import_dmabuf(struct file *filep, amdgpu_amdkfd_gpuvm_free_memory_of_gpu(dev->kgd, (struct kgd_mem *)mem, NULL); err_unlock: mutex_unlock(&p->mutex); + dma_buf_put(dmabuf); return r; } From c9918d1f63a3e77ec20997a77c997a6fa7282f2f Mon Sep 17 00:00:00 2001 From: Changfeng Date: Mon, 7 Dec 2020 15:42:29 +0800 Subject: [PATCH 36/59] drm/amd/pm: update smu10.h WORKLOAD_PPLIB setting for raven When using old WORKLOAD_PPLIB setting in smu10.h, there is problem that it can't be able to switch to mak gpu clk during compute workload. It needs to update WORKLOAD_PPLIB setting to fix this issue. Signed-off-by: Changfeng Reviewed-by: Huang Rui Acked-by: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org --- drivers/gpu/drm/amd/pm/inc/smu10.h | 14 ++++++-------- .../gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c | 9 +++------ 2 files changed, 9 insertions(+), 14 deletions(-) diff --git a/drivers/gpu/drm/amd/pm/inc/smu10.h b/drivers/gpu/drm/amd/pm/inc/smu10.h index b96520528240..9e837a5014c5 100644 --- a/drivers/gpu/drm/amd/pm/inc/smu10.h +++ b/drivers/gpu/drm/amd/pm/inc/smu10.h @@ -136,14 +136,12 @@ #define FEATURE_CORE_CSTATES_MASK (1 << FEATURE_CORE_CSTATES_BIT) /* Workload bits */ -#define WORKLOAD_DEFAULT_BIT 0 -#define WORKLOAD_PPLIB_FULL_SCREEN_3D_BIT 1 -#define WORKLOAD_PPLIB_POWER_SAVING_BIT 2 -#define WORKLOAD_PPLIB_VIDEO_BIT 3 -#define WORKLOAD_PPLIB_VR_BIT 4 -#define WORKLOAD_PPLIB_COMPUTE_BIT 5 -#define WORKLOAD_PPLIB_CUSTOM_BIT 6 -#define WORKLOAD_PPLIB_COUNT 7 +#define WORKLOAD_PPLIB_FULL_SCREEN_3D_BIT 0 +#define WORKLOAD_PPLIB_VIDEO_BIT 2 +#define WORKLOAD_PPLIB_VR_BIT 3 +#define WORKLOAD_PPLIB_COMPUTE_BIT 4 +#define WORKLOAD_PPLIB_CUSTOM_BIT 5 +#define WORKLOAD_PPLIB_COUNT 6 typedef struct { /* MP1_EXT_SCRATCH0 */ diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c index cf60f3992303..e6f40ee9f313 100644 --- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c +++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c @@ -1297,15 +1297,9 @@ static int conv_power_profile_to_pplib_workload(int power_profile) int pplib_workload = 0; switch (power_profile) { - case PP_SMC_POWER_PROFILE_BOOTUP_DEFAULT: - pplib_workload = WORKLOAD_DEFAULT_BIT; - break; case PP_SMC_POWER_PROFILE_FULLSCREEN3D: pplib_workload = WORKLOAD_PPLIB_FULL_SCREEN_3D_BIT; break; - case PP_SMC_POWER_PROFILE_POWERSAVING: - pplib_workload = WORKLOAD_PPLIB_POWER_SAVING_BIT; - break; case PP_SMC_POWER_PROFILE_VIDEO: pplib_workload = WORKLOAD_PPLIB_VIDEO_BIT; break; @@ -1315,6 +1309,9 @@ static int conv_power_profile_to_pplib_workload(int power_profile) case PP_SMC_POWER_PROFILE_COMPUTE: pplib_workload = WORKLOAD_PPLIB_COMPUTE_BIT; break; + case PP_SMC_POWER_PROFILE_CUSTOM: + pplib_workload = WORKLOAD_PPLIB_CUSTOM_BIT; + break; } return pplib_workload; From 157fe68d74c2ad2db438c91af9ed3d3a51de4ed7 Mon Sep 17 00:00:00 2001 From: Alex Deucher Date: Mon, 7 Dec 2020 13:12:29 -0500 Subject: [PATCH 37/59] drm/amdgpu: fix size calculation with stolen vga memory MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit If we need to keep the stolen vga memory, make sure it is at least as big as the legacy vga size. Acked-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org --- drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c index 36604d751d62..3e4892b7b7d3 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c @@ -499,6 +499,9 @@ void amdgpu_gmc_get_vbios_allocations(struct amdgpu_device *adev) else size = amdgpu_gmc_get_vbios_fb_size(adev); + if (adev->mman.keep_stolen_vga_memory) + size = max(size, (unsigned)AMDGPU_VBIOS_VGA_ALLOCATION); + /* set to 0 if the pre-OS buffer uses up most of vram */ if ((adev->gmc.real_vram_size - size) < (8 * 1024 * 1024)) size = 0; From ab43234d0bafcf2accd9db4fc4d193180b752f94 Mon Sep 17 00:00:00 2001 From: Andrey Grodzovsky Date: Tue, 8 Dec 2020 15:16:15 -0500 Subject: [PATCH 38/59] drm/amdgpu: Initialise drm_gem_object_funcs for imported BOs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit For BOs imported from outside of amdgpu, setting of amdgpu_gem_object_funcs was missing in amdgpu_dma_buf_create_obj. Fix by refactoring BO creation and amdgpu_gem_object_funcs setting into single function called from both code paths. Fixes: d693def4fd1c ("drm: Remove obsolete GEM and PRIME callbacks from struct drm_driver") v2: Use use amdgpu_gem_object_create() directly v3: fix warning Reviewed-by: Christian König Signed-off-by: Andrey Grodzovsky Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 8 +++- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 41 ++++++++++++--------- 2 files changed, 29 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c index 957934926b24..1b56dbc1f304 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c @@ -459,6 +459,7 @@ amdgpu_dma_buf_create_obj(struct drm_device *dev, struct dma_buf *dma_buf) struct amdgpu_device *adev = drm_to_adev(dev); struct amdgpu_bo *bo; struct amdgpu_bo_param bp; + struct drm_gem_object *gobj; int ret; memset(&bp, 0, sizeof(bp)); @@ -469,17 +470,20 @@ amdgpu_dma_buf_create_obj(struct drm_device *dev, struct dma_buf *dma_buf) bp.type = ttm_bo_type_sg; bp.resv = resv; dma_resv_lock(resv, NULL); - ret = amdgpu_bo_create(adev, &bp, &bo); + ret = amdgpu_gem_object_create(adev, dma_buf->size, PAGE_SIZE, + AMDGPU_GEM_DOMAIN_CPU, + 0, ttm_bo_type_sg, resv, &gobj); if (ret) goto error; + bo = gem_to_amdgpu_bo(gobj); bo->allowed_domains = AMDGPU_GEM_DOMAIN_GTT; bo->preferred_domains = AMDGPU_GEM_DOMAIN_GTT; if (dma_buf->ops != &amdgpu_dmabuf_ops) bo->prime_shared_count = 1; dma_resv_unlock(resv); - return &bo->tbo.base; + return gobj; error: dma_resv_unlock(resv); diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c index 7e8265da9f25..e8c76bd8c501 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c @@ -66,26 +66,12 @@ int amdgpu_gem_object_create(struct amdgpu_device *adev, unsigned long size, bp.type = type; bp.resv = resv; bp.preferred_domain = initial_domain; -retry: bp.flags = flags; bp.domain = initial_domain; r = amdgpu_bo_create(adev, &bp, &bo); - if (r) { - if (r != -ERESTARTSYS) { - if (flags & AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED) { - flags &= ~AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED; - goto retry; - } - - if (initial_domain == AMDGPU_GEM_DOMAIN_VRAM) { - initial_domain |= AMDGPU_GEM_DOMAIN_GTT; - goto retry; - } - DRM_DEBUG("Failed to allocate GEM object (%ld, %d, %u, %d)\n", - size, initial_domain, alignment, r); - } + if (r) return r; - } + *obj = &bo->tbo.base; return 0; @@ -225,7 +211,7 @@ int amdgpu_gem_create_ioctl(struct drm_device *dev, void *data, uint64_t size = args->in.bo_size; struct dma_resv *resv = NULL; struct drm_gem_object *gobj; - uint32_t handle; + uint32_t handle, initial_domain; int r; /* reject invalid gem flags */ @@ -269,9 +255,28 @@ int amdgpu_gem_create_ioctl(struct drm_device *dev, void *data, resv = vm->root.base.bo->tbo.base.resv; } +retry: + initial_domain = (u32)(0xffffffff & args->in.domains); r = amdgpu_gem_object_create(adev, size, args->in.alignment, - (u32)(0xffffffff & args->in.domains), + initial_domain, flags, ttm_bo_type_device, resv, &gobj); + if (r) { + if (r != -ERESTARTSYS) { + if (flags & AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED) { + flags &= ~AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED; + goto retry; + } + + if (initial_domain == AMDGPU_GEM_DOMAIN_VRAM) { + initial_domain |= AMDGPU_GEM_DOMAIN_GTT; + goto retry; + } + DRM_DEBUG("Failed to allocate GEM object (%llu, %d, %llu, %d)\n", + size, initial_domain, args->in.alignment, r); + } + return r; + } + if (flags & AMDGPU_GEM_CREATE_VM_ALWAYS_VALID) { if (!r) { struct amdgpu_bo *abo = gem_to_amdgpu_bo(gobj); From c5b58c8c860db330c0b8b891b69014ee9d470dab Mon Sep 17 00:00:00 2001 From: Evan Quan Date: Wed, 9 Dec 2020 16:34:22 +0800 Subject: [PATCH 39/59] drm/amd/pm: typo fix (CUSTOM -> COMPUTE) The "COMPUTE" was wrongly spelled as "CUSTOM". Signed-off-by: Evan Quan Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org # 5.9.x --- drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c index 895d89bea7fa..cf7c4f0e0a0b 100644 --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c @@ -217,7 +217,7 @@ static struct cmn2asic_mapping sienna_cichlid_workload_map[PP_SMC_POWER_PROFILE_ WORKLOAD_MAP(PP_SMC_POWER_PROFILE_POWERSAVING, WORKLOAD_PPLIB_POWER_SAVING_BIT), WORKLOAD_MAP(PP_SMC_POWER_PROFILE_VIDEO, WORKLOAD_PPLIB_VIDEO_BIT), WORKLOAD_MAP(PP_SMC_POWER_PROFILE_VR, WORKLOAD_PPLIB_VR_BIT), - WORKLOAD_MAP(PP_SMC_POWER_PROFILE_COMPUTE, WORKLOAD_PPLIB_CUSTOM_BIT), + WORKLOAD_MAP(PP_SMC_POWER_PROFILE_COMPUTE, WORKLOAD_PPLIB_COMPUTE_BIT), WORKLOAD_MAP(PP_SMC_POWER_PROFILE_CUSTOM, WORKLOAD_PPLIB_CUSTOM_BIT), }; From 6bea0225a4bf14a58af71cb9677a756921469e46 Mon Sep 17 00:00:00 2001 From: Damien Le Moal Date: Wed, 9 Dec 2020 20:16:10 +0900 Subject: [PATCH 40/59] zonefs: fix page reference and BIO leak In zonefs_file_dio_append(), the pages obtained using bio_iov_iter_get_pages() are not released on completion of the REQ_OP_APPEND BIO, nor when bio_iov_iter_get_pages() fails. Furthermore, a call to bio_put() is missing when bio_iov_iter_get_pages() fails. Fix these resource leaks by adding BIO resource release code (bio_put()i and bio_release_pages()) at the end of the function after the BIO execution and add a jump to this resource cleanup code in case of bio_iov_iter_get_pages() failure. While at it, also fix the call to task_io_account_write() to be passed the correct BIO size instead of bio_iov_iter_get_pages() return value. Reported-by: Christoph Hellwig Fixes: 02ef12a663c7 ("zonefs: use REQ_OP_ZONE_APPEND for sync DIO") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal Reviewed-by: Chaitanya Kulkarni Reviewed-by: Christoph Hellwig --- fs/zonefs/super.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/fs/zonefs/super.c b/fs/zonefs/super.c index ff5930be096c..bec47f2d074b 100644 --- a/fs/zonefs/super.c +++ b/fs/zonefs/super.c @@ -691,21 +691,23 @@ static ssize_t zonefs_file_dio_append(struct kiocb *iocb, struct iov_iter *from) bio->bi_opf |= REQ_FUA; ret = bio_iov_iter_get_pages(bio, from); - if (unlikely(ret)) { - bio_io_error(bio); - return ret; - } + if (unlikely(ret)) + goto out_release; + size = bio->bi_iter.bi_size; - task_io_account_write(ret); + task_io_account_write(size); if (iocb->ki_flags & IOCB_HIPRI) bio_set_polled(bio, iocb); ret = submit_bio_wait(bio); + zonefs_file_write_dio_end_io(iocb, size, ret, 0); + +out_release: + bio_release_pages(bio, false); bio_put(bio); - zonefs_file_write_dio_end_io(iocb, size, ret, 0); if (ret >= 0) { iocb->ki_pos += size; return size; From b1f195fc49812359296a901e26cc7c0b761d8a70 Mon Sep 17 00:00:00 2001 From: Chris Wilson Date: Thu, 10 Dec 2020 23:07:41 +0000 Subject: [PATCH 41/59] drm/i915/display: Go softly softly on initial modeset failure MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Reduce the module/device probe error into a mere debug to hide issues where the initial modeset is failing (after lies told by hw probe) and the system hangs with a livelock in cleaning up the failed commit. Reported-by: H.J. Lu Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=210619 Fixes: b3bf99daaee9 ("drm/i915/display: Defer initial modeset until after GGTT is initialised") Fixes: ccc9e67ab26f ("drm/i915/display: Defer initial modeset until after GGTT is initialised") Signed-off-by: Chris Wilson Cc: "Ville Syrjälä" Cc: Rodrigo Vivi Cc: H.J. Lu Cc: Dave Airlie Reviewed-by: Rodrigo Vivi Signed-off-by: Dave Airlie Link: https://patchwork.freedesktop.org/patch/msgid/20201210230741.17140-1-chris@chris-wilson.co.uk --- drivers/gpu/drm/i915/display/intel_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index 3bfe6ed67da1..aabf09f89cad 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -18040,7 +18040,7 @@ int intel_modeset_init(struct drm_i915_private *i915) */ ret = intel_initial_commit(&i915->drm); if (ret) - return ret; + drm_dbg_kms(&i915->drm, "Initial modeset failed, %d\n", ret); intel_overlay_setup(i915); From 249a9599c9123a4af655dd5800c2506602ffa055 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Thu, 3 Dec 2020 20:03:32 +0100 Subject: [PATCH 42/59] mtd: rawnand: ams-delta: Do not force a particular software ECC engine Originally, commit d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") kind of broke the logic around the initialization of several ECC engines. Unfortunately, the fix (which indeed moved the ECC initialization to the right place) did not take into account the fact that a different ECC algorithm could have been used thanks to a DT property, considering the "Hamming" algorithm entry a configuration while it was only a default. Add the necessary logic to be sure Hamming keeps being only a default. Fixes: 59d93473323a ("mtd: rawnand: ams-delta: Move the ECC initialization to ->attach_chip()") Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-2-miquel.raynal@bootlin.com --- drivers/mtd/nand/raw/ams-delta.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/nand/raw/ams-delta.c b/drivers/mtd/nand/raw/ams-delta.c index 0c352b39ad4b..ff1697f899ba 100644 --- a/drivers/mtd/nand/raw/ams-delta.c +++ b/drivers/mtd/nand/raw/ams-delta.c @@ -218,7 +218,9 @@ static int gpio_nand_setup_interface(struct nand_chip *this, int csline, static int gpio_nand_attach_chip(struct nand_chip *chip) { chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; - chip->ecc.algo = NAND_ECC_ALGO_HAMMING; + + if (chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) + chip->ecc.algo = NAND_ECC_ALGO_HAMMING; return 0; } From 52277269c4060ced7e7d1a83c77377590d106f44 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Thu, 3 Dec 2020 20:03:33 +0100 Subject: [PATCH 43/59] mtd: rawnand: au1550: Do not force a particular software ECC engine Originally, commit d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") kind of broke the logic around the initialization of several ECC engines. Unfortunately, the fix (which indeed moved the ECC initialization to the right place) did not take into account the fact that a different ECC algorithm could have been used thanks to a DT property, considering the "Hamming" algorithm entry a configuration while it was only a default. Add the necessary logic to be sure Hamming keeps being only a default. Fixes: dbffc8ccdf3a ("mtd: rawnand: au1550: Move the ECC initialization to ->attach_chip()") Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-3-miquel.raynal@bootlin.com --- drivers/mtd/nand/raw/au1550nd.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/nand/raw/au1550nd.c b/drivers/mtd/nand/raw/au1550nd.c index 7892022bd6dd..7b6b354f2d39 100644 --- a/drivers/mtd/nand/raw/au1550nd.c +++ b/drivers/mtd/nand/raw/au1550nd.c @@ -239,7 +239,9 @@ static int au1550nd_exec_op(struct nand_chip *this, static int au1550nd_attach_chip(struct nand_chip *chip) { chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; - chip->ecc.algo = NAND_ECC_ALGO_HAMMING; + + if (chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) + chip->ecc.algo = NAND_ECC_ALGO_HAMMING; return 0; } From bd47fa451315684424d2b39aa95f2ed235fee37a Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Thu, 3 Dec 2020 20:03:34 +0100 Subject: [PATCH 44/59] mtd: rawnand: gpio: Do not force a particular software ECC engine Originally, commit d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") kind of broke the logic around the initialization of several ECC engines. Unfortunately, the fix (which indeed moved the ECC initialization to the right place) did not take into account the fact that a different ECC algorithm could have been used thanks to a DT property, considering the "Hamming" algorithm entry a configuration while it was only a default. Add the necessary logic to be sure Hamming keeps being only a default. Fixes: f6341f6448e0 ("mtd: rawnand: gpio: Move the ECC initialization to ->attach_chip()") Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-4-miquel.raynal@bootlin.com --- drivers/mtd/nand/raw/gpio.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/nand/raw/gpio.c b/drivers/mtd/nand/raw/gpio.c index eb03b8cea1cb..fb7a086de35e 100644 --- a/drivers/mtd/nand/raw/gpio.c +++ b/drivers/mtd/nand/raw/gpio.c @@ -164,7 +164,9 @@ static int gpio_nand_exec_op(struct nand_chip *chip, static int gpio_nand_attach_chip(struct nand_chip *chip) { chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; - chip->ecc.algo = NAND_ECC_ALGO_HAMMING; + + if (chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) + chip->ecc.algo = NAND_ECC_ALGO_HAMMING; return 0; } From f49bde9fe25cf4cd02440a7ec68f278957ddea37 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Thu, 3 Dec 2020 20:03:35 +0100 Subject: [PATCH 45/59] mtd: rawnand: mpc5121: Do not force a particular software ECC engine Originally, commit d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") kind of broke the logic around the initialization of several ECC engines. Unfortunately, the fix (which indeed moved the ECC initialization to the right place) did not take into account the fact that a different ECC algorithm could have been used thanks to a DT property, considering the "Hamming" algorithm entry a configuration while it was only a default. Add the necessary logic to be sure Hamming keeps being only a default. Fixes: 6dd09f775b72 ("mtd: rawnand: mpc5121: Move the ECC initialization to ->attach_chip()") Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-5-miquel.raynal@bootlin.com --- drivers/mtd/nand/raw/mpc5121_nfc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/nand/raw/mpc5121_nfc.c b/drivers/mtd/nand/raw/mpc5121_nfc.c index fb4c0b11689f..bcd4a556c959 100644 --- a/drivers/mtd/nand/raw/mpc5121_nfc.c +++ b/drivers/mtd/nand/raw/mpc5121_nfc.c @@ -606,7 +606,9 @@ static void mpc5121_nfc_free(struct device *dev, struct mtd_info *mtd) static int mpc5121_nfc_attach_chip(struct nand_chip *chip) { chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; - chip->ecc.algo = NAND_ECC_ALGO_HAMMING; + + if (chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) + chip->ecc.algo = NAND_ECC_ALGO_HAMMING; return 0; } From f87b720a21641d5c5ccd4f5ccc06d96251b7f282 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Thu, 3 Dec 2020 20:03:36 +0100 Subject: [PATCH 46/59] mtd: rawnand: orion: Do not force a particular software ECC engine Originally, commit d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") kind of broke the logic around the initialization of several ECC engines. Unfortunately, the fix (which indeed moved the ECC initialization to the right place) did not take into account the fact that a different ECC algorithm could have been used thanks to a DT property, considering the "Hamming" algorithm entry a configuration while it was only a default. Add the necessary logic to be sure Hamming keeps being only a default. Reported-by: Chris Packham Fixes: 553508cec2e8 ("mtd: rawnand: orion: Move the ECC initialization to ->attach_chip()") Signed-off-by: Miquel Raynal Tested-by: Chris Packham Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-6-miquel.raynal@bootlin.com --- drivers/mtd/nand/raw/orion_nand.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/nand/raw/orion_nand.c b/drivers/mtd/nand/raw/orion_nand.c index e3bb65fd3ab2..66211c9311d2 100644 --- a/drivers/mtd/nand/raw/orion_nand.c +++ b/drivers/mtd/nand/raw/orion_nand.c @@ -86,7 +86,9 @@ static void orion_nand_read_buf(struct nand_chip *chip, uint8_t *buf, int len) static int orion_nand_attach_chip(struct nand_chip *chip) { chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; - chip->ecc.algo = NAND_ECC_ALGO_HAMMING; + + if (chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) + chip->ecc.algo = NAND_ECC_ALGO_HAMMING; return 0; } From 9506ab943db438d316386d45eb8a8b60bfeee27c Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Thu, 3 Dec 2020 20:03:37 +0100 Subject: [PATCH 47/59] mtd: rawnand: pasemi: Do not force a particular software ECC engine Originally, commit d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") kind of broke the logic around the initialization of several ECC engines. Unfortunately, the fix (which indeed moved the ECC initialization to the right place) did not take into account the fact that a different ECC algorithm could have been used thanks to a DT property, considering the "Hamming" algorithm entry a configuration while it was only a default. Add the necessary logic to be sure Hamming keeps being only a default. Fixes: 8fc6f1f042b2 ("mtd: rawnand: pasemi: Move the ECC initialization to ->attach_chip()") Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-7-miquel.raynal@bootlin.com --- drivers/mtd/nand/raw/pasemi_nand.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/nand/raw/pasemi_nand.c b/drivers/mtd/nand/raw/pasemi_nand.c index 4dfff34800f4..68c08772d7c2 100644 --- a/drivers/mtd/nand/raw/pasemi_nand.c +++ b/drivers/mtd/nand/raw/pasemi_nand.c @@ -77,7 +77,9 @@ static int pasemi_device_ready(struct nand_chip *chip) static int pasemi_attach_chip(struct nand_chip *chip) { chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; - chip->ecc.algo = NAND_ECC_ALGO_HAMMING; + + if (chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) + chip->ecc.algo = NAND_ECC_ALGO_HAMMING; return 0; } From 148b4f16159f49c6d05da8189e0941880ad10a46 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Thu, 3 Dec 2020 20:03:38 +0100 Subject: [PATCH 48/59] mtd: rawnand: plat_nand: Do not force a particular software ECC engine Originally, commit d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") kind of broke the logic around the initialization of several ECC engines. Unfortunately, the fix (which indeed moved the ECC initialization to the right place) did not take into account the fact that a different ECC algorithm could have been used thanks to a DT property, considering the "Hamming" algorithm entry a configuration while it was only a default. Add the necessary logic to be sure Hamming keeps being only a default. Fixes: 612e048e6aab ("mtd: rawnand: plat_nand: Move the ECC initialization to ->attach_chip()") Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-8-miquel.raynal@bootlin.com --- drivers/mtd/nand/raw/plat_nand.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/nand/raw/plat_nand.c b/drivers/mtd/nand/raw/plat_nand.c index 93d9f1694dc1..7711e1020c21 100644 --- a/drivers/mtd/nand/raw/plat_nand.c +++ b/drivers/mtd/nand/raw/plat_nand.c @@ -22,7 +22,9 @@ struct plat_nand_data { static int plat_nand_attach_chip(struct nand_chip *chip) { chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; - chip->ecc.algo = NAND_ECC_ALGO_HAMMING; + + if (chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) + chip->ecc.algo = NAND_ECC_ALGO_HAMMING; return 0; } From cf75f00fc8026040f6ff8f054cfec99e820b62e7 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Thu, 3 Dec 2020 20:03:39 +0100 Subject: [PATCH 49/59] mtd: rawnand: socrates: Do not force a particular software ECC engine Originally, commit d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") kind of broke the logic around the initialization of several ECC engines. Unfortunately, the fix (which indeed moved the ECC initialization to the right place) did not take into account the fact that a different ECC algorithm could have been used thanks to a DT property, considering the "Hamming" algorithm entry a configuration while it was only a default. Add the necessary logic to be sure Hamming keeps being only a default. Fixes: b36bf0a0fe5d ("mtd: rawnand: socrates: Move the ECC initialization to ->attach_chip()") Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-9-miquel.raynal@bootlin.com --- drivers/mtd/nand/raw/socrates_nand.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/nand/raw/socrates_nand.c b/drivers/mtd/nand/raw/socrates_nand.c index 107208311987..70f8305c9b6e 100644 --- a/drivers/mtd/nand/raw/socrates_nand.c +++ b/drivers/mtd/nand/raw/socrates_nand.c @@ -120,7 +120,9 @@ static int socrates_nand_device_ready(struct nand_chip *nand_chip) static int socrates_attach_chip(struct nand_chip *chip) { chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; - chip->ecc.algo = NAND_ECC_ALGO_HAMMING; + + if (chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) + chip->ecc.algo = NAND_ECC_ALGO_HAMMING; return 0; } From 33d974e76e21e9da8a36b14d2dce6394c36c3e30 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Thu, 3 Dec 2020 20:03:40 +0100 Subject: [PATCH 50/59] mtd: rawnand: xway: Do not force a particular software ECC engine Originally, commit d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") kind of broke the logic around the initialization of several ECC engines. Unfortunately, the fix (which indeed moved the ECC initialization to the right place) did not take into account the fact that a different ECC algorithm could have been used thanks to a DT property, considering the "Hamming" algorithm entry a configuration while it was only a default. Add the necessary logic to be sure Hamming keeps being only a default. Fixes: d525914b5bd8 ("mtd: rawnand: xway: Move the ECC initialization to ->attach_chip()") Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-10-miquel.raynal@bootlin.com --- drivers/mtd/nand/raw/xway_nand.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/nand/raw/xway_nand.c b/drivers/mtd/nand/raw/xway_nand.c index efc5bf5434e0..26751976e502 100644 --- a/drivers/mtd/nand/raw/xway_nand.c +++ b/drivers/mtd/nand/raw/xway_nand.c @@ -149,7 +149,9 @@ static void xway_write_buf(struct nand_chip *chip, const u_char *buf, int len) static int xway_attach_chip(struct nand_chip *chip) { chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; - chip->ecc.algo = NAND_ECC_ALGO_HAMMING; + + if (chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) + chip->ecc.algo = NAND_ECC_ALGO_HAMMING; return 0; } From 16c0cc0ce3059e315a0aab6538061d95a6612589 Mon Sep 17 00:00:00 2001 From: Andrew Morton Date: Fri, 11 Dec 2020 13:36:27 -0800 Subject: [PATCH 51/59] revert "mm/filemap: add static for function __add_to_page_cache_locked" Revert commit 3351b16af494 ("mm/filemap: add static for function __add_to_page_cache_locked") due to incompatibility with ALLOW_ERROR_INJECTION which result in build errors. Link: https://lkml.kernel.org/r/CAADnVQJ6tmzBXvtroBuEH6QA0H+q7yaSKxrVvVxhqr3KBZdEXg@mail.gmail.com Tested-by: Justin Forbes Tested-by: Greg Thelen Acked-by: Alexei Starovoitov Cc: Michal Kubecek Cc: Alex Shi Cc: Souptick Joarder Cc: Daniel Borkmann Cc: Josef Bacik Cc: Tony Luck Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- mm/filemap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/filemap.c b/mm/filemap.c index 331f4261d723..0b2067b3c328 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -827,7 +827,7 @@ int replace_page_cache_page(struct page *old, struct page *new, gfp_t gfp_mask) } EXPORT_SYMBOL_GPL(replace_page_cache_page); -static noinline int __add_to_page_cache_locked(struct page *page, +noinline int __add_to_page_cache_locked(struct page *page, struct address_space *mapping, pgoff_t offset, gfp_t gfp, void **shadowp) From 40d6366e9d86d9a67b5642040e76082fdb5bdcf9 Mon Sep 17 00:00:00 2001 From: Miles Chen Date: Fri, 11 Dec 2020 13:36:31 -0800 Subject: [PATCH 52/59] proc: use untagged_addr() for pagemap_read addresses When we try to visit the pagemap of a tagged userspace pointer, we find that the start_vaddr is not correct because of the tag. To fix it, we should untag the userspace pointers in pagemap_read(). I tested with 5.10-rc4 and the issue remains. Explanation from Catalin in [1]: "Arguably, that's a user-space bug since tagged file offsets were never supported. In this case it's not even a tag at bit 56 as per the arm64 tagged address ABI but rather down to bit 47. You could say that the problem is caused by the C library (malloc()) or whoever created the tagged vaddr and passed it to this function. It's not a kernel regression as we've never supported it. Now, pagemap is a special case where the offset is usually not generated as a classic file offset but rather derived by shifting a user virtual address. I guess we can make a concession for pagemap (only) and allow such offset with the tag at bit (56 - PAGE_SHIFT + 3)" My test code is based on [2]: A userspace pointer which has been tagged by 0xb4: 0xb400007662f541c8 userspace program: uint64 OsLayer::VirtualToPhysical(void *vaddr) { uint64 frame, paddr, pfnmask, pagemask; int pagesize = sysconf(_SC_PAGESIZE); off64_t off = ((uintptr_t)vaddr) / pagesize * 8; // off = 0xb400007662f541c8 / pagesize * 8 = 0x5a00003b317aa0 int fd = open(kPagemapPath, O_RDONLY); ... if (lseek64(fd, off, SEEK_SET) != off || read(fd, &frame, 8) != 8) { int err = errno; string errtxt = ErrorString(err); if (fd >= 0) close(fd); return 0; } ... } kernel fs/proc/task_mmu.c: static ssize_t pagemap_read(struct file *file, char __user *buf, size_t count, loff_t *ppos) { ... src = *ppos; svpfn = src / PM_ENTRY_BYTES; // svpfn == 0xb400007662f54 start_vaddr = svpfn << PAGE_SHIFT; // start_vaddr == 0xb400007662f54000 end_vaddr = mm->task_size; /* watch out for wraparound */ // svpfn == 0xb400007662f54 // (mm->task_size >> PAGE) == 0x8000000 if (svpfn > mm->task_size >> PAGE_SHIFT) // the condition is true because of the tag 0xb4 start_vaddr = end_vaddr; ret = 0; while (count && (start_vaddr < end_vaddr)) { // we cannot visit correct entry because start_vaddr is set to end_vaddr int len; unsigned long end; ... } ... } [1] https://lore.kernel.org/patchwork/patch/1343258/ [2] https://github.com/stressapptest/stressapptest/blob/master/src/os.cc#L158 Link: https://lkml.kernel.org/r/20201204024347.8295-1-miles.chen@mediatek.com Signed-off-by: Miles Chen Reviewed-by: Vincenzo Frascino Reviewed-by: Catalin Marinas Cc: Alexey Dobriyan Cc: Andrey Konovalov Cc: Alexander Potapenko Cc: Vincenzo Frascino Cc: Andrey Ryabinin Cc: Catalin Marinas Cc: Dmitry Vyukov Cc: Marco Elver Cc: Will Deacon Cc: Eric W. Biederman Cc: Song Bao Hua (Barry Song) Cc: [5.4-] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- fs/proc/task_mmu.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c index 217aa2705d5d..ee5a235b3056 100644 --- a/fs/proc/task_mmu.c +++ b/fs/proc/task_mmu.c @@ -1599,11 +1599,15 @@ static ssize_t pagemap_read(struct file *file, char __user *buf, src = *ppos; svpfn = src / PM_ENTRY_BYTES; - start_vaddr = svpfn << PAGE_SHIFT; end_vaddr = mm->task_size; /* watch out for wraparound */ - if (svpfn > mm->task_size >> PAGE_SHIFT) + start_vaddr = end_vaddr; + if (svpfn <= (ULONG_MAX >> PAGE_SHIFT)) + start_vaddr = untagged_addr(svpfn << PAGE_SHIFT); + + /* Ensure the address is inside the task */ + if (start_vaddr > mm->task_size) start_vaddr = end_vaddr; /* From 84edc2eff82730d45ab513ecec49cb63beb973c9 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann Date: Fri, 11 Dec 2020 13:36:35 -0800 Subject: [PATCH 53/59] selftest/fpu: avoid clang warning With extra warnings enabled, clang complains about the redundant -mhard-float argument: clang: error: argument unused during compilation: '-mhard-float' [-Werror,-Wunused-command-line-argument] Move this into the gcc-only part of the Makefile. Link: https://lkml.kernel.org/r/20201203223652.1320700-1-arnd@kernel.org Fixes: 4185b3b92792 ("selftests/fpu: Add an FPU selftest") Signed-off-by: Arnd Bergmann Cc: Nathan Chancellor Cc: Nick Desaulniers Cc: Petteri Aimonen Cc: Borislav Petkov Cc: Arnd Bergmann Cc: Andy Shevchenko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- lib/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/Makefile b/lib/Makefile index ce45af50983a..d415fc7067c5 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -107,7 +107,7 @@ obj-$(CONFIG_TEST_FREE_PAGES) += test_free_pages.o # off the generation of FPU/SSE* instructions for kernel proper but FPU_FLAGS # get appended last to CFLAGS and thus override those previous compiler options. # -FPU_CFLAGS := -mhard-float -msse -msse2 +FPU_CFLAGS := -msse -msse2 ifdef CONFIG_CC_IS_GCC # Stack alignment mismatch, proceed with caution. # GCC < 7.1 cannot compile code using `double` and -mpreferred-stack-boundary=3 @@ -120,6 +120,7 @@ ifdef CONFIG_CC_IS_GCC # -mpreferred-stack-boundary=3 is not between 4 and 12 # # can be triggered. Otherwise gcc doesn't complain. +FPU_CFLAGS += -mhard-float FPU_CFLAGS += $(call cc-option,-msse -mpreferred-stack-boundary=3,-mpreferred-stack-boundary=4) endif From 14dc3983b5dff513a90bd5a8cc90acaf7867c3d0 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann Date: Fri, 11 Dec 2020 13:36:38 -0800 Subject: [PATCH 54/59] kbuild: avoid static_assert for genksyms genksyms does not know or care about the _Static_assert() built-in, and sometimes falls back to ignoring the later symbols, which causes undefined behavior such as WARNING: modpost: EXPORT symbol "ethtool_set_ethtool_phy_ops" [vmlinux] version generation failed, symbol will not be versioned. ld: net/ethtool/common.o: relocation R_AARCH64_ABS32 against `__crc_ethtool_set_ethtool_phy_ops' can not be used when making a shared object net/ethtool/common.o:(_ftrace_annotated_branch+0x0): dangerous relocation: unsupported relocation Redefine static_assert for genksyms to avoid that. Link: https://lkml.kernel.org/r/20201203230955.1482058-1-arnd@kernel.org Signed-off-by: Arnd Bergmann Suggested-by: Ard Biesheuvel Cc: Masahiro Yamada Cc: Michal Marek Cc: Kees Cook Cc: Rikard Falkeborn Cc: Marco Elver Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- include/linux/build_bug.h | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/include/linux/build_bug.h b/include/linux/build_bug.h index e3a0be2c90ad..7bb66e15b481 100644 --- a/include/linux/build_bug.h +++ b/include/linux/build_bug.h @@ -77,4 +77,9 @@ #define static_assert(expr, ...) __static_assert(expr, ##__VA_ARGS__, #expr) #define __static_assert(expr, msg, ...) _Static_assert(expr, msg) +#ifdef __GENKSYMS__ +/* genksyms gets confused by _Static_assert */ +#define _Static_assert(expr, ...) +#endif + #endif /* _LINUX_BUILD_BUG_H */ From 55d5b7dd6451b58489ce384282ca5a4a289eb8d5 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann Date: Fri, 11 Dec 2020 13:36:42 -0800 Subject: [PATCH 55/59] initramfs: fix clang build failure There is only one function in init/initramfs.c that is in the .text section, and it is marked __weak. When building with clang-12 and the integrated assembler, this leads to a bug with recordmcount: ./scripts/recordmcount "init/initramfs.o" Cannot find symbol for section 2: .text. init/initramfs.o: failed I'm not quite sure what exactly goes wrong, but I notice that this function is only ever called from an __init function, and normally inlined. Marking it __init as well is clearly correct and it leads to recordmcount no longer complaining. Link: https://lkml.kernel.org/r/20201204165742.3815221-1-arnd@kernel.org Signed-off-by: Arnd Bergmann Cc: Nathan Chancellor Cc: Nick Desaulniers Cc: Barret Rhoden Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- init/initramfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/init/initramfs.c b/init/initramfs.c index 1f97c0328a7a..55b74d7e5260 100644 --- a/init/initramfs.c +++ b/init/initramfs.c @@ -535,7 +535,7 @@ extern unsigned long __initramfs_size; #include #include -void __weak free_initrd_mem(unsigned long start, unsigned long end) +void __weak __init free_initrd_mem(unsigned long start, unsigned long end) { #ifdef CONFIG_ARCH_KEEP_MEMBLOCK unsigned long aligned_start = ALIGN_DOWN(start, PAGE_SIZE); From 6e7b64b9dd6d96537d816ea07ec26b7dedd397b9 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann Date: Fri, 11 Dec 2020 13:36:46 -0800 Subject: [PATCH 56/59] elfcore: fix building with clang kernel/elfcore.c only contains weak symbols, which triggers a bug with clang in combination with recordmcount: Cannot find symbol for section 2: .text. kernel/elfcore.o: failed Move the empty stubs into linux/elfcore.h as inline functions. As only two architectures use these, just use the architecture specific Kconfig symbols to key off the declaration. Link: https://lkml.kernel.org/r/20201204165742.3815221-2-arnd@kernel.org Signed-off-by: Arnd Bergmann Cc: Nathan Chancellor Cc: Nick Desaulniers Cc: Barret Rhoden Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- include/linux/elfcore.h | 22 ++++++++++++++++++++++ kernel/Makefile | 1 - kernel/elfcore.c | 26 -------------------------- 3 files changed, 22 insertions(+), 27 deletions(-) delete mode 100644 kernel/elfcore.c diff --git a/include/linux/elfcore.h b/include/linux/elfcore.h index 46c3d691f677..de51c1bef27d 100644 --- a/include/linux/elfcore.h +++ b/include/linux/elfcore.h @@ -104,6 +104,7 @@ static inline int elf_core_copy_task_fpregs(struct task_struct *t, struct pt_reg #endif } +#if defined(CONFIG_UM) || defined(CONFIG_IA64) /* * These functions parameterize elf_core_dump in fs/binfmt_elf.c to write out * extra segments containing the gate DSO contents. Dumping its @@ -118,5 +119,26 @@ elf_core_write_extra_phdrs(struct coredump_params *cprm, loff_t offset); extern int elf_core_write_extra_data(struct coredump_params *cprm); extern size_t elf_core_extra_data_size(void); +#else +static inline Elf_Half elf_core_extra_phdrs(void) +{ + return 0; +} + +static inline int elf_core_write_extra_phdrs(struct coredump_params *cprm, loff_t offset) +{ + return 1; +} + +static inline int elf_core_write_extra_data(struct coredump_params *cprm) +{ + return 1; +} + +static inline size_t elf_core_extra_data_size(void) +{ + return 0; +} +#endif #endif /* _LINUX_ELFCORE_H */ diff --git a/kernel/Makefile b/kernel/Makefile index af601b9bda0e..6c9f19911be0 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -97,7 +97,6 @@ obj-$(CONFIG_TASK_DELAY_ACCT) += delayacct.o obj-$(CONFIG_TASKSTATS) += taskstats.o tsacct.o obj-$(CONFIG_TRACEPOINTS) += tracepoint.o obj-$(CONFIG_LATENCYTOP) += latencytop.o -obj-$(CONFIG_ELFCORE) += elfcore.o obj-$(CONFIG_FUNCTION_TRACER) += trace/ obj-$(CONFIG_TRACING) += trace/ obj-$(CONFIG_TRACE_CLOCK) += trace/ diff --git a/kernel/elfcore.c b/kernel/elfcore.c deleted file mode 100644 index 57fb4dcff434..000000000000 --- a/kernel/elfcore.c +++ /dev/null @@ -1,26 +0,0 @@ -// SPDX-License-Identifier: GPL-2.0 -#include -#include -#include -#include -#include - -Elf_Half __weak elf_core_extra_phdrs(void) -{ - return 0; -} - -int __weak elf_core_write_extra_phdrs(struct coredump_params *cprm, loff_t offset) -{ - return 1; -} - -int __weak elf_core_write_extra_data(struct coredump_params *cprm) -{ - return 1; -} - -size_t __weak elf_core_extra_data_size(void) -{ - return 0; -} From 6c82d45c7f0348b44e00bd7dcccfc47dec7577d1 Mon Sep 17 00:00:00 2001 From: Kuan-Ying Lee Date: Fri, 11 Dec 2020 13:36:49 -0800 Subject: [PATCH 57/59] kasan: fix object remaining in offline per-cpu quarantine We hit this issue in our internal test. When enabling generic kasan, a kfree()'d object is put into per-cpu quarantine first. If the cpu goes offline, object still remains in the per-cpu quarantine. If we call kmem_cache_destroy() now, slub will report "Objects remaining" error. ============================================================================= BUG test_module_slab (Not tainted): Objects remaining in test_module_slab on __kmem_cache_shutdown() ----------------------------------------------------------------------------- Disabling lock debugging due to kernel taint INFO: Slab 0x(____ptrval____) objects=34 used=1 fp=0x(____ptrval____) flags=0x2ffff00000010200 CPU: 3 PID: 176 Comm: cat Tainted: G B 5.10.0-rc1-00007-g4525c8781ec0-dirty #10 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0x0/0x2b0 show_stack+0x18/0x68 dump_stack+0xfc/0x168 slab_err+0xac/0xd4 __kmem_cache_shutdown+0x1e4/0x3c8 kmem_cache_destroy+0x68/0x130 test_version_show+0x84/0xf0 module_attr_show+0x40/0x60 sysfs_kf_seq_show+0x128/0x1c0 kernfs_seq_show+0xa0/0xb8 seq_read+0x1f0/0x7e8 kernfs_fop_read+0x70/0x338 vfs_read+0xe4/0x250 ksys_read+0xc8/0x180 __arm64_sys_read+0x44/0x58 el0_svc_common.constprop.0+0xac/0x228 do_el0_svc+0x38/0xa0 el0_sync_handler+0x170/0x178 el0_sync+0x174/0x180 INFO: Object 0x(____ptrval____) @offset=15848 INFO: Allocated in test_version_show+0x98/0xf0 age=8188 cpu=6 pid=172 stack_trace_save+0x9c/0xd0 set_track+0x64/0xf0 alloc_debug_processing+0x104/0x1a0 ___slab_alloc+0x628/0x648 __slab_alloc.isra.0+0x2c/0x58 kmem_cache_alloc+0x560/0x588 test_version_show+0x98/0xf0 module_attr_show+0x40/0x60 sysfs_kf_seq_show+0x128/0x1c0 kernfs_seq_show+0xa0/0xb8 seq_read+0x1f0/0x7e8 kernfs_fop_read+0x70/0x338 vfs_read+0xe4/0x250 ksys_read+0xc8/0x180 __arm64_sys_read+0x44/0x58 el0_svc_common.constprop.0+0xac/0x228 kmem_cache_destroy test_module_slab: Slab cache still has objects Register a cpu hotplug function to remove all objects in the offline per-cpu quarantine when cpu is going offline. Set a per-cpu variable to indicate this cpu is offline. [qiang.zhang@windriver.com: fix slab double free when cpu-hotplug] Link: https://lkml.kernel.org/r/20201204102206.20237-1-qiang.zhang@windriver.com Link: https://lkml.kernel.org/r/1606895585-17382-2-git-send-email-Kuan-Ying.Lee@mediatek.com Signed-off-by: Kuan-Ying Lee Signed-off-by: Zqiang Suggested-by: Dmitry Vyukov Reported-by: Guangye Yang Reviewed-by: Dmitry Vyukov Cc: Andrey Ryabinin Cc: Alexander Potapenko Cc: Matthias Brugger Cc: Nicholas Tang Cc: Miles Chen Cc: Qian Cai Cc: Stephen Rothwell Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- mm/kasan/quarantine.c | 39 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) diff --git a/mm/kasan/quarantine.c b/mm/kasan/quarantine.c index 4c5375810449..0e3f8494628f 100644 --- a/mm/kasan/quarantine.c +++ b/mm/kasan/quarantine.c @@ -29,6 +29,7 @@ #include #include #include +#include #include "../slab.h" #include "kasan.h" @@ -43,6 +44,7 @@ struct qlist_head { struct qlist_node *head; struct qlist_node *tail; size_t bytes; + bool offline; }; #define QLIST_INIT { NULL, NULL, 0 } @@ -188,6 +190,10 @@ void quarantine_put(struct kasan_free_meta *info, struct kmem_cache *cache) local_irq_save(flags); q = this_cpu_ptr(&cpu_quarantine); + if (q->offline) { + local_irq_restore(flags); + return; + } qlist_put(q, &info->quarantine_link, cache->size); if (unlikely(q->bytes > QUARANTINE_PERCPU_SIZE)) { qlist_move_all(q, &temp); @@ -328,3 +334,36 @@ void quarantine_remove_cache(struct kmem_cache *cache) synchronize_srcu(&remove_cache_srcu); } + +static int kasan_cpu_online(unsigned int cpu) +{ + this_cpu_ptr(&cpu_quarantine)->offline = false; + return 0; +} + +static int kasan_cpu_offline(unsigned int cpu) +{ + struct qlist_head *q; + + q = this_cpu_ptr(&cpu_quarantine); + /* Ensure the ordering between the writing to q->offline and + * qlist_free_all. Otherwise, cpu_quarantine may be corrupted + * by interrupt. + */ + WRITE_ONCE(q->offline, true); + barrier(); + qlist_free_all(q, NULL); + return 0; +} + +static int __init kasan_cpu_quarantine_init(void) +{ + int ret = 0; + + ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "mm/kasan:online", + kasan_cpu_online, kasan_cpu_offline); + if (ret < 0) + pr_err("kasan cpu quarantine register failed [%d]\n", ret); + return ret; +} +late_initcall(kasan_cpu_quarantine_init); From ba9c1201beaa86a773e83be5654602a0667e4a4d Mon Sep 17 00:00:00 2001 From: Gerald Schaefer Date: Fri, 11 Dec 2020 13:36:53 -0800 Subject: [PATCH 58/59] mm/hugetlb: clear compound_nr before freeing gigantic pages Commit 1378a5ee451a ("mm: store compound_nr as well as compound_order") added compound_nr counter to first tail struct page, overlaying with page->mapping. The overlay itself is fine, but while freeing gigantic hugepages via free_contig_range(), a "bad page" check will trigger for non-NULL page->mapping on the first tail page: BUG: Bad page state in process bash pfn:380001 page:00000000c35f0856 refcount:0 mapcount:0 mapping:00000000126b68aa index:0x0 pfn:0x380001 aops:0x0 flags: 0x3ffff00000000000() raw: 3ffff00000000000 0000000000000100 0000000000000122 0000000100000000 raw: 0000000000000000 0000000000000000 ffffffff00000000 0000000000000000 page dumped because: non-NULL mapping Modules linked in: CPU: 6 PID: 616 Comm: bash Not tainted 5.10.0-rc7-next-20201208 #1 Hardware name: IBM 3906 M03 703 (LPAR) Call Trace: show_stack+0x6e/0xe8 dump_stack+0x90/0xc8 bad_page+0xd6/0x130 free_pcppages_bulk+0x26a/0x800 free_unref_page+0x6e/0x90 free_contig_range+0x94/0xe8 update_and_free_page+0x1c4/0x2c8 free_pool_huge_page+0x11e/0x138 set_max_huge_pages+0x228/0x300 nr_hugepages_store_common+0xb8/0x130 kernfs_fop_write+0xd2/0x218 vfs_write+0xb0/0x2b8 ksys_write+0xac/0xe0 system_call+0xe6/0x288 Disabling lock debugging due to kernel taint This is because only the compound_order is cleared in destroy_compound_gigantic_page(), and compound_nr is set to 1U << order == 1 for order 0 in set_compound_order(page, 0). Fix this by explicitly clearing compound_nr for first tail page after calling set_compound_order(page, 0). Link: https://lkml.kernel.org/r/20201208182813.66391-2-gerald.schaefer@linux.ibm.com Fixes: 1378a5ee451a ("mm: store compound_nr as well as compound_order") Signed-off-by: Gerald Schaefer Reviewed-by: Matthew Wilcox (Oracle) Cc: Heiko Carstens Cc: Mike Kravetz Cc: Christian Borntraeger Cc: [5.9+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- mm/hugetlb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 37f15c3c24dc..d029d938d26d 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -1216,6 +1216,7 @@ static void destroy_compound_gigantic_page(struct page *page, } set_compound_order(page, 0); + page[1].compound_nr = 0; __ClearPageHead(page); } From b7906b70a2337e445b8dca3ce7ba8976b6ebd07d Mon Sep 17 00:00:00 2001 From: Andrii Nakryiko Date: Fri, 11 Dec 2020 22:36:25 +0100 Subject: [PATCH 59/59] bpf: Fix enum names for bpf_this_cpu_ptr() and bpf_per_cpu_ptr() helpers Remove bpf_ prefix, which causes these helpers to be reported in verifier dump as bpf_bpf_this_cpu_ptr() and bpf_bpf_per_cpu_ptr(), respectively. Lets fix it as long as it is still possible before UAPI freezes on these helpers. Fixes: eaa6bcb71ef6 ("bpf: Introduce bpf_per_cpu_ptr()") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Signed-off-by: Linus Torvalds --- include/uapi/linux/bpf.h | 4 ++-- kernel/bpf/helpers.c | 4 ++-- kernel/trace/bpf_trace.c | 4 ++-- tools/include/uapi/linux/bpf.h | 4 ++-- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h index e6ceac3f7d62..556216dc9703 100644 --- a/include/uapi/linux/bpf.h +++ b/include/uapi/linux/bpf.h @@ -3897,8 +3897,8 @@ union bpf_attr { FN(seq_printf_btf), \ FN(skb_cgroup_classid), \ FN(redirect_neigh), \ - FN(bpf_per_cpu_ptr), \ - FN(bpf_this_cpu_ptr), \ + FN(per_cpu_ptr), \ + FN(this_cpu_ptr), \ FN(redirect_peer), \ /* */ diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c index 25520f5eeaf6..deda1185237b 100644 --- a/kernel/bpf/helpers.c +++ b/kernel/bpf/helpers.c @@ -717,9 +717,9 @@ bpf_base_func_proto(enum bpf_func_id func_id) return &bpf_snprintf_btf_proto; case BPF_FUNC_jiffies64: return &bpf_jiffies64_proto; - case BPF_FUNC_bpf_per_cpu_ptr: + case BPF_FUNC_per_cpu_ptr: return &bpf_per_cpu_ptr_proto; - case BPF_FUNC_bpf_this_cpu_ptr: + case BPF_FUNC_this_cpu_ptr: return &bpf_this_cpu_ptr_proto; default: break; diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c index 048c655315f1..a125ea5e04cd 100644 --- a/kernel/trace/bpf_trace.c +++ b/kernel/trace/bpf_trace.c @@ -1337,9 +1337,9 @@ bpf_tracing_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog) return prog->aux->sleepable ? &bpf_copy_from_user_proto : NULL; case BPF_FUNC_snprintf_btf: return &bpf_snprintf_btf_proto; - case BPF_FUNC_bpf_per_cpu_ptr: + case BPF_FUNC_per_cpu_ptr: return &bpf_per_cpu_ptr_proto; - case BPF_FUNC_bpf_this_cpu_ptr: + case BPF_FUNC_this_cpu_ptr: return &bpf_this_cpu_ptr_proto; default: return NULL; diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h index e6ceac3f7d62..556216dc9703 100644 --- a/tools/include/uapi/linux/bpf.h +++ b/tools/include/uapi/linux/bpf.h @@ -3897,8 +3897,8 @@ union bpf_attr { FN(seq_printf_btf), \ FN(skb_cgroup_classid), \ FN(redirect_neigh), \ - FN(bpf_per_cpu_ptr), \ - FN(bpf_this_cpu_ptr), \ + FN(per_cpu_ptr), \ + FN(this_cpu_ptr), \ FN(redirect_peer), \ /* */