[PATCH v11 1/3] dt-bindings: vendor-prefixes: Add asix prefix
Add the prefix for ASIX Electronics Corporation. Signed-off-by: Łukasz Stelmach Reviewed-by: Krzysztof Kozlowski Acked-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index e8c773478f54..b962f852ccaf 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -125,6 +125,8 @@ patternProperties: description: Asahi Kasei Corp. "^asc,.*": description: All Sensors Corporation + "^asix,.*": +description: ASIX Electronics Corporation "^aspeed,.*": description: ASPEED Technology Inc. "^asus,.*": -- 2.26.2
[PATCH v11 2/3] dt-bindings: net: Add bindings for AX88796C SPI Ethernet Adapter
Add bindings for AX88796C SPI Ethernet Adapter.
Signed-off-by: Łukasz Stelmach
Reviewed-by: Rob Herring
Acked-by: Krzysztof Kozlowski
---
.../bindings/net/asix,ax88796c.yaml | 73 +++
1 file changed, 73 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/asix,ax88796c.yaml
diff --git a/Documentation/devicetree/bindings/net/asix,ax88796c.yaml
b/Documentation/devicetree/bindings/net/asix,ax88796c.yaml
new file mode 100644
index ..699ebf452479
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/asix,ax88796c.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/asix,ax88796c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ASIX AX88796C SPI Ethernet Adapter
+
+maintainers:
+ - Łukasz Stelmach
+
+description: |
+ ASIX AX88796C is an Ethernet controller with a built in PHY. This
+ describes SPI mode of the chip.
+
+ The node for this driver must be a child node of an SPI controller,
+ hence all mandatory properties described in
+ ../spi/spi-controller.yaml must be specified.
+
+allOf:
+ - $ref: ethernet-controller.yaml#
+
+properties:
+ compatible:
+const: asix,ax88796c
+
+ reg:
+maxItems: 1
+
+ spi-max-frequency:
+maximum: 4000
+
+ interrupts:
+maxItems: 1
+
+ reset-gpios:
+description:
+ A GPIO line handling reset of the chip. As the line is active low,
+ it should be marked GPIO_ACTIVE_LOW.
+maxItems: 1
+
+ local-mac-address: true
+
+ mac-address: true
+
+required:
+ - compatible
+ - reg
+ - spi-max-frequency
+ - interrupts
+ - reset-gpios
+
+additionalProperties: false
+
+examples:
+ # Artik5 eval board
+ - |
+#include
+#include
+spi0 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+ethernet@0 {
+compatible = "asix,ax88796c";
+reg = <0x0>;
+local-mac-address = [00 00 00 00 00 00]; /* Filled in by a
bootloader */
+interrupt-parent = <&gpx2>;
+interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+spi-max-frequency = <4000>;
+reset-gpios = <&gpe0 2 GPIO_ACTIVE_LOW>;
+};
+};
--
2.26.2
Re: [PATCH v4 0/4] arm64: rockchip: Fix PCIe ep-gpios requirement and Add Nanopi M4B
On Fri, 22 Jan 2021 00:23:17 +0800, Chen-Yu Tsai wrote: > This is v4 of my Nanopi M4B series. > > Changes since v3 include: > > - Directly return dev_err_probe() instead of having a separate return > statement > > [...] Applied to pci/rockchip (dropped dts patches 3-4), thanks! [1/2] PCI: rockchip: Make 'ep-gpios' DT property optional https://git.kernel.org/lpieralisi/pci/c/96f760cc00 [2/2] dt-bindings: arm: rockchip: Add FriendlyARM NanoPi M4B https://git.kernel.org/lpieralisi/pci/c/b205659626 Thanks, Lorenzo
Re: [PATCH 4/4] phy: qcom-qmp: Add support for SM8350 UFS phy
On Mon 25 Jan 04:09 CST 2021, Vinod Koul wrote:
> Add the tables for init sequences for UFS QMP phy found in SM8350 SoC.
>
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> Signed-off-by: Vinod Koul
> ---
> drivers/phy/qualcomm/phy-qcom-qmp.c | 127
> 1 file changed, 127 insertions(+)
>
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c
> b/drivers/phy/qualcomm/phy-qcom-qmp.c
> index dbc12a19b702..4a9d1010910d 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
> @@ -1983,6 +1983,106 @@ static const struct qmp_phy_init_tbl
> sm8250_qmp_gen3x2_pcie_pcs_misc_tbl[] = {
> QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_POWER_STATE_CONFIG4, 0x07),
> };
>
> +static const struct qmp_phy_init_tbl sm8350_ufsphy_serdes_tbl[] = {
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_SYSCLK_EN_SEL, 0xd9),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_HSCLK_SEL, 0x11),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_HSCLK_HS_SWITCH_SEL, 0x00),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP_EN, 0x42),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_VCO_TUNE_MAP, 0x02),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_PLL_IVCO, 0x0f),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_VCO_TUNE_INITVAL2, 0x00),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_BIN_VCOCAL_HSCLK_SEL, 0x11),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_DEC_START_MODE0, 0x82),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_CP_CTRL_MODE0, 0x14),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_PLL_RCTRL_MODE0, 0x18),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_PLL_CCTRL_MODE0, 0x18),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP1_MODE0, 0xff),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP2_MODE0, 0x19),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE1_MODE0, 0xac),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE2_MODE0, 0x1e),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_DEC_START_MODE1, 0x98),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_CP_CTRL_MODE1, 0x14),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_PLL_RCTRL_MODE1, 0x18),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_PLL_CCTRL_MODE1, 0x18),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP1_MODE1, 0x65),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP2_MODE1, 0x1e),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE1_MODE1, 0xdd),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE2_MODE1, 0x23),
> +
> + /* Rate B */
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_VCO_TUNE_MAP, 0x06),
> +};
> +
> +static const struct qmp_phy_init_tbl sm8350_ufsphy_tx_tbl[] = {
> + QMP_PHY_INIT_CFG(QSERDES_SM8350_TX_PWM_GEAR_1_DIVIDER_BAND0_1, 0x06),
> + QMP_PHY_INIT_CFG(QSERDES_SM8350_TX_PWM_GEAR_2_DIVIDER_BAND0_1, 0x03),
> + QMP_PHY_INIT_CFG(QSERDES_SM8350_TX_PWM_GEAR_3_DIVIDER_BAND0_1, 0x01),
> + QMP_PHY_INIT_CFG(QSERDES_SM8350_TX_PWM_GEAR_4_DIVIDER_BAND0_1, 0x00),
> + QMP_PHY_INIT_CFG(QSERDES_V4_TX_LANE_MODE_1, 0xf5),
> + QMP_PHY_INIT_CFG(QSERDES_V4_TX_LANE_MODE_3, 0x3f),
> + QMP_PHY_INIT_CFG(QSERDES_V4_TX_RES_CODE_LANE_OFFSET_TX, 0x09),
> + QMP_PHY_INIT_CFG(QSERDES_V4_TX_RES_CODE_LANE_OFFSET_RX, 0x09),
> + QMP_PHY_INIT_CFG(QSERDES_SM8350_TX_TRAN_DRVR_EMP_EN, 0x0c),
> +};
> +
> +static const struct qmp_phy_init_tbl sm8350_ufsphy_rx_tbl[] = {
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_SIGDET_LVL, 0x24),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_SIGDET_CNTRL, 0x0f),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_SIGDET_DEGLITCH_CNTRL, 0x1e),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_BAND, 0x18),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_FASTLOCK_FO_GAIN, 0x0a),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_SO_SATURATION_AND_ENABLE, 0x5a),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_PI_CONTROLS, 0xf1),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_FASTLOCK_COUNT_LOW, 0x80),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_PI_CTRL2, 0x80),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_FO_GAIN, 0x0e),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_SO_GAIN, 0x04),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_TERM_BW, 0x1b),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_EQU_ADAPTOR_CNTRL1, 0x04),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_EQU_ADAPTOR_CNTRL2, 0x06),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_EQU_ADAPTOR_CNTRL3, 0x04),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_EQU_ADAPTOR_CNTRL4, 0x1a),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_EQ_OFFSET_ADAPTOR_CNTRL1, 0x17),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_OFFSET_ADAPTOR_CNTRL2, 0x00),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_IDAC_MEASURE_TIME, 0x10),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_IDAC_TSETTLE_LOW, 0xc0),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_IDAC_TSETTLE_HIGH, 0x00),
> + QMP_PHY_INIT_CFG(QSERDES_SM8350_RX_RX_MODE_00_LOW, 0x6d),
> + QMP_PHY_INIT_CFG(QSERDES_SM8350_RX_RX_MODE_00_HIGH, 0x6d),
> + QMP_PHY_INIT_CFG(QSERDES_SM8350_RX_RX_MODE_00_HIGH2, 0xed),
> + QMP_PHY_INIT_CFG(QSERDES_SM8350_RX_RX_MODE_00_HIGH3, 0x3b),
> + QMP_PHY_INIT_CFG(QSERDES_SM8350_RX_RX_MODE_00_HIGH4, 0x3c),
> + QMP_PHY_INIT_CFG(
[PATCH v3 RFC net-next 01/19] doc: marvell: add cm3-mem device tree bindings description
From: Stefan Chulski Signed-off-by: Stefan Chulski --- Documentation/devicetree/bindings/net/marvell-pp2.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/net/marvell-pp2.txt b/Documentation/devicetree/bindings/net/marvell-pp2.txt index b783976..f9f8cc6 100644 --- a/Documentation/devicetree/bindings/net/marvell-pp2.txt +++ b/Documentation/devicetree/bindings/net/marvell-pp2.txt @@ -37,6 +37,7 @@ Required properties (port): GOP (Group Of Ports) point of view. This ID is used to index the per-port registers in the second register area. - phy-mode: See ethernet.txt file in the same directory +- cm3-mem: phandle to CM3 SRAM definitions Optional properties (port): -- 1.9.1
[PATCH v3 RFC net-next 00/19] net: mvpp2: Add TX Flow Control support
From: Stefan Chulski Armada hardware has a pause generation mechanism in GOP (MAC). The GOP generate flow control frames based on an indication programmed in Ports Control 0 Register. There is a bit per port. However assertion of the PortX Pause bits in the ports control 0 register only sends a one time pause. To complement the function the GOP has a mechanism to periodically send pause control messages based on periodic counters. This mechanism ensures that the pause is effective as long as the Appropriate PortX Pause is asserted. Problem is that Packet Processor that actually can drop packets due to lack of resources not connected to the GOP flow control generation mechanism. To solve this issue Armada has firmware running on CM3 CPU dedicated for Flow Control support. Firmware monitors Packet Processor resources and asserts XON/XOFF by writing to Ports Control 0 Register. MSS shared SRAM memory used to communicate between CM3 firmware and PP2 driver. During init PP2 driver informs firmware about used BM pools, RXQs, congestion and depletion thresholds. The pause frames are generated whenever congestion or depletion in resources is detected. The back pressure is stopped when the resource reaches a sufficient level. So the congestion/depletion and sufficient level implement a hysteresis that reduces the XON/XOFF toggle frequency. Packet Processor v23 hardware introduces support for RX FIFO fill level monitor. Patch "add PPv23 version definition" to differ between v23 and v22 hardware. Patch "add TX FC firmware check" verifies that CM3 firmware supports Flow Control monitoring. v2 --> v3 - Remove inline functions - Add PPv2.3 description into marvell-pp2.txt - Improve mvpp2_interrupts_mask/unmask procedure - Improve FC enable/disable procedure - Add priv->sram_pool check - Remove gen_pool_destroy call - Reduce Flow Control timer to x100 faster v1 --> v2 - Add memory requirements information - Add EPROBE_DEFER if of_gen_pool_get return NULL - Move Flow control configuration to mvpp2_mac_link_up callback - Add firmware version info with Flow control support Konstantin Porotchkin (1): dts: marvell: add CM3 SRAM memory to cp115 ethernet device tree Stefan Chulski (18): doc: marvell: add cm3-mem device tree bindings description net: mvpp2: add CM3 SRAM memory map doc: marvell: add PPv2.3 description to marvell-pp2.txt net: mvpp2: add PPv23 version definition net: mvpp2: always compare hw-version vs MVPP21 net: mvpp2: increase BM pool size to 2048 buffers net: mvpp2: increase RXQ size to 1024 descriptors net: mvpp2: add FCA periodic timer configurations net: mvpp2: add FCA RXQ non occupied descriptor threshold net: mvpp2: add spinlock for FW FCA configuration path net: mvpp2: enable global flow control net: mvpp2: add RXQ flow control configurations net: mvpp2: add ethtool flow control configuration support net: mvpp2: add BM protection underrun feature support net: mvpp2: add PPv23 RX FIFO flow control net: mvpp2: set 802.3x GoP Flow Control mode net: mvpp2: limit minimum ring size to 1024 descriptors net: mvpp2: add TX FC firmware check Documentation/devicetree/bindings/net/marvell-pp2.txt | 4 +- arch/arm64/boot/dts/marvell/armada-cp11x.dtsi | 10 + drivers/net/ethernet/marvell/mvpp2/mvpp2.h| 130 - drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 564 ++-- 4 files changed, 658 insertions(+), 50 deletions(-) -- 1.9.1
[PATCH v3 RFC net-next 05/19] net: mvpp2: add PPv23 version definition
From: Stefan Chulski
This patch add PPv23 version definition.
PPv23 is new packet processor in CP115.
Everything that supported by PPv22, also supported by PPv23.
No functional changes in this stage.
Signed-off-by: Stefan Chulski
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 24
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 17 +-
2 files changed, 25 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index aec9179..89b3ede 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -60,6 +60,9 @@
/* Top Registers */
#define MVPP2_MH_REG(port) (0x5040 + 4 * (port))
#define MVPP2_DSA_EXTENDED BIT(5)
+#define MVPP2_VER_ID_REG 0x50b0
+#define MVPP2_VER_PP22 0x10
+#define MVPP2_VER_PP23 0x11
/* Parser Registers */
#define MVPP2_PRS_INIT_LOOKUP_REG 0x1000
@@ -469,7 +472,7 @@
#define MVPP22_GMAC_INT_SUM_MASK_LINK_STAT BIT(1)
#defineMVPP22_GMAC_INT_SUM_MASK_PTPBIT(2)
-/* Per-port XGMAC registers. PPv2.2 only, only for GOP port 0,
+/* Per-port XGMAC registers. PPv2.2 and PPv2.3, only for GOP port 0,
* relative to port->base.
*/
#define MVPP22_XLG_CTRL0_REG 0x100
@@ -506,7 +509,7 @@
#define MVPP22_XLG_CTRL4_MACMODSELECT_GMAC BIT(12)
#define MVPP22_XLG_CTRL4_EN_IDLE_CHECK BIT(14)
-/* SMI registers. PPv2.2 only, relative to priv->iface_base. */
+/* SMI registers. PPv2.2 and PPv2.3, relative to priv->iface_base. */
#define MVPP22_SMI_MISC_CFG_REG0x1204
#define MVPP22_SMI_POLLING_EN BIT(10)
@@ -582,7 +585,7 @@
#define MVPP2_QUEUE_NEXT_DESC(q, index) \
(((index) < (q)->last_desc) ? ((index) + 1) : 0)
-/* XPCS registers. PPv2.2 only */
+/* XPCS registers.PPv2.2 and PPv2.3 */
#define MVPP22_MPCS_BASE(port) (0x7000 + (port) * 0x1000)
#define MVPP22_MPCS_CTRL 0x14
#define MVPP22_MPCS_CTRL_FWD_ERR_CONN BIT(10)
@@ -593,7 +596,7 @@
#define MVPP22_MPCS_CLK_RESET_DIV_RATIO(n) ((n) << 4)
#define MVPP22_MPCS_CLK_RESET_DIV_SET BIT(11)
-/* XPCS registers. PPv2.2 only */
+/* XPCS registers. PPv2.2 and PPv2.3 */
#define MVPP22_XPCS_BASE(port) (0x7400 + (port) * 0x1000)
#define MVPP22_XPCS_CFG0 0x0
#define MVPP22_XPCS_CFG0_RESET_DIS BIT(0)
@@ -930,15 +933,16 @@ struct mvpp2 {
void __iomem *iface_base;
void __iomem *cm3_base;
- /* On PPv2.2, each "software thread" can access the base
+ /* On PPv2.2 and PPv2.3, each "software thread" can access the base
* register through a separate address space, each 64 KB apart
* from each other. Typically, such address spaces will be
* used per CPU.
*/
void __iomem *swth_base[MVPP2_MAX_THREADS];
- /* On PPv2.2, some port control registers are located into the system
-* controller space. These registers are accessible through a regmap.
+ /* On PPv2.2 and PPv2.3, some port control registers are located into
+* the system controller space. These registers are accessible
+* through a regmap.
*/
struct regmap *sysctrl_base;
@@ -980,7 +984,7 @@ struct mvpp2 {
u32 tclk;
/* HW version */
- enum { MVPP21, MVPP22 } hw_version;
+ enum { MVPP21, MVPP22, MVPP23 } hw_version;
/* Maximum number of RXQs per port */
unsigned int max_port_rxqs;
@@ -1227,7 +1231,7 @@ struct mvpp21_rx_desc {
__le32 reserved8;
};
-/* HW TX descriptor for PPv2.2 */
+/* HW TX descriptor for PPv2.2 and PPv2.3 */
struct mvpp22_tx_desc {
__le32 command;
u8 packet_offset;
@@ -1239,7 +1243,7 @@ struct mvpp22_tx_desc {
__le64 buf_cookie_misc;
};
-/* HW RX descriptor for PPv2.2 */
+/* HW RX descriptor for PPv2.2 and PPv2.3 */
struct mvpp22_rx_desc {
__le32 status;
__le16 reserved1;
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 4b07f6c..4f482ad 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -395,7 +395,7 @@ static int mvpp2_bm_pool_create(struct device *dev, struct
mvpp2 *priv,
if (!IS_ALIGNED(size, 16))
return -EINVAL;
- /* PPv2.1 needs 8 bytes per buffer pointer, PPv2.2 needs 16
+ /* PPv2.1 needs 8 bytes per buffer pointer, PPv2.2 and PPv2.3 needs 16
* bytes per buffer pointer
*/
if (priv->hw_version == MVPP21)
@@ -1183,7 +1183,7 @@ static void mvpp2_interrupts_unmask(void *arg)
u32 val;
int i;
- if (port->priv->hw_version != MVPP22)
+ if
Re: [PATCH v5 13/21] arm64: Allow ID_AA64MMFR1_EL1.VH to be overridden from the command line
On Mon, Jan 25, 2021 at 10:50:11AM +, Marc Zyngier wrote: > As we want to be able to disable VHE at runtime, let's match > "id_aa64mmfr1.vh=" from the command line as an override. > This doesn't have much effect yet as our boot code doesn't look > at the cpufeature, but only at the HW registers. > > Signed-off-by: Marc Zyngier > Acked-by: David Brazdil Reviewed-by: Catalin Marinas
Re: [PATCH] mmc: brcmstb: Fix sdhci_pltfm_suspend link error
On 25/01/2021 13:50, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> sdhci_pltfm_suspend() is only available when CONFIG_PM_SLEEP
> support is built into the kernel, which caused a regression
> in a recent bugfix:
>
> ld.lld: error: undefined symbol: sdhci_pltfm_suspend
referenced by sdhci-brcmstb.c
mmc/host/sdhci-brcmstb.o:(sdhci_brcmstb_shutdown) in archive
drivers/built-in.a
>
> Making the call conditional on the symbol fixes the link
> error.
>
> Fixes: 5b191dcba719 ("mmc: sdhci-brcmstb: Fix mmc timeout errors on S5
> suspend")
> Fixes: e7b5d63a82fe ("mmc: sdhci-brcmstb: Add shutdown callback")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Arnd Bergmann
> ---
> It would be helpful if someone could test this to ensure that the
> driver works correctly even when CONFIG_PM_SLEEP is disabled
Good evening Arnd,
I have just given this patch a test, and the driver works fine on my side,
afterwards.
Tested-by: Nicolas Schichan
> ---
> drivers/mmc/host/sdhci-brcmstb.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sdhci-brcmstb.c
> b/drivers/mmc/host/sdhci-brcmstb.c
> index f9780c65ebe9..dc9280b149db 100644
> --- a/drivers/mmc/host/sdhci-brcmstb.c
> +++ b/drivers/mmc/host/sdhci-brcmstb.c
> @@ -314,7 +314,8 @@ static int sdhci_brcmstb_probe(struct platform_device
> *pdev)
>
> static void sdhci_brcmstb_shutdown(struct platform_device *pdev)
> {
> - sdhci_pltfm_suspend(&pdev->dev);
> + if (IS_ENABLED(CONFIG_PM_SLEEP))
> + sdhci_pltfm_suspend(&pdev->dev);
> }
>
> MODULE_DEVICE_TABLE(of, sdhci_brcm_of_match);
>
--
Nicolas Schichan
Freebox SAS
Re: [PATCH 3/3] iio: proximity: Add a ChromeOS EC MKBP proximity driver
Quoting Jonathan Cameron (2021-01-24 09:38:20)
> On Fri, 22 Jan 2021 14:54:43 -0800
> Stephen Boyd wrote:
>
> > Add support for a ChromeOS EC proximity driver that exposes a "front"
> > proximity sensor via the IIO subsystem. The EC decides when front
> > proximity is near and sets an MKBP switch 'EC_MKBP_FRONT_PROXIMITY' to
> > notify the kernel of proximity. Similarly, when proximity detects
> > something far away it sets the switch bit to 0. For now this driver
> > exposes a single sensor, but it could be expanded in the future via more
> > MKBP bits if desired.
> >
> > Cc: Dmitry Torokhov
> > Cc: Benson Leung
> > Cc: Guenter Roeck
> > Cc: Douglas Anderson
> > Cc: Gwendal Grignou
> > Signed-off-by: Stephen Boyd
>
> Hi Stephen,
>
> Looks more or less fine to me. My main concern is potential confusion
> in naming with the cros_ec_prox_light driver that we already have.
>
> A few other minor bits and bobs inline.
>
Cool thanks.
> > diff --git a/drivers/iio/proximity/Makefile b/drivers/iio/proximity/Makefile
> > index 9c1aca1a8b79..b1330dd8e212 100644
> > --- a/drivers/iio/proximity/Makefile
> > +++ b/drivers/iio/proximity/Makefile
> > @@ -5,6 +5,7 @@
> >
> > # When adding new entries keep the list in alphabetical order
> > obj-$(CONFIG_AS3935) += as3935.o
> > +obj-$(CONFIG_CROS_EC_PROXIMITY) += cros_ec_proximity.o
> > obj-$(CONFIG_ISL29501) += isl29501.o
> > obj-$(CONFIG_LIDAR_LITE_V2) += pulsedlight-lidar-lite-v2.o
> > obj-$(CONFIG_MB1232) += mb1232.o
> > diff --git a/drivers/iio/proximity/cros_ec_proximity.c
> > b/drivers/iio/proximity/cros_ec_proximity.c
> > new file mode 100644
> > index ..a3aef911e3cc
> > --- /dev/null
> > +++ b/drivers/iio/proximity/cros_ec_proximity.c
> > @@ -0,0 +1,252 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Driver for cros-ec proximity sensor exposed through MKBP switch
> > + *
> > + * Copyright 2021 Google LLC.
> > + */
> > +
> > +#include
> > +#include
> > +#include
>
> Slight preference for alphabetical order though keeping specific
> sections separate as done here is fine.
Will fix.
>
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +
> > +struct cros_ec_proximity_data {
> > + struct cros_ec_device *ec;
> > + struct iio_dev *indio_dev;
> > + struct mutex lock;
> > + struct notifier_block notifier;
> > + bool enabled;
> > +};
> > +
> > +static const struct iio_event_spec cros_ec_prox_events[] = {
> > + {
> > + .type = IIO_EV_TYPE_THRESH,
> > + .dir = IIO_EV_DIR_EITHER,
> > + .mask_separate = BIT(IIO_EV_INFO_ENABLE),
> > + },
> > +};
> > +
> > +static const struct iio_chan_spec cros_ec_prox_chan_spec[] = {
> > + {
> > + .type = IIO_PROXIMITY,
> > + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> > + .event_spec = cros_ec_prox_events,
> > + .num_event_specs = ARRAY_SIZE(cros_ec_prox_events),
> > + },
> > +};
> > +
> > +static int cros_ec_proximity_parse_state(const void *data)
> > +{
> > + u32 switches = get_unaligned_le32(data);
> > +
> > + return !!(switches & BIT(EC_MKBP_FRONT_PROXIMITY));
> > +}
> > +
> > +static int cros_ec_proximity_query(struct cros_ec_device *ec_dev, int
> > *state)
> > +{
> > + struct ec_params_mkbp_info *params;
> > + struct cros_ec_command *msg;
> > + int ret;
> > +
> > + msg = kzalloc(sizeof(*msg) + max(sizeof(u32), sizeof(*params)),
> > + GFP_KERNEL);
>
> Given this is known at build time, perhaps better to add it to the
> iio_priv() accessed structure and avoid having to handle allocations
> separately.
Ok.
>
> > + if (!msg)
> > + return -ENOMEM;
[...]
> > +static int cros_ec_proximity_read_raw(struct iio_dev *indio_dev,
> > +const struct iio_chan_spec *chan, int *val,
> > +int *val2, long mask)
> > +{
> > + struct cros_ec_proximity_data *data = iio_priv(indio_dev);
> > + struct cros_ec_device *ec = data->ec;
> > + int ret;
> > +
> > + if (chan->type != IIO_PROXIMITY)
> > + return -EINVAL;
> > +
> > + switch (mask) {
> > + case IIO_CHAN_INFO_RAW:
> > + ret = iio_device_claim_direct_mode(indio_dev);
>
> Normally we only introduce these protections when adding the ability
> to change the state from direct to buffered (which these prevent).
> This driver doesn't yet support any other modes so I don't think
> there is any benefit in having these.
>
> If the aim is more local protection then should use a local lock
> as the semantics fo these functions might change in future.
Alright I'll drop it.
>
>
> > + if (ret)
> > + return ret;
> > +
> > + ret = cros_ec_proximity_query(ec, val);
> > +
Re: [PATCH v7 02/28] coresight: etm4x: Skip accessing TRCPDCR in save/restore
On Sun, Jan 10, 2021 at 10:48:24PM +, Suzuki K Poulose wrote:
> When the ETM is affected by Qualcomm errata, modifying the
> TRCPDCR could cause the system hang. Even though this is
> taken care of during enable/disable ETM, the ETM state
> save/restore could still access the TRCPDCR. Make sure
> we skip the access during the save/restore.
>
> Found by code inspection.
>
> Fixes: 02510a5aa78df45 ("coresight: etm4x: Add support to skip trace unit
> power up")
The SHA1 should be 12 character long, something I commented on in V4. I fixed
it.
> Cc: Mathieu Poirier
> Cc: Mike Leach
> Cc: Sai Prakash Ranjan
> Cc: Tingwei Zhang
> Reviewed-by: Sai Prakash Ranjan
> Tested-by: Sai Prakash Ranjan
> Signed-off-by: Suzuki K Poulose
> ---
> drivers/hwtracing/coresight/coresight-etm4x-core.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c
> b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> index 76526679b998..cce65fc0c9aa 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> @@ -1373,7 +1373,8 @@ static int etm4_cpu_save(struct etmv4_drvdata *drvdata)
>
> state->trcclaimset = readl(drvdata->base + TRCCLAIMCLR);
>
> - state->trcpdcr = readl(drvdata->base + TRCPDCR);
> + if (!drvdata->skip_power_up)
> + state->trcpdcr = readl(drvdata->base + TRCPDCR);
>
> /* wait for TRCSTATR.IDLE to go up */
> if (coresight_timeout(drvdata->base, TRCSTATR, TRCSTATR_IDLE_BIT, 1)) {
> @@ -1391,9 +1392,9 @@ static int etm4_cpu_save(struct etmv4_drvdata *drvdata)
>* potentially save power on systems that respect the TRCPDCR_PU
>* despite requesting software to save/restore state.
>*/
> - writel_relaxed((state->trcpdcr & ~TRCPDCR_PU),
> - drvdata->base + TRCPDCR);
> -
> + if (!drvdata->skip_power_up)
> + writel_relaxed((state->trcpdcr & ~TRCPDCR_PU),
> + drvdata->base + TRCPDCR);
> out:
> CS_LOCK(drvdata->base);
> return ret;
> @@ -1488,7 +1489,8 @@ static void etm4_cpu_restore(struct etmv4_drvdata
> *drvdata)
>
> writel_relaxed(state->trcclaimset, drvdata->base + TRCCLAIMSET);
>
> - writel_relaxed(state->trcpdcr, drvdata->base + TRCPDCR);
> + if (!drvdata->skip_power_up)
> + writel_relaxed(state->trcpdcr, drvdata->base + TRCPDCR);
>
> drvdata->state_needs_restore = false;
>
> --
> 2.24.1
>
Re: [patch 1/8] rtc: mc146818: Prevent reading garbage - bug
Hi,
After some bisecting, I found that commit 05a0302c3548 ("rtc: mc146818:
Prevent reading garbage", this patch, introduced since v5.11-rc1) makes
my VM hang at boot. Before this commit, I got this (and didn't notice)
at every boot:
rtc_cmos rtc_cmos: registered as rtc0
rtc_cmos rtc_cmos: hctosys: unable to read the hardware clock
rtc_cmos rtc_cmos: alarms up to one day, 114 bytes nvram
I notice that this patch creates infinite loops, which my VM falls into
(cf. below).
I didn't succeed to properly fix this without a revert. I tried to set a
maximum number of jumps, but I got pvqspinlock warnings.
Regards,
Mickaël
On 06/12/2020 22:46, Thomas Gleixner wrote:
> The MC146818 driver is prone to read garbage from the RTC. There are
> several issues all related to the update cycle of the MC146818. The chip
> increments seconds obviously once per second and indicates that by a bit in
> a register. The bit goes high 244us before the actual update starts. During
> the update the readout of the time values is undefined.
>
> The code just checks whether the update in progress bit (UIP) is set before
> reading the clock. If it's set it waits arbitrary 20ms before retrying,
> which is ample because the maximum update time is ~2ms.
>
> But this check does not guarantee that the UIP bit goes high and the actual
> update happens during the readout. So the following can happen
>
> 0.997 UIP = False
>-> Interrupt/NMI/preemption
> 0.998 UIP -> True
> 0.999 Readout <- Undefined
>
> To prevent this rework the code so it checks UIP before and after the
> readout and if set after the readout try again.
>
> But that's not enough to cover the following:
>
> 0.997 UIP = False
> Readout seconds
>-> NMI (or vCPU scheduled out)
> 0.998 UIP -> True
> update completes
> UIP -> False
> 1.000 Readout minutes,
> UIP check succeeds
>
> That can make the readout wrong up to 59 seconds.
>
> To prevent this, read the seconds value before the first UIP check,
> validate it after checking UIP and after reading out the rest.
>
> It's amazing that the original i386 code had this actually correct and
> the generic implementation of the MC146818 driver got it wrong in 2002 and
> it stayed that way until today.
>
> Signed-off-by: Thomas Gleixner
> ---
> drivers/rtc/rtc-mc146818-lib.c | 64
> -
> 1 file changed, 39 insertions(+), 25 deletions(-)
>
> --- a/drivers/rtc/rtc-mc146818-lib.c
> +++ b/drivers/rtc/rtc-mc146818-lib.c
> @@ -8,41 +8,41 @@
> #include
> #endif
>
> -/*
> - * Returns true if a clock update is in progress
> - */
> -static inline unsigned char mc146818_is_updating(void)
> -{
> - unsigned char uip;
> - unsigned long flags;
> -
> - spin_lock_irqsave(&rtc_lock, flags);
> - uip = (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP);
> - spin_unlock_irqrestore(&rtc_lock, flags);
> - return uip;
> -}
> -
> unsigned int mc146818_get_time(struct rtc_time *time)
> {
> unsigned char ctrl;
> unsigned long flags;
> unsigned char century = 0;
> + bool retry;
>
> #ifdef CONFIG_MACH_DECSTATION
> unsigned int real_year;
> #endif
>
> +again:
> + spin_lock_irqsave(&rtc_lock, flags);
> /*
> - * read RTC once any update in progress is done. The update
> - * can take just over 2ms. We wait 20ms. There is no need to
> - * to poll-wait (up to 1s - eeccch) for the falling edge of RTC_UIP.
> - * If you need to know *exactly* when a second has started, enable
> - * periodic update complete interrupts, (via ioctl) and then
> - * immediately read /dev/rtc which will block until you get the IRQ.
> - * Once the read clears, read the RTC time (again via ioctl). Easy.
> + * Check whether there is an update in progress during which the
> + * readout is unspecified. The maximum update time is ~2ms. Poll
> + * every msec for completion.
> + *
> + * Store the second value before checking UIP so a long lasting NMI
> + * which happens to hit after the UIP check cannot make an update
> + * cycle invisible.
>*/
> - if (mc146818_is_updating())
> - mdelay(20);
> + time->tm_sec = CMOS_READ(RTC_SECONDS);
> +
> + if (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP) {
> + spin_unlock_irqrestore(&rtc_lock, flags);
> + mdelay(1);
My VM loops here.
time->tm_sec is always 255.
> + goto again;
> + }
> +
> + /* Revalidate the above readout */
> + if (time->tm_sec != CMOS_READ(RTC_SECONDS)) {
> + spin_unlock_irqrestore(&rtc_lock, flags);
> + goto again;
> + }
>
> /*
>* Only the values that we read from the RTC are set. We leave
> @@ -50,8 +50,6 @@ unsigned int mc146818_get_time(struct rt
>* RTC has RTC_DAY_OF_WEEK, we igno
[PATCH 4.19 01/58] i2c: bpmp-tegra: Ignore unknown I2C_M flags
From: Mikko Perttunen commit bc1c2048abbe3c3074b4de91d213595c57741a6b upstream. In order to not to start returning errors when new I2C_M flags are added, change behavior to just ignore all flags that we don't know about. This includes the I2C_M_DMA_SAFE flag that already exists but causes -EINVAL to be returned for valid transactions. Cc: sta...@vger.kernel.org # v4.19+ Signed-off-by: Mikko Perttunen Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman --- drivers/i2c/busses/i2c-tegra-bpmp.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/i2c/busses/i2c-tegra-bpmp.c +++ b/drivers/i2c/busses/i2c-tegra-bpmp.c @@ -91,7 +91,7 @@ static int tegra_bpmp_xlate_flags(u16 fl flags &= ~I2C_M_RECV_LEN; } - return (flags != 0) ? -EINVAL : 0; + return 0; } /**
[PATCH 4.19 11/58] ASoC: Intel: haswell: Add missing pm_ops
From: Cezary Rojewski
[ Upstream commit bb224c3e3e41d940612d4cc9573289cdbd5cb8f5 ]
haswell machine board is missing pm_ops what prevents it from undergoing
suspend-resume procedure successfully. Assign default snd_soc_pm_ops so
this is no longer the case.
Signed-off-by: Cezary Rojewski
Link: https://lore.kernel.org/r/20201217105401.27865-1-cezary.rojew...@intel.com
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/intel/boards/haswell.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/intel/boards/haswell.c b/sound/soc/intel/boards/haswell.c
index a4022983a7ce0..67eb4a446c3cb 100644
--- a/sound/soc/intel/boards/haswell.c
+++ b/sound/soc/intel/boards/haswell.c
@@ -198,6 +198,7 @@ static struct platform_driver haswell_audio = {
.probe = haswell_audio_probe,
.driver = {
.name = "haswell-audio",
+ .pm = &snd_soc_pm_ops,
},
};
--
2.27.0
[PATCH 4.19 02/58] ALSA: seq: oss: Fix missing error check in snd_seq_oss_synth_make_info()
From: Takashi Iwai
commit 217bfbb8b0bfa24619b11ab75c135fec99b99b20 upstream.
snd_seq_oss_synth_make_info() didn't check the error code from
snd_seq_oss_midi_make_info(), and this leads to the call of strlcpy()
with the uninitialized string as the source, which may lead to the
access over the limit.
Add the proper error check for avoiding the failure.
Reported-by: syzbot+e42504ff21cff05a5...@syzkaller.appspotmail.com
Cc:
Link: https://lore.kernel.org/r/20210115093428.15882-1-ti...@suse.de
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
---
sound/core/seq/oss/seq_oss_synth.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/sound/core/seq/oss/seq_oss_synth.c
+++ b/sound/core/seq/oss/seq_oss_synth.c
@@ -624,7 +624,8 @@ snd_seq_oss_synth_make_info(struct seq_o
if (info->is_midi) {
struct midi_info minf;
- snd_seq_oss_midi_make_info(dp, info->midi_mapped, &minf);
+ if (snd_seq_oss_midi_make_info(dp, info->midi_mapped, &minf))
+ return -ENXIO;
inf->synth_type = SYNTH_TYPE_MIDI;
inf->synth_subtype = 0;
inf->nr_voices = 16;
[PATCH 4.19 22/58] drm/nouveau/mmu: fix vram heap sizing
From: Ben Skeggs
[ Upstream commit add42781ad76c5ae65127bf13852a4c6b2f08849 ]
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c
index ee11ccaf0563c..cb51e248cb41b 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c
@@ -316,9 +316,9 @@ nvkm_mmu_vram(struct nvkm_mmu *mmu)
{
struct nvkm_device *device = mmu->subdev.device;
struct nvkm_mm *mm = &device->fb->ram->vram;
- const u32 sizeN = nvkm_mm_heap_size(mm, NVKM_RAM_MM_NORMAL);
- const u32 sizeU = nvkm_mm_heap_size(mm, NVKM_RAM_MM_NOMAP);
- const u32 sizeM = nvkm_mm_heap_size(mm, NVKM_RAM_MM_MIXED);
+ const u64 sizeN = nvkm_mm_heap_size(mm, NVKM_RAM_MM_NORMAL);
+ const u64 sizeU = nvkm_mm_heap_size(mm, NVKM_RAM_MM_NOMAP);
+ const u64 sizeM = nvkm_mm_heap_size(mm, NVKM_RAM_MM_MIXED);
u8 type = NVKM_MEM_KIND * !!mmu->func->kind;
u8 heap = NVKM_MEM_VRAM;
int heapM, heapN, heapU;
--
2.27.0
[PATCH 4.19 04/58] ACPI: scan: Make acpi_bus_get_device() clear return pointer on error
From: Hans de Goede
commit 78a18fec5258c8df9435399a1ea022d73d3eceb9 upstream.
Set the acpi_device pointer which acpi_bus_get_device() returns-by-
reference to NULL on errors.
We've recently had 2 cases where callers of acpi_bus_get_device()
did not properly error check the return value, so set the returned-
by-reference acpi_device pointer to NULL, because at least some
callers of acpi_bus_get_device() expect that to be done on errors.
[ rjw: This issue was exposed by commit 71da201f38df ("ACPI: scan:
Defer enumeration of devices with _DEP lists") which caused it to
be much more likely to occur on some systems, but the real defect
had been introduced by an earlier commit. ]
Fixes: 40e7fcb19293 ("ACPI: Add _DEP support to fix battery issue on Asus
T100TA")
Fixes: bcfcd409d4db ("usb: split code locating ACPI companion into port and
device")
Reported-by: Pierre-Louis Bossart
Tested-by: Pierre-Louis Bossart
Diagnosed-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
Cc: All applicable
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
---
drivers/acpi/scan.c |2 ++
1 file changed, 2 insertions(+)
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -586,6 +586,8 @@ static int acpi_get_device_data(acpi_han
if (!device)
return -EINVAL;
+ *device = NULL;
+
status = acpi_get_data_full(handle, acpi_scan_drop_device,
(void **)device, callback);
if (ACPI_FAILURE(status) || !*device) {
[PATCH 4.19 21/58] drm/nouveau/i2c/gm200: increase width of aux semaphore owner fields
From: Ben Skeggs
[ Upstream commit ba6e9ab0fcf3d76e3952deb12b5f993991621d9c ]
Noticed while debugging GA102.
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c
index edb6148cbca04..d0e80ad526845 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c
@@ -33,7 +33,7 @@ static void
gm200_i2c_aux_fini(struct gm200_i2c_aux *aux)
{
struct nvkm_device *device = aux->base.pad->i2c->subdev.device;
- nvkm_mask(device, 0x00d954 + (aux->ch * 0x50), 0x0031, 0x);
+ nvkm_mask(device, 0x00d954 + (aux->ch * 0x50), 0x0071, 0x);
}
static int
@@ -54,10 +54,10 @@ gm200_i2c_aux_init(struct gm200_i2c_aux *aux)
AUX_ERR(&aux->base, "begin idle timeout %08x", ctrl);
return -EBUSY;
}
- } while (ctrl & 0x0301);
+ } while (ctrl & 0x0701);
/* set some magic, and wait up to 1ms for it to appear */
- nvkm_mask(device, 0x00d954 + (aux->ch * 0x50), 0x0030, ureq);
+ nvkm_mask(device, 0x00d954 + (aux->ch * 0x50), 0x0070, ureq);
timeout = 1000;
do {
ctrl = nvkm_rd32(device, 0x00d954 + (aux->ch * 0x50));
@@ -67,7 +67,7 @@ gm200_i2c_aux_init(struct gm200_i2c_aux *aux)
gm200_i2c_aux_fini(aux);
return -EBUSY;
}
- } while ((ctrl & 0x0300) != urep);
+ } while ((ctrl & 0x0700) != urep);
return 0;
}
--
2.27.0
[PATCH 4.19 23/58] drm/nouveau/kms/nv50-: fix case where notifier buffer is at offset 0
From: Ben Skeggs
[ Upstream commit caeb6ab899c3d36a74cda6e299c6e1c9c4e2a22e ]
VRAM offset 0 is a valid address, triggered on GA102.
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 4 ++--
drivers/gpu/drm/nouveau/dispnv50/disp.h | 2 +-
drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 1bb0a9f6fa730..fbe156302ee86 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -131,7 +131,7 @@ nv50_dmac_destroy(struct nv50_dmac *dmac)
int
nv50_dmac_create(struct nvif_device *device, struct nvif_object *disp,
-const s32 *oclass, u8 head, void *data, u32 size, u64 syncbuf,
+const s32 *oclass, u8 head, void *data, u32 size, s64 syncbuf,
struct nv50_dmac *dmac)
{
struct nouveau_cli *cli = (void *)device->object.client;
@@ -166,7 +166,7 @@ nv50_dmac_create(struct nvif_device *device, struct
nvif_object *disp,
if (ret)
return ret;
- if (!syncbuf)
+ if (syncbuf < 0)
return 0;
ret = nvif_object_init(&dmac->base.user, 0xf000, NV_DMA_IN_MEMORY,
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.h
b/drivers/gpu/drm/nouveau/dispnv50/disp.h
index 66c125a6b0b3c..55205d23360c8 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.h
@@ -68,7 +68,7 @@ struct nv50_dmac {
int nv50_dmac_create(struct nvif_device *device, struct nvif_object *disp,
const s32 *oclass, u8 head, void *data, u32 size,
-u64 syncbuf, struct nv50_dmac *dmac);
+s64 syncbuf, struct nv50_dmac *dmac);
void nv50_dmac_destroy(struct nv50_dmac *);
u32 *evo_wait(struct nv50_dmac *, int nr);
diff --git a/drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c
b/drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c
index f7dbd965e4e72..b49a212af4d8d 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c
@@ -68,7 +68,7 @@ wimmc37b_init_(const struct nv50_wimm_func *func, struct
nouveau_drm *drm,
int ret;
ret = nv50_dmac_create(&drm->client.device, &disp->disp->object,
- &oclass, 0, &args, sizeof(args), 0,
+ &oclass, 0, &args, sizeof(args), -1,
&wndw->wimm);
if (ret) {
NV_ERROR(drm, "wimm%04x allocation failed: %d\n", oclass, ret);
--
2.27.0
[PATCH 4.19 20/58] drm/nouveau/privring: ack interrupts the same way as RM
From: Ben Skeggs [ Upstream commit e05e06cd34f5311f677294a08b609acfbc315236 ] Whatever it is that we were doing before doesn't work on Ampere. Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin --- drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gf100.c | 10 +++--- drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gk104.c | 10 +++--- 2 files changed, 14 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gf100.c b/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gf100.c index d80dbc8f09b20..55a4ea4393c62 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gf100.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gf100.c @@ -22,6 +22,7 @@ * Authors: Ben Skeggs */ #include "priv.h" +#include static void gf100_ibus_intr_hub(struct nvkm_subdev *ibus, int i) @@ -31,7 +32,6 @@ gf100_ibus_intr_hub(struct nvkm_subdev *ibus, int i) u32 data = nvkm_rd32(device, 0x122124 + (i * 0x0400)); u32 stat = nvkm_rd32(device, 0x122128 + (i * 0x0400)); nvkm_debug(ibus, "HUB%d: %06x %08x (%08x)\n", i, addr, data, stat); - nvkm_mask(device, 0x122128 + (i * 0x0400), 0x0200, 0x); } static void @@ -42,7 +42,6 @@ gf100_ibus_intr_rop(struct nvkm_subdev *ibus, int i) u32 data = nvkm_rd32(device, 0x124124 + (i * 0x0400)); u32 stat = nvkm_rd32(device, 0x124128 + (i * 0x0400)); nvkm_debug(ibus, "ROP%d: %06x %08x (%08x)\n", i, addr, data, stat); - nvkm_mask(device, 0x124128 + (i * 0x0400), 0x0200, 0x); } static void @@ -53,7 +52,6 @@ gf100_ibus_intr_gpc(struct nvkm_subdev *ibus, int i) u32 data = nvkm_rd32(device, 0x128124 + (i * 0x0400)); u32 stat = nvkm_rd32(device, 0x128128 + (i * 0x0400)); nvkm_debug(ibus, "GPC%d: %06x %08x (%08x)\n", i, addr, data, stat); - nvkm_mask(device, 0x128128 + (i * 0x0400), 0x0200, 0x); } void @@ -90,6 +88,12 @@ gf100_ibus_intr(struct nvkm_subdev *ibus) intr1 &= ~stat; } } + + nvkm_mask(device, 0x121c4c, 0x003f, 0x0002); + nvkm_msec(device, 2000, + if (!(nvkm_rd32(device, 0x121c4c) & 0x003f)) + break; + ); } static int diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gk104.c b/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gk104.c index 9025ed1bd2a99..4caf3ef087e1d 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gk104.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gk104.c @@ -22,6 +22,7 @@ * Authors: Ben Skeggs */ #include "priv.h" +#include static void gk104_ibus_intr_hub(struct nvkm_subdev *ibus, int i) @@ -31,7 +32,6 @@ gk104_ibus_intr_hub(struct nvkm_subdev *ibus, int i) u32 data = nvkm_rd32(device, 0x122124 + (i * 0x0800)); u32 stat = nvkm_rd32(device, 0x122128 + (i * 0x0800)); nvkm_debug(ibus, "HUB%d: %06x %08x (%08x)\n", i, addr, data, stat); - nvkm_mask(device, 0x122128 + (i * 0x0800), 0x0200, 0x); } static void @@ -42,7 +42,6 @@ gk104_ibus_intr_rop(struct nvkm_subdev *ibus, int i) u32 data = nvkm_rd32(device, 0x124124 + (i * 0x0800)); u32 stat = nvkm_rd32(device, 0x124128 + (i * 0x0800)); nvkm_debug(ibus, "ROP%d: %06x %08x (%08x)\n", i, addr, data, stat); - nvkm_mask(device, 0x124128 + (i * 0x0800), 0x0200, 0x); } static void @@ -53,7 +52,6 @@ gk104_ibus_intr_gpc(struct nvkm_subdev *ibus, int i) u32 data = nvkm_rd32(device, 0x128124 + (i * 0x0800)); u32 stat = nvkm_rd32(device, 0x128128 + (i * 0x0800)); nvkm_debug(ibus, "GPC%d: %06x %08x (%08x)\n", i, addr, data, stat); - nvkm_mask(device, 0x128128 + (i * 0x0800), 0x0200, 0x); } void @@ -90,6 +88,12 @@ gk104_ibus_intr(struct nvkm_subdev *ibus) intr1 &= ~stat; } } + + nvkm_mask(device, 0x12004c, 0x003f, 0x0002); + nvkm_msec(device, 2000, + if (!(nvkm_rd32(device, 0x12004c) & 0x003f)) + break; + ); } static int -- 2.27.0
[PATCH 4.19 05/58] btrfs: fix lockdep splat in btrfs_recover_relocation
From: Josef Bacik
commit fb286100974e7239af243bc2255a52f29442f9c8 upstream.
While testing the error paths of relocation I hit the following lockdep
splat:
==
WARNING: possible circular locking dependency detected
5.10.0-rc6+ #217 Not tainted
--
mount/779 is trying to acquire lock:
a0e676945418 (&fs_info->balance_mutex){+.+.}-{3:3}, at:
btrfs_recover_balance+0x2f0/0x340
but task is already holding lock:
a0e60ee31da8 (btrfs-root-00){}-{3:3}, at:
__btrfs_tree_read_lock+0x27/0x100
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (btrfs-root-00){}-{3:3}:
down_read_nested+0x43/0x130
__btrfs_tree_read_lock+0x27/0x100
btrfs_read_lock_root_node+0x31/0x40
btrfs_search_slot+0x462/0x8f0
btrfs_update_root+0x55/0x2b0
btrfs_drop_snapshot+0x398/0x750
clean_dirty_subvols+0xdf/0x120
btrfs_recover_relocation+0x534/0x5a0
btrfs_start_pre_rw_mount+0xcb/0x170
open_ctree+0x151f/0x1726
btrfs_mount_root.cold+0x12/0xea
legacy_get_tree+0x30/0x50
vfs_get_tree+0x28/0xc0
vfs_kern_mount.part.0+0x71/0xb0
btrfs_mount+0x10d/0x380
legacy_get_tree+0x30/0x50
vfs_get_tree+0x28/0xc0
path_mount+0x433/0xc10
__x64_sys_mount+0xe3/0x120
do_syscall_64+0x33/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xa9
-> #1 (sb_internal#2){.+.+}-{0:0}:
start_transaction+0x444/0x700
insert_balance_item.isra.0+0x37/0x320
btrfs_balance+0x354/0xf40
btrfs_ioctl_balance+0x2cf/0x380
__x64_sys_ioctl+0x83/0xb0
do_syscall_64+0x33/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xa9
-> #0 (&fs_info->balance_mutex){+.+.}-{3:3}:
__lock_acquire+0x1120/0x1e10
lock_acquire+0x116/0x370
__mutex_lock+0x7e/0x7b0
btrfs_recover_balance+0x2f0/0x340
open_ctree+0x1095/0x1726
btrfs_mount_root.cold+0x12/0xea
legacy_get_tree+0x30/0x50
vfs_get_tree+0x28/0xc0
vfs_kern_mount.part.0+0x71/0xb0
btrfs_mount+0x10d/0x380
legacy_get_tree+0x30/0x50
vfs_get_tree+0x28/0xc0
path_mount+0x433/0xc10
__x64_sys_mount+0xe3/0x120
do_syscall_64+0x33/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xa9
other info that might help us debug this:
Chain exists of:
&fs_info->balance_mutex --> sb_internal#2 --> btrfs-root-00
Possible unsafe locking scenario:
CPU0CPU1
lock(btrfs-root-00);
lock(sb_internal#2);
lock(btrfs-root-00);
lock(&fs_info->balance_mutex);
*** DEADLOCK ***
2 locks held by mount/779:
#0: a0e60dc040e0 (&type->s_umount_key#47/1){+.+.}-{3:3}, at:
alloc_super+0xb5/0x380
#1: a0e60ee31da8 (btrfs-root-00){}-{3:3}, at:
__btrfs_tree_read_lock+0x27/0x100
stack backtrace:
CPU: 0 PID: 779 Comm: mount Not tainted 5.10.0-rc6+ #217
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32
04/01/2014
Call Trace:
dump_stack+0x8b/0xb0
check_noncircular+0xcf/0xf0
? trace_call_bpf+0x139/0x260
__lock_acquire+0x1120/0x1e10
lock_acquire+0x116/0x370
? btrfs_recover_balance+0x2f0/0x340
__mutex_lock+0x7e/0x7b0
? btrfs_recover_balance+0x2f0/0x340
? btrfs_recover_balance+0x2f0/0x340
? rcu_read_lock_sched_held+0x3f/0x80
? kmem_cache_alloc_trace+0x2c4/0x2f0
? btrfs_get_64+0x5e/0x100
btrfs_recover_balance+0x2f0/0x340
open_ctree+0x1095/0x1726
btrfs_mount_root.cold+0x12/0xea
? rcu_read_lock_sched_held+0x3f/0x80
legacy_get_tree+0x30/0x50
vfs_get_tree+0x28/0xc0
vfs_kern_mount.part.0+0x71/0xb0
btrfs_mount+0x10d/0x380
? __kmalloc_track_caller+0x2f2/0x320
legacy_get_tree+0x30/0x50
vfs_get_tree+0x28/0xc0
? capable+0x3a/0x60
path_mount+0x433/0xc10
__x64_sys_mount+0xe3/0x120
do_syscall_64+0x33/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xa9
This is straightforward to fix, simply release the path before we setup
the balance_ctl.
CC: sta...@vger.kernel.org # 4.4+
Reviewed-by: Qu Wenruo
Reviewed-by: Johannes Thumshirn
Signed-off-by: Josef Bacik
Reviewed-by: David Sterba
Signed-off-by: David Sterba
Signed-off-by: Greg Kroah-Hartman
---
fs/btrfs/volumes.c |2 ++
1 file changed, 2 insertions(+)
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -4011,6 +4011,8 @@ int btrfs_recover_balance(struct btrfs_f
btrfs_warn(fs_info,
"balance: cannot set exclusive op status, resume manually");
+ btrfs_release_path(path);
+
mutex_lock(&fs_info->balance_mutex);
BUG_ON(fs_info->balance_ctl);
spin_lock(&fs_info->balance_lock);
[PATCH 4.19 17/58] clk: tegra30: Add hda clock default rates to clock driver
From: Peter Geis
[ Upstream commit f4eccc7fea203cfb35205891eced1ab51836f362 ]
Current implementation defaults the hda clocks to clk_m. This causes hda
to run too slow to operate correctly. Fix this by defaulting to pll_p and
setting the frequency to the correct rate.
This matches upstream t124 and downstream t30.
Acked-by: Jon Hunter
Tested-by: Ion Agorria
Acked-by: Sameer Pujar
Acked-by: Thierry Reding
Signed-off-by: Peter Geis
Link: https://lore.kernel.org/r/20210108135913.2421585-2-pgwipe...@gmail.com
Signed-off-by: Takashi Iwai
Signed-off-by: Sasha Levin
---
drivers/clk/tegra/clk-tegra30.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/clk/tegra/clk-tegra30.c b/drivers/clk/tegra/clk-tegra30.c
index e0aaecd98fbff..678019f86bc7a 100644
--- a/drivers/clk/tegra/clk-tegra30.c
+++ b/drivers/clk/tegra/clk-tegra30.c
@@ -1274,6 +1274,8 @@ static struct tegra_clk_init_table init_table[]
__initdata = {
{ TEGRA30_CLK_I2S3_SYNC, TEGRA30_CLK_CLK_MAX, 2400, 0 },
{ TEGRA30_CLK_I2S4_SYNC, TEGRA30_CLK_CLK_MAX, 2400, 0 },
{ TEGRA30_CLK_VIMCLK_SYNC, TEGRA30_CLK_CLK_MAX, 2400, 0 },
+ { TEGRA30_CLK_HDA, TEGRA30_CLK_PLL_P, 10200, 0 },
+ { TEGRA30_CLK_HDA2CODEC_2X, TEGRA30_CLK_PLL_P, 4800, 0 },
/* must be the last entry */
{ TEGRA30_CLK_CLK_MAX, TEGRA30_CLK_CLK_MAX, 0, 0 },
};
--
2.27.0
[PATCH 4.19 36/58] ehci: fix EHCI host controller initialization sequence
From: Eugene Korenevsky
commit 280a9045bb18833db921b316a5527d2b565e9f2e upstream.
According to EHCI spec, EHCI HC clears USBSTS.HCHalted whenever
USBCMD.RS=1.
However, it is a good practice to wait some time after setting USBCMD.RS
(approximately 100ms) until USBSTS.HCHalted become zero.
Without this waiting, VirtualBox's EHCI virtual HC accidentally hangs
(see BugLink).
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=211095
Acked-by: Alan Stern
Signed-off-by: Eugene Korenevsky
Cc: stable
Link: https://lore.kernel.org/r/20210110173609.ga17...@himera.home
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/host/ehci-hcd.c | 12
1 file changed, 12 insertions(+)
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -574,6 +574,7 @@ static int ehci_run (struct usb_hcd *hcd
struct ehci_hcd *ehci = hcd_to_ehci (hcd);
u32 temp;
u32 hcc_params;
+ int rc;
hcd->uses_new_polling = 1;
@@ -629,9 +630,20 @@ static int ehci_run (struct usb_hcd *hcd
down_write(&ehci_cf_port_reset_rwsem);
ehci->rh_state = EHCI_RH_RUNNING;
ehci_writel(ehci, FLAG_CF, &ehci->regs->configured_flag);
+
+ /* Wait until HC become operational */
ehci_readl(ehci, &ehci->regs->command); /* unblock posted writes */
msleep(5);
+ rc = ehci_handshake(ehci, &ehci->regs->status, STS_HALT, 0, 100 * 1000);
+
up_write(&ehci_cf_port_reset_rwsem);
+
+ if (rc) {
+ ehci_err(ehci, "USB %x.%x, controller refused to start: %d\n",
+((ehci->sbrn & 0xf0)>>4), (ehci->sbrn & 0x0f), rc);
+ return rc;
+ }
+
ehci->last_periodic_enable = ktime_get_real();
temp = HC_VERSION(ehci, ehci_readl(ehci, &ehci->caps->hc_capbase));
[PATCH 4.19 26/58] platform/x86: intel-vbtn: Drop HP Stream x360 Convertible PC 11 from allow-list
From: Hans de Goede
[ Upstream commit 070222731be52d741e55d8967b1764482b81e54c ]
THe HP Stream x360 Convertible PC 11 DSDT has the following VGBS function:
Method (VGBS, 0, Serialized)
{
If ((^^PCI0.LPCB.EC0.ROLS == Zero))
{
VBDS = Zero
}
Else
{
VBDS = Zero
}
Return (VBDS) /* \_SB_.VGBI.VBDS */
}
Which is obviously wrong, because it always returns 0 independent of the
2-in-1 being in laptop or tablet mode. This causes the intel-vbtn driver
to initially report SW_TABLET_MODE = 1 to userspace, which is known to
cause problems when the 2-in-1 is actually in laptop mode.
During earlier testing this turned out to not be a problem because the
2-in-1 would do a Notify(..., 0xCC) or Notify(..., 0xCD) soon after
the intel-vbtn driver loaded, correcting the SW_TABLET_MODE state.
Further testing however has shown that this Notify() soon after the
intel-vbtn driver loads, does not always happen. When the Notify
does not happen, then intel-vbtn reports SW_TABLET_MODE = 1 resulting in
a non-working touchpad.
IOW the tablet-mode reporting is not reliable on this device, so it
should be dropped from the allow-list, fixing the touchpad sometimes
not working.
Fixes: 8169bd3e6e19 ("platform/x86: intel-vbtn: Switch to an allow-list for
SW_TABLET_MODE reporting")
Link: https://lore.kernel.org/r/20210114143432.31750-1-hdego...@redhat.com
Signed-off-by: Hans de Goede
Signed-off-by: Sasha Levin
---
drivers/platform/x86/intel-vbtn.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/platform/x86/intel-vbtn.c
b/drivers/platform/x86/intel-vbtn.c
index 36d6e72f50735..f5774372c3871 100644
--- a/drivers/platform/x86/intel-vbtn.c
+++ b/drivers/platform/x86/intel-vbtn.c
@@ -191,12 +191,6 @@ static const struct dmi_system_id
dmi_switches_allow_list[] = {
DMI_MATCH(DMI_PRODUCT_NAME, "Venue 11 Pro 7130"),
},
},
- {
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
- DMI_MATCH(DMI_PRODUCT_NAME, "HP Stream x360 Convertible
PC 11"),
- },
- },
{
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
--
2.27.0
[PATCH 4.19 39/58] usb: udc: core: Use lock when write to soft_connect
From: Thinh Nguyen
commit c28095bc99073ddda65e4f31f6ae0d908d4d5cd8 upstream.
Use lock to guard against concurrent access for soft-connect/disconnect
operations when writing to soft_connect sysfs.
Fixes: 2ccea03a8f7e ("usb: gadget: introduce UDC Class")
Cc: sta...@vger.kernel.org
Acked-by: Felipe Balbi
Signed-off-by: Thinh Nguyen
Link:
https://lore.kernel.org/r/338ea01fbd69b1985ef58f0f59af02c805ddf189.1610611437.git.thinh.ngu...@synopsys.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/gadget/udc/core.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
--- a/drivers/usb/gadget/udc/core.c
+++ b/drivers/usb/gadget/udc/core.c
@@ -1471,10 +1471,13 @@ static ssize_t soft_connect_store(struct
struct device_attribute *attr, const char *buf, size_t n)
{
struct usb_udc *udc = container_of(dev, struct usb_udc, dev);
+ ssize_t ret;
+ mutex_lock(&udc_lock);
if (!udc->driver) {
dev_err(dev, "soft-connect without a gadget driver\n");
- return -EOPNOTSUPP;
+ ret = -EOPNOTSUPP;
+ goto out;
}
if (sysfs_streq(buf, "connect")) {
@@ -1486,10 +1489,14 @@ static ssize_t soft_connect_store(struct
usb_gadget_udc_stop(udc);
} else {
dev_err(dev, "unsupported command '%s'\n", buf);
- return -EINVAL;
+ ret = -EINVAL;
+ goto out;
}
- return n;
+ ret = n;
+out:
+ mutex_unlock(&udc_lock);
+ return ret;
}
static DEVICE_ATTR_WO(soft_connect);
[PATCH 4.19 40/58] usb: bdc: Make bdc pci driver depend on BROKEN
From: Patrik Jakobsson commit ef02684c4e67d8c35ac83083564135bc7b1d3445 upstream. The bdc pci driver is going to be removed due to it not existing in the wild. This patch turns off compilation of the driver so that stable kernels can also pick up the change. This helps the out-of-tree facetimehd webcam driver as the pci id conflicts with bdc. Cc: Al Cooper Cc: Acked-by: Felipe Balbi Signed-off-by: Patrik Jakobsson Link: https://lore.kernel.org/r/20210118203615.13995-1-patrik.r.jakobs...@gmail.com Signed-off-by: Greg Kroah-Hartman --- drivers/usb/gadget/udc/bdc/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/usb/gadget/udc/bdc/Kconfig +++ b/drivers/usb/gadget/udc/bdc/Kconfig @@ -15,7 +15,7 @@ if USB_BDC_UDC comment "Platform Support" config USB_BDC_PCI tristate "BDC support for PCIe based platforms" - depends on USB_PCI + depends on USB_PCI && BROKEN default USB_BDC_UDC help Enable support for platforms which have BDC connected through PCIe, such as Lego3 FPGA platform.
[PATCH 4.19 42/58] xhci: tegra: Delay for disabling LFPS detector
From: JC Kuo
commit da7e0c3c2909a3d9bf8acfe1db3cb213bd7febfb upstream.
Occasionally, we are seeing some SuperSpeed devices resumes right after
being directed to U3. This commits add 500us delay to ensure LFPS
detector is disabled before sending ACK to firmware.
[ 16.099363] tegra-xusb 7009.usb: entering ELPG
[ 16.104343] tegra-xusb 7009.usb: 2-1 isn't suspended: 0x0c001203
[ 16.114576] tegra-xusb 7009.usb: not all ports suspended: -16
[ 16.120789] tegra-xusb 7009.usb: entering ELPG failed
The register write passes through a few flop stages of 32KHz clock domain.
NVIDIA ASIC designer reviewed RTL and suggests 500us delay.
Cc: sta...@vger.kernel.org
Signed-off-by: JC Kuo
Signed-off-by: Mathias Nyman
Link:
https://lore.kernel.org/r/20210115161907.2875631-3-mathias.ny...@linux.intel.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/host/xhci-tegra.c |7 +++
1 file changed, 7 insertions(+)
--- a/drivers/usb/host/xhci-tegra.c
+++ b/drivers/usb/host/xhci-tegra.c
@@ -578,6 +578,13 @@ static void tegra_xusb_mbox_handle(struc
enable);
if (err < 0)
break;
+
+ /*
+* wait 500us for LFPS detector to be disabled before
+* sending ACK
+*/
+ if (!enable)
+ usleep_range(500, 1000);
}
if (err < 0) {
[PATCH 4.19 43/58] driver core: Extend device_is_dependent()
From: Rafael J. Wysocki
commit 3d1cf435e201d1fd63e4346b141881aed086effd upstream.
If the device passed as the target (second argument) to
device_is_dependent() is not completely registered (that is, it has
been initialized, but not added yet), but the parent pointer of it
is set, it may be missing from the list of the parent's children
and device_for_each_child() called by device_is_dependent() cannot
be relied on to catch that dependency.
For this reason, modify device_is_dependent() to check the ancestors
of the target device by following its parent pointer in addition to
the device_for_each_child() walk.
Fixes: 9ed9895370ae ("driver core: Functional dependencies tracking support")
Reported-by: Stephan Gerhold
Tested-by: Stephan Gerhold
Reviewed-by: Saravana Kannan
Signed-off-by: Rafael J. Wysocki
Link: https://lore.kernel.org/r/17705994.d592GUb2YH@kreacher
Cc: stable
Signed-off-by: Greg Kroah-Hartman
---
drivers/base/core.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -93,6 +93,16 @@ void device_links_read_unlock(int not_us
}
#endif /* !CONFIG_SRCU */
+static bool device_is_ancestor(struct device *dev, struct device *target)
+{
+ while (target->parent) {
+ target = target->parent;
+ if (dev == target)
+ return true;
+ }
+ return false;
+}
+
/**
* device_is_dependent - Check if one device depends on another one
* @dev: Device to check dependencies for.
@@ -106,7 +116,12 @@ static int device_is_dependent(struct de
struct device_link *link;
int ret;
- if (dev == target)
+ /*
+* The "ancestors" check is needed to catch the case when the target
+* device has not been completely initialized yet and it is still
+* missing from the list of children of its parent device.
+*/
+ if (dev == target || device_is_ancestor(dev, target))
return 1;
ret = device_for_each_child(dev, target, device_is_dependent);
[PATCH 4.19 44/58] netfilter: rpfilter: mask ecn bits before fib lookup
From: Guillaume Nault
commit 2e5a6266fbb11ae93c468dfecab169aca9c27b43 upstream.
RT_TOS() only masks one of the two ECN bits. Therefore rpfilter_mt()
treats Not-ECT or ECT(1) packets in a different way than those with
ECT(0) or CE.
Reproducer:
Create two netns, connected with a veth:
$ ip netns add ns0
$ ip netns add ns1
$ ip link add name veth01 netns ns0 type veth peer name veth10 netns ns1
$ ip -netns ns0 link set dev veth01 up
$ ip -netns ns1 link set dev veth10 up
$ ip -netns ns0 address add 192.0.2.10/32 dev veth01
$ ip -netns ns1 address add 192.0.2.11/32 dev veth10
Add a route to ns1 in ns0:
$ ip -netns ns0 route add 192.0.2.11/32 dev veth01
In ns1, only packets with TOS 4 can be routed to ns0:
$ ip -netns ns1 route add 192.0.2.10/32 tos 4 dev veth10
Ping from ns0 to ns1 works regardless of the ECN bits, as long as TOS
is 4:
$ ip netns exec ns0 ping -Q 4 192.0.2.11 # TOS 4, Not-ECT
... 0% packet loss ...
$ ip netns exec ns0 ping -Q 5 192.0.2.11 # TOS 4, ECT(1)
... 0% packet loss ...
$ ip netns exec ns0 ping -Q 6 192.0.2.11 # TOS 4, ECT(0)
... 0% packet loss ...
$ ip netns exec ns0 ping -Q 7 192.0.2.11 # TOS 4, CE
... 0% packet loss ...
Now use iptable's rpfilter module in ns1:
$ ip netns exec ns1 iptables-legacy -t raw -A PREROUTING -m rpfilter --invert
-j DROP
Not-ECT and ECT(1) packets still pass:
$ ip netns exec ns0 ping -Q 4 192.0.2.11 # TOS 4, Not-ECT
... 0% packet loss ...
$ ip netns exec ns0 ping -Q 5 192.0.2.11 # TOS 4, ECT(1)
... 0% packet loss ...
But ECT(0) and ECN packets are dropped:
$ ip netns exec ns0 ping -Q 6 192.0.2.11 # TOS 4, ECT(0)
... 100% packet loss ...
$ ip netns exec ns0 ping -Q 7 192.0.2.11 # TOS 4, CE
... 100% packet loss ...
After this patch, rpfilter doesn't drop ECT(0) and CE packets anymore.
Fixes: 8f97339d3feb ("netfilter: add ipv4 reverse path filter match")
Signed-off-by: Guillaume Nault
Signed-off-by: Jakub Kicinski
Signed-off-by: Greg Kroah-Hartman
---
net/ipv4/netfilter/ipt_rpfilter.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/ipv4/netfilter/ipt_rpfilter.c
+++ b/net/ipv4/netfilter/ipt_rpfilter.c
@@ -94,7 +94,7 @@ static bool rpfilter_mt(const struct sk_
flow.daddr = iph->saddr;
flow.saddr = rpfilter_get_saddr(iph->daddr);
flow.flowi4_mark = info->flags & XT_RPFILTER_VALID_MARK ? skb->mark : 0;
- flow.flowi4_tos = RT_TOS(iph->tos);
+ flow.flowi4_tos = iph->tos & IPTOS_RT_MASK;
flow.flowi4_scope = RT_SCOPE_UNIVERSE;
flow.flowi4_oif = l3mdev_master_ifindex_rcu(xt_in(par));
[PATCH 4.19 41/58] xhci: make sure TRB is fully written before giving it to the controller
From: Mathias Nyman commit 576667bad341516edc4e18eb85acb0a2b4c9c9d9 upstream. Once the command ring doorbell is rung the xHC controller will parse all command TRBs on the command ring that have the cycle bit set properly. If the driver just started writing the next command TRB to the ring when hardware finished the previous TRB, then HW might fetch an incomplete TRB as long as its cycle bit set correctly. A command TRB is 16 bytes (128 bits) long. Driver writes the command TRB in four 32 bit chunks, with the chunk containing the cycle bit last. This does however not guarantee that chunks actually get written in that order. This was detected in stress testing when canceling URBs with several connected USB devices. Two consecutive "Set TR Dequeue pointer" commands got queued right after each other, and the second one was only partially written when the controller parsed it, causing the dequeue pointer to be set to bogus values. This was seen as error messages: "Mismatch between completed Set TR Deq Ptr command & xHCI internal state" Solution is to add a write memory barrier before writing the cycle bit. Cc: Tested-by: Ross Zwisler Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20210115161907.2875631-2-mathias.ny...@linux.intel.com Signed-off-by: Greg Kroah-Hartman --- drivers/usb/host/xhci-ring.c |2 ++ 1 file changed, 2 insertions(+) --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -2835,6 +2835,8 @@ static void queue_trb(struct xhci_hcd *x trb->field[0] = cpu_to_le32(field1); trb->field[1] = cpu_to_le32(field2); trb->field[2] = cpu_to_le32(field3); + /* make sure TRB is fully written before giving it to the controller */ + wmb(); trb->field[3] = cpu_to_le32(field4); trace_xhci_queue_trb(ring, trb);
[PATCH 4.19 37/58] USB: ehci: fix an interrupt calltrace error
From: Longfang Liu commit 643a4df7fe3f6831d14536fd692be85f92670a52 upstream. The system that use Synopsys USB host controllers goes to suspend when using USB audio player. This causes the USB host controller continuous send interrupt signal to system, When the number of interrupts exceeds 10, the system will forcibly close the interrupts and output a calltrace error. When the system goes to suspend, the last interrupt is reported to the driver. At this time, the system has set the state to suspend. This causes the last interrupt to not be processed by the system and not clear the interrupt flag. This uncleared interrupt flag constantly triggers new interrupt event. This causing the driver to receive more than 100,000 interrupts, which causes the system to forcibly close the interrupt report and report the calltrace error. so, when the driver goes to sleep and changes the system state to suspend, the interrupt flag needs to be cleared. Signed-off-by: Longfang Liu Acked-by: Alan Stern Link: https://lore.kernel.org/r/1610416647-45774-1-git-send-email-liulongf...@huawei.com Cc: stable Signed-off-by: Greg Kroah-Hartman --- drivers/usb/host/ehci-hub.c |3 +++ 1 file changed, 3 insertions(+) --- a/drivers/usb/host/ehci-hub.c +++ b/drivers/usb/host/ehci-hub.c @@ -345,6 +345,9 @@ static int ehci_bus_suspend (struct usb_ unlink_empty_async_suspended(ehci); + /* Some Synopsys controllers mistakenly leave IAA turned on */ + ehci_writel(ehci, STS_IAA, &ehci->regs->status); + /* Any IAA cycle that started before the suspend is now invalid */ end_iaa_cycle(ehci); ehci_handle_start_intr_unlinks(ehci);
[PATCH 4.19 45/58] sh: dma: fix kconfig dependency for G2_DMA
From: Necip Fazil Yildiran
commit f477a538c14d07f8c45e554c8c5208d588514e98 upstream.
When G2_DMA is enabled and SH_DMA is disabled, it results in the following
Kbuild warning:
WARNING: unmet direct dependencies detected for SH_DMA_API
Depends on [n]: SH_DMA [=n]
Selected by [y]:
- G2_DMA [=y] && SH_DREAMCAST [=y]
The reason is that G2_DMA selects SH_DMA_API without depending on or
selecting SH_DMA while SH_DMA_API depends on SH_DMA.
When G2_DMA was first introduced with commit 40f49e7ed77f
("sh: dma: Make G2 DMA configurable."), this wasn't an issue since
SH_DMA_API didn't have such dependency, and this way was the only way to
enable it since SH_DMA_API was non-visible. However, later SH_DMA_API was
made visible and dependent on SH_DMA with commit d8902adcc1a9
("dmaengine: sh: Add Support SuperH DMA Engine driver").
Let G2_DMA depend on SH_DMA_API instead to avoid Kbuild issues.
Fixes: d8902adcc1a9 ("dmaengine: sh: Add Support SuperH DMA Engine driver")
Signed-off-by: Necip Fazil Yildiran
Signed-off-by: Rich Felker
Signed-off-by: Greg Kroah-Hartman
---
arch/sh/drivers/dma/Kconfig |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/arch/sh/drivers/dma/Kconfig
+++ b/arch/sh/drivers/dma/Kconfig
@@ -63,8 +63,7 @@ config PVR2_DMA
config G2_DMA
tristate "G2 Bus DMA support"
- depends on SH_DREAMCAST
- select SH_DMA_API
+ depends on SH_DREAMCAST && SH_DMA_API
help
This enables support for the DMA controller for the Dreamcast's
G2 bus. Drivers that want this will generally enable this on
[PATCH 4.19 19/58] drm/nouveau/bios: fix issue shadowing expansion ROMs
From: Ben Skeggs
[ Upstream commit 402a89660e9dc880710b12773076a336c9dab3d7 ]
This issue has generally been covered up by the presence of additional
expansion ROMs after the ones we're interested in, with header fetches
of subsequent images loading enough of the ROM to hide the issue.
Noticed on GA102, which lacks a type 0x70 image compared to TU102,.
[ 906.364197] nouveau :09:00.0: bios: : type 00, 65024 bytes
[ 906.381205] nouveau :09:00.0: bios: fe00: type 03, 91648 bytes
[ 906.405213] nouveau :09:00.0: bios: 00026400: type e0, 22016 bytes
[ 906.410984] nouveau :09:00.0: bios: 0002ba00: type e0, 366080 bytes
vs
[ 22.961901] nouveau :09:00.0: bios: : type 00, 60416 bytes
[ 22.984174] nouveau :09:00.0: bios: ec00: type 03, 71168 bytes
[ 23.010446] nouveau :09:00.0: bios: 00020200: type e0, 48128 bytes
[ 23.028220] nouveau :09:00.0: bios: 0002be00: type e0, 140800 bytes
[ 23.080196] nouveau :09:00.0: bios: 0004e400: type 70, 7168 bytes
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
index 7deb81b6dbac6..4b571cc6bc70f 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
@@ -75,7 +75,7 @@ shadow_image(struct nvkm_bios *bios, int idx, u32 offset,
struct shadow *mthd)
nvkm_debug(subdev, "%08x: type %02x, %d bytes\n",
image.base, image.type, image.size);
- if (!shadow_fetch(bios, mthd, image.size)) {
+ if (!shadow_fetch(bios, mthd, image.base + image.size)) {
nvkm_debug(subdev, "%08x: fetch failed\n", image.base);
return 0;
}
--
2.27.0
[PATCH 4.19 00/58] 4.19.171-rc1 review
This is the start of the stable review cycle for the 4.19.171 release. There are 58 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed, 27 Jan 2021 18:31:44 +. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.171-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y and the diffstat can be found below. thanks, greg k-h - Pseudo-Shortlog of commits: Greg Kroah-Hartman Linux 4.19.171-rc1 Dan Carpenter net: dsa: b53: fix an off by one in checking "vlan->vid" Tariq Toukan net: Disable NETIF_F_HW_TLS_RX when RXCSUM is disabled Vladimir Oltean net: mscc: ocelot: allow offloading of bridge on top of LAG Matteo Croce ipv6: set multicast flag on the multicast route Eric Dumazet net_sched: reject silly cell_log in qdisc_get_rtab() Eric Dumazet net_sched: avoid shift-out-of-bounds in tcindex_set_parms() Matteo Croce ipv6: create multicast route with RTPROT_KERNEL Guillaume Nault udp: mask TOS bits in udp_v4_early_demux() Lecopzer Chen kasan: fix incorrect arguments passing in kasan_add_zero_shadow Lecopzer Chen kasan: fix unaligned address is unhandled in kasan_remove_zero_shadow Alexander Lobakin skbuff: back tiny skbs with kmalloc() in __netdev_alloc_skb() too Geert Uytterhoeven sh_eth: Fix power down vs. is_opened flag ordering Rasmus Villemoes net: dsa: mv88e6xxx: also read STU state in mv88e6250_g1_vtu_getnext Necip Fazil Yildiran sh: dma: fix kconfig dependency for G2_DMA Guillaume Nault netfilter: rpfilter: mask ecn bits before fib lookup Rafael J. Wysocki driver core: Extend device_is_dependent() JC Kuo xhci: tegra: Delay for disabling LFPS detector Mathias Nyman xhci: make sure TRB is fully written before giving it to the controller Patrik Jakobsson usb: bdc: Make bdc pci driver depend on BROKEN Thinh Nguyen usb: udc: core: Use lock when write to soft_connect Ryan Chen usb: gadget: aspeed: fix stop dma register setting. Longfang Liu USB: ehci: fix an interrupt calltrace error Eugene Korenevsky ehci: fix EHCI host controller initialization sequence Pali Rohár serial: mvebu-uart: fix tx lost characters at power off Wang Hui stm class: Fix module init return on allocation failure Alexander Shishkin intel_th: pci: Add Alder Lake-P support Mathias Kresin irqchip/mips-cpu: Set IPI domain parent chip Lars-Peter Clausen iio: ad5504: Fix setting power-down state Vincent Mailhol can: peak_usb: fix use after free bugs Vincent Mailhol can: vxcan: vxcan_xmit: fix use after free bug Vincent Mailhol can: dev: can_restart: fix use after free bug Hangbin Liu selftests: net: fib_tests: remove duplicate log test Hans de Goede platform/x86: intel-vbtn: Drop HP Stream x360 Convertible PC 11 from allow-list Wolfram Sang i2c: octeon: check correct size of maximum RECV_LEN packet Arnd Bergmann scsi: megaraid_sas: Fix MEGASAS_IOC_FIRMWARE regression Ben Skeggs drm/nouveau/kms/nv50-: fix case where notifier buffer is at offset 0 Ben Skeggs drm/nouveau/mmu: fix vram heap sizing Ben Skeggs drm/nouveau/i2c/gm200: increase width of aux semaphore owner fields Ben Skeggs drm/nouveau/privring: ack interrupts the same way as RM Ben Skeggs drm/nouveau/bios: fix issue shadowing expansion ROMs David Woodhouse xen: Fix event channel callback via INTX/GSI Peter Geis clk: tegra30: Add hda clock default rates to clock driver Seth Miller HID: Ignore battery for Elan touchscreen on ASUS UX550 Damien Le Moal riscv: Fix kernel time_init() Nilesh Javali scsi: qedi: Correct max length of CHAP secret Can Guo scsi: ufs: Correct the LUN used in eh_device_reset_handler() callback Anthony Iliopoulos dm integrity: select CRYPTO_SKCIPHER Cezary Rojewski ASoC: Intel: haswell: Add missing pm_ops Pan Bian drm/atomic: put state on error path Mikulas Patocka dm integrity: fix a crash if "recalculate" used without "internal_hash" Hannes Reinecke dm: avoid filesystem lookup in dm_get_dev_t() Alex Leibovich mmc: sdhci-xenon: fix 1.8v regulator stabilization Peter Collingbourne mmc: core: don't initialize block size from ext_csd if not present Josef Bacik btrfs: fix lockdep splat in btrfs_recover_relocation Hans de Goede ACPI: scan: Make acpi_bus_get_device() clear return pointer on error Takashi Iwai ALSA: hda/via: Add minimum mute flag Takashi Iwai ALSA: seq: oss: Fix missing error check in snd_seq_oss_synth_make_info() Mikko Perttunen i2c: bpmp-tegra: Ignore unkn
[PATCH 4.19 08/58] dm: avoid filesystem lookup in dm_get_dev_t()
From: Hannes Reinecke
commit 809b1e4945774c9ec5619a8f4e2189b7b3833c0c upstream.
This reverts commit
644bda6f3460 ("dm table: fall back to getting device using name_to_dev_t()")
dm_get_dev_t() is just used to convert an arbitrary 'path' string
into a dev_t. It doesn't presume that the device is present; that
check will be done later, as the only caller is dm_get_device(),
which does a dm_get_table_device() later on, which will properly
open the device.
So if the path string already _is_ in major:minor representation
we can convert it directly, avoiding a recursion into the filesystem
to lookup the block device.
This avoids a hang in multipath_message() when the filesystem is
inaccessible.
Fixes: 644bda6f3460 ("dm table: fall back to getting device using
name_to_dev_t()")
Cc: sta...@vger.kernel.org
Signed-off-by: Hannes Reinecke
Signed-off-by: Martin Wilck
Reviewed-by: Christoph Hellwig
Signed-off-by: Mike Snitzer
Signed-off-by: Greg Kroah-Hartman
---
drivers/md/dm-table.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
--- a/drivers/md/dm-table.c
+++ b/drivers/md/dm-table.c
@@ -431,14 +431,23 @@ int dm_get_device(struct dm_target *ti,
{
int r;
dev_t dev;
+ unsigned int major, minor;
+ char dummy;
struct dm_dev_internal *dd;
struct dm_table *t = ti->table;
BUG_ON(!t);
- dev = dm_get_dev_t(path);
- if (!dev)
- return -ENODEV;
+ if (sscanf(path, "%u:%u%c", &major, &minor, &dummy) == 2) {
+ /* Extract the major/minor numbers */
+ dev = MKDEV(major, minor);
+ if (MAJOR(dev) != major || MINOR(dev) != minor)
+ return -EOVERFLOW;
+ } else {
+ dev = dm_get_dev_t(path);
+ if (!dev)
+ return -ENODEV;
+ }
dd = find_device(&t->devices, dev);
if (!dd) {
[PATCH 4.19 09/58] dm integrity: fix a crash if "recalculate" used without "internal_hash"
From: Mikulas Patocka
commit 2d06dfecb132a1cc2e374a44eae83b5c4356b8b4 upstream.
Recalculate can only be specified with internal_hash.
Cc: sta...@vger.kernel.org # v4.19+
Signed-off-by: Mikulas Patocka
Signed-off-by: Mike Snitzer
Signed-off-by: Greg Kroah-Hartman
---
drivers/md/dm-integrity.c |6 ++
1 file changed, 6 insertions(+)
--- a/drivers/md/dm-integrity.c
+++ b/drivers/md/dm-integrity.c
@@ -3515,6 +3515,12 @@ try_smaller_buffer:
r = -ENOMEM;
goto bad;
}
+ } else {
+ if (ic->sb->flags & cpu_to_le32(SB_FLAG_RECALCULATING)) {
+ ti->error = "Recalculate can only be specified with
internal_hash";
+ r = -EINVAL;
+ goto bad;
+ }
}
ic->bufio = dm_bufio_client_create(ic->meta_dev ? ic->meta_dev->bdev :
ic->dev->bdev,
Re: [PATCH] arm64: dts: meson: add i2c3/rtc nodes and rtc aliases to ODROID-N2 dtsi
On Mon, 11 Jan 2021 13:58:31 +, Christian Hewitt wrote: > Enable the onboard pcf8563 rtc hardware on ODROID N2/N2+ boards via the > common dtsi. Also add aliases to ensure vrtc does not claim /dev/rtc0. Applied, thanks! [1/1] arm64: dts: meson: add i2c3/rtc nodes and rtc aliases to ODROID-N2 dtsi commit: 930f424bd8cec154466d7929c10f1ad0525f605f Best regards, -- Kevin Hilman
Re: [PATCH] arm64: dts: meson: shorten audio card names for alsa compatibility
On Fri, 1 Jan 2021 06:37:37 +, Christian Hewitt wrote: > This patch shortens all audio card model names by dropping the SoC prefix > (for conformity) and rewording those that are still longer than alsa's 15 > character name limit [0] to avoid userspace config issues. > > [0] > https://github.com/torvalds/linux/blob/master/Documentation/sound/alsa-configuration.rst#common-parameters-for-top-sound-card-modules Applied, thanks! [1/1] arm64: dts: meson: shorten audio card names for alsa compatibility commit: cf21697a8c5bf65eb4e05717ca5caee8215c3797 Best regards, -- Kevin Hilman
[PATCH 4.19 38/58] usb: gadget: aspeed: fix stop dma register setting.
From: Ryan Chen
commit 4e0dcf62ab4cf917d0cbe751b8bf229a065248d4 upstream.
The vhub engine has two dma mode, one is descriptor list, another
is single stage DMA. Each mode has different stop register setting.
Descriptor list operation (bit2) : 0 disable reset, 1: enable reset
Single mode operation (bit0) : 0 : disable, 1: enable
Fixes: 7ecca2a4080c ("usb/gadget: Add driver for Aspeed SoC virtual hub")
Cc: stable
Acked-by: Felipe Balbi
Acked-by: Joel Stanley
Signed-off-by: Ryan Chen
Link: https://lore.kernel.org/r/20210108081238.10199-2-ryan_c...@aspeedtech.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/gadget/udc/aspeed-vhub/epn.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/usb/gadget/udc/aspeed-vhub/epn.c
+++ b/drivers/usb/gadget/udc/aspeed-vhub/epn.c
@@ -420,7 +420,10 @@ static void ast_vhub_stop_active_req(str
u32 state, reg, loops;
/* Stop DMA activity */
- writel(0, ep->epn.regs + AST_VHUB_EP_DMA_CTLSTAT);
+ if (ep->epn.desc_mode)
+ writel(VHUB_EP_DMA_CTRL_RESET, ep->epn.regs +
AST_VHUB_EP_DMA_CTLSTAT);
+ else
+ writel(0, ep->epn.regs + AST_VHUB_EP_DMA_CTLSTAT);
/* Wait for it to complete */
for (loops = 0; loops < 1000; loops++) {
[PATCH 4.19 48/58] skbuff: back tiny skbs with kmalloc() in __netdev_alloc_skb() too
From: Alexander Lobakin
commit 66c556025d687dbdd0f748c5e1df89c977b6c02a upstream.
Commit 3226b158e67c ("net: avoid 32 x truesize under-estimation for
tiny skbs") ensured that skbs with data size lower than 1025 bytes
will be kmalloc'ed to avoid excessive page cache fragmentation and
memory consumption.
However, the fix adressed only __napi_alloc_skb() (primarily for
virtio_net and napi_get_frags()), but the issue can still be achieved
through __netdev_alloc_skb(), which is still used by several drivers.
Drivers often allocate a tiny skb for headers and place the rest of
the frame to frags (so-called copybreak).
Mirror the condition to __netdev_alloc_skb() to handle this case too.
Since v1 [0]:
- fix "Fixes:" tag;
- refine commit message (mention copybreak usecase).
[0] https://lore.kernel.org/netdev/20210114235423.232737-1-aloba...@pm.me
Fixes: a1c7fff7e18f ("net: netdev_alloc_skb() use build_skb()")
Signed-off-by: Alexander Lobakin
Link: https://lore.kernel.org/r/20210115150354.85967-1-aloba...@pm.me
Signed-off-by: Jakub Kicinski
Signed-off-by: Greg Kroah-Hartman
---
net/core/skbuff.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -398,7 +398,11 @@ struct sk_buff *__netdev_alloc_skb(struc
len += NET_SKB_PAD;
- if ((len > SKB_WITH_OVERHEAD(PAGE_SIZE)) ||
+ /* If requested length is either too small or too big,
+* we use kmalloc() for skb->head allocation.
+*/
+ if (len <= SKB_WITH_OVERHEAD(1024) ||
+ len > SKB_WITH_OVERHEAD(PAGE_SIZE) ||
(gfp_mask & (__GFP_DIRECT_RECLAIM | GFP_DMA))) {
skb = __alloc_skb(len, gfp_mask, SKB_ALLOC_RX, NUMA_NO_NODE);
if (!skb)
[PATCH 4.19 49/58] kasan: fix unaligned address is unhandled in kasan_remove_zero_shadow
From: Lecopzer Chen
commit a11a496ee6e2ab6ed850233c96b94caf042af0b9 upstream.
During testing kasan_populate_early_shadow and kasan_remove_zero_shadow,
if the shadow start and end address in kasan_remove_zero_shadow() is not
aligned to PMD_SIZE, the remain unaligned PTE won't be removed.
In the test case for kasan_remove_zero_shadow():
shadow_start: 0xffb80200, shadow end: 0xffbfbe00
3-level page table:
PUD_SIZE: 0x4000 PMD_SIZE: 0x20 PAGE_SIZE: 4K
0xffbf8000 ~ 0xffbfbdf8 will not be removed because in
kasan_remove_pud_table(), kasan_pmd_table(*pud) is true but the next
address is 0xffbfbdf8 which is not aligned to PUD_SIZE.
In the correct condition, this should fallback to the next level
kasan_remove_pmd_table() but the condition flow always continue to skip
the unaligned part.
Fix by correcting the condition when next and addr are neither aligned.
Link: https://lkml.kernel.org/r/20210103135621.83129-1-lecop...@gmail.com
Fixes: 0207df4fa1a86 ("kernel/memremap, kasan: make ZONE_DEVICE with work with
KASAN")
Signed-off-by: Lecopzer Chen
Cc: Andrey Ryabinin
Cc: Dan Williams
Cc: Dmitry Vyukov
Cc: Alexander Potapenko
Cc: YJ Chiang
Cc: Andrey Konovalov
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
mm/kasan/kasan_init.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
--- a/mm/kasan/kasan_init.c
+++ b/mm/kasan/kasan_init.c
@@ -372,9 +372,10 @@ static void kasan_remove_pmd_table(pmd_t
if (kasan_pte_table(*pmd)) {
if (IS_ALIGNED(addr, PMD_SIZE) &&
- IS_ALIGNED(next, PMD_SIZE))
+ IS_ALIGNED(next, PMD_SIZE)) {
pmd_clear(pmd);
- continue;
+ continue;
+ }
}
pte = pte_offset_kernel(pmd, addr);
kasan_remove_pte_table(pte, addr, next);
@@ -397,9 +398,10 @@ static void kasan_remove_pud_table(pud_t
if (kasan_pmd_table(*pud)) {
if (IS_ALIGNED(addr, PUD_SIZE) &&
- IS_ALIGNED(next, PUD_SIZE))
+ IS_ALIGNED(next, PUD_SIZE)) {
pud_clear(pud);
- continue;
+ continue;
+ }
}
pmd = pmd_offset(pud, addr);
pmd_base = pmd_offset(pud, 0);
@@ -423,9 +425,10 @@ static void kasan_remove_p4d_table(p4d_t
if (kasan_pud_table(*p4d)) {
if (IS_ALIGNED(addr, P4D_SIZE) &&
- IS_ALIGNED(next, P4D_SIZE))
+ IS_ALIGNED(next, P4D_SIZE)) {
p4d_clear(p4d);
- continue;
+ continue;
+ }
}
pud = pud_offset(p4d, addr);
kasan_remove_pud_table(pud, addr, next);
@@ -457,9 +460,10 @@ void kasan_remove_zero_shadow(void *star
if (kasan_p4d_table(*pgd)) {
if (IS_ALIGNED(addr, PGDIR_SIZE) &&
- IS_ALIGNED(next, PGDIR_SIZE))
+ IS_ALIGNED(next, PGDIR_SIZE)) {
pgd_clear(pgd);
- continue;
+ continue;
+ }
}
p4d = p4d_offset(pgd, addr);
[PATCH 4.19 47/58] sh_eth: Fix power down vs. is_opened flag ordering
From: Geert Uytterhoeven
commit f6a2e94b3f9d89cb40771ff746b16b5687650cbb upstream.
sh_eth_close() does a synchronous power down of the device before
marking it closed. Revert the order, to make sure the device is never
marked opened while suspended.
While at it, use pm_runtime_put() instead of pm_runtime_put_sync(), as
there is no reason to do a synchronous power down.
Fixes: 7fa2955ff70ce453 ("sh_eth: Fix sleeping function called from invalid
context")
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Sergei Shtylyov
Reviewed-by: Niklas Söderlund
Link: https://lore.kernel.org/r/20210118150812.796791-1-geert+rene...@glider.be
Signed-off-by: Jakub Kicinski
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/ethernet/renesas/sh_eth.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -2620,10 +2620,10 @@ static int sh_eth_close(struct net_devic
/* Free all the skbuffs in the Rx queue and the DMA buffer. */
sh_eth_ring_free(ndev);
- pm_runtime_put_sync(&mdp->pdev->dev);
-
mdp->is_opened = 0;
+ pm_runtime_put(&mdp->pdev->dev);
+
return 0;
}
[PATCH 4.19 46/58] net: dsa: mv88e6xxx: also read STU state in mv88e6250_g1_vtu_getnext
From: Rasmus Villemoes commit 87fe04367d842c4d97a77303242d4dd4ac351e46 upstream. mv88e6xxx_port_vlan_join checks whether the VTU already contains an entry for the given vid (via mv88e6xxx_vtu_getnext), and if so, merely changes the relevant .member[] element and loads the updated entry into the VTU. However, at least for the mv88e6250, the on-stack struct mv88e6xxx_vtu_entry vlan never has its .state[] array explicitly initialized, neither in mv88e6xxx_port_vlan_join() nor inside the getnext implementation. So the new entry has random garbage for the STU bits, breaking VLAN filtering. When the VTU entry is initially created, those bits are all zero, and we should make sure to keep them that way when the entry is updated. Fixes: 92307069a96c (net: dsa: mv88e6xxx: Avoid VTU corruption on 6097) Signed-off-by: Rasmus Villemoes Reviewed-by: Florian Fainelli Reviewed-by: Tobias Waldekranz Tested-by: Tobias Waldekranz Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman --- drivers/net/dsa/mv88e6xxx/global1_vtu.c |4 1 file changed, 4 insertions(+) --- a/drivers/net/dsa/mv88e6xxx/global1_vtu.c +++ b/drivers/net/dsa/mv88e6xxx/global1_vtu.c @@ -357,6 +357,10 @@ int mv88e6185_g1_vtu_getnext(struct mv88 if (err) return err; + err = mv88e6185_g1_stu_data_read(chip, entry); + if (err) + return err; + /* VTU DBNum[3:0] are located in VTU Operation 3:0 * VTU DBNum[7:4] are located in VTU Operation 11:8 */
[PATCH 4.19 28/58] can: dev: can_restart: fix use after free bug
From: Vincent Mailhol
[ Upstream commit 03f16c5075b22c8902d2af739969e878b0879c94 ]
After calling netif_rx_ni(skb), dereferencing skb is unsafe.
Especially, the can_frame cf which aliases skb memory is accessed
after the netif_rx_ni() in:
stats->rx_bytes += cf->len;
Reordering the lines solves the issue.
Fixes: 39549eef3587 ("can: CAN Network device driver and Netlink interface")
Link:
https://lore.kernel.org/r/20210120114137.200019-2-mailhol.vinc...@wanadoo.fr
Signed-off-by: Vincent Mailhol
Signed-off-by: Marc Kleine-Budde
Signed-off-by: Sasha Levin
---
drivers/net/can/dev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index f88590074569e..953c6fdc75cc4 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -579,11 +579,11 @@ static void can_restart(struct net_device *dev)
}
cf->can_id |= CAN_ERR_RESTARTED;
- netif_rx_ni(skb);
-
stats->rx_packets++;
stats->rx_bytes += cf->can_dlc;
+ netif_rx_ni(skb);
+
restart:
netdev_dbg(dev, "restarted\n");
priv->can_stats.restarts++;
--
2.27.0
[PATCH 4.19 55/58] ipv6: set multicast flag on the multicast route
From: Matteo Croce
commit ceed9038b2783d14e0422bdc6fd04f70580efb4c upstream.
The multicast route ff00::/8 is created with type RTN_UNICAST:
$ ip -6 -d route
unicast ::1 dev lo proto kernel scope global metric 256 pref medium
unicast fe80::/64 dev eth0 proto kernel scope global metric 256 pref medium
unicast ff00::/8 dev eth0 proto kernel scope global metric 256 pref medium
Set the type to RTN_MULTICAST which is more appropriate.
Fixes: e8478e80e5a7 ("net/ipv6: Save route type in rt6_info")
Signed-off-by: Matteo Croce
Signed-off-by: Jakub Kicinski
Signed-off-by: Greg Kroah-Hartman
---
net/ipv6/addrconf.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2395,7 +2395,7 @@ static void addrconf_add_mroute(struct n
.fc_ifindex = dev->ifindex,
.fc_dst_len = 8,
.fc_flags = RTF_UP,
- .fc_type = RTN_UNICAST,
+ .fc_type = RTN_MULTICAST,
.fc_nlinfo.nl_net = dev_net(dev),
.fc_protocol = RTPROT_KERNEL,
};
[PATCH 4.19 32/58] irqchip/mips-cpu: Set IPI domain parent chip
From: Mathias Kresin
commit 599b3063adf4bf041a87a69244ee36aded0d878f upstream.
Since commit 55567976629e ("genirq/irqdomain: Allow partial trimming of
irq_data hierarchy") the irq_data chain is valided.
The irq_domain_trim_hierarchy() function doesn't consider the irq + ipi
domain hierarchy as valid, since the ipi domain has the irq domain set
as parent, but the parent domain has no chip set. Hence the boot ends in
a kernel panic.
Set the chip for the parent domain as it is done in the mips gic irq
driver, to have a valid irq_data chain.
Fixes: 3838a547fda2 ("irqchip: mips-cpu: Introduce IPI IRQ domain support")
Cc: # v5.10+
Signed-off-by: Mathias Kresin
Signed-off-by: Marc Zyngier
Link: https://lore.kernel.org/r/20210107213603.1637781-1-...@kresin.me
Signed-off-by: Greg Kroah-Hartman
---
drivers/irqchip/irq-mips-cpu.c |7 +++
1 file changed, 7 insertions(+)
--- a/drivers/irqchip/irq-mips-cpu.c
+++ b/drivers/irqchip/irq-mips-cpu.c
@@ -201,6 +201,13 @@ static int mips_cpu_ipi_alloc(struct irq
if (ret)
return ret;
+ ret = irq_domain_set_hwirq_and_chip(domain->parent, virq + i,
hwirq,
+ &mips_mt_cpu_irq_controller,
+ NULL);
+
+ if (ret)
+ return ret;
+
ret = irq_set_irq_type(virq + i, IRQ_TYPE_LEVEL_HIGH);
if (ret)
return ret;
[PATCH 4.19 31/58] iio: ad5504: Fix setting power-down state
From: Lars-Peter Clausen
commit efd597b2839a9895e8a98fcb0b76d2f545802cd4 upstream.
The power-down mask of the ad5504 is actually a power-up mask. Meaning if
a bit is set the corresponding channel is powered up and if it is not set
the channel is powered down.
The driver currently has this the wrong way around, resulting in the
channel being powered up when requested to be powered down and vice versa.
Fixes: 3bbbf150ffde ("staging:iio:dac:ad5504: Use strtobool for boolean values")
Signed-off-by: Lars-Peter Clausen
Acked-by: Alexandru Ardelean
Link: https://lore.kernel.org/r/20201209104649.5794-1-l...@metafoo.de
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman
---
drivers/iio/dac/ad5504.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/iio/dac/ad5504.c
+++ b/drivers/iio/dac/ad5504.c
@@ -189,9 +189,9 @@ static ssize_t ad5504_write_dac_powerdow
return ret;
if (pwr_down)
- st->pwr_down_mask |= (1 << chan->channel);
- else
st->pwr_down_mask &= ~(1 << chan->channel);
+ else
+ st->pwr_down_mask |= (1 << chan->channel);
ret = ad5504_spi_write(st, AD5504_ADDR_CTRL,
AD5504_DAC_PWRDWN_MODE(st->pwr_down_mode) |
[PATCH 4.19 57/58] net: Disable NETIF_F_HW_TLS_RX when RXCSUM is disabled
From: Tariq Toukan
commit a3eb4e9d4c9218476d05c52dfd2be3d6fdce6b91 upstream.
With NETIF_F_HW_TLS_RX packets are decrypted in HW. This cannot be
logically done when RXCSUM offload is off.
Fixes: 14136564c8ee ("net: Add TLS RX offload feature")
Signed-off-by: Tariq Toukan
Reviewed-by: Boris Pismenny
Link: https://lore.kernel.org/r/20210117151538.9411-1-tar...@nvidia.com
Signed-off-by: Jakub Kicinski
Signed-off-by: Greg Kroah-Hartman
---
net/core/dev.c |5 +
1 file changed, 5 insertions(+)
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -8351,6 +8351,11 @@ static netdev_features_t netdev_fix_feat
}
}
+ if ((features & NETIF_F_HW_TLS_RX) && !(features & NETIF_F_RXCSUM)) {
+ netdev_dbg(dev, "Dropping TLS RX HW offload feature since no
RXCSUM feature.\n");
+ features &= ~NETIF_F_HW_TLS_RX;
+ }
+
return features;
}
[PATCH 4.19 33/58] intel_th: pci: Add Alder Lake-P support
From: Alexander Shishkin
commit cb5c681ab9037e25fcca20689c82cf034566d610 upstream.
This adds support for the Trace Hub in Alder Lake-P.
Signed-off-by: Alexander Shishkin
Link:
https://lore.kernel.org/r/20210115195917.3184-3-alexander.shish...@linux.intel.com
Cc: stable
Signed-off-by: Greg Kroah-Hartman
---
drivers/hwtracing/intel_th/pci.c |5 +
1 file changed, 5 insertions(+)
--- a/drivers/hwtracing/intel_th/pci.c
+++ b/drivers/hwtracing/intel_th/pci.c
@@ -231,6 +231,11 @@ static const struct pci_device_id intel_
.driver_data = (kernel_ulong_t)&intel_th_2x,
},
{
+ /* Alder Lake-P */
+ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x51a6),
+ .driver_data = (kernel_ulong_t)&intel_th_2x,
+ },
+ {
/* Emmitsburg PCH */
PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x1bcc),
.driver_data = (kernel_ulong_t)&intel_th_2x,
[PATCH 4.19 29/58] can: vxcan: vxcan_xmit: fix use after free bug
From: Vincent Mailhol
[ Upstream commit 75854cad5d80976f6ea0f0431f8cedd3bcc475cb ]
After calling netif_rx_ni(skb), dereferencing skb is unsafe.
Especially, the canfd_frame cfd which aliases skb memory is accessed
after the netif_rx_ni().
Fixes: a8f820a380a2 ("can: add Virtual CAN Tunnel driver (vxcan)")
Link:
https://lore.kernel.org/r/20210120114137.200019-3-mailhol.vinc...@wanadoo.fr
Signed-off-by: Vincent Mailhol
Signed-off-by: Marc Kleine-Budde
Signed-off-by: Sasha Levin
---
drivers/net/can/vxcan.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/vxcan.c b/drivers/net/can/vxcan.c
index ed6828821fbd3..ccd758ba3fb09 100644
--- a/drivers/net/can/vxcan.c
+++ b/drivers/net/can/vxcan.c
@@ -49,6 +49,7 @@ static netdev_tx_t vxcan_xmit(struct sk_buff *skb, struct
net_device *dev)
struct net_device *peer;
struct canfd_frame *cfd = (struct canfd_frame *)skb->data;
struct net_device_stats *peerstats, *srcstats = &dev->stats;
+ u8 len;
if (can_dropped_invalid_skb(dev, skb))
return NETDEV_TX_OK;
@@ -71,12 +72,13 @@ static netdev_tx_t vxcan_xmit(struct sk_buff *skb, struct
net_device *dev)
skb->dev= peer;
skb->ip_summed = CHECKSUM_UNNECESSARY;
+ len = cfd->len;
if (netif_rx_ni(skb) == NET_RX_SUCCESS) {
srcstats->tx_packets++;
- srcstats->tx_bytes += cfd->len;
+ srcstats->tx_bytes += len;
peerstats = &peer->stats;
peerstats->rx_packets++;
- peerstats->rx_bytes += cfd->len;
+ peerstats->rx_bytes += len;
}
out_unlock:
--
2.27.0
[PATCH 4.19 54/58] net_sched: reject silly cell_log in qdisc_get_rtab()
From: Eric Dumazet
commit e4bedf48aaa5552bc1f49703abd17606e7e6e82a upstream.
iproute2 probably never goes beyond 8 for the cell exponent,
but stick to the max shift exponent for signed 32bit.
UBSAN reported:
UBSAN: shift-out-of-bounds in net/sched/sch_api.c:389:22
shift exponent 130 is too large for 32-bit type 'int'
CPU: 1 PID: 8450 Comm: syz-executor586 Not tainted 5.11.0-rc3-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:79 [inline]
dump_stack+0x183/0x22e lib/dump_stack.c:120
ubsan_epilogue lib/ubsan.c:148 [inline]
__ubsan_handle_shift_out_of_bounds+0x432/0x4d0 lib/ubsan.c:395
__detect_linklayer+0x2a9/0x330 net/sched/sch_api.c:389
qdisc_get_rtab+0x2b5/0x410 net/sched/sch_api.c:435
cbq_init+0x28f/0x12c0 net/sched/sch_cbq.c:1180
qdisc_create+0x801/0x1470 net/sched/sch_api.c:1246
tc_modify_qdisc+0x9e3/0x1fc0 net/sched/sch_api.c:1662
rtnetlink_rcv_msg+0xb1d/0xe60 net/core/rtnetlink.c:5564
netlink_rcv_skb+0x1f0/0x460 net/netlink/af_netlink.c:2494
netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline]
netlink_unicast+0x7de/0x9b0 net/netlink/af_netlink.c:1330
netlink_sendmsg+0xaa6/0xe90 net/netlink/af_netlink.c:1919
sock_sendmsg_nosec net/socket.c:652 [inline]
sock_sendmsg net/socket.c:672 [inline]
sys_sendmsg+0x5a2/0x900 net/socket.c:2345
___sys_sendmsg net/socket.c:2399 [inline]
__sys_sendmsg+0x319/0x400 net/socket.c:2432
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Dumazet
Reported-by: syzbot
Acked-by: Cong Wang
Link: https://lore.kernel.org/r/20210114160637.1660597-1-eric.duma...@gmail.com
Signed-off-by: Jakub Kicinski
Signed-off-by: Greg Kroah-Hartman
---
net/sched/sch_api.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/net/sched/sch_api.c
+++ b/net/sched/sch_api.c
@@ -398,7 +398,8 @@ struct qdisc_rate_table *qdisc_get_rtab(
{
struct qdisc_rate_table *rtab;
- if (tab == NULL || r->rate == 0 || r->cell_log == 0 ||
+ if (tab == NULL || r->rate == 0 ||
+ r->cell_log == 0 || r->cell_log >= 32 ||
nla_len(tab) != TC_RTAB_SIZE) {
NL_SET_ERR_MSG(extack, "Invalid rate table parameters for
searching");
return NULL;
[PATCH 4.19 58/58] net: dsa: b53: fix an off by one in checking "vlan->vid"
From: Dan Carpenter
commit 8e4052c32d6b4b39c1e13c652c7e33748d447409 upstream.
The > comparison should be >= to prevent accessing one element beyond
the end of the dev->vlans[] array in the caller function, b53_vlan_add().
The "dev->vlans" array is allocated in the b53_switch_init() function
and it has "dev->num_vlans" elements.
Fixes: a2482d2ce349 ("net: dsa: b53: Plug in VLAN support")
Signed-off-by: Dan Carpenter
Acked-by: Florian Fainelli
Link: https://lore.kernel.org/r/YAbxI97Dl/pmBy5V@mwanda
Signed-off-by: Jakub Kicinski
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/dsa/b53/b53_common.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -1142,7 +1142,7 @@ int b53_vlan_prepare(struct dsa_switch *
if ((is5325(dev) || is5365(dev)) && vlan->vid_begin == 0)
return -EOPNOTSUPP;
- if (vlan->vid_end > dev->num_vlans)
+ if (vlan->vid_end >= dev->num_vlans)
return -ERANGE;
b53_enable_vlan(dev, true, dev->vlan_filtering_enabled);
[PATCH 5.4 03/86] platform/x86: ideapad-laptop: Disable touchpad_switch for ELAN0634
From: Jiaxun Yang
commit f419e5940f1d9892ea6f45acdaca572b9e73ff39 upstream.
Newer ideapads (e.g.: Yoga 14s, 720S 14) come with ELAN0634 touchpad do not
use EC to switch touchpad.
Reading VPCCMD_R_TOUCHPAD will return zero thus touchpad may be blocked
unexpectedly.
Writing VPCCMD_W_TOUCHPAD may cause a spurious key press.
Add has_touchpad_switch to workaround these machines.
Signed-off-by: Jiaxun Yang
Cc: sta...@vger.kernel.org # 5.4+
--
v2: Specify touchpad to ELAN0634
v3: Stupid missing ! in v2
v4: Correct acpi_dev_present usage (Hans)
Link: https://lore.kernel.org/r/20210107144438.12605-1-jiaxun.y...@flygoat.com
Signed-off-by: Hans de Goede
Signed-off-by: Greg Kroah-Hartman
---
drivers/platform/x86/ideapad-laptop.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -92,6 +92,7 @@ struct ideapad_private {
struct dentry *debug;
unsigned long cfg;
bool has_hw_rfkill_switch;
+ bool has_touchpad_switch;
const char *fnesc_guid;
};
@@ -535,7 +536,9 @@ static umode_t ideapad_is_visible(struct
} else if (attr == &dev_attr_fn_lock.attr) {
supported = acpi_has_method(priv->adev->handle, "HALS") &&
acpi_has_method(priv->adev->handle, "SALS");
- } else
+ } else if (attr == &dev_attr_touchpad.attr)
+ supported = priv->has_touchpad_switch;
+ else
supported = true;
return supported ? attr->mode : 0;
@@ -867,6 +870,9 @@ static void ideapad_sync_touchpad_state(
{
unsigned long value;
+ if (!priv->has_touchpad_switch)
+ return;
+
/* Without reading from EC touchpad LED doesn't switch state */
if (!read_ec_data(priv->adev->handle, VPCCMD_R_TOUCHPAD, &value)) {
/* Some IdeaPads don't really turn off touchpad - they only
@@ -989,6 +995,9 @@ static int ideapad_acpi_add(struct platf
priv->platform_device = pdev;
priv->has_hw_rfkill_switch = dmi_check_system(hw_rfkill_list);
+ /* Most ideapads with ELAN0634 touchpad don't use EC touchpad switch */
+ priv->has_touchpad_switch = !acpi_dev_present("ELAN0634", NULL, -1);
+
ret = ideapad_sysfs_init(priv);
if (ret)
return ret;
@@ -1006,6 +1015,10 @@ static int ideapad_acpi_add(struct platf
if (!priv->has_hw_rfkill_switch)
write_ec_cmd(priv->adev->handle, VPCCMD_W_RF, 1);
+ /* The same for Touchpad */
+ if (!priv->has_touchpad_switch)
+ write_ec_cmd(priv->adev->handle, VPCCMD_W_TOUCHPAD, 1);
+
for (i = 0; i < IDEAPAD_RFKILL_DEV_NUM; i++)
if (test_bit(ideapad_rfk_data[i].cfgbit, &priv->cfg))
ideapad_register_rfkill(priv, i);
[PATCH 5.4 02/86] platform/x86: i2c-multi-instantiate: Dont create platform device for INT3515 ACPI nodes
From: Heikki Krogerus
commit 9bba96275576da0cf78ede62aeb2fc975ed8a32d upstream.
There are several reports about the tps6598x causing
interrupt flood on boards with the INT3515 ACPI node, which
then causes instability. There appears to be several
problems with the interrupt. One problem is that the
I2CSerialBus resources do not always map to the Interrupt
resource with the same index, but that is not the only
problem. We have not been able to come up with a solution
for all the issues, and because of that disabling the device
for now.
The PD controller on these platforms is autonomous, and the
purpose for the driver is primarily to supply status to the
userspace, so this will not affect any functionality.
Reported-by: Moody Salem
Fixes: a3dd034a1707 ("ACPI / scan: Create platform device for INT3515 ACPI
nodes")
Cc: sta...@vger.kernel.org
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1883511
Signed-off-by: Heikki Krogerus
Link:
https://lore.kernel.org/r/20201223143644.33341-1-heikki.kroge...@linux.intel.com
Signed-off-by: Hans de Goede
Signed-off-by: Greg Kroah-Hartman
---
drivers/platform/x86/i2c-multi-instantiate.c | 31 ---
1 file changed, 23 insertions(+), 8 deletions(-)
--- a/drivers/platform/x86/i2c-multi-instantiate.c
+++ b/drivers/platform/x86/i2c-multi-instantiate.c
@@ -166,13 +166,29 @@ static const struct i2c_inst_data bsg215
{}
};
-static const struct i2c_inst_data int3515_data[] = {
- { "tps6598x", IRQ_RESOURCE_APIC, 0 },
- { "tps6598x", IRQ_RESOURCE_APIC, 1 },
- { "tps6598x", IRQ_RESOURCE_APIC, 2 },
- { "tps6598x", IRQ_RESOURCE_APIC, 3 },
- {}
-};
+/*
+ * Device with _HID INT3515 (TI PD controllers) has some unresolved interrupt
+ * issues. The most common problem seen is interrupt flood.
+ *
+ * There are at least two known causes. Firstly, on some boards, the
+ * I2CSerialBus resource index does not match the Interrupt resource, i.e. they
+ * are not one-to-one mapped like in the array below. Secondly, on some boards
+ * the IRQ line from the PD controller is not actually connected at all. But
the
+ * interrupt flood is also seen on some boards where those are not a problem,
so
+ * there are some other problems as well.
+ *
+ * Because of the issues with the interrupt, the device is disabled for now. If
+ * you wish to debug the issues, uncomment the below, and add an entry for the
+ * INT3515 device to the i2c_multi_instance_ids table.
+ *
+ * static const struct i2c_inst_data int3515_data[] = {
+ * { "tps6598x", IRQ_RESOURCE_APIC, 0 },
+ * { "tps6598x", IRQ_RESOURCE_APIC, 1 },
+ * { "tps6598x", IRQ_RESOURCE_APIC, 2 },
+ * { "tps6598x", IRQ_RESOURCE_APIC, 3 },
+ * { }
+ * };
+ */
/*
* Note new device-ids must also be added to i2c_multi_instantiate_ids in
@@ -181,7 +197,6 @@ static const struct i2c_inst_data int351
static const struct acpi_device_id i2c_multi_inst_acpi_ids[] = {
{ "BSG1160", (unsigned long)bsg1160_data },
{ "BSG2150", (unsigned long)bsg2150_data },
- { "INT3515", (unsigned long)int3515_data },
{ }
};
MODULE_DEVICE_TABLE(acpi, i2c_multi_inst_acpi_ids);
Re: [PATCH 0/5] Thermal zone configuration for Meson8/Meson8b/Meson8m2
On Mon, 21 Dec 2020 19:13:01 +0100, Martin Blumenstingl wrote: > This adds the thermal zone configuration on Meson8/Meson8b/Meson8m2 > SoCs. The thermal sensor reading is taken from SAR ADC. With > "generic-adc-thermal" it is then used to configure the thermal zone. > > CPU and GPU frequencies can both be managed. The vendor kernel also > manages the number of active GPU pixel processor cores. This is not > supported yet so we skip it. > > [...] Applied, thanks! [1/5] ARM: dts: meson: move iio-hwmon for the SoC temperature to meson.dtsi commit: e9ced25e41588a2ff95280b4d3dabf3a0865513b [2/5] ARM: dts: meson: add the ADC thermal sensor to meson.dtsi commit: c8559511107120403f7810428f50fc68fd77ed5a [3/5] ARM: dts: meson8: add the thermal-zones with cooling configuration commit: ecdb744b1f819949f783508331ff6ff8a6a45730 [4/5] ARM: dts: meson8b: add the thermal-zones with cooling configuration commit: 9073f694efd8733b0e7c97d3396d81161bd05582 [5/5] ARM: multi_v7_defconfig: Enable support for the ADC thermal sensor commit: 726731566a862fa375de44313f601e49c4d40377 Best regards, -- Kevin Hilman
Re: [PATCH v7 03/28] coresight: Introduce device access abstraction
On Sun, Jan 10, 2021 at 10:48:25PM +, Suzuki K Poulose wrote:
> We are about to introduce support for sysreg access to ETMv4.4+
> component. Since there are generic routines that access the
> registers (e.g, CS_LOCK/UNLOCK , claim/disclaim operations, timeout)
> and in order to preserve the logic of these operations at a
> single place we introduce an abstraction layer for the accesses
> to a given device.
>
> Cc: Mike Leach
> Reviewed-by: Mathieu Poirier
> Signed-off-by: Suzuki K Poulose
> ---
> Change since v6:
> - Fix code indentation in coresight.h (Mathieu Poirier)
> Change since v3
> - Dropped csa argument to read()/write().
> - Addressed comments on spacing and adding labels for the #if #else #endifs.
>(Mathieu)
> ---
> drivers/hwtracing/coresight/coresight-catu.c | 1 +
> drivers/hwtracing/coresight/coresight-core.c | 43
> .../hwtracing/coresight/coresight-cti-core.c | 1 +
> drivers/hwtracing/coresight/coresight-etb10.c | 1 +
> .../coresight/coresight-etm3x-core.c | 1 +
> .../coresight/coresight-etm4x-core.c | 1 +
> .../hwtracing/coresight/coresight-funnel.c| 1 +
> .../coresight/coresight-replicator.c | 1 +
> drivers/hwtracing/coresight/coresight-stm.c | 1 +
> .../hwtracing/coresight/coresight-tmc-core.c | 1 +
> drivers/hwtracing/coresight/coresight-tpiu.c | 1 +
> include/linux/coresight.h | 193 +-
> 12 files changed, 243 insertions(+), 3 deletions(-)
[...]
> +u32 coresight_relaxed_read32(struct coresight_device *csdev, u32 offset);
> +u32 coresight_read32(struct coresight_device *csdev, u32 offset);
> +void coresight_write32(struct coresight_device *csdev, u32 val, u32 offset);
> +void coresight_relaxed_write32(struct coresight_device *csdev,
> +u32 val,
> +u32 offset);
More stacking - I fixed it.
> +u64 coresight_relaxed_read64(struct coresight_device *csdev, u32 offset);
> +u64 coresight_read64(struct coresight_device *csdev, u32 offset);
> +void coresight_relaxed_write64(struct coresight_device *csdev,
> +u64 val, u32 offset);
> +void coresight_write64(struct coresight_device *csdev, u64 val, u32 offset);
> +
> +
> #else
> static inline struct coresight_device *
> coresight_register(struct coresight_desc *desc) { return NULL; }
> @@ -369,10 +512,54 @@ static inline bool
> coresight_loses_context_with_cpu(struct device *dev)
> {
> return false;
> }
> -#endif
> +
> +static inline u32 coresight_relaxed_read32(struct coresight_device *csdev,
> u32 offset)
> +{
> + WARN_ON_ONCE(1);
> + return 0;
> +}
> +
> +static inline u32 coresight_read32(struct coresight_device *csdev, u32
> offset)
> +{
> + WARN_ON_ONCE(1);
> + return 0;
> +}
> +
> +static inline void coresight_write32(struct coresight_device *csdev, u32
> val, u32 offset)
> +{
> +}
> +
> +static inline void coresight_relaxed_write32(struct coresight_device *csdev,
> + u32 val, u32 offset)
> +{
> +}
> +
> +static inline u64 coresight_relaxed_read64(struct coresight_device *csdev,
> +u32 offset)
> +{
> + WARN_ON_ONCE(1);
> + return 0;
> +}
> +
> +static inline u64 coresight_read64(struct coresight_device *csdev, u32
> offset)
> +{
> + WARN_ON_ONCE(1);
> + return 0;
> +}
> +
> +static inline void coresight_relaxed_write64(struct coresight_device *csdev,
> + u64 val, u32 offset)
> +{
> +}
> +
> +static inline void coresight_write64(struct coresight_device *csdev, u64
> val, u32 offset)
> +{
> +}
> +
> +#endif /* IS_ENABLED(CONFIG_CORESIGHT) */
>
> extern int coresight_get_cpu(struct device *dev);
>
> struct coresight_platform_data *coresight_get_platform_data(struct device
> *dev);
>
> -#endif
> +#endif /* _LINUX_COREISGHT_H */
> --
> 2.24.1
>
[PATCH 5.4 18/86] ASoC: Intel: haswell: Add missing pm_ops
From: Cezary Rojewski
[ Upstream commit bb224c3e3e41d940612d4cc9573289cdbd5cb8f5 ]
haswell machine board is missing pm_ops what prevents it from undergoing
suspend-resume procedure successfully. Assign default snd_soc_pm_ops so
this is no longer the case.
Signed-off-by: Cezary Rojewski
Link: https://lore.kernel.org/r/20201217105401.27865-1-cezary.rojew...@intel.com
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/intel/boards/haswell.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/intel/boards/haswell.c b/sound/soc/intel/boards/haswell.c
index 3dadf9bff796a..cf47fd9cd506b 100644
--- a/sound/soc/intel/boards/haswell.c
+++ b/sound/soc/intel/boards/haswell.c
@@ -206,6 +206,7 @@ static struct platform_driver haswell_audio = {
.probe = haswell_audio_probe,
.driver = {
.name = "haswell-audio",
+ .pm = &snd_soc_pm_ops,
},
};
--
2.27.0
[PATCH 5.4 00/86] 5.4.93-rc1 review
This is the start of the stable review cycle for the 5.4.93 release. There are 86 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed, 27 Jan 2021 18:31:44 +. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.93-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y and the diffstat can be found below. thanks, greg k-h - Pseudo-Shortlog of commits: Greg Kroah-Hartman Linux 5.4.93-rc1 Enke Chen tcp: fix TCP_USER_TIMEOUT with zero window Eric Dumazet tcp: do not mess with cloned skbs in tcp_add_backlog() Dan Carpenter net: dsa: b53: fix an off by one in checking "vlan->vid" Tariq Toukan net: Disable NETIF_F_HW_TLS_RX when RXCSUM is disabled Vladimir Oltean net: mscc: ocelot: allow offloading of bridge on top of LAG Matteo Croce ipv6: set multicast flag on the multicast route Eric Dumazet net_sched: reject silly cell_log in qdisc_get_rtab() Eric Dumazet net_sched: avoid shift-out-of-bounds in tcindex_set_parms() Matteo Croce ipv6: create multicast route with RTPROT_KERNEL Guillaume Nault udp: mask TOS bits in udp_v4_early_demux() Lecopzer Chen kasan: fix incorrect arguments passing in kasan_add_zero_shadow Lecopzer Chen kasan: fix unaligned address is unhandled in kasan_remove_zero_shadow Alexander Lobakin skbuff: back tiny skbs with kmalloc() in __netdev_alloc_skb() too Pan Bian lightnvm: fix memory leak when submit fails Geert Uytterhoeven sh_eth: Fix power down vs. is_opened flag ordering Rasmus Villemoes net: dsa: mv88e6xxx: also read STU state in mv88e6250_g1_vtu_getnext Necip Fazil Yildiran sh: dma: fix kconfig dependency for G2_DMA Guillaume Nault netfilter: rpfilter: mask ecn bits before fib lookup Yazen Ghannam x86/cpu/amd: Set __max_die_per_package on AMD Paul Cercueil pinctrl: ingenic: Fix JZ4760 support Rafael J. Wysocki driver core: Extend device_is_dependent() JC Kuo xhci: tegra: Delay for disabling LFPS detector Mathias Nyman xhci: make sure TRB is fully written before giving it to the controller Patrik Jakobsson usb: bdc: Make bdc pci driver depend on BROKEN Thinh Nguyen usb: udc: core: Use lock when write to soft_connect Ryan Chen usb: gadget: aspeed: fix stop dma register setting. Longfang Liu USB: ehci: fix an interrupt calltrace error Eugene Korenevsky ehci: fix EHCI host controller initialization sequence Pali Rohár serial: mvebu-uart: fix tx lost characters at power off Wang Hui stm class: Fix module init return on allocation failure Alexander Shishkin intel_th: pci: Add Alder Lake-P support Andy Lutomirski x86/mmx: Use KFPU_387 for MMX string operations Mathias Kresin irqchip/mips-cpu: Set IPI domain parent chip Ronnie Sahlberg cifs: do not fail __smb_send_rqst if non-fatal signals are pending Lars-Peter Clausen iio: ad5504: Fix setting power-down state Vincent Mailhol can: peak_usb: fix use after free bugs Vincent Mailhol can: vxcan: vxcan_xmit: fix use after free bug Vincent Mailhol can: dev: can_restart: fix use after free bug Hangbin Liu selftests: net: fib_tests: remove duplicate log test Hans de Goede platform/x86: intel-vbtn: Drop HP Stream x360 Convertible PC 11 from allow-list Wolfram Sang i2c: octeon: check correct size of maximum RECV_LEN packet Ariel Marcovitch powerpc: Fix alignment bug within the init sections Arnd Bergmann scsi: megaraid_sas: Fix MEGASAS_IOC_FIRMWARE regression Billy Tsai pinctrl: aspeed: g6: Fix PWMG0 pinctrl setting Youling Tang powerpc: Use the common INIT_DATA_SECTION macro in vmlinux.lds.S Ben Skeggs drm/nouveau/kms/nv50-: fix case where notifier buffer is at offset 0 Ben Skeggs drm/nouveau/mmu: fix vram heap sizing Ben Skeggs drm/nouveau/i2c/gm200: increase width of aux semaphore owner fields Ben Skeggs drm/nouveau/privring: ack interrupts the same way as RM Ben Skeggs drm/nouveau/bios: fix issue shadowing expansion ROMs Wayne Lin drm/amd/display: Fix to be able to stop crc calculation Victor Zhao drm/amdgpu/psp: fix psp gfx ctrl cmds Sagar Shrikant Kadam riscv: defconfig: enable gpio support for HiFive Unleashed Sagar Shrikant Kadam dts: phy: add GPIO number and active state used for phy reset Sagar Shrikant Kadam dts: phy: fix missing mdio device and probe failure of vsc8541-01 device David Woodhouse x86/xen: Add xen_no_vector_callback option to test PCI INTX delivery David Woodhouse xen: Fix event channel callback via INTX/GSI Arnd Bergmann arm64:
[PATCH 5.4 01/86] i2c: bpmp-tegra: Ignore unknown I2C_M flags
From: Mikko Perttunen commit bc1c2048abbe3c3074b4de91d213595c57741a6b upstream. In order to not to start returning errors when new I2C_M flags are added, change behavior to just ignore all flags that we don't know about. This includes the I2C_M_DMA_SAFE flag that already exists but causes -EINVAL to be returned for valid transactions. Cc: sta...@vger.kernel.org # v4.19+ Signed-off-by: Mikko Perttunen Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman --- drivers/i2c/busses/i2c-tegra-bpmp.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/i2c/busses/i2c-tegra-bpmp.c +++ b/drivers/i2c/busses/i2c-tegra-bpmp.c @@ -80,7 +80,7 @@ static int tegra_bpmp_xlate_flags(u16 fl flags &= ~I2C_M_RECV_LEN; } - return (flags != 0) ? -EINVAL : 0; + return 0; } /**
[PATCH 5.4 15/86] drm/atomic: put state on error path
From: Pan Bian
commit 43b67309b6b2a3c08396cc9b3f83f21aa529d273 upstream.
Put the state before returning error code.
Fixes: 44596b8c4750 ("drm/atomic: Unify conflicting encoder handling.")
Signed-off-by: Pan Bian
Cc: sta...@vger.kernel.org
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/20210119121127.84127-1-bianpan2...@163.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_atomic_helper.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2948,7 +2948,7 @@ int drm_atomic_helper_set_config(struct
ret = handle_conflicting_encoders(state, true);
if (ret)
- return ret;
+ goto fail;
ret = drm_atomic_commit(state);
[PATCH 5.4 06/86] ACPI: scan: Make acpi_bus_get_device() clear return pointer on error
From: Hans de Goede
commit 78a18fec5258c8df9435399a1ea022d73d3eceb9 upstream.
Set the acpi_device pointer which acpi_bus_get_device() returns-by-
reference to NULL on errors.
We've recently had 2 cases where callers of acpi_bus_get_device()
did not properly error check the return value, so set the returned-
by-reference acpi_device pointer to NULL, because at least some
callers of acpi_bus_get_device() expect that to be done on errors.
[ rjw: This issue was exposed by commit 71da201f38df ("ACPI: scan:
Defer enumeration of devices with _DEP lists") which caused it to
be much more likely to occur on some systems, but the real defect
had been introduced by an earlier commit. ]
Fixes: 40e7fcb19293 ("ACPI: Add _DEP support to fix battery issue on Asus
T100TA")
Fixes: bcfcd409d4db ("usb: split code locating ACPI companion into port and
device")
Reported-by: Pierre-Louis Bossart
Tested-by: Pierre-Louis Bossart
Diagnosed-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
Cc: All applicable
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
---
drivers/acpi/scan.c |2 ++
1 file changed, 2 insertions(+)
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -587,6 +587,8 @@ static int acpi_get_device_data(acpi_han
if (!device)
return -EINVAL;
+ *device = NULL;
+
status = acpi_get_data_full(handle, acpi_scan_drop_device,
(void **)device, callback);
if (ACPI_FAILURE(status) || !*device) {
[PATCH 5.4 16/86] drm/syncobj: Fix use-after-free
From: Daniel Vetter
commit a37eef63bc9e16e06361b539e528058146af80ab upstream.
While reviewing Christian's annotation patch I noticed that we have a
user-after-free for the WAIT_FOR_SUBMIT case: We drop the syncobj
reference before we've completed the waiting.
Of course usually there's nothing bad happening here since userspace
keeps the reference, but we can't rely on userspace to play nice here!
Signed-off-by: Daniel Vetter
Fixes: bc9c80fe01a2 ("drm/syncobj: use the timeline point in
drm_syncobj_find_fence v4")
Reviewed-by: Christian König
Cc: Christian König
Cc: Lionel Landwerlin
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Cc: # v5.2+
Link:
https://patchwork.freedesktop.org/patch/msgid/20210119130318.615145-1-daniel.vet...@ffwll.ch
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_syncobj.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -326,19 +326,18 @@ int drm_syncobj_find_fence(struct drm_fi
return -ENOENT;
*fence = drm_syncobj_fence_get(syncobj);
- drm_syncobj_put(syncobj);
if (*fence) {
ret = dma_fence_chain_find_seqno(fence, point);
if (!ret)
- return 0;
+ goto out;
dma_fence_put(*fence);
} else {
ret = -EINVAL;
}
if (!(flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT))
- return ret;
+ goto out;
memset(&wait, 0, sizeof(wait));
wait.task = current;
@@ -370,6 +369,9 @@ int drm_syncobj_find_fence(struct drm_fi
if (wait.node.next)
drm_syncobj_remove_wait(syncobj, &wait);
+out:
+ drm_syncobj_put(syncobj);
+
return ret;
}
EXPORT_SYMBOL(drm_syncobj_find_fence);
[PATCH 5.4 26/86] HID: logitech-dj: add the G602 receiver
From: Filipe Laíns
[ Upstream commit e400071a805d6229223a98899e9da8c6233704a1 ]
Tested. The device gets correctly exported to userspace and I can see
mouse and keyboard events.
Signed-off-by: Filipe Laíns
Signed-off-by: Jiri Kosina
Signed-off-by: Sasha Levin
---
drivers/hid/hid-logitech-dj.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
index 54d811fdcdb44..e5550a5bf49d0 100644
--- a/drivers/hid/hid-logitech-dj.c
+++ b/drivers/hid/hid-logitech-dj.c
@@ -1862,6 +1862,10 @@ static const struct hid_device_id logi_dj_receivers[] = {
HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
0xc531),
.driver_data = recvr_type_gaming_hidpp},
+ { /* Logitech G602 receiver (0xc537) */
+ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
+ 0xc537),
+.driver_data = recvr_type_gaming_hidpp},
{ /* Logitech lightspeed receiver (0xc539) */
HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1),
--
2.27.0
Re: [PATCH] mm/filemap: Adding missing mem_cgroup_uncharge() to __add_to_page_cache_locked()
On Mon, Jan 25, 2021 at 05:41:18PM +0100, Michal Hocko wrote:
> On Mon 25-01-21 16:25:06, Matthew Wilcox wrote:
> > On Mon, Jan 25, 2021 at 05:03:28PM +0100, Michal Hocko wrote:
> > > On Mon 25-01-21 10:57:54, Waiman Long wrote:
> > > > On 1/25/21 4:28 AM, Michal Hocko wrote:
> > > > > On Sun 24-01-21 23:24:41, Waiman Long wrote:
> > > > > > The commit 3fea5a499d57 ("mm: memcontrol: convert page
> > > > > > cache to a new mem_cgroup_charge() API") introduced a bug in
> > > > > > __add_to_page_cache_locked() causing the following splat:
> > > > > >
> > > > > > [ 1570.068330] page dumped because:
> > > > > > VM_BUG_ON_PAGE(page_memcg(page))
> > > > > > [ 1570.068333] pages's memcg:8889a4116000
> > > > > > [ 1570.068343] [ cut here ]
> > > > > > [ 1570.068346] kernel BUG at mm/memcontrol.c:2924!
> > > > > > [ 1570.068355] invalid opcode: [#1] SMP KASAN PTI
> > > > > > [ 1570.068359] CPU: 35 PID: 12345 Comm: cat Tainted: G S W I
> > > > > > 5.11.0-rc4-debug+ #1
> > > > > > [ 1570.068363] Hardware name: HP HP Z8 G4 Workstation/81C7, BIOS
> > > > > > P60 v01.25 12/06/2017
> > > > > > [ 1570.068365] RIP: 0010:commit_charge+0xf4/0x130
> > > > > > :
> > > > > > [ 1570.068375] RSP: 0018:8881b38d70e8 EFLAGS: 00010286
> > > > > > [ 1570.068379] RAX: RBX: ea00260ddd00 RCX:
> > > > > > 0027
> > > > > > [ 1570.068382] RDX: RSI: 0004 RDI:
> > > > > > 88907ebe05a8
> > > > > > [ 1570.068384] RBP: ea00260ddd00 R08: ed120fd7c0b6 R09:
> > > > > > ed120fd7c0b6
> > > > > > [ 1570.068386] R10: 88907ebe05ab R11: ed120fd7c0b5 R12:
> > > > > > ea00260ddd38
> > > > > > [ 1570.068389] R13: 8889a4116000 R14: 8889a4116000 R15:
> > > > > > 0001
> > > > > > [ 1570.068391] FS: 7ff039638680()
> > > > > > GS:88907ea0() knlGS:
> > > > > > [ 1570.068394] CS: 0010 DS: ES: CR0: 80050033
> > > > > > [ 1570.068396] CR2: 7f36f354cc20 CR3: 0008a0126006 CR4:
> > > > > > 007706e0
> > > > > > [ 1570.068398] DR0: DR1: DR2:
> > > > > >
> > > > > > [ 1570.068400] DR3: DR6: fffe0ff0 DR7:
> > > > > > 0400
> > > > > > [ 1570.068402] PKRU: 5554
> > > > > > [ 1570.068404] Call Trace:
> > > > > > [ 1570.068407] mem_cgroup_charge+0x175/0x770
> > > > > > [ 1570.068413] __add_to_page_cache_locked+0x712/0xad0
> > > > > > [ 1570.068439] add_to_page_cache_lru+0xc5/0x1f0
> > > > > > [ 1570.068461] cachefiles_read_or_alloc_pages+0x895/0x2e10
> > > > > > [cachefiles]
> > > > > > [ 1570.068524] __fscache_read_or_alloc_pages+0x6c0/0xa00
> > > > > > [fscache]
> > > > > > [ 1570.068540] __nfs_readpages_from_fscache+0x16d/0x630 [nfs]
> > > > > > [ 1570.068585] nfs_readpages+0x24e/0x540 [nfs]
> > > > > > [ 1570.068693] read_pages+0x5b1/0xc40
> > > > > > [ 1570.068711] page_cache_ra_unbounded+0x460/0x750
> > > > > > [ 1570.068729] generic_file_buffered_read_get_pages+0x290/0x1710
> > > > > > [ 1570.068756] generic_file_buffered_read+0x2a9/0xc30
> > > > > > [ 1570.068832] nfs_file_read+0x13f/0x230 [nfs]
> > > > > > [ 1570.068872] new_sync_read+0x3af/0x610
> > > > > > [ 1570.068901] vfs_read+0x339/0x4b0
> > > > > > [ 1570.068909] ksys_read+0xf1/0x1c0
> > > > > > [ 1570.068920] do_syscall_64+0x33/0x40
> > > > > > [ 1570.068926] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > > > > > [ 1570.068930] RIP: 0033:0x7ff039135595
> > > > > >
> > > > > > Before that commit, there was a try_charge() and commit_charge()
> > > > > > in __add_to_page_cache_locked(). These 2 separated charge functions
> > > > > > were replaced by a single mem_cgroup_charge(). However, it forgot
> > > > > > to add a matching mem_cgroup_uncharge() when the xarray insertion
> > > > > > failed with the page released back to the pool. Fix this by adding a
> > > > > > mem_cgroup_uncharge() call when insertion error happens.
> > > > > >
> > > > > > Fixes: 3fea5a499d57 ("mm: memcontrol: convert page cache to a new
> > > > > > mem_cgroup_charge() API")
> > > > > > Signed-off-by: Waiman Long
> > > > > OK, this is indeed a subtle bug. The patch aimed at simplifying the
> > > > > charge lifetime so that users do not really have to think about when
> > > > > to
> > > > > uncharge as that happens when the page is freed. fscache somehow
> > > > > breaks
> > > > > that assumption because it doesn't free up pages but it keeps some of
> > > > > them in the cache.
> > > > >
> > > > > I have tried to wrap my head around the cached object life time in
> > > > > fscache but failed and got lost in the maze. Is this the only instance
> > > > > of the problem? Would it make more sense to explicitly handle charges
> > > > > in
> > > > > the fscache code or there are other potential users to fall into th
FOR THE LESS PRIVILEDGE
Dear Friend. My name is Mrs.Virginia Dumitru a merchant in Romania. I have been diagnosed with Esophageal cancer. I have a huge cash deposit of TWELVE MILLION DOLLARS $12,000,000, That I have with a finance/Security Company abroad. I will want you to help me collect this deposit and dispatched it to charity organizations. I have set aside 25% for you and for your time if you want to help me to collect this Funds and also invest this money. PLEASE I WILL ADVICE YOU TO CONTACT MY ATTORNEY IN NETHERLANDS IMMEDIATELY. Name: Barrister Peter Kenin Reply email address: peterkeni...@gmail.com Mrs. Virginia Dumitru
[PATCH 5.4 20/86] dm integrity: select CRYPTO_SKCIPHER
From: Anthony Iliopoulos [ Upstream commit f7b347acb5f6c29d9229bb64893d8b6a2c7949fb ] The integrity target relies on skcipher for encryption/decryption, but certain kernel configurations may not enable CRYPTO_SKCIPHER, leading to compilation errors due to unresolved symbols. Explicitly select CRYPTO_SKCIPHER for DM_INTEGRITY, since it is unconditionally dependent on it. Signed-off-by: Anthony Iliopoulos Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin --- drivers/md/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig index aa98953f4462e..7dd6e98257c72 100644 --- a/drivers/md/Kconfig +++ b/drivers/md/Kconfig @@ -565,6 +565,7 @@ config DM_INTEGRITY select BLK_DEV_INTEGRITY select DM_BUFIO select CRYPTO + select CRYPTO_SKCIPHER select ASYNC_XOR ---help--- This device-mapper target emulates a block device that has -- 2.27.0
[PATCH 5.4 23/86] scsi: sd: Suppress spurious errors when WRITE SAME is being disabled
From: Ewan D. Milne
[ Upstream commit e5cc9002caafacbaa8dab878d17a313192c3b03b ]
The block layer code will split a large zeroout request into multiple bios
and if WRITE SAME is disabled because the storage device reports that it
does not support it (or support the length used), we can get an error
message from the block layer despite the setting of RQF_QUIET on the first
request. This is because more than one request may have already been
submitted.
Fix this by setting RQF_QUIET when BLK_STS_TARGET is returned to fail the
request early, we don't need to log a message because we did not actually
submit the command to the device, and the block layer code will handle the
error by submitting individual write bios.
Link: https://lore.kernel.org/r/20201207221021.28243-1-emi...@redhat.com
Reviewed-by: Christoph Hellwig
Signed-off-by: Ewan D. Milne
Signed-off-by: Martin K. Petersen
Signed-off-by: Sasha Levin
---
drivers/scsi/sd.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 6a2f8bacfacea..f55249766d224 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -934,8 +934,10 @@ static blk_status_t sd_setup_write_zeroes_cmnd(struct
scsi_cmnd *cmd)
}
}
- if (sdp->no_write_same)
+ if (sdp->no_write_same) {
+ rq->rq_flags |= RQF_QUIET;
return BLK_STS_TARGET;
+ }
if (sdkp->ws16 || lba > 0x || nr_blocks > 0x)
return sd_setup_write_same16_cmnd(cmd, false);
--
2.27.0
[PATCH 5.4 34/86] riscv: defconfig: enable gpio support for HiFive Unleashed
From: Sagar Shrikant Kadam [ Upstream commit 0983834a83931606a647c275e5d4165ce4e7b49f ] Ethernet phy VSC8541-01 on HiFive Unleashed has its reset line connected to a gpio, so enable GPIO driver's required to reset the phy. Signed-off-by: Sagar Shrikant Kadam Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin --- arch/riscv/configs/defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig index 420a0dbef3866..3c656fe97e583 100644 --- a/arch/riscv/configs/defconfig +++ b/arch/riscv/configs/defconfig @@ -62,6 +62,8 @@ CONFIG_HW_RANDOM=y CONFIG_HW_RANDOM_VIRTIO=y CONFIG_SPI=y CONFIG_SPI_SIFIVE=y +CONFIG_GPIOLIB=y +CONFIG_GPIO_SIFIVE=y # CONFIG_PTP_1588_CLOCK is not set CONFIG_DRM=y CONFIG_DRM_RADEON=y -- 2.27.0
[PATCH 5.4 08/86] btrfs: fix lockdep splat in btrfs_recover_relocation
From: Josef Bacik
commit fb286100974e7239af243bc2255a52f29442f9c8 upstream.
While testing the error paths of relocation I hit the following lockdep
splat:
==
WARNING: possible circular locking dependency detected
5.10.0-rc6+ #217 Not tainted
--
mount/779 is trying to acquire lock:
a0e676945418 (&fs_info->balance_mutex){+.+.}-{3:3}, at:
btrfs_recover_balance+0x2f0/0x340
but task is already holding lock:
a0e60ee31da8 (btrfs-root-00){}-{3:3}, at:
__btrfs_tree_read_lock+0x27/0x100
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (btrfs-root-00){}-{3:3}:
down_read_nested+0x43/0x130
__btrfs_tree_read_lock+0x27/0x100
btrfs_read_lock_root_node+0x31/0x40
btrfs_search_slot+0x462/0x8f0
btrfs_update_root+0x55/0x2b0
btrfs_drop_snapshot+0x398/0x750
clean_dirty_subvols+0xdf/0x120
btrfs_recover_relocation+0x534/0x5a0
btrfs_start_pre_rw_mount+0xcb/0x170
open_ctree+0x151f/0x1726
btrfs_mount_root.cold+0x12/0xea
legacy_get_tree+0x30/0x50
vfs_get_tree+0x28/0xc0
vfs_kern_mount.part.0+0x71/0xb0
btrfs_mount+0x10d/0x380
legacy_get_tree+0x30/0x50
vfs_get_tree+0x28/0xc0
path_mount+0x433/0xc10
__x64_sys_mount+0xe3/0x120
do_syscall_64+0x33/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xa9
-> #1 (sb_internal#2){.+.+}-{0:0}:
start_transaction+0x444/0x700
insert_balance_item.isra.0+0x37/0x320
btrfs_balance+0x354/0xf40
btrfs_ioctl_balance+0x2cf/0x380
__x64_sys_ioctl+0x83/0xb0
do_syscall_64+0x33/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xa9
-> #0 (&fs_info->balance_mutex){+.+.}-{3:3}:
__lock_acquire+0x1120/0x1e10
lock_acquire+0x116/0x370
__mutex_lock+0x7e/0x7b0
btrfs_recover_balance+0x2f0/0x340
open_ctree+0x1095/0x1726
btrfs_mount_root.cold+0x12/0xea
legacy_get_tree+0x30/0x50
vfs_get_tree+0x28/0xc0
vfs_kern_mount.part.0+0x71/0xb0
btrfs_mount+0x10d/0x380
legacy_get_tree+0x30/0x50
vfs_get_tree+0x28/0xc0
path_mount+0x433/0xc10
__x64_sys_mount+0xe3/0x120
do_syscall_64+0x33/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xa9
other info that might help us debug this:
Chain exists of:
&fs_info->balance_mutex --> sb_internal#2 --> btrfs-root-00
Possible unsafe locking scenario:
CPU0CPU1
lock(btrfs-root-00);
lock(sb_internal#2);
lock(btrfs-root-00);
lock(&fs_info->balance_mutex);
*** DEADLOCK ***
2 locks held by mount/779:
#0: a0e60dc040e0 (&type->s_umount_key#47/1){+.+.}-{3:3}, at:
alloc_super+0xb5/0x380
#1: a0e60ee31da8 (btrfs-root-00){}-{3:3}, at:
__btrfs_tree_read_lock+0x27/0x100
stack backtrace:
CPU: 0 PID: 779 Comm: mount Not tainted 5.10.0-rc6+ #217
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32
04/01/2014
Call Trace:
dump_stack+0x8b/0xb0
check_noncircular+0xcf/0xf0
? trace_call_bpf+0x139/0x260
__lock_acquire+0x1120/0x1e10
lock_acquire+0x116/0x370
? btrfs_recover_balance+0x2f0/0x340
__mutex_lock+0x7e/0x7b0
? btrfs_recover_balance+0x2f0/0x340
? btrfs_recover_balance+0x2f0/0x340
? rcu_read_lock_sched_held+0x3f/0x80
? kmem_cache_alloc_trace+0x2c4/0x2f0
? btrfs_get_64+0x5e/0x100
btrfs_recover_balance+0x2f0/0x340
open_ctree+0x1095/0x1726
btrfs_mount_root.cold+0x12/0xea
? rcu_read_lock_sched_held+0x3f/0x80
legacy_get_tree+0x30/0x50
vfs_get_tree+0x28/0xc0
vfs_kern_mount.part.0+0x71/0xb0
btrfs_mount+0x10d/0x380
? __kmalloc_track_caller+0x2f2/0x320
legacy_get_tree+0x30/0x50
vfs_get_tree+0x28/0xc0
? capable+0x3a/0x60
path_mount+0x433/0xc10
__x64_sys_mount+0xe3/0x120
do_syscall_64+0x33/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xa9
This is straightforward to fix, simply release the path before we setup
the balance_ctl.
CC: sta...@vger.kernel.org # 4.4+
Reviewed-by: Qu Wenruo
Reviewed-by: Johannes Thumshirn
Signed-off-by: Josef Bacik
Reviewed-by: David Sterba
Signed-off-by: David Sterba
Signed-off-by: Greg Kroah-Hartman
---
fs/btrfs/volumes.c |2 ++
1 file changed, 2 insertions(+)
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -4409,6 +4409,8 @@ int btrfs_recover_balance(struct btrfs_f
btrfs_warn(fs_info,
"balance: cannot set exclusive op status, resume manually");
+ btrfs_release_path(path);
+
mutex_lock(&fs_info->balance_mutex);
BUG_ON(fs_info->balance_ctl);
spin_lock(&fs_info->balance_lock);
[PATCH 5.4 32/86] dts: phy: fix missing mdio device and probe failure of vsc8541-01 device
From: Sagar Shrikant Kadam
[ Upstream commit be969b7cfbcfa8a835a528f1dc467f0975c6d883 ]
HiFive unleashed A00 board has VSC8541-01 ethernet phy, this device is
identified as a Revision B device as described in device identification
registers. In order to use this phy in the unmanaged mode, it requires
a specific reset sequence of logical 0-1-0-1 transition on the NRESET pin
as documented here [1].
Currently, the bootloader (fsbl or u-boot-spl) takes care of the phy reset.
If due to some reason the phy device hasn't received the reset by the prior
stages before the linux macb driver comes into the picture, the MACB mii
bus gets probed but the mdio scan fails and is not even able to read the
phy ID registers. It gives an error message:
"libphy: MACB_mii_bus: probed
mdio_bus 1009.ethernet-: MDIO device at address 0 is missing."
Thus adding the device OUI (Organizationally Unique Identifier) to the phy
device node helps to probe the phy device.
[1]: VSC8541-01 datasheet:
https://www.mouser.com/ds/2/523/Microsemi_VSC8541-01_Datasheet_10496_V40-1148034.pdf
Signed-off-by: Sagar Shrikant Kadam
Signed-off-by: Palmer Dabbelt
Signed-off-by: Sasha Levin
---
arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts
b/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts
index 88cfcb96bf233..cc04e66752aac 100644
--- a/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts
+++ b/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts
@@ -83,6 +83,7 @@
phy-mode = "gmii";
phy-handle = <&phy0>;
phy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-id0007.0771";
reg = <0>;
};
};
--
2.27.0
[PATCH 5.4 35/86] drm/amdgpu/psp: fix psp gfx ctrl cmds
From: Victor Zhao [ Upstream commit f14a5c34d143f6627f0be70c0de1d962f3a6ff1c ] psp GFX_CTRL_CMD_ID_CONSUME_CMD different for windows and linux, according to psp, linux cmds are not correct. v2: only correct GFX_CTRL_CMD_ID_CONSUME_CMD. Signed-off-by: Victor Zhao Reviewed-by: Emily.Deng Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/psp_gfx_if.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/psp_gfx_if.h b/drivers/gpu/drm/amd/amdgpu/psp_gfx_if.h index 74a9fe8e0cfb9..8c54f0be51bab 100644 --- a/drivers/gpu/drm/amd/amdgpu/psp_gfx_if.h +++ b/drivers/gpu/drm/amd/amdgpu/psp_gfx_if.h @@ -44,7 +44,7 @@ enum psp_gfx_crtl_cmd_id GFX_CTRL_CMD_ID_DISABLE_INT = 0x0006, /* disable PSP-to-Gfx interrupt */ GFX_CTRL_CMD_ID_MODE1_RST = 0x0007, /* trigger the Mode 1 reset */ GFX_CTRL_CMD_ID_GBR_IH_SET = 0x0008, /* set Gbr IH_RB_CNTL registers */ -GFX_CTRL_CMD_ID_CONSUME_CMD = 0x000A, /* send interrupt to psp for updating write pointer of vf */ +GFX_CTRL_CMD_ID_CONSUME_CMD = 0x0009, /* send interrupt to psp for updating write pointer of vf */ GFX_CTRL_CMD_ID_DESTROY_GPCOM_RING = 0x000C, /* destroy GPCOM ring */ GFX_CTRL_CMD_ID_MAX = 0x000F, /* max command ID */ -- 2.27.0
[PATCH 5.4 40/86] drm/nouveau/mmu: fix vram heap sizing
From: Ben Skeggs
[ Upstream commit add42781ad76c5ae65127bf13852a4c6b2f08849 ]
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c
index ee11ccaf0563c..cb51e248cb41b 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c
@@ -316,9 +316,9 @@ nvkm_mmu_vram(struct nvkm_mmu *mmu)
{
struct nvkm_device *device = mmu->subdev.device;
struct nvkm_mm *mm = &device->fb->ram->vram;
- const u32 sizeN = nvkm_mm_heap_size(mm, NVKM_RAM_MM_NORMAL);
- const u32 sizeU = nvkm_mm_heap_size(mm, NVKM_RAM_MM_NOMAP);
- const u32 sizeM = nvkm_mm_heap_size(mm, NVKM_RAM_MM_MIXED);
+ const u64 sizeN = nvkm_mm_heap_size(mm, NVKM_RAM_MM_NORMAL);
+ const u64 sizeU = nvkm_mm_heap_size(mm, NVKM_RAM_MM_NOMAP);
+ const u64 sizeM = nvkm_mm_heap_size(mm, NVKM_RAM_MM_MIXED);
u8 type = NVKM_MEM_KIND * !!mmu->func->kind;
u8 heap = NVKM_MEM_VRAM;
int heapM, heapN, heapU;
--
2.27.0
[PATCH 5.4 12/86] mmc: sdhci-xenon: fix 1.8v regulator stabilization
From: Alex Leibovich
commit 1a3ed0dc3594d99ff341ec63865a40519ea24b8d upstream.
Automatic Clock Gating is a feature used for the power consumption
optimisation. It turned out that during early init phase it may prevent the
stable voltage switch to 1.8V - due to that on some platforms an endless
printout in dmesg can be observed: "mmc1: 1.8V regulator output did not
became stable" Fix the problem by disabling the ACG at very beginning of
the sdhci_init and let that be enabled later.
Fixes: 3a3748dba881 ("mmc: sdhci-xenon: Add Marvell Xenon SDHC core
functionality")
Signed-off-by: Alex Leibovich
Signed-off-by: Marcin Wojtas
Cc: sta...@vger.kernel.org
Acked-by: Adrian Hunter
Link: https://lore.kernel.org/r/20201211141656.24915-1...@semihalf.com
Signed-off-by: Ulf Hansson
Signed-off-by: Greg Kroah-Hartman
---
drivers/mmc/host/sdhci-xenon.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/drivers/mmc/host/sdhci-xenon.c
+++ b/drivers/mmc/host/sdhci-xenon.c
@@ -167,7 +167,12 @@ static void xenon_reset_exit(struct sdhc
/* Disable tuning request and auto-retuning again */
xenon_retune_setup(host);
- xenon_set_acg(host, true);
+ /*
+* The ACG should be turned off at the early init time, in order
+* to solve a possible issues with the 1.8V regulator stabilization.
+* The feature is enabled in later stage.
+*/
+ xenon_set_acg(host, false);
xenon_set_sdclk_off_idle(host, sdhc_id, false);
[PATCH 5.4 13/86] dm: avoid filesystem lookup in dm_get_dev_t()
From: Hannes Reinecke
commit 809b1e4945774c9ec5619a8f4e2189b7b3833c0c upstream.
This reverts commit
644bda6f3460 ("dm table: fall back to getting device using name_to_dev_t()")
dm_get_dev_t() is just used to convert an arbitrary 'path' string
into a dev_t. It doesn't presume that the device is present; that
check will be done later, as the only caller is dm_get_device(),
which does a dm_get_table_device() later on, which will properly
open the device.
So if the path string already _is_ in major:minor representation
we can convert it directly, avoiding a recursion into the filesystem
to lookup the block device.
This avoids a hang in multipath_message() when the filesystem is
inaccessible.
Fixes: 644bda6f3460 ("dm table: fall back to getting device using
name_to_dev_t()")
Cc: sta...@vger.kernel.org
Signed-off-by: Hannes Reinecke
Signed-off-by: Martin Wilck
Reviewed-by: Christoph Hellwig
Signed-off-by: Mike Snitzer
Signed-off-by: Greg Kroah-Hartman
---
drivers/md/dm-table.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
--- a/drivers/md/dm-table.c
+++ b/drivers/md/dm-table.c
@@ -428,14 +428,23 @@ int dm_get_device(struct dm_target *ti,
{
int r;
dev_t dev;
+ unsigned int major, minor;
+ char dummy;
struct dm_dev_internal *dd;
struct dm_table *t = ti->table;
BUG_ON(!t);
- dev = dm_get_dev_t(path);
- if (!dev)
- return -ENODEV;
+ if (sscanf(path, "%u:%u%c", &major, &minor, &dummy) == 2) {
+ /* Extract the major/minor numbers */
+ dev = MKDEV(major, minor);
+ if (MAJOR(dev) != major || MINOR(dev) != minor)
+ return -EOVERFLOW;
+ } else {
+ dev = dm_get_dev_t(path);
+ if (!dev)
+ return -ENODEV;
+ }
dd = find_device(&t->devices, dev);
if (!dd) {
[PATCH 5.4 58/86] serial: mvebu-uart: fix tx lost characters at power off
From: Pali Rohár
commit 54ca955b5a4024e2ce0f206b03adb7109bc4da26 upstream.
Commit c685af1108d7 ("serial: mvebu-uart: fix tx lost characters") fixed tx
lost characters at low baud rates but started causing tx lost characters
when kernel is going to power off or reboot.
TX_EMP tells us when transmit queue is empty therefore all characters were
transmitted. TX_RDY tells us when CPU can send a new character.
Therefore we need to use different check prior transmitting new character
and different check after all characters were sent.
This patch splits polling code into two functions: wait_for_xmitr() which
waits for TX_RDY and wait_for_xmite() which waits for TX_EMP.
When rebooting A3720 platform without this patch on UART is print only:
[ 42.699�
And with this patch on UART is full output:
[ 39.530216] reboot: Restarting system
Fixes: c685af1108d7 ("serial: mvebu-uart: fix tx lost characters")
Signed-off-by: Pali Rohár
Cc: stable
Link: https://lore.kernel.org/r/20201223191931.18343-1-p...@kernel.org
Signed-off-by: Greg Kroah-Hartman
---
drivers/tty/serial/mvebu-uart.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
--- a/drivers/tty/serial/mvebu-uart.c
+++ b/drivers/tty/serial/mvebu-uart.c
@@ -648,6 +648,14 @@ static void wait_for_xmitr(struct uart_p
(val & STAT_TX_RDY(port)), 1, 1);
}
+static void wait_for_xmite(struct uart_port *port)
+{
+ u32 val;
+
+ readl_poll_timeout_atomic(port->membase + UART_STAT, val,
+ (val & STAT_TX_EMP), 1, 1);
+}
+
static void mvebu_uart_console_putchar(struct uart_port *port, int ch)
{
wait_for_xmitr(port);
@@ -675,7 +683,7 @@ static void mvebu_uart_console_write(str
uart_console_write(port, s, count, mvebu_uart_console_putchar);
- wait_for_xmitr(port);
+ wait_for_xmite(port);
if (ier)
writel(ier, port->membase + UART_CTRL(port));
[PATCH 5.4 50/86] can: vxcan: vxcan_xmit: fix use after free bug
From: Vincent Mailhol
[ Upstream commit 75854cad5d80976f6ea0f0431f8cedd3bcc475cb ]
After calling netif_rx_ni(skb), dereferencing skb is unsafe.
Especially, the canfd_frame cfd which aliases skb memory is accessed
after the netif_rx_ni().
Fixes: a8f820a380a2 ("can: add Virtual CAN Tunnel driver (vxcan)")
Link:
https://lore.kernel.org/r/20210120114137.200019-3-mailhol.vinc...@wanadoo.fr
Signed-off-by: Vincent Mailhol
Signed-off-by: Marc Kleine-Budde
Signed-off-by: Sasha Levin
---
drivers/net/can/vxcan.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/vxcan.c b/drivers/net/can/vxcan.c
index d6ba9426be4de..b1baa4ac1d537 100644
--- a/drivers/net/can/vxcan.c
+++ b/drivers/net/can/vxcan.c
@@ -39,6 +39,7 @@ static netdev_tx_t vxcan_xmit(struct sk_buff *skb, struct
net_device *dev)
struct net_device *peer;
struct canfd_frame *cfd = (struct canfd_frame *)skb->data;
struct net_device_stats *peerstats, *srcstats = &dev->stats;
+ u8 len;
if (can_dropped_invalid_skb(dev, skb))
return NETDEV_TX_OK;
@@ -61,12 +62,13 @@ static netdev_tx_t vxcan_xmit(struct sk_buff *skb, struct
net_device *dev)
skb->dev= peer;
skb->ip_summed = CHECKSUM_UNNECESSARY;
+ len = cfd->len;
if (netif_rx_ni(skb) == NET_RX_SUCCESS) {
srcstats->tx_packets++;
- srcstats->tx_bytes += cfd->len;
+ srcstats->tx_bytes += len;
peerstats = &peer->stats;
peerstats->rx_packets++;
- peerstats->rx_bytes += cfd->len;
+ peerstats->rx_bytes += len;
}
out_unlock:
--
2.27.0
[PATCH 5.4 49/86] can: dev: can_restart: fix use after free bug
From: Vincent Mailhol
[ Upstream commit 03f16c5075b22c8902d2af739969e878b0879c94 ]
After calling netif_rx_ni(skb), dereferencing skb is unsafe.
Especially, the can_frame cf which aliases skb memory is accessed
after the netif_rx_ni() in:
stats->rx_bytes += cf->len;
Reordering the lines solves the issue.
Fixes: 39549eef3587 ("can: CAN Network device driver and Netlink interface")
Link:
https://lore.kernel.org/r/20210120114137.200019-2-mailhol.vinc...@wanadoo.fr
Signed-off-by: Vincent Mailhol
Signed-off-by: Marc Kleine-Budde
Signed-off-by: Sasha Levin
---
drivers/net/can/dev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index 5b8791135de13..247aeacb3a440 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -567,11 +567,11 @@ static void can_restart(struct net_device *dev)
}
cf->can_id |= CAN_ERR_RESTARTED;
- netif_rx_ni(skb);
-
stats->rx_packets++;
stats->rx_bytes += cf->can_dlc;
+ netif_rx_ni(skb);
+
restart:
netdev_dbg(dev, "restarted\n");
priv->can_stats.restarts++;
--
2.27.0
[PATCH 5.4 51/86] can: peak_usb: fix use after free bugs
From: Vincent Mailhol
[ Upstream commit 50aca891d7a554db0901b245167cd653d73aaa71 ]
After calling peak_usb_netif_rx_ni(skb), dereferencing skb is unsafe.
Especially, the can_frame cf which aliases skb memory is accessed
after the peak_usb_netif_rx_ni().
Reordering the lines solves the issue.
Fixes: 0a25e1f4f185 ("can: peak_usb: add support for PEAK new CANFD USB
adapters")
Link:
https://lore.kernel.org/r/20210120114137.200019-4-mailhol.vinc...@wanadoo.fr
Signed-off-by: Vincent Mailhol
Signed-off-by: Marc Kleine-Budde
Signed-off-by: Sasha Levin
---
drivers/net/can/usb/peak_usb/pcan_usb_fd.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_fd.c
b/drivers/net/can/usb/peak_usb/pcan_usb_fd.c
index dee3e689b54da..96bbdef672bc9 100644
--- a/drivers/net/can/usb/peak_usb/pcan_usb_fd.c
+++ b/drivers/net/can/usb/peak_usb/pcan_usb_fd.c
@@ -512,11 +512,11 @@ static int pcan_usb_fd_decode_canmsg(struct
pcan_usb_fd_if *usb_if,
else
memcpy(cfd->data, rm->d, cfd->len);
- peak_usb_netif_rx(skb, &usb_if->time_ref, le32_to_cpu(rm->ts_low));
-
netdev->stats.rx_packets++;
netdev->stats.rx_bytes += cfd->len;
+ peak_usb_netif_rx(skb, &usb_if->time_ref, le32_to_cpu(rm->ts_low));
+
return 0;
}
@@ -578,11 +578,11 @@ static int pcan_usb_fd_decode_status(struct
pcan_usb_fd_if *usb_if,
if (!skb)
return -ENOMEM;
- peak_usb_netif_rx(skb, &usb_if->time_ref, le32_to_cpu(sm->ts_low));
-
netdev->stats.rx_packets++;
netdev->stats.rx_bytes += cf->can_dlc;
+ peak_usb_netif_rx(skb, &usb_if->time_ref, le32_to_cpu(sm->ts_low));
+
return 0;
}
--
2.27.0
[PATCH 5.4 52/86] iio: ad5504: Fix setting power-down state
From: Lars-Peter Clausen
commit efd597b2839a9895e8a98fcb0b76d2f545802cd4 upstream.
The power-down mask of the ad5504 is actually a power-up mask. Meaning if
a bit is set the corresponding channel is powered up and if it is not set
the channel is powered down.
The driver currently has this the wrong way around, resulting in the
channel being powered up when requested to be powered down and vice versa.
Fixes: 3bbbf150ffde ("staging:iio:dac:ad5504: Use strtobool for boolean values")
Signed-off-by: Lars-Peter Clausen
Acked-by: Alexandru Ardelean
Link: https://lore.kernel.org/r/20201209104649.5794-1-l...@metafoo.de
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman
---
drivers/iio/dac/ad5504.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/iio/dac/ad5504.c
+++ b/drivers/iio/dac/ad5504.c
@@ -188,9 +188,9 @@ static ssize_t ad5504_write_dac_powerdow
return ret;
if (pwr_down)
- st->pwr_down_mask |= (1 << chan->channel);
- else
st->pwr_down_mask &= ~(1 << chan->channel);
+ else
+ st->pwr_down_mask |= (1 << chan->channel);
ret = ad5504_spi_write(st, AD5504_ADDR_CTRL,
AD5504_DAC_PWRDWN_MODE(st->pwr_down_mode) |
[PATCH 5.4 54/86] irqchip/mips-cpu: Set IPI domain parent chip
From: Mathias Kresin
commit 599b3063adf4bf041a87a69244ee36aded0d878f upstream.
Since commit 55567976629e ("genirq/irqdomain: Allow partial trimming of
irq_data hierarchy") the irq_data chain is valided.
The irq_domain_trim_hierarchy() function doesn't consider the irq + ipi
domain hierarchy as valid, since the ipi domain has the irq domain set
as parent, but the parent domain has no chip set. Hence the boot ends in
a kernel panic.
Set the chip for the parent domain as it is done in the mips gic irq
driver, to have a valid irq_data chain.
Fixes: 3838a547fda2 ("irqchip: mips-cpu: Introduce IPI IRQ domain support")
Cc: # v5.10+
Signed-off-by: Mathias Kresin
Signed-off-by: Marc Zyngier
Link: https://lore.kernel.org/r/20210107213603.1637781-1-...@kresin.me
Signed-off-by: Greg Kroah-Hartman
---
drivers/irqchip/irq-mips-cpu.c |7 +++
1 file changed, 7 insertions(+)
--- a/drivers/irqchip/irq-mips-cpu.c
+++ b/drivers/irqchip/irq-mips-cpu.c
@@ -197,6 +197,13 @@ static int mips_cpu_ipi_alloc(struct irq
if (ret)
return ret;
+ ret = irq_domain_set_hwirq_and_chip(domain->parent, virq + i,
hwirq,
+ &mips_mt_cpu_irq_controller,
+ NULL);
+
+ if (ret)
+ return ret;
+
ret = irq_set_irq_type(virq + i, IRQ_TYPE_LEVEL_HIGH);
if (ret)
return ret;
[PATCH 5.4 53/86] cifs: do not fail __smb_send_rqst if non-fatal signals are pending
From: Ronnie Sahlberg
commit 214a5ea081e77346e4963dd6d20c5539ff8b6ae6 upstream.
RHBZ 1848178
The original intent of returning an error in this function
in the patch:
"CIFS: Mask off signals when sending SMB packets"
was to avoid interrupting packet send in the middle of
sending the data (and thus breaking an SMB connection),
but we also don't want to fail the request for non-fatal
signals even before we have had a chance to try to
send it (the reported problem could be reproduced e.g.
by exiting a child process when the parent process was in
the midst of calling futimens to update a file's timestamps).
In addition, since the signal may remain pending when we enter the
sending loop, we may end up not sending the whole packet before
TCP buffers become full. In this case the code returns -EINTR
but what we need here is to return -ERESTARTSYS instead to
allow system calls to be restarted.
Fixes: b30c74c73c78 ("CIFS: Mask off signals when sending SMB packets")
Cc: sta...@vger.kernel.org # v5.1+
Signed-off-by: Ronnie Sahlberg
Reviewed-by: Pavel Shilovsky
Signed-off-by: Steve French
Signed-off-by: Greg Kroah-Hartman
---
fs/cifs/transport.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/cifs/transport.c
+++ b/fs/cifs/transport.c
@@ -339,7 +339,7 @@ __smb_send_rqst(struct TCP_Server_Info *
if (ssocket == NULL)
return -EAGAIN;
- if (signal_pending(current)) {
+ if (fatal_signal_pending(current)) {
cifs_dbg(FYI, "signal pending before send request\n");
return -ERESTARTSYS;
}
@@ -431,7 +431,7 @@ unmask:
if (signal_pending(current) && (total_len != send_length)) {
cifs_dbg(FYI, "signal is pending after attempt to send\n");
- rc = -EINTR;
+ rc = -ERESTARTSYS;
}
/* uncork it */
[PATCH 5.4 56/86] intel_th: pci: Add Alder Lake-P support
From: Alexander Shishkin
commit cb5c681ab9037e25fcca20689c82cf034566d610 upstream.
This adds support for the Trace Hub in Alder Lake-P.
Signed-off-by: Alexander Shishkin
Link:
https://lore.kernel.org/r/20210115195917.3184-3-alexander.shish...@linux.intel.com
Cc: stable
Signed-off-by: Greg Kroah-Hartman
---
drivers/hwtracing/intel_th/pci.c |5 +
1 file changed, 5 insertions(+)
--- a/drivers/hwtracing/intel_th/pci.c
+++ b/drivers/hwtracing/intel_th/pci.c
@@ -259,6 +259,11 @@ static const struct pci_device_id intel_
.driver_data = (kernel_ulong_t)&intel_th_2x,
},
{
+ /* Alder Lake-P */
+ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x51a6),
+ .driver_data = (kernel_ulong_t)&intel_th_2x,
+ },
+ {
/* Emmitsburg PCH */
PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x1bcc),
.driver_data = (kernel_ulong_t)&intel_th_2x,
[PATCH 5.4 41/86] drm/nouveau/kms/nv50-: fix case where notifier buffer is at offset 0
From: Ben Skeggs
[ Upstream commit caeb6ab899c3d36a74cda6e299c6e1c9c4e2a22e ]
VRAM offset 0 is a valid address, triggered on GA102.
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 4 ++--
drivers/gpu/drm/nouveau/dispnv50/disp.h | 2 +-
drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index ee2b1e1199e09..daa79d39201f9 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -132,7 +132,7 @@ nv50_dmac_destroy(struct nv50_dmac *dmac)
int
nv50_dmac_create(struct nvif_device *device, struct nvif_object *disp,
-const s32 *oclass, u8 head, void *data, u32 size, u64 syncbuf,
+const s32 *oclass, u8 head, void *data, u32 size, s64 syncbuf,
struct nv50_dmac *dmac)
{
struct nouveau_cli *cli = (void *)device->object.client;
@@ -167,7 +167,7 @@ nv50_dmac_create(struct nvif_device *device, struct
nvif_object *disp,
if (ret)
return ret;
- if (!syncbuf)
+ if (syncbuf < 0)
return 0;
ret = nvif_object_init(&dmac->base.user, 0xf000, NV_DMA_IN_MEMORY,
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.h
b/drivers/gpu/drm/nouveau/dispnv50/disp.h
index 7c41b0599d1ac..284068fa6d007 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.h
@@ -70,7 +70,7 @@ struct nv50_dmac {
int nv50_dmac_create(struct nvif_device *device, struct nvif_object *disp,
const s32 *oclass, u8 head, void *data, u32 size,
-u64 syncbuf, struct nv50_dmac *dmac);
+s64 syncbuf, struct nv50_dmac *dmac);
void nv50_dmac_destroy(struct nv50_dmac *);
u32 *evo_wait(struct nv50_dmac *, int nr);
diff --git a/drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c
b/drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c
index f7dbd965e4e72..b49a212af4d8d 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c
@@ -68,7 +68,7 @@ wimmc37b_init_(const struct nv50_wimm_func *func, struct
nouveau_drm *drm,
int ret;
ret = nv50_dmac_create(&drm->client.device, &disp->disp->object,
- &oclass, 0, &args, sizeof(args), 0,
+ &oclass, 0, &args, sizeof(args), -1,
&wndw->wimm);
if (ret) {
NV_ERROR(drm, "wimm%04x allocation failed: %d\n", oclass, ret);
--
2.27.0
[PATCH 5.4 60/86] USB: ehci: fix an interrupt calltrace error
From: Longfang Liu commit 643a4df7fe3f6831d14536fd692be85f92670a52 upstream. The system that use Synopsys USB host controllers goes to suspend when using USB audio player. This causes the USB host controller continuous send interrupt signal to system, When the number of interrupts exceeds 10, the system will forcibly close the interrupts and output a calltrace error. When the system goes to suspend, the last interrupt is reported to the driver. At this time, the system has set the state to suspend. This causes the last interrupt to not be processed by the system and not clear the interrupt flag. This uncleared interrupt flag constantly triggers new interrupt event. This causing the driver to receive more than 100,000 interrupts, which causes the system to forcibly close the interrupt report and report the calltrace error. so, when the driver goes to sleep and changes the system state to suspend, the interrupt flag needs to be cleared. Signed-off-by: Longfang Liu Acked-by: Alan Stern Link: https://lore.kernel.org/r/1610416647-45774-1-git-send-email-liulongf...@huawei.com Cc: stable Signed-off-by: Greg Kroah-Hartman --- drivers/usb/host/ehci-hub.c |3 +++ 1 file changed, 3 insertions(+) --- a/drivers/usb/host/ehci-hub.c +++ b/drivers/usb/host/ehci-hub.c @@ -345,6 +345,9 @@ static int ehci_bus_suspend (struct usb_ unlink_empty_async_suspended(ehci); + /* Some Synopsys controllers mistakenly leave IAA turned on */ + ehci_writel(ehci, STS_IAA, &ehci->regs->status); + /* Any IAA cycle that started before the suspend is now invalid */ end_iaa_cycle(ehci); ehci_handle_start_intr_unlinks(ehci);
[PATCH 5.4 57/86] stm class: Fix module init return on allocation failure
From: Wang Hui
commit 927633a6d20af319d986f3e42c3ef9f6d7835008 upstream.
In stm_heartbeat_init(): return value gets reset after the first
iteration by stm_source_register_device(), so allocation failures
after that will, after a clean up, return success. Fix that.
Fixes: 119291853038 ("stm class: Add heartbeat stm source device")
Reported-by: Hulk Robot
Signed-off-by: Wang Hui
Signed-off-by: Alexander Shishkin
Link:
https://lore.kernel.org/r/20210115195917.3184-2-alexander.shish...@linux.intel.com
Cc: stable
Signed-off-by: Greg Kroah-Hartman
---
drivers/hwtracing/stm/heartbeat.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/hwtracing/stm/heartbeat.c
+++ b/drivers/hwtracing/stm/heartbeat.c
@@ -64,7 +64,7 @@ static void stm_heartbeat_unlink(struct
static int stm_heartbeat_init(void)
{
- int i, ret = -ENOMEM;
+ int i, ret;
if (nr_devs < 0 || nr_devs > STM_HEARTBEAT_MAX)
return -EINVAL;
@@ -72,8 +72,10 @@ static int stm_heartbeat_init(void)
for (i = 0; i < nr_devs; i++) {
stm_heartbeat[i].data.name =
kasprintf(GFP_KERNEL, "heartbeat.%d", i);
- if (!stm_heartbeat[i].data.name)
+ if (!stm_heartbeat[i].data.name) {
+ ret = -ENOMEM;
goto fail_unregister;
+ }
stm_heartbeat[i].data.nr_chans = 1;
stm_heartbeat[i].data.link = stm_heartbeat_link;
[PATCH 5.4 66/86] driver core: Extend device_is_dependent()
From: Rafael J. Wysocki
commit 3d1cf435e201d1fd63e4346b141881aed086effd upstream.
If the device passed as the target (second argument) to
device_is_dependent() is not completely registered (that is, it has
been initialized, but not added yet), but the parent pointer of it
is set, it may be missing from the list of the parent's children
and device_for_each_child() called by device_is_dependent() cannot
be relied on to catch that dependency.
For this reason, modify device_is_dependent() to check the ancestors
of the target device by following its parent pointer in addition to
the device_for_each_child() walk.
Fixes: 9ed9895370ae ("driver core: Functional dependencies tracking support")
Reported-by: Stephan Gerhold
Tested-by: Stephan Gerhold
Reviewed-by: Saravana Kannan
Signed-off-by: Rafael J. Wysocki
Link: https://lore.kernel.org/r/17705994.d592GUb2YH@kreacher
Cc: stable
Signed-off-by: Greg Kroah-Hartman
---
drivers/base/core.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -106,6 +106,16 @@ int device_links_read_lock_held(void)
#endif
#endif /* !CONFIG_SRCU */
+static bool device_is_ancestor(struct device *dev, struct device *target)
+{
+ while (target->parent) {
+ target = target->parent;
+ if (dev == target)
+ return true;
+ }
+ return false;
+}
+
/**
* device_is_dependent - Check if one device depends on another one
* @dev: Device to check dependencies for.
@@ -119,7 +129,12 @@ static int device_is_dependent(struct de
struct device_link *link;
int ret;
- if (dev == target)
+ /*
+* The "ancestors" check is needed to catch the case when the target
+* device has not been completely initialized yet and it is still
+* missing from the list of children of its parent device.
+*/
+ if (dev == target || device_is_ancestor(dev, target))
return 1;
ret = device_for_each_child(dev, target, device_is_dependent);
[PATCH 5.4 61/86] usb: gadget: aspeed: fix stop dma register setting.
From: Ryan Chen
commit 4e0dcf62ab4cf917d0cbe751b8bf229a065248d4 upstream.
The vhub engine has two dma mode, one is descriptor list, another
is single stage DMA. Each mode has different stop register setting.
Descriptor list operation (bit2) : 0 disable reset, 1: enable reset
Single mode operation (bit0) : 0 : disable, 1: enable
Fixes: 7ecca2a4080c ("usb/gadget: Add driver for Aspeed SoC virtual hub")
Cc: stable
Acked-by: Felipe Balbi
Acked-by: Joel Stanley
Signed-off-by: Ryan Chen
Link: https://lore.kernel.org/r/20210108081238.10199-2-ryan_c...@aspeedtech.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/gadget/udc/aspeed-vhub/epn.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/usb/gadget/udc/aspeed-vhub/epn.c
+++ b/drivers/usb/gadget/udc/aspeed-vhub/epn.c
@@ -420,7 +420,10 @@ static void ast_vhub_stop_active_req(str
u32 state, reg, loops;
/* Stop DMA activity */
- writel(0, ep->epn.regs + AST_VHUB_EP_DMA_CTLSTAT);
+ if (ep->epn.desc_mode)
+ writel(VHUB_EP_DMA_CTRL_RESET, ep->epn.regs +
AST_VHUB_EP_DMA_CTLSTAT);
+ else
+ writel(0, ep->epn.regs + AST_VHUB_EP_DMA_CTLSTAT);
/* Wait for it to complete */
for (loops = 0; loops < 1000; loops++) {
[PATCH 5.4 65/86] xhci: tegra: Delay for disabling LFPS detector
From: JC Kuo
commit da7e0c3c2909a3d9bf8acfe1db3cb213bd7febfb upstream.
Occasionally, we are seeing some SuperSpeed devices resumes right after
being directed to U3. This commits add 500us delay to ensure LFPS
detector is disabled before sending ACK to firmware.
[ 16.099363] tegra-xusb 7009.usb: entering ELPG
[ 16.104343] tegra-xusb 7009.usb: 2-1 isn't suspended: 0x0c001203
[ 16.114576] tegra-xusb 7009.usb: not all ports suspended: -16
[ 16.120789] tegra-xusb 7009.usb: entering ELPG failed
The register write passes through a few flop stages of 32KHz clock domain.
NVIDIA ASIC designer reviewed RTL and suggests 500us delay.
Cc: sta...@vger.kernel.org
Signed-off-by: JC Kuo
Signed-off-by: Mathias Nyman
Link:
https://lore.kernel.org/r/20210115161907.2875631-3-mathias.ny...@linux.intel.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/host/xhci-tegra.c |7 +++
1 file changed, 7 insertions(+)
--- a/drivers/usb/host/xhci-tegra.c
+++ b/drivers/usb/host/xhci-tegra.c
@@ -562,6 +562,13 @@ static void tegra_xusb_mbox_handle(struc
enable);
if (err < 0)
break;
+
+ /*
+* wait 500us for LFPS detector to be disabled before
+* sending ACK
+*/
+ if (!enable)
+ usleep_range(500, 1000);
}
if (err < 0) {
[PATCH 5.4 71/86] net: dsa: mv88e6xxx: also read STU state in mv88e6250_g1_vtu_getnext
From: Rasmus Villemoes commit 87fe04367d842c4d97a77303242d4dd4ac351e46 upstream. mv88e6xxx_port_vlan_join checks whether the VTU already contains an entry for the given vid (via mv88e6xxx_vtu_getnext), and if so, merely changes the relevant .member[] element and loads the updated entry into the VTU. However, at least for the mv88e6250, the on-stack struct mv88e6xxx_vtu_entry vlan never has its .state[] array explicitly initialized, neither in mv88e6xxx_port_vlan_join() nor inside the getnext implementation. So the new entry has random garbage for the STU bits, breaking VLAN filtering. When the VTU entry is initially created, those bits are all zero, and we should make sure to keep them that way when the entry is updated. Fixes: 92307069a96c (net: dsa: mv88e6xxx: Avoid VTU corruption on 6097) Signed-off-by: Rasmus Villemoes Reviewed-by: Florian Fainelli Reviewed-by: Tobias Waldekranz Tested-by: Tobias Waldekranz Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman --- drivers/net/dsa/mv88e6xxx/global1_vtu.c |4 1 file changed, 4 insertions(+) --- a/drivers/net/dsa/mv88e6xxx/global1_vtu.c +++ b/drivers/net/dsa/mv88e6xxx/global1_vtu.c @@ -351,6 +351,10 @@ int mv88e6250_g1_vtu_getnext(struct mv88 if (err) return err; + err = mv88e6185_g1_stu_data_read(chip, entry); + if (err) + return err; + /* VTU DBNum[3:0] are located in VTU Operation 3:0 * VTU DBNum[5:4] are located in VTU Operation 9:8 */
[PATCH 5.4 42/86] powerpc: Use the common INIT_DATA_SECTION macro in vmlinux.lds.S
From: Youling Tang
[ Upstream commit fdcfeaba38e5b183045f5b079af94f97658eabe6 ]
Use the common INIT_DATA_SECTION rule for the linker script in an effort
to regularize the linker script.
Signed-off-by: Youling Tang
Signed-off-by: Michael Ellerman
Link:
https://lore.kernel.org/r/1604487550-20040-1-git-send-email-tangyoul...@loongson.cn
Signed-off-by: Sasha Levin
---
arch/powerpc/kernel/vmlinux.lds.S | 19 +--
1 file changed, 1 insertion(+), 18 deletions(-)
diff --git a/arch/powerpc/kernel/vmlinux.lds.S
b/arch/powerpc/kernel/vmlinux.lds.S
index 4def51c12e1bf..f9081724d6910 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -223,21 +223,7 @@ SECTIONS
EXIT_TEXT
}
- .init.data : AT(ADDR(.init.data) - LOAD_OFFSET) {
- INIT_DATA
- }
-
- .init.setup : AT(ADDR(.init.setup) - LOAD_OFFSET) {
- INIT_SETUP(16)
- }
-
- .initcall.init : AT(ADDR(.initcall.init) - LOAD_OFFSET) {
- INIT_CALLS
- }
-
- .con_initcall.init : AT(ADDR(.con_initcall.init) - LOAD_OFFSET) {
- CON_INITCALL
- }
+ INIT_DATA_SECTION(16)
. = ALIGN(8);
__ftr_fixup : AT(ADDR(__ftr_fixup) - LOAD_OFFSET) {
@@ -265,9 +251,6 @@ SECTIONS
__stop___fw_ftr_fixup = .;
}
#endif
- .init.ramfs : AT(ADDR(.init.ramfs) - LOAD_OFFSET) {
- INIT_RAM_FS
- }
PERCPU_SECTION(L1_CACHE_BYTES)
--
2.27.0
[PATCH 5.4 69/86] netfilter: rpfilter: mask ecn bits before fib lookup
From: Guillaume Nault
commit 2e5a6266fbb11ae93c468dfecab169aca9c27b43 upstream.
RT_TOS() only masks one of the two ECN bits. Therefore rpfilter_mt()
treats Not-ECT or ECT(1) packets in a different way than those with
ECT(0) or CE.
Reproducer:
Create two netns, connected with a veth:
$ ip netns add ns0
$ ip netns add ns1
$ ip link add name veth01 netns ns0 type veth peer name veth10 netns ns1
$ ip -netns ns0 link set dev veth01 up
$ ip -netns ns1 link set dev veth10 up
$ ip -netns ns0 address add 192.0.2.10/32 dev veth01
$ ip -netns ns1 address add 192.0.2.11/32 dev veth10
Add a route to ns1 in ns0:
$ ip -netns ns0 route add 192.0.2.11/32 dev veth01
In ns1, only packets with TOS 4 can be routed to ns0:
$ ip -netns ns1 route add 192.0.2.10/32 tos 4 dev veth10
Ping from ns0 to ns1 works regardless of the ECN bits, as long as TOS
is 4:
$ ip netns exec ns0 ping -Q 4 192.0.2.11 # TOS 4, Not-ECT
... 0% packet loss ...
$ ip netns exec ns0 ping -Q 5 192.0.2.11 # TOS 4, ECT(1)
... 0% packet loss ...
$ ip netns exec ns0 ping -Q 6 192.0.2.11 # TOS 4, ECT(0)
... 0% packet loss ...
$ ip netns exec ns0 ping -Q 7 192.0.2.11 # TOS 4, CE
... 0% packet loss ...
Now use iptable's rpfilter module in ns1:
$ ip netns exec ns1 iptables-legacy -t raw -A PREROUTING -m rpfilter --invert
-j DROP
Not-ECT and ECT(1) packets still pass:
$ ip netns exec ns0 ping -Q 4 192.0.2.11 # TOS 4, Not-ECT
... 0% packet loss ...
$ ip netns exec ns0 ping -Q 5 192.0.2.11 # TOS 4, ECT(1)
... 0% packet loss ...
But ECT(0) and ECN packets are dropped:
$ ip netns exec ns0 ping -Q 6 192.0.2.11 # TOS 4, ECT(0)
... 100% packet loss ...
$ ip netns exec ns0 ping -Q 7 192.0.2.11 # TOS 4, CE
... 100% packet loss ...
After this patch, rpfilter doesn't drop ECT(0) and CE packets anymore.
Fixes: 8f97339d3feb ("netfilter: add ipv4 reverse path filter match")
Signed-off-by: Guillaume Nault
Signed-off-by: Jakub Kicinski
Signed-off-by: Greg Kroah-Hartman
---
net/ipv4/netfilter/ipt_rpfilter.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/ipv4/netfilter/ipt_rpfilter.c
+++ b/net/ipv4/netfilter/ipt_rpfilter.c
@@ -76,7 +76,7 @@ static bool rpfilter_mt(const struct sk_
flow.daddr = iph->saddr;
flow.saddr = rpfilter_get_saddr(iph->daddr);
flow.flowi4_mark = info->flags & XT_RPFILTER_VALID_MARK ? skb->mark : 0;
- flow.flowi4_tos = RT_TOS(iph->tos);
+ flow.flowi4_tos = iph->tos & IPTOS_RT_MASK;
flow.flowi4_scope = RT_SCOPE_UNIVERSE;
flow.flowi4_oif = l3mdev_master_ifindex_rcu(xt_in(par));
[PATCH 5.4 63/86] usb: bdc: Make bdc pci driver depend on BROKEN
From: Patrik Jakobsson commit ef02684c4e67d8c35ac83083564135bc7b1d3445 upstream. The bdc pci driver is going to be removed due to it not existing in the wild. This patch turns off compilation of the driver so that stable kernels can also pick up the change. This helps the out-of-tree facetimehd webcam driver as the pci id conflicts with bdc. Cc: Al Cooper Cc: Acked-by: Felipe Balbi Signed-off-by: Patrik Jakobsson Link: https://lore.kernel.org/r/20210118203615.13995-1-patrik.r.jakobs...@gmail.com Signed-off-by: Greg Kroah-Hartman --- drivers/usb/gadget/udc/bdc/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/usb/gadget/udc/bdc/Kconfig +++ b/drivers/usb/gadget/udc/bdc/Kconfig @@ -17,7 +17,7 @@ if USB_BDC_UDC comment "Platform Support" config USB_BDC_PCI tristate "BDC support for PCIe based platforms" - depends on USB_PCI + depends on USB_PCI && BROKEN default USB_BDC_UDC help Enable support for platforms which have BDC connected through PCIe, such as Lego3 FPGA platform.
[PATCH 5.4 44/86] scsi: megaraid_sas: Fix MEGASAS_IOC_FIRMWARE regression
From: Arnd Bergmann
[ Upstream commit b112036535eda34460677ea883eaecc3a45a435d ]
Phil Oester reported that a fix for a possible buffer overrun that I sent
caused a regression that manifests in this output:
Event Message: A PCI parity error was detected on a component at bus 0 device
5 function 0.
Severity: Critical
Message ID: PCI1308
The original code tried to handle the sense data pointer differently when
using 32-bit 64-bit DMA addressing, which would lead to a 32-bit dma_addr_t
value of 0x11223344 to get stored
32-bit kernel: 44 33 22 11 ?? ?? ?? ??
64-bit LE kernel:44 33 22 11 00 00 00 00
64-bit BE kernel:00 00 00 00 44 33 22 11
or a 64-bit dma_addr_t value of 0x1122334455667788 to get stored as
32-bit kernel: 88 77 66 55 ?? ?? ?? ??
64-bit kernel: 88 77 66 55 44 33 22 11
In my patch, I tried to ensure that the same value is used on both 32-bit
and 64-bit kernels, and picked what seemed to be the most sensible
combination, storing 32-bit addresses in the first four bytes (as 32-bit
kernels already did), and 64-bit addresses in eight consecutive bytes (as
64-bit kernels already did), but evidently this was incorrect.
Always storing the dma_addr_t pointer as 64-bit little-endian,
i.e. initializing the second four bytes to zero in case of 32-bit
addressing, apparently solved the problem for Phil, and is consistent with
what all 64-bit little-endian machines did before.
I also checked in the history that in previous versions of the code, the
pointer was always in the first four bytes without padding, and that
previous attempts to fix 64-bit user space, big-endian architectures and
64-bit DMA were clearly flawed and seem to have introduced made this worse.
Link: https://lore.kernel.org/r/20210104234137.438275-1-a...@kernel.org
Fixes: 381d34e376e3 ("scsi: megaraid_sas: Check user-provided offsets")
Fixes: 107a60dd71b5 ("scsi: megaraid_sas: Add support for 64bit consistent DMA")
Fixes: 94cd65ddf4d7 ("[SCSI] megaraid_sas: addded support for big endian
architecture")
Fixes: 7b2519afa1ab ("[SCSI] megaraid_sas: fix 64 bit sense pointer truncation")
Reported-by: Phil Oester
Tested-by: Phil Oester
Signed-off-by: Arnd Bergmann
Signed-off-by: Martin K. Petersen
Signed-off-by: Sasha Levin
---
drivers/scsi/megaraid/megaraid_sas_base.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 4a23dd8b7f9aa..b9c1f722f1ded 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -8174,11 +8174,9 @@ megasas_mgmt_fw_ioctl(struct megasas_instance *instance,
goto out;
}
+ /* always store 64 bits regardless of addressing */
sense_ptr = (void *)cmd->frame + ioc->sense_off;
- if (instance->consistent_mask_64bit)
- put_unaligned_le64(sense_handle, sense_ptr);
- else
- put_unaligned_le32(sense_handle, sense_ptr);
+ put_unaligned_le64(sense_handle, sense_ptr);
}
/*
--
2.27.0
[PATCH 5.4 67/86] pinctrl: ingenic: Fix JZ4760 support
From: Paul Cercueil
commit 9a85c09a3f507b925d75cb0c7c8f364467038052 upstream.
- JZ4760 and JZ4760B have a similar register layout as the JZ4740, and
don't use the new register layout, which was introduced with the
JZ4770 SoC and not the JZ4760 or JZ4760B SoCs.
- The JZ4740 code path only expected two function modes to be
configurable for each pin, and wouldn't work with more than two. Fix
it for the JZ4760, which has four configurable function modes.
Fixes: 0257595a5cf4 ("pinctrl: Ingenic: Add pinctrl driver for JZ4760 and
JZ4760B.")
Cc: # 5.3
Signed-off-by: Paul Cercueil
Link: https://lore.kernel.org/r/20201211232810.261565-1-p...@crapouillou.net
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman
---
drivers/pinctrl/pinctrl-ingenic.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
--- a/drivers/pinctrl/pinctrl-ingenic.c
+++ b/drivers/pinctrl/pinctrl-ingenic.c
@@ -1378,7 +1378,7 @@ static inline bool ingenic_gpio_get_valu
static void ingenic_gpio_set_value(struct ingenic_gpio_chip *jzgc,
u8 offset, int value)
{
- if (jzgc->jzpc->version >= ID_JZ4760)
+ if (jzgc->jzpc->version >= ID_JZ4770)
ingenic_gpio_set_bit(jzgc, JZ4760_GPIO_PAT0, offset, !!value);
else
ingenic_gpio_set_bit(jzgc, JZ4740_GPIO_DATA, offset, !!value);
@@ -1389,7 +1389,7 @@ static void irq_set_type(struct ingenic_
{
u8 reg1, reg2;
- if (jzgc->jzpc->version >= ID_JZ4760) {
+ if (jzgc->jzpc->version >= ID_JZ4770) {
reg1 = JZ4760_GPIO_PAT1;
reg2 = JZ4760_GPIO_PAT0;
} else {
@@ -1464,7 +1464,7 @@ static void ingenic_gpio_irq_enable(stru
struct ingenic_gpio_chip *jzgc = gpiochip_get_data(gc);
int irq = irqd->hwirq;
- if (jzgc->jzpc->version >= ID_JZ4760)
+ if (jzgc->jzpc->version >= ID_JZ4770)
ingenic_gpio_set_bit(jzgc, JZ4760_GPIO_INT, irq, true);
else
ingenic_gpio_set_bit(jzgc, JZ4740_GPIO_SELECT, irq, true);
@@ -1480,7 +1480,7 @@ static void ingenic_gpio_irq_disable(str
ingenic_gpio_irq_mask(irqd);
- if (jzgc->jzpc->version >= ID_JZ4760)
+ if (jzgc->jzpc->version >= ID_JZ4770)
ingenic_gpio_set_bit(jzgc, JZ4760_GPIO_INT, irq, false);
else
ingenic_gpio_set_bit(jzgc, JZ4740_GPIO_SELECT, irq, false);
@@ -1505,7 +1505,7 @@ static void ingenic_gpio_irq_ack(struct
irq_set_type(jzgc, irq, IRQ_TYPE_LEVEL_HIGH);
}
- if (jzgc->jzpc->version >= ID_JZ4760)
+ if (jzgc->jzpc->version >= ID_JZ4770)
ingenic_gpio_set_bit(jzgc, JZ4760_GPIO_FLAG, irq, false);
else
ingenic_gpio_set_bit(jzgc, JZ4740_GPIO_DATA, irq, true);
@@ -1562,7 +1562,7 @@ static void ingenic_gpio_irq_handler(str
chained_irq_enter(irq_chip, desc);
- if (jzgc->jzpc->version >= ID_JZ4760)
+ if (jzgc->jzpc->version >= ID_JZ4770)
flag = ingenic_gpio_read_reg(jzgc, JZ4760_GPIO_FLAG);
else
flag = ingenic_gpio_read_reg(jzgc, JZ4740_GPIO_FLAG);
@@ -1643,7 +1643,7 @@ static int ingenic_gpio_get_direction(st
struct ingenic_pinctrl *jzpc = jzgc->jzpc;
unsigned int pin = gc->base + offset;
- if (jzpc->version >= ID_JZ4760)
+ if (jzpc->version >= ID_JZ4770)
return ingenic_get_pin_config(jzpc, pin, JZ4760_GPIO_INT) ||
ingenic_get_pin_config(jzpc, pin, JZ4760_GPIO_PAT1);
@@ -1676,7 +1676,7 @@ static int ingenic_pinmux_set_pin_fn(str
ingenic_shadow_config_pin(jzpc, pin, JZ4760_GPIO_PAT1, func &
0x2);
ingenic_shadow_config_pin(jzpc, pin, JZ4760_GPIO_PAT0, func &
0x1);
ingenic_shadow_config_pin_load(jzpc, pin);
- } else if (jzpc->version >= ID_JZ4760) {
+ } else if (jzpc->version >= ID_JZ4770) {
ingenic_config_pin(jzpc, pin, JZ4760_GPIO_INT, false);
ingenic_config_pin(jzpc, pin, GPIO_MSK, false);
ingenic_config_pin(jzpc, pin, JZ4760_GPIO_PAT1, func & 0x2);
@@ -1684,7 +1684,7 @@ static int ingenic_pinmux_set_pin_fn(str
} else {
ingenic_config_pin(jzpc, pin, JZ4740_GPIO_FUNC, true);
ingenic_config_pin(jzpc, pin, JZ4740_GPIO_TRIG, func & 0x2);
- ingenic_config_pin(jzpc, pin, JZ4740_GPIO_SELECT, func > 0);
+ ingenic_config_pin(jzpc, pin, JZ4740_GPIO_SELECT, func & 0x1);
}
return 0;
@@ -1734,7 +1734,7 @@ static int ingenic_pinmux_gpio_set_direc
ingenic_shadow_config_pin(jzpc, pin, GPIO_MSK, true);
ingenic_shadow_config_pin(jzpc, pin, JZ4760_GPIO_PAT1, input);
ingenic_shadow_config_pin_load(jzpc, pin);
- } else if (jzpc->version >= ID_JZ4760) {
+ } else if (jzpc->version >= ID_JZ4770) {
[PATCH 5.4 46/86] i2c: octeon: check correct size of maximum RECV_LEN packet
From: Wolfram Sang
[ Upstream commit 1b2cfa2d1dbdcc3b6dba1ecb7026a537a1d7277f ]
I2C_SMBUS_BLOCK_MAX defines already the maximum number as defined in the
SMBus 2.0 specs. No reason to add one to it.
Fixes: 886f6f8337dd ("i2c: octeon: Support I2C_M_RECV_LEN")
Signed-off-by: Wolfram Sang
Reviewed-by: Robert Richter
Signed-off-by: Wolfram Sang
Signed-off-by: Sasha Levin
---
drivers/i2c/busses/i2c-octeon-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-octeon-core.c
b/drivers/i2c/busses/i2c-octeon-core.c
index d9607905dc2f1..845eda70b8cab 100644
--- a/drivers/i2c/busses/i2c-octeon-core.c
+++ b/drivers/i2c/busses/i2c-octeon-core.c
@@ -347,7 +347,7 @@ static int octeon_i2c_read(struct octeon_i2c *i2c, int
target,
if (result)
return result;
if (recv_len && i == 0) {
- if (data[i] > I2C_SMBUS_BLOCK_MAX + 1)
+ if (data[i] > I2C_SMBUS_BLOCK_MAX)
return -EPROTO;
length += data[i];
}
--
2.27.0
[PATCH 5.4 83/86] net: Disable NETIF_F_HW_TLS_RX when RXCSUM is disabled
From: Tariq Toukan
commit a3eb4e9d4c9218476d05c52dfd2be3d6fdce6b91 upstream.
With NETIF_F_HW_TLS_RX packets are decrypted in HW. This cannot be
logically done when RXCSUM offload is off.
Fixes: 14136564c8ee ("net: Add TLS RX offload feature")
Signed-off-by: Tariq Toukan
Reviewed-by: Boris Pismenny
Link: https://lore.kernel.org/r/20210117151538.9411-1-tar...@nvidia.com
Signed-off-by: Jakub Kicinski
Signed-off-by: Greg Kroah-Hartman
---
net/core/dev.c |5 +
1 file changed, 5 insertions(+)
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -8692,6 +8692,11 @@ static netdev_features_t netdev_fix_feat
}
}
+ if ((features & NETIF_F_HW_TLS_RX) && !(features & NETIF_F_RXCSUM)) {
+ netdev_dbg(dev, "Dropping TLS RX HW offload feature since no
RXCSUM feature.\n");
+ features &= ~NETIF_F_HW_TLS_RX;
+ }
+
return features;
}
[PATCH 5.4 45/86] powerpc: Fix alignment bug within the init sections
From: Ariel Marcovitch
[ Upstream commit 2225a8dda263edc35a0e8b858fe2945cf6240fde ]
This is a bug that causes early crashes in builds with an .exit.text
section smaller than a page and an .init.text section that ends in the
beginning of a physical page (this is kinda random, which might
explain why this wasn't really encountered before).
The init sections are ordered like this:
.init.text
.exit.text
.init.data
Currently, these sections aren't page aligned.
Because the init code might become read-only at runtime and because
the .init.text section can potentially reside on the same physical
page as .init.data, the beginning of .init.data might be mapped
read-only along with .init.text.
Then when the kernel tries to modify a variable in .init.data (like
kthreadd_done, used in kernel_init()) the kernel panics.
To avoid this, make _einittext page aligned and also align .exit.text
to make sure .init.data is always seperated from the text segments.
Fixes: 060ef9d89d18 ("powerpc32: PAGE_EXEC required for inittext")
Signed-off-by: Ariel Marcovitch
Reviewed-by: Christophe Leroy
Signed-off-by: Michael Ellerman
Link:
https://lore.kernel.org/r/20210102201156.10805-1-ariel.marcovi...@gmail.com
Signed-off-by: Sasha Levin
---
arch/powerpc/kernel/vmlinux.lds.S | 8
1 file changed, 8 insertions(+)
diff --git a/arch/powerpc/kernel/vmlinux.lds.S
b/arch/powerpc/kernel/vmlinux.lds.S
index f9081724d6910..a4e576019d79c 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -210,6 +210,12 @@ SECTIONS
.init.text : AT(ADDR(.init.text) - LOAD_OFFSET) {
_sinittext = .;
INIT_TEXT
+
+ /*
+*.init.text might be RO so we must ensure this section ends on
+* a page boundary.
+*/
+ . = ALIGN(PAGE_SIZE);
_einittext = .;
#ifdef CONFIG_PPC64
*(.tramp.ftrace.init);
@@ -223,6 +229,8 @@ SECTIONS
EXIT_TEXT
}
+ . = ALIGN(PAGE_SIZE);
+
INIT_DATA_SECTION(16)
. = ALIGN(8);
--
2.27.0
[PATCH 5.4 73/86] lightnvm: fix memory leak when submit fails
From: Pan Bian
commit 97784481757fba7570121a70dd37ca74a29f50a8 upstream.
The allocated page is not released if error occurs in
nvm_submit_io_sync_raw(). __free_page() is moved ealier to avoid
possible memory leak issue.
Fixes: aff3fb18f957 ("lightnvm: move bad block and chunk state logic to core")
Signed-off-by: Pan Bian
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman
---
drivers/lightnvm/core.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/lightnvm/core.c
+++ b/drivers/lightnvm/core.c
@@ -849,11 +849,10 @@ static int nvm_bb_chunk_sense(struct nvm
rqd.ppa_addr = generic_to_dev_addr(dev, ppa);
ret = nvm_submit_io_sync_raw(dev, &rqd);
+ __free_page(page);
if (ret)
return ret;
- __free_page(page);
-
return rqd.error;
}
Re: [PATCH] arm64: kfence: fix header inclusion
On Mon, Jan 25, 2021 at 01:50:20PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Randconfig builds started warning about a missing function declaration
> after set_memory_valid() is moved to a new file:
>
> In file included from mm/kfence/core.c:26:
> arch/arm64/include/asm/kfence.h:17:2: error: implicit declaration of function
> 'set_memory_valid' [-Werror,-Wimplicit-function-declaration]
>
> Include the correct header again.
>
> Fixes: 9e18ec3cfabd ("set_memory: allow querying whether set_direct_map_*()
> is actually enabled")
> Fixes: 204555ff8bd6 ("arm64, kfence: enable KFENCE for ARM64")
> Signed-off-by: Arnd Bergmann
Acked-by: Catalin Marinas
(it should go via the mm tree with the other kfence patches)
[PATCH 5.4 86/86] tcp: fix TCP_USER_TIMEOUT with zero window
From: Enke Chen
commit 9d9b1ee0b2d1c9e02b2338c4a4b0a062d2d3edac upstream.
The TCP session does not terminate with TCP_USER_TIMEOUT when data
remain untransmitted due to zero window.
The number of unanswered zero-window probes (tcp_probes_out) is
reset to zero with incoming acks irrespective of the window size,
as described in tcp_probe_timer():
RFC 1122 4.2.2.17 requires the sender to stay open indefinitely
as long as the receiver continues to respond probes. We support
this by default and reset icsk_probes_out with incoming ACKs.
This counter, however, is the wrong one to be used in calculating the
duration that the window remains closed and data remain untransmitted.
Thanks to Jonathan Maxwell for diagnosing the
actual issue.
In this patch a new timestamp is introduced for the socket in order to
track the elapsed time for the zero-window probes that have not been
answered with any non-zero window ack.
Fixes: 9721e709fa68 ("tcp: simplify window probe aborting on USER_TIMEOUT")
Reported-by: William McCall
Co-developed-by: Neal Cardwell
Signed-off-by: Neal Cardwell
Signed-off-by: Enke Chen
Reviewed-by: Yuchung Cheng
Reviewed-by: Eric Dumazet
Link: https://lore.kernel.org/r/20210115223058.GA39267@localhost.localdomain
Signed-off-by: Jakub Kicinski
Signed-off-by: Greg Kroah-Hartman
---
include/net/inet_connection_sock.h |3 +++
net/ipv4/inet_connection_sock.c|1 +
net/ipv4/tcp.c |1 +
net/ipv4/tcp_input.c |1 +
net/ipv4/tcp_output.c |1 +
net/ipv4/tcp_timer.c | 14 +++---
6 files changed, 14 insertions(+), 7 deletions(-)
--- a/include/net/inet_connection_sock.h
+++ b/include/net/inet_connection_sock.h
@@ -83,6 +83,8 @@ struct inet_connection_sock_af_ops {
* @icsk_ext_hdr_len: Network protocol overhead (IP/IPv6 options)
* @icsk_ack: Delayed ACK control data
* @icsk_mtup;MTU probing control data
+ * @icsk_probes_tstamp:Probe timestamp (cleared by non-zero window ack)
+ * @icsk_user_timeout:TCP_USER_TIMEOUT value
*/
struct inet_connection_sock {
/* inet_sock has to be the first member! */
@@ -133,6 +135,7 @@ struct inet_connection_sock {
u32 probe_timestamp;
} icsk_mtup;
+ u32 icsk_probes_tstamp;
u32 icsk_user_timeout;
u64 icsk_ca_priv[104 / sizeof(u64)];
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -840,6 +840,7 @@ struct sock *inet_csk_clone_lock(const s
newicsk->icsk_retransmits = 0;
newicsk->icsk_backoff = 0;
newicsk->icsk_probes_out = 0;
+ newicsk->icsk_probes_tstamp = 0;
/* Deinitialize accept_queue to trap illegal accesses. */
memset(&newicsk->icsk_accept_queue, 0,
sizeof(newicsk->icsk_accept_queue));
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2627,6 +2627,7 @@ int tcp_disconnect(struct sock *sk, int
icsk->icsk_backoff = 0;
tp->snd_cwnd = 2;
icsk->icsk_probes_out = 0;
+ icsk->icsk_probes_tstamp = 0;
icsk->icsk_rto = TCP_TIMEOUT_INIT;
tp->snd_ssthresh = TCP_INFINITE_SSTHRESH;
tp->snd_cwnd = TCP_INIT_CWND;
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -3286,6 +3286,7 @@ static void tcp_ack_probe(struct sock *s
return;
if (!after(TCP_SKB_CB(head)->end_seq, tcp_wnd_end(tp))) {
icsk->icsk_backoff = 0;
+ icsk->icsk_probes_tstamp = 0;
inet_csk_clear_xmit_timer(sk, ICSK_TIME_PROBE0);
/* Socket must be waked up by subsequent tcp_data_snd_check().
* This function is not for random using!
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -3835,6 +3835,7 @@ void tcp_send_probe0(struct sock *sk)
/* Cancel probe timer, if it is not required. */
icsk->icsk_probes_out = 0;
icsk->icsk_backoff = 0;
+ icsk->icsk_probes_tstamp = 0;
return;
}
--- a/net/ipv4/tcp_timer.c
+++ b/net/ipv4/tcp_timer.c
@@ -344,6 +344,7 @@ static void tcp_probe_timer(struct sock
if (tp->packets_out || !skb) {
icsk->icsk_probes_out = 0;
+ icsk->icsk_probes_tstamp = 0;
return;
}
@@ -355,13 +356,12 @@ static void tcp_probe_timer(struct sock
* corresponding system limit. We also implement similar policy when
* we use RTO to probe window in tcp_retransmit_timer().
*/
- if (icsk->icsk_user_timeout) {
- u32 elapsed = tcp_model_timeout(sk, icsk->icsk_probes_out,
- tcp_probe0_base(sk));
-
- if (elapsed >= icsk->icsk_user_timeout)
- goto abort;
- }
+ if (!i
