- Linux-stable-mirror - lists.linaro.org

FAILED: patch "[PATCH] ice: fix lost multicast packets in promisc mode" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. Possible dependencies: 43fbca02c2dd ("ice: fix lost multicast packets in promisc mode") abddafd4585c ("ice: Fix clearing of promisc mode with bridge over bond") 1273f89578f2 ("ice: Fix broken IFF_ALLMULTI handling") 1babaf77f49d ("ice: Advertise 802.1ad VLAN filtering and offloads for PF netdev") c31af68a1b94 ("ice: Add outer_vlan_ops and VSI specific VLAN ops implementations") 7bd527aa174f ("ice: Adjust naming for inner VLAN operations") 2bfefa2dab6b ("ice: Use the proto argument for VLAN ops") a19d7f7f0122 ("ice: Refactor vf->port_vlan_info to use ice_vlan") fb05ba1257d7 ("ice: Introduce ice_vlan struct") bc42afa95487 ("ice: Add new VSI VLAN ops") 3e0b59714bd4 ("ice: Add helper function for adding VLAN 0") daf4dd16438b ("ice: Refactor spoofcheck configuration functions") c1e5da5dd465 ("ice: improve switchdev's slow-path") c36a2b971627 ("ice: replay advanced rules after reset") 3a7496234d17 ("ice: implement basic E822 PTP support") b2ee72565cd0 ("ice: introduce ice_ptp_init_phc function") 39b2810642e8 ("ice: use 'int err' instead of 'int status' in ice_ptp_hw.c") 78267d0c9cab ("ice: introduce ice_base_incval function") 4809671015a1 ("ice: Fix E810 PTP reset flow") c14846914ed6 ("ice: Propagate error codes") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 43fbca02c2ddc39ff5879b6f3a4a097b1ba02098 Mon Sep 17 00:00:00 2001 From: Jesse Brandeburg <jesse.brandeburg(a)intel.com> Date: Mon, 6 Feb 2023 15:54:36 -0800 Subject: [PATCH] ice: fix lost multicast packets in promisc mode There was a problem reported to us where the addition of a VF with an IPv6 address ending with a particular sequence would cause the parent device on the PF to no longer be able to respond to neighbor discovery packets. In this case, we had an ovs-bridge device living on top of a VLAN, which was on top of a PF, and it would not be able to talk anymore (the neighbor entry would expire and couldn't be restored). The root cause of the issue is that if the PF is asked to be in IFF_PROMISC mode (promiscuous mode) and it had an ipv6 address that needed the 33:33:ff:00:00:04 multicast address to work, then when the VF was added with the need for the same multicast address, the VF would steal all the traffic destined for that address. The ice driver didn't auto-subscribe a request of IFF_PROMISC to the "multicast replication from other port's traffic" meaning that it won't get for instance, packets with an exact destination in the VF, as above. The VF's IPv6 address, which adds a "perfect filter" for 33:33:ff:00:00:04, results in no packets for that multicast address making it to the PF (which is in promisc but NOT "multicast replication"). The fix is to enable "multicast promiscuous" whenever the driver is asked to enable IFF_PROMISC, and make sure to disable it when appropriate. Fixes: e94d44786693 ("ice: Implement filter sync, NDO operations and bump version") Signed-off-by: Jesse Brandeburg <jesse.brandeburg(a)intel.com> Tested-by: Rafal Romanowski <rafal.romanowski(a)intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen(a)intel.com> diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c index b288a01a321a..8ec24f6cf6be 100644 --- a/drivers/net/ethernet/intel/ice/ice_main.c +++ b/drivers/net/ethernet/intel/ice/ice_main.c @@ -275,6 +275,8 @@ static int ice_set_promisc(struct ice_vsi *vsi, u8 promisc_m) if (status && status != -EEXIST) return status; + netdev_dbg(vsi->netdev, "set promisc filter bits for VSI %i: 0x%x\n", + vsi->vsi_num, promisc_m); return 0; } @@ -300,6 +302,8 @@ static int ice_clear_promisc(struct ice_vsi *vsi, u8 promisc_m) promisc_m, 0); } + netdev_dbg(vsi->netdev, "clear promisc filter bits for VSI %i: 0x%x\n", + vsi->vsi_num, promisc_m); return status; } @@ -414,6 +418,16 @@ static int ice_vsi_sync_fltr(struct ice_vsi *vsi) } err = 0; vlan_ops->dis_rx_filtering(vsi); + + /* promiscuous mode implies allmulticast so + * that VSIs that are in promiscuous mode are + * subscribed to multicast packets coming to + * the port + */ + err = ice_set_promisc(vsi, + ICE_MCAST_PROMISC_BITS); + if (err) + goto out_promisc; } } else { /* Clear Rx filter to remove traffic from wire */ @@ -430,6 +444,18 @@ static int ice_vsi_sync_fltr(struct ice_vsi *vsi) NETIF_F_HW_VLAN_CTAG_FILTER) vlan_ops->ena_rx_filtering(vsi); } + + /* disable allmulti here, but only if allmulti is not + * still enabled for the netdev + */ + if (!(vsi->current_netdev_flags & IFF_ALLMULTI)) { + err = ice_clear_promisc(vsi, + ICE_MCAST_PROMISC_BITS); + if (err) { + netdev_err(netdev, "Error %d clearing multicast promiscuous on VSI %i\n", + err, vsi->vsi_num); + } + } } } goto exit;

2 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] ice: fix lost multicast packets in promisc mode" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. Possible dependencies: 43fbca02c2dd ("ice: fix lost multicast packets in promisc mode") abddafd4585c ("ice: Fix clearing of promisc mode with bridge over bond") 1273f89578f2 ("ice: Fix broken IFF_ALLMULTI handling") 1babaf77f49d ("ice: Advertise 802.1ad VLAN filtering and offloads for PF netdev") c31af68a1b94 ("ice: Add outer_vlan_ops and VSI specific VLAN ops implementations") 7bd527aa174f ("ice: Adjust naming for inner VLAN operations") 2bfefa2dab6b ("ice: Use the proto argument for VLAN ops") a19d7f7f0122 ("ice: Refactor vf->port_vlan_info to use ice_vlan") fb05ba1257d7 ("ice: Introduce ice_vlan struct") bc42afa95487 ("ice: Add new VSI VLAN ops") 3e0b59714bd4 ("ice: Add helper function for adding VLAN 0") daf4dd16438b ("ice: Refactor spoofcheck configuration functions") c1e5da5dd465 ("ice: improve switchdev's slow-path") c36a2b971627 ("ice: replay advanced rules after reset") 3a7496234d17 ("ice: implement basic E822 PTP support") b2ee72565cd0 ("ice: introduce ice_ptp_init_phc function") 39b2810642e8 ("ice: use 'int err' instead of 'int status' in ice_ptp_hw.c") 78267d0c9cab ("ice: introduce ice_base_incval function") 4809671015a1 ("ice: Fix E810 PTP reset flow") c14846914ed6 ("ice: Propagate error codes") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 43fbca02c2ddc39ff5879b6f3a4a097b1ba02098 Mon Sep 17 00:00:00 2001 From: Jesse Brandeburg <jesse.brandeburg(a)intel.com> Date: Mon, 6 Feb 2023 15:54:36 -0800 Subject: [PATCH] ice: fix lost multicast packets in promisc mode There was a problem reported to us where the addition of a VF with an IPv6 address ending with a particular sequence would cause the parent device on the PF to no longer be able to respond to neighbor discovery packets. In this case, we had an ovs-bridge device living on top of a VLAN, which was on top of a PF, and it would not be able to talk anymore (the neighbor entry would expire and couldn't be restored). The root cause of the issue is that if the PF is asked to be in IFF_PROMISC mode (promiscuous mode) and it had an ipv6 address that needed the 33:33:ff:00:00:04 multicast address to work, then when the VF was added with the need for the same multicast address, the VF would steal all the traffic destined for that address. The ice driver didn't auto-subscribe a request of IFF_PROMISC to the "multicast replication from other port's traffic" meaning that it won't get for instance, packets with an exact destination in the VF, as above. The VF's IPv6 address, which adds a "perfect filter" for 33:33:ff:00:00:04, results in no packets for that multicast address making it to the PF (which is in promisc but NOT "multicast replication"). The fix is to enable "multicast promiscuous" whenever the driver is asked to enable IFF_PROMISC, and make sure to disable it when appropriate. Fixes: e94d44786693 ("ice: Implement filter sync, NDO operations and bump version") Signed-off-by: Jesse Brandeburg <jesse.brandeburg(a)intel.com> Tested-by: Rafal Romanowski <rafal.romanowski(a)intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen(a)intel.com> diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c index b288a01a321a..8ec24f6cf6be 100644 --- a/drivers/net/ethernet/intel/ice/ice_main.c +++ b/drivers/net/ethernet/intel/ice/ice_main.c @@ -275,6 +275,8 @@ static int ice_set_promisc(struct ice_vsi *vsi, u8 promisc_m) if (status && status != -EEXIST) return status; + netdev_dbg(vsi->netdev, "set promisc filter bits for VSI %i: 0x%x\n", + vsi->vsi_num, promisc_m); return 0; } @@ -300,6 +302,8 @@ static int ice_clear_promisc(struct ice_vsi *vsi, u8 promisc_m) promisc_m, 0); } + netdev_dbg(vsi->netdev, "clear promisc filter bits for VSI %i: 0x%x\n", + vsi->vsi_num, promisc_m); return status; } @@ -414,6 +418,16 @@ static int ice_vsi_sync_fltr(struct ice_vsi *vsi) } err = 0; vlan_ops->dis_rx_filtering(vsi); + + /* promiscuous mode implies allmulticast so + * that VSIs that are in promiscuous mode are + * subscribed to multicast packets coming to + * the port + */ + err = ice_set_promisc(vsi, + ICE_MCAST_PROMISC_BITS); + if (err) + goto out_promisc; } } else { /* Clear Rx filter to remove traffic from wire */ @@ -430,6 +444,18 @@ static int ice_vsi_sync_fltr(struct ice_vsi *vsi) NETIF_F_HW_VLAN_CTAG_FILTER) vlan_ops->ena_rx_filtering(vsi); } + + /* disable allmulti here, but only if allmulti is not + * still enabled for the netdev + */ + if (!(vsi->current_netdev_flags & IFF_ALLMULTI)) { + err = ice_clear_promisc(vsi, + ICE_MCAST_PROMISC_BITS); + if (err) { + netdev_err(netdev, "Error %d clearing multicast promiscuous on VSI %i\n", + err, vsi->vsi_num); + } + } } } goto exit;

2 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] ice: fix lost multicast packets in promisc mode" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. Possible dependencies: 43fbca02c2dd ("ice: fix lost multicast packets in promisc mode") abddafd4585c ("ice: Fix clearing of promisc mode with bridge over bond") 1273f89578f2 ("ice: Fix broken IFF_ALLMULTI handling") 1babaf77f49d ("ice: Advertise 802.1ad VLAN filtering and offloads for PF netdev") c31af68a1b94 ("ice: Add outer_vlan_ops and VSI specific VLAN ops implementations") 7bd527aa174f ("ice: Adjust naming for inner VLAN operations") 2bfefa2dab6b ("ice: Use the proto argument for VLAN ops") a19d7f7f0122 ("ice: Refactor vf->port_vlan_info to use ice_vlan") fb05ba1257d7 ("ice: Introduce ice_vlan struct") bc42afa95487 ("ice: Add new VSI VLAN ops") 3e0b59714bd4 ("ice: Add helper function for adding VLAN 0") daf4dd16438b ("ice: Refactor spoofcheck configuration functions") c1e5da5dd465 ("ice: improve switchdev's slow-path") c36a2b971627 ("ice: replay advanced rules after reset") 3a7496234d17 ("ice: implement basic E822 PTP support") b2ee72565cd0 ("ice: introduce ice_ptp_init_phc function") 39b2810642e8 ("ice: use 'int err' instead of 'int status' in ice_ptp_hw.c") 78267d0c9cab ("ice: introduce ice_base_incval function") 4809671015a1 ("ice: Fix E810 PTP reset flow") c14846914ed6 ("ice: Propagate error codes") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 43fbca02c2ddc39ff5879b6f3a4a097b1ba02098 Mon Sep 17 00:00:00 2001 From: Jesse Brandeburg <jesse.brandeburg(a)intel.com> Date: Mon, 6 Feb 2023 15:54:36 -0800 Subject: [PATCH] ice: fix lost multicast packets in promisc mode There was a problem reported to us where the addition of a VF with an IPv6 address ending with a particular sequence would cause the parent device on the PF to no longer be able to respond to neighbor discovery packets. In this case, we had an ovs-bridge device living on top of a VLAN, which was on top of a PF, and it would not be able to talk anymore (the neighbor entry would expire and couldn't be restored). The root cause of the issue is that if the PF is asked to be in IFF_PROMISC mode (promiscuous mode) and it had an ipv6 address that needed the 33:33:ff:00:00:04 multicast address to work, then when the VF was added with the need for the same multicast address, the VF would steal all the traffic destined for that address. The ice driver didn't auto-subscribe a request of IFF_PROMISC to the "multicast replication from other port's traffic" meaning that it won't get for instance, packets with an exact destination in the VF, as above. The VF's IPv6 address, which adds a "perfect filter" for 33:33:ff:00:00:04, results in no packets for that multicast address making it to the PF (which is in promisc but NOT "multicast replication"). The fix is to enable "multicast promiscuous" whenever the driver is asked to enable IFF_PROMISC, and make sure to disable it when appropriate. Fixes: e94d44786693 ("ice: Implement filter sync, NDO operations and bump version") Signed-off-by: Jesse Brandeburg <jesse.brandeburg(a)intel.com> Tested-by: Rafal Romanowski <rafal.romanowski(a)intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen(a)intel.com> diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c index b288a01a321a..8ec24f6cf6be 100644 --- a/drivers/net/ethernet/intel/ice/ice_main.c +++ b/drivers/net/ethernet/intel/ice/ice_main.c @@ -275,6 +275,8 @@ static int ice_set_promisc(struct ice_vsi *vsi, u8 promisc_m) if (status && status != -EEXIST) return status; + netdev_dbg(vsi->netdev, "set promisc filter bits for VSI %i: 0x%x\n", + vsi->vsi_num, promisc_m); return 0; } @@ -300,6 +302,8 @@ static int ice_clear_promisc(struct ice_vsi *vsi, u8 promisc_m) promisc_m, 0); } + netdev_dbg(vsi->netdev, "clear promisc filter bits for VSI %i: 0x%x\n", + vsi->vsi_num, promisc_m); return status; } @@ -414,6 +418,16 @@ static int ice_vsi_sync_fltr(struct ice_vsi *vsi) } err = 0; vlan_ops->dis_rx_filtering(vsi); + + /* promiscuous mode implies allmulticast so + * that VSIs that are in promiscuous mode are + * subscribed to multicast packets coming to + * the port + */ + err = ice_set_promisc(vsi, + ICE_MCAST_PROMISC_BITS); + if (err) + goto out_promisc; } } else { /* Clear Rx filter to remove traffic from wire */ @@ -430,6 +444,18 @@ static int ice_vsi_sync_fltr(struct ice_vsi *vsi) NETIF_F_HW_VLAN_CTAG_FILTER) vlan_ops->ena_rx_filtering(vsi); } + + /* disable allmulti here, but only if allmulti is not + * still enabled for the netdev + */ + if (!(vsi->current_netdev_flags & IFF_ALLMULTI)) { + err = ice_clear_promisc(vsi, + ICE_MCAST_PROMISC_BITS); + if (err) { + netdev_err(netdev, "Error %d clearing multicast promiscuous on VSI %i\n", + err, vsi->vsi_num); + } + } } } goto exit;

2 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] ice: fix lost multicast packets in promisc mode" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. Possible dependencies: 43fbca02c2dd ("ice: fix lost multicast packets in promisc mode") abddafd4585c ("ice: Fix clearing of promisc mode with bridge over bond") 1273f89578f2 ("ice: Fix broken IFF_ALLMULTI handling") 1babaf77f49d ("ice: Advertise 802.1ad VLAN filtering and offloads for PF netdev") c31af68a1b94 ("ice: Add outer_vlan_ops and VSI specific VLAN ops implementations") 7bd527aa174f ("ice: Adjust naming for inner VLAN operations") 2bfefa2dab6b ("ice: Use the proto argument for VLAN ops") a19d7f7f0122 ("ice: Refactor vf->port_vlan_info to use ice_vlan") fb05ba1257d7 ("ice: Introduce ice_vlan struct") bc42afa95487 ("ice: Add new VSI VLAN ops") 3e0b59714bd4 ("ice: Add helper function for adding VLAN 0") daf4dd16438b ("ice: Refactor spoofcheck configuration functions") c1e5da5dd465 ("ice: improve switchdev's slow-path") c36a2b971627 ("ice: replay advanced rules after reset") 3a7496234d17 ("ice: implement basic E822 PTP support") b2ee72565cd0 ("ice: introduce ice_ptp_init_phc function") 39b2810642e8 ("ice: use 'int err' instead of 'int status' in ice_ptp_hw.c") 78267d0c9cab ("ice: introduce ice_base_incval function") 4809671015a1 ("ice: Fix E810 PTP reset flow") c14846914ed6 ("ice: Propagate error codes") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 43fbca02c2ddc39ff5879b6f3a4a097b1ba02098 Mon Sep 17 00:00:00 2001 From: Jesse Brandeburg <jesse.brandeburg(a)intel.com> Date: Mon, 6 Feb 2023 15:54:36 -0800 Subject: [PATCH] ice: fix lost multicast packets in promisc mode There was a problem reported to us where the addition of a VF with an IPv6 address ending with a particular sequence would cause the parent device on the PF to no longer be able to respond to neighbor discovery packets. In this case, we had an ovs-bridge device living on top of a VLAN, which was on top of a PF, and it would not be able to talk anymore (the neighbor entry would expire and couldn't be restored). The root cause of the issue is that if the PF is asked to be in IFF_PROMISC mode (promiscuous mode) and it had an ipv6 address that needed the 33:33:ff:00:00:04 multicast address to work, then when the VF was added with the need for the same multicast address, the VF would steal all the traffic destined for that address. The ice driver didn't auto-subscribe a request of IFF_PROMISC to the "multicast replication from other port's traffic" meaning that it won't get for instance, packets with an exact destination in the VF, as above. The VF's IPv6 address, which adds a "perfect filter" for 33:33:ff:00:00:04, results in no packets for that multicast address making it to the PF (which is in promisc but NOT "multicast replication"). The fix is to enable "multicast promiscuous" whenever the driver is asked to enable IFF_PROMISC, and make sure to disable it when appropriate. Fixes: e94d44786693 ("ice: Implement filter sync, NDO operations and bump version") Signed-off-by: Jesse Brandeburg <jesse.brandeburg(a)intel.com> Tested-by: Rafal Romanowski <rafal.romanowski(a)intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen(a)intel.com> diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c index b288a01a321a..8ec24f6cf6be 100644 --- a/drivers/net/ethernet/intel/ice/ice_main.c +++ b/drivers/net/ethernet/intel/ice/ice_main.c @@ -275,6 +275,8 @@ static int ice_set_promisc(struct ice_vsi *vsi, u8 promisc_m) if (status && status != -EEXIST) return status; + netdev_dbg(vsi->netdev, "set promisc filter bits for VSI %i: 0x%x\n", + vsi->vsi_num, promisc_m); return 0; } @@ -300,6 +302,8 @@ static int ice_clear_promisc(struct ice_vsi *vsi, u8 promisc_m) promisc_m, 0); } + netdev_dbg(vsi->netdev, "clear promisc filter bits for VSI %i: 0x%x\n", + vsi->vsi_num, promisc_m); return status; } @@ -414,6 +418,16 @@ static int ice_vsi_sync_fltr(struct ice_vsi *vsi) } err = 0; vlan_ops->dis_rx_filtering(vsi); + + /* promiscuous mode implies allmulticast so + * that VSIs that are in promiscuous mode are + * subscribed to multicast packets coming to + * the port + */ + err = ice_set_promisc(vsi, + ICE_MCAST_PROMISC_BITS); + if (err) + goto out_promisc; } } else { /* Clear Rx filter to remove traffic from wire */ @@ -430,6 +444,18 @@ static int ice_vsi_sync_fltr(struct ice_vsi *vsi) NETIF_F_HW_VLAN_CTAG_FILTER) vlan_ops->ena_rx_filtering(vsi); } + + /* disable allmulti here, but only if allmulti is not + * still enabled for the netdev + */ + if (!(vsi->current_netdev_flags & IFF_ALLMULTI)) { + err = ice_clear_promisc(vsi, + ICE_MCAST_PROMISC_BITS); + if (err) { + netdev_err(netdev, "Error %d clearing multicast promiscuous on VSI %i\n", + err, vsi->vsi_num); + } + } } } goto exit;

2 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] drm/i915/gen11: Wa_1408615072/Wa_1407596294 should be on GT" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. Possible dependencies: d5a1224aa68c ("drm/i915/gen11: Wa_1408615072/Wa_1407596294 should be on GT list") 67b858dd8993 ("drm/i915/gen11: Moving WAs to icl_gt_workarounds_init()") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From d5a1224aa68c8b124a4c5c390186e571815ed390 Mon Sep 17 00:00:00 2001 From: Matt Roper <matthew.d.roper(a)intel.com> Date: Wed, 1 Feb 2023 14:28:29 -0800 Subject: [PATCH] drm/i915/gen11: Wa_1408615072/Wa_1407596294 should be on GT list The UNSLICE_UNIT_LEVEL_CLKGATE register programmed by this workaround has 'BUS' style reset, indicating that it does not lose its value on engine resets. Furthermore, this register is part of the GT forcewake domain rather than the RENDER domain, so it should not be impacted by RCS engine resets. As such, we should implement this on the GT workaround list rather than an engine list. Bspec: 19219 Fixes: 3551ff928744 ("drm/i915/gen11: Moving WAs to rcs_engine_wa_init()") Signed-off-by: Matt Roper <matthew.d.roper(a)intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa(a)intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230201222831.608281-2-matth… (cherry picked from commit 5f21dc07b52eb54a908e66f5d6e05a87bcb5b049) Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c index 949c19339015..a0740308555d 100644 --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c @@ -1355,6 +1355,13 @@ icl_gt_workarounds_init(struct intel_gt *gt, struct i915_wa_list *wal) GAMT_CHKN_BIT_REG, GAMT_CHKN_DISABLE_L3_COH_PIPE); + /* + * Wa_1408615072:icl,ehl (vsunit) + * Wa_1407596294:icl,ehl (hsunit) + */ + wa_write_or(wal, UNSLICE_UNIT_LEVEL_CLKGATE, + VSUNIT_CLKGATE_DIS | HSUNIT_CLKGATE_DIS); + /* Wa_1407352427:icl,ehl */ wa_write_or(wal, UNSLICE_UNIT_LEVEL_CLKGATE2, PSDUNIT_CLKGATE_DIS); @@ -2539,13 +2546,6 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, struct i915_wa_list *wal) wa_masked_en(wal, GEN9_CSFE_CHICKEN1_RCS, GEN11_ENABLE_32_PLANE_MODE); - /* - * Wa_1408615072:icl,ehl (vsunit) - * Wa_1407596294:icl,ehl (hsunit) - */ - wa_write_or(wal, UNSLICE_UNIT_LEVEL_CLKGATE, - VSUNIT_CLKGATE_DIS | HSUNIT_CLKGATE_DIS); - /* * Wa_1408767742:icl[a2..forever],ehl[all] * Wa_1605460711:icl[a0..c0]

2 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] drm/i915/gen11: Wa_1408615072/Wa_1407596294 should be on GT" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. Possible dependencies: d5a1224aa68c ("drm/i915/gen11: Wa_1408615072/Wa_1407596294 should be on GT list") 67b858dd8993 ("drm/i915/gen11: Moving WAs to icl_gt_workarounds_init()") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From d5a1224aa68c8b124a4c5c390186e571815ed390 Mon Sep 17 00:00:00 2001 From: Matt Roper <matthew.d.roper(a)intel.com> Date: Wed, 1 Feb 2023 14:28:29 -0800 Subject: [PATCH] drm/i915/gen11: Wa_1408615072/Wa_1407596294 should be on GT list The UNSLICE_UNIT_LEVEL_CLKGATE register programmed by this workaround has 'BUS' style reset, indicating that it does not lose its value on engine resets. Furthermore, this register is part of the GT forcewake domain rather than the RENDER domain, so it should not be impacted by RCS engine resets. As such, we should implement this on the GT workaround list rather than an engine list. Bspec: 19219 Fixes: 3551ff928744 ("drm/i915/gen11: Moving WAs to rcs_engine_wa_init()") Signed-off-by: Matt Roper <matthew.d.roper(a)intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa(a)intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230201222831.608281-2-matth… (cherry picked from commit 5f21dc07b52eb54a908e66f5d6e05a87bcb5b049) Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c index 949c19339015..a0740308555d 100644 --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c @@ -1355,6 +1355,13 @@ icl_gt_workarounds_init(struct intel_gt *gt, struct i915_wa_list *wal) GAMT_CHKN_BIT_REG, GAMT_CHKN_DISABLE_L3_COH_PIPE); + /* + * Wa_1408615072:icl,ehl (vsunit) + * Wa_1407596294:icl,ehl (hsunit) + */ + wa_write_or(wal, UNSLICE_UNIT_LEVEL_CLKGATE, + VSUNIT_CLKGATE_DIS | HSUNIT_CLKGATE_DIS); + /* Wa_1407352427:icl,ehl */ wa_write_or(wal, UNSLICE_UNIT_LEVEL_CLKGATE2, PSDUNIT_CLKGATE_DIS); @@ -2539,13 +2546,6 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, struct i915_wa_list *wal) wa_masked_en(wal, GEN9_CSFE_CHICKEN1_RCS, GEN11_ENABLE_32_PLANE_MODE); - /* - * Wa_1408615072:icl,ehl (vsunit) - * Wa_1407596294:icl,ehl (hsunit) - */ - wa_write_or(wal, UNSLICE_UNIT_LEVEL_CLKGATE, - VSUNIT_CLKGATE_DIS | HSUNIT_CLKGATE_DIS); - /* * Wa_1408767742:icl[a2..forever],ehl[all] * Wa_1605460711:icl[a0..c0]

2 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] drm/vc4: Fix YUV plane handling when planes are in different" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. Possible dependencies: 6b77b16de75a ("drm/vc4: Fix YUV plane handling when planes are in different buffers") 8c30eecc6769 ("drm/gem: rename struct drm_gem_dma_object.{paddr => dma_addr}") 4a83c26a1d87 ("drm/gem: rename GEM CMA helpers to GEM DMA helpers") 6bcfe8eaeef0 ("drm/fb: rename FB CMA helpers to FB DMA helpers") 5e8bf00ea915 ("drm/fb: remove unused includes of drm_fb_cma_helper.h") a4d847df8b44 ("drm/fsl-dcu: Use drm_plane_helper_destroy()") 254e5e8829a9 ("drm: Remove unnecessary include statements of drm_plane_helper.h") 382fc1f68132 ("drm/atomic-helper: Move DRM_PLANE_HELPER_NO_SCALING to atomic helpers") b7345c9799da ("drm/vc4: txp: Protect device resources") e23a5e14aa27 ("Backmerge tag 'v5.19-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into drm-next") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 6b77b16de75a6efc0870b1fa467209387cbee8f3 Mon Sep 17 00:00:00 2001 From: Dave Stevenson <dave.stevenson(a)raspberrypi.com> Date: Fri, 27 Jan 2023 16:57:08 +0100 Subject: [PATCH] drm/vc4: Fix YUV plane handling when planes are in different buffers YUV images can either be presented as one allocation with offsets for the different planes, or multiple allocations with 0 offsets. The driver only ever calls drm_fb_[dma|cma]_get_gem_obj with plane index 0, therefore any application using the second approach was incorrectly rendered. Correctly determine the address for each plane, removing the assumption that the base address is the same for each. Fixes: fc04023fafec ("drm/vc4: Add support for YUV planes.") Signed-off-by: Dave Stevenson <dave.stevenson(a)raspberrypi.com> Signed-off-by: Maxime Ripard <maxime(a)cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20230127155708.454704-1-maxim… diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c index 8b92a45a3c89..bd5acc4a8687 100644 --- a/drivers/gpu/drm/vc4/vc4_plane.c +++ b/drivers/gpu/drm/vc4/vc4_plane.c @@ -340,7 +340,7 @@ static int vc4_plane_setup_clipping_and_scaling(struct drm_plane_state *state) { struct vc4_plane_state *vc4_state = to_vc4_plane_state(state); struct drm_framebuffer *fb = state->fb; - struct drm_gem_dma_object *bo = drm_fb_dma_get_gem_obj(fb, 0); + struct drm_gem_dma_object *bo; int num_planes = fb->format->num_planes; struct drm_crtc_state *crtc_state; u32 h_subsample = fb->format->hsub; @@ -359,8 +359,10 @@ static int vc4_plane_setup_clipping_and_scaling(struct drm_plane_state *state) if (ret) return ret; - for (i = 0; i < num_planes; i++) + for (i = 0; i < num_planes; i++) { + bo = drm_fb_dma_get_gem_obj(fb, i); vc4_state->offsets[i] = bo->dma_addr + fb->offsets[i]; + } /* * We don't support subpixel source positioning for scaling,

2 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] drm/vc4: Fix YUV plane handling when planes are in different" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. Possible dependencies: 6b77b16de75a ("drm/vc4: Fix YUV plane handling when planes are in different buffers") 8c30eecc6769 ("drm/gem: rename struct drm_gem_dma_object.{paddr => dma_addr}") 4a83c26a1d87 ("drm/gem: rename GEM CMA helpers to GEM DMA helpers") 6bcfe8eaeef0 ("drm/fb: rename FB CMA helpers to FB DMA helpers") 5e8bf00ea915 ("drm/fb: remove unused includes of drm_fb_cma_helper.h") a4d847df8b44 ("drm/fsl-dcu: Use drm_plane_helper_destroy()") 254e5e8829a9 ("drm: Remove unnecessary include statements of drm_plane_helper.h") 382fc1f68132 ("drm/atomic-helper: Move DRM_PLANE_HELPER_NO_SCALING to atomic helpers") b7345c9799da ("drm/vc4: txp: Protect device resources") e23a5e14aa27 ("Backmerge tag 'v5.19-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into drm-next") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 6b77b16de75a6efc0870b1fa467209387cbee8f3 Mon Sep 17 00:00:00 2001 From: Dave Stevenson <dave.stevenson(a)raspberrypi.com> Date: Fri, 27 Jan 2023 16:57:08 +0100 Subject: [PATCH] drm/vc4: Fix YUV plane handling when planes are in different buffers YUV images can either be presented as one allocation with offsets for the different planes, or multiple allocations with 0 offsets. The driver only ever calls drm_fb_[dma|cma]_get_gem_obj with plane index 0, therefore any application using the second approach was incorrectly rendered. Correctly determine the address for each plane, removing the assumption that the base address is the same for each. Fixes: fc04023fafec ("drm/vc4: Add support for YUV planes.") Signed-off-by: Dave Stevenson <dave.stevenson(a)raspberrypi.com> Signed-off-by: Maxime Ripard <maxime(a)cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20230127155708.454704-1-maxim… diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c index 8b92a45a3c89..bd5acc4a8687 100644 --- a/drivers/gpu/drm/vc4/vc4_plane.c +++ b/drivers/gpu/drm/vc4/vc4_plane.c @@ -340,7 +340,7 @@ static int vc4_plane_setup_clipping_and_scaling(struct drm_plane_state *state) { struct vc4_plane_state *vc4_state = to_vc4_plane_state(state); struct drm_framebuffer *fb = state->fb; - struct drm_gem_dma_object *bo = drm_fb_dma_get_gem_obj(fb, 0); + struct drm_gem_dma_object *bo; int num_planes = fb->format->num_planes; struct drm_crtc_state *crtc_state; u32 h_subsample = fb->format->hsub; @@ -359,8 +359,10 @@ static int vc4_plane_setup_clipping_and_scaling(struct drm_plane_state *state) if (ret) return ret; - for (i = 0; i < num_planes; i++) + for (i = 0; i < num_planes; i++) { + bo = drm_fb_dma_get_gem_obj(fb, i); vc4_state->offsets[i] = bo->dma_addr + fb->offsets[i]; + } /* * We don't support subpixel source positioning for scaling,

2 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] drm/vc4: Fix YUV plane handling when planes are in different" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. Possible dependencies: 6b77b16de75a ("drm/vc4: Fix YUV plane handling when planes are in different buffers") 8c30eecc6769 ("drm/gem: rename struct drm_gem_dma_object.{paddr => dma_addr}") 4a83c26a1d87 ("drm/gem: rename GEM CMA helpers to GEM DMA helpers") 6bcfe8eaeef0 ("drm/fb: rename FB CMA helpers to FB DMA helpers") 5e8bf00ea915 ("drm/fb: remove unused includes of drm_fb_cma_helper.h") a4d847df8b44 ("drm/fsl-dcu: Use drm_plane_helper_destroy()") 254e5e8829a9 ("drm: Remove unnecessary include statements of drm_plane_helper.h") 382fc1f68132 ("drm/atomic-helper: Move DRM_PLANE_HELPER_NO_SCALING to atomic helpers") b7345c9799da ("drm/vc4: txp: Protect device resources") e23a5e14aa27 ("Backmerge tag 'v5.19-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into drm-next") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 6b77b16de75a6efc0870b1fa467209387cbee8f3 Mon Sep 17 00:00:00 2001 From: Dave Stevenson <dave.stevenson(a)raspberrypi.com> Date: Fri, 27 Jan 2023 16:57:08 +0100 Subject: [PATCH] drm/vc4: Fix YUV plane handling when planes are in different buffers YUV images can either be presented as one allocation with offsets for the different planes, or multiple allocations with 0 offsets. The driver only ever calls drm_fb_[dma|cma]_get_gem_obj with plane index 0, therefore any application using the second approach was incorrectly rendered. Correctly determine the address for each plane, removing the assumption that the base address is the same for each. Fixes: fc04023fafec ("drm/vc4: Add support for YUV planes.") Signed-off-by: Dave Stevenson <dave.stevenson(a)raspberrypi.com> Signed-off-by: Maxime Ripard <maxime(a)cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20230127155708.454704-1-maxim… diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c index 8b92a45a3c89..bd5acc4a8687 100644 --- a/drivers/gpu/drm/vc4/vc4_plane.c +++ b/drivers/gpu/drm/vc4/vc4_plane.c @@ -340,7 +340,7 @@ static int vc4_plane_setup_clipping_and_scaling(struct drm_plane_state *state) { struct vc4_plane_state *vc4_state = to_vc4_plane_state(state); struct drm_framebuffer *fb = state->fb; - struct drm_gem_dma_object *bo = drm_fb_dma_get_gem_obj(fb, 0); + struct drm_gem_dma_object *bo; int num_planes = fb->format->num_planes; struct drm_crtc_state *crtc_state; u32 h_subsample = fb->format->hsub; @@ -359,8 +359,10 @@ static int vc4_plane_setup_clipping_and_scaling(struct drm_plane_state *state) if (ret) return ret; - for (i = 0; i < num_planes; i++) + for (i = 0; i < num_planes; i++) { + bo = drm_fb_dma_get_gem_obj(fb, i); vc4_state->offsets[i] = bo->dma_addr + fb->offsets[i]; + } /* * We don't support subpixel source positioning for scaling,

2 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] drm/vc4: Fix YUV plane handling when planes are in different" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. Possible dependencies: 6b77b16de75a ("drm/vc4: Fix YUV plane handling when planes are in different buffers") 8c30eecc6769 ("drm/gem: rename struct drm_gem_dma_object.{paddr => dma_addr}") 4a83c26a1d87 ("drm/gem: rename GEM CMA helpers to GEM DMA helpers") 6bcfe8eaeef0 ("drm/fb: rename FB CMA helpers to FB DMA helpers") 5e8bf00ea915 ("drm/fb: remove unused includes of drm_fb_cma_helper.h") a4d847df8b44 ("drm/fsl-dcu: Use drm_plane_helper_destroy()") 254e5e8829a9 ("drm: Remove unnecessary include statements of drm_plane_helper.h") 382fc1f68132 ("drm/atomic-helper: Move DRM_PLANE_HELPER_NO_SCALING to atomic helpers") b7345c9799da ("drm/vc4: txp: Protect device resources") e23a5e14aa27 ("Backmerge tag 'v5.19-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into drm-next") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 6b77b16de75a6efc0870b1fa467209387cbee8f3 Mon Sep 17 00:00:00 2001 From: Dave Stevenson <dave.stevenson(a)raspberrypi.com> Date: Fri, 27 Jan 2023 16:57:08 +0100 Subject: [PATCH] drm/vc4: Fix YUV plane handling when planes are in different buffers YUV images can either be presented as one allocation with offsets for the different planes, or multiple allocations with 0 offsets. The driver only ever calls drm_fb_[dma|cma]_get_gem_obj with plane index 0, therefore any application using the second approach was incorrectly rendered. Correctly determine the address for each plane, removing the assumption that the base address is the same for each. Fixes: fc04023fafec ("drm/vc4: Add support for YUV planes.") Signed-off-by: Dave Stevenson <dave.stevenson(a)raspberrypi.com> Signed-off-by: Maxime Ripard <maxime(a)cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20230127155708.454704-1-maxim… diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c index 8b92a45a3c89..bd5acc4a8687 100644 --- a/drivers/gpu/drm/vc4/vc4_plane.c +++ b/drivers/gpu/drm/vc4/vc4_plane.c @@ -340,7 +340,7 @@ static int vc4_plane_setup_clipping_and_scaling(struct drm_plane_state *state) { struct vc4_plane_state *vc4_state = to_vc4_plane_state(state); struct drm_framebuffer *fb = state->fb; - struct drm_gem_dma_object *bo = drm_fb_dma_get_gem_obj(fb, 0); + struct drm_gem_dma_object *bo; int num_planes = fb->format->num_planes; struct drm_crtc_state *crtc_state; u32 h_subsample = fb->format->hsub; @@ -359,8 +359,10 @@ static int vc4_plane_setup_clipping_and_scaling(struct drm_plane_state *state) if (ret) return ret; - for (i = 0; i < num_planes; i++) + for (i = 0; i < num_planes; i++) { + bo = drm_fb_dma_get_gem_obj(fb, i); vc4_state->offsets[i] = bo->dma_addr + fb->offsets[i]; + } /* * We don't support subpixel source positioning for scaling,

2 years, 8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror