5.15.7-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainerPATCH 141/207 drm/vc4: kms: Add missing drm_crtc_commit_put
In reply to Greg Kroah-HartmanFrom: Maxime Ripard <[email protected]>
commit 049cfff8d53a30cae3349ff71a4c01b7d9981bc2 upstream.
Commit 9ec03d7f1ed3 ("drm/vc4: kms: Wait on previous FIFO users before a commit") introduced a global state for the HVS, with each FIFO storing the current CRTC commit so that we can properly synchronize commits.
However, the refcounting was off and we thus ended up leaking the drm_crtc_commit structure every commit. Add a drm_crtc_commit_put to prevent the leakage.
--- drivers/gpu/drm/vc4/vc4_kms.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
drivers/gpu/drm/vc4/vc4_kms.c +8 -1
@@ -361,6 +361,7 @@ static void vc4_atomic_commit_tail(strucstruct vc4_crtc_state *vc4_crtc_state =to_vc4_crtc_state (old_crtc_state);unsigned int channel = vc4_crtc_state->assigned_channel; +struct drm_crtc_commit *commit;int ret;if (channel ==VC4_HVS_CHANNEL_DISABLED )
@@ -369,9 +370,15 @@ static void vc4_atomic_commit_tail(strucif (!old_hvs_state->fifo_state[channel].in_use)continue ; - ret =drm_crtc_commit_wait (old_hvs_state->fifo_state[channel].pending_commit); + commit = old_hvs_state->fifo_state[channel].pending_commit; +if (!commit) +continue ; + + ret =drm_crtc_commit_wait (commit);if (ret)drm_err (dev,"Timed out waiting for commit\n" ); + +drm_crtc_commit_put (commit); }if (vc4->hvs->hvs5)
Greg Kroah-Hartman
maintainerPATCH 142/207 drm/vc4: kms: Clear the HVS FIFO commit pointer once done
In reply to Greg Kroah-HartmanFrom: Maxime Ripard <[email protected]>
commit d134c5ff71c7f2320fc7997f2fbbdedf0c76889a upstream.
Commit 9ec03d7f1ed3 ("drm/vc4: kms: Wait on previous FIFO users before a commit") introduced a wait on the previous commit done on a given HVS FIFO.
However, we never cleared that pointer once done. Since drm_crtc_commit_put can free the drm_crtc_commit structure directly if we were the last user, this means that it can lead to a use-after free if we were to duplicate the state, and that stale pointer would even be copied to the new state.
Set the pointer to NULL once we're done with the wait so that we don't carry over a pointer to a free'd structure.
--- drivers/gpu/drm/vc4/vc4_kms.c | 1 + 1 file changed, 1 insertion(+)
drivers/gpu/drm/vc4/vc4_kms.c +1 -0
@@ -379,6 +379,7 @@ static void vc4_atomic_commit_tail(strucdrm_err (dev,"Timed out waiting for commit\n" );drm_crtc_commit_put (commit); + old_hvs_state->fifo_state[channel].pending_commit =NULL ; }if (vc4->hvs->hvs5)
Greg Kroah-Hartman
maintainerPATCH 143/207 drm/vc4: kms: Dont duplicate pending commit
In reply to Greg Kroah-HartmanFrom: Maxime Ripard <[email protected]>
commit d354699e2292c60f25496d3c31ce4e7b1563b899 upstream.
Our HVS global state, when duplicated, will also copy the pointer to the drm_crtc_commit (and increase the reference count) for each FIFO if the pointer is not NULL.
However, our atomic_setup function will overwrite that pointer without putting the reference back leading to a memory leak.
Since the commit is only relevant during the atomic commit process, it doesn't make sense to duplicate the reference to the commit anyway. Let's remove it.
--- drivers/gpu/drm/vc4/vc4_kms.c | 6 ------ 1 file changed, 6 deletions(-)
drivers/gpu/drm/vc4/vc4_kms.c +0 -6
@@ -676,12 +676,6 @@ vc4_hvs_channels_duplicate_state(structfor (i =0 ; i <HVS_NUM_CHANNELS ; i++) { state->fifo_state[i].in_use = old_state->fifo_state[i].in_use; - -if (!old_state->fifo_state[i].pending_commit) -continue ; - - state->fifo_state[i].pending_commit = -drm_crtc_commit_get (old_state->fifo_state[i].pending_commit); }return &state->base;
Greg Kroah-Hartman
maintainerPATCH 144/207 drm/vc4: kms: Fix previous HVS commit wait
In reply to Greg Kroah-HartmanFrom: Maxime Ripard <[email protected]>
commit 6052a3110be208e547a4a8aeb184446199a16e8a upstream.
Our current code is supposed to serialise the commits by waiting for all the drm_crtc_commits associated to the previous HVS state.
However, assuming we have two CRTCs running and being configured and we configure each one alternately, we end up in a situation where we're not waiting at all.
Indeed, starting with a state (state 0) where both CRTCs are running, and doing a commit (state 1) on the first CRTC (CRTC 0), we'll associate its commit to its assigned FIFO in vc4_hvs_state.
If we get a new commit (state 2), this time affecting the second CRTC (CRTC 1), the DRM core will allow both commits to execute in parallel (assuming they don't have any share resources).
Our code in vc4_atomic_commit_tail is supposed to make sure we only get one commit at a time and serialised by order of submission. It does so by using for_each_old_crtc_in_state, making sure that the CRTC has a FIFO assigned, is used, and has a commit pending. If it does, then we'll wait for the commit before going forward.
During the transition from state 0 to state 1, as our old CRTC state we get the CRTC 0 state 0, its commit, we wait for it, everything works fine.
During the transition from state 1 to state 2 though, the use of for_each_old_crtc_in_state is wrong. Indeed, while the code assumes it's returning the state of the CRTC in the old state (so CRTC 0 state 1), it actually returns the old state of the CRTC affected by the current commit, so CRTC 0 state 0 since it wasn't part of state 1.
Due to this, if we alternate between the configuration of CRTC 0 and CRTC 1, we never actually wait for anything since we should be waiting on the other every time, but it never is affected by the previous commit.
Change the logic to, at every commit, look at every FIFO in the previous HVS state, and if it's in use and has a commit associated to it, wait for that commit.
--- drivers/gpu/drm/vc4/vc4_kms.c | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-)
drivers/gpu/drm/vc4/vc4_kms.c +2 -8
@@ -337,10 +337,10 @@ static void vc4_atomic_commit_tail(strucstruct drm_device *dev = state->dev;struct vc4_dev *vc4 =to_vc4_dev (dev);struct vc4_hvs *hvs = vc4->hvs; -struct drm_crtc_state *old_crtc_state;struct drm_crtc_state *new_crtc_state;struct drm_crtc *crtc;struct vc4_hvs_state *old_hvs_state; +unsigned int channel;int i;for_each_new_crtc_in_state (state, crtc, new_crtc_state, i) {
@@ -357,16 +357,10 @@ static void vc4_atomic_commit_tail(strucif (IS_ERR (old_hvs_state))return ; -for_each_old_crtc_in_state (state, crtc, old_crtc_state, i) { -struct vc4_crtc_state *vc4_crtc_state = -to_vc4_crtc_state (old_crtc_state); -unsigned int channel = vc4_crtc_state->assigned_channel; +for (channel =0 ; channel <HVS_NUM_CHANNELS ; channel++) {struct drm_crtc_commit *commit;int ret; -if (channel ==VC4_HVS_CHANNEL_DISABLED ) -continue ; -if (!old_hvs_state->fifo_state[channel].in_use)continue ;
Greg Kroah-Hartman
maintainerPATCH 145/207 atlantic: Increase delay for fw transactions
In reply to Greg Kroah-HartmanFrom: Dmitry Bogdanov <[email protected]>
commit aa1dcb5646fdf34a15763facf4bf5e482a2814ca upstream.
The max waiting period (of 1 ms) while reading the data from FW shared buffer is too small for certain types of data (e.g., stats). There's a chance that FW could be updating buffer at the same time and driver would be unsuccessful in reading data. Firmware manual recommends to have 1 sec timeout to fix this issue.
--- drivers/net/ethernet/aquantia/atlantic/hw_atl2/hw_atl2_utils_fw.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/net/ethernet/aquantia/atlantic/hw_atl2/hw_atl2_utils_fw.c +5 -2
@@ -84,7 +84,7 @@ static int hw_atl2_shared_buffer_read_blif (cnt >AQ_A2_FW_READ_TRY_MAX )return -ETIME ;if (tid1.transaction_cnt_a != tid1.transaction_cnt_b) -udelay (1 ); +mdelay (1 ); }while (tid1.transaction_cnt_a != tid1.transaction_cnt_b);hw_atl2_mif_shared_buf_read (self, offset, (u32 *)data, dwords);
@@ -339,8 +339,11 @@ static int aq_a2_fw_update_stats(struct {struct hw_atl2_priv *priv = (struct hw_atl2_priv *)self->priv;struct statistics_s stats; +int err; -hw_atl2_shared_buffer_read_safe (self, stats, &stats); + err =hw_atl2_shared_buffer_read_safe (self, stats, &stats); +if (err) +return err;#define AQ_SDELTA (_N_, _F_) (self->curr_stats._N_ += \ stats.msm._F_ - priv->last_stats.msm._F_)
Greg Kroah-Hartman
maintainerPATCH 146/207 atlatnic: enable Nbase-t speeds with base-t
In reply to Greg Kroah-HartmanFrom: Nikita Danilov <[email protected]>
commit aa685acd98eae25d5351e30288d6cfb65b9c80a5 upstream.
When 2.5G is advertised, N-Base should be advertised against the T-base caps. N5G is out of use in baseline code and driver should treat both 5G and N5G (and also 2.5G and N2.5G) equally from user perspective.
--- drivers/net/ethernet/aquantia/atlantic/aq_common.h | 25 ++++------ drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils_fw2x.c | 3 - drivers/net/ethernet/aquantia/atlantic/hw_atl2/hw_atl2_utils_fw.c | 4 - 3 files changed, 13 insertions(+), 19 deletions(-)
drivers/net/ethernet/aquantia/atlantic/aq_common.h +12 -13
@@ -53,20 +53,19 @@#define AQ_NIC_RATE_10G BIT(0)#define AQ_NIC_RATE_5G BIT(1) -#define AQ_NIC_RATE_5GSR BIT(2) -#define AQ_NIC_RATE_2G5 BIT(3) -#define AQ_NIC_RATE_1G BIT(4) -#define AQ_NIC_RATE_100M BIT(5) -#define AQ_NIC_RATE_10M BIT(6) -#define AQ_NIC_RATE_1G_HALF BIT(7) -#define AQ_NIC_RATE_100M_HALF BIT(8) -#define AQ_NIC_RATE_10M_HALF BIT(9) +#define AQ_NIC_RATE_2G5 BIT(2) +#define AQ_NIC_RATE_1G BIT(3) +#define AQ_NIC_RATE_100M BIT(4) +#define AQ_NIC_RATE_10M BIT(5) +#define AQ_NIC_RATE_1G_HALF BIT(6) +#define AQ_NIC_RATE_100M_HALF BIT(7) +#define AQ_NIC_RATE_10M_HALF BIT(8) -#define AQ_NIC_RATE_EEE_10G BIT(10) -#define AQ_NIC_RATE_EEE_5G BIT(11) -#define AQ_NIC_RATE_EEE_2G5 BIT(12) -#define AQ_NIC_RATE_EEE_1G BIT(13) -#define AQ_NIC_RATE_EEE_100M BIT(14) +#define AQ_NIC_RATE_EEE_10G BIT(9) +#define AQ_NIC_RATE_EEE_5G BIT(10) +#define AQ_NIC_RATE_EEE_2G5 BIT(11) +#define AQ_NIC_RATE_EEE_1G BIT(12) +#define AQ_NIC_RATE_EEE_100M BIT(13)#define AQ_NIC_RATE_EEE_MSK (AQ_NIC_RATE_EEE_10G |\ AQ_NIC_RATE_EEE_5G |\ AQ_NIC_RATE_EEE_2G5 |\
drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils_fw2x.c +0 -3
@@ -132,9 +132,6 @@ static enum hw_atl_fw2x_rate link_speed_if (speed &AQ_NIC_RATE_5G ) rate |=FW2X_RATE_5G ; -if (speed &AQ_NIC_RATE_5GSR ) - rate |=FW2X_RATE_5G ; -if (speed &AQ_NIC_RATE_2G5 ) rate |=FW2X_RATE_2G5 ;
drivers/net/ethernet/aquantia/atlantic/hw_atl2/hw_atl2_utils_fw.c +1 -3
@@ -154,7 +154,7 @@ static void a2_link_speed_mask2fw(u32 sp { link_options->rate_10G = !!(speed &AQ_NIC_RATE_10G ); link_options->rate_5G = !!(speed &AQ_NIC_RATE_5G ); - link_options->rate_N5G = !!(speed &AQ_NIC_RATE_5GSR ); + link_options->rate_N5G = link_options->rate_5G; link_options->rate_2P5G = !!(speed &AQ_NIC_RATE_2G5 ); link_options->rate_N2P5G = link_options->rate_2P5G; link_options->rate_1G = !!(speed &AQ_NIC_RATE_1G );
@@ -192,8 +192,6 @@ static u32 a2_fw_lkp_to_mask(struct lkp_ rate |=AQ_NIC_RATE_10G ;if (lkp_link_caps->rate_5G) rate |=AQ_NIC_RATE_5G ; -if (lkp_link_caps->rate_N5G) - rate |=AQ_NIC_RATE_5GSR ;if (lkp_link_caps->rate_2P5G) rate |=AQ_NIC_RATE_2G5 ;if (lkp_link_caps->rate_1G)
Greg Kroah-Hartman
maintainerPATCH 147/207 atlantic: Fix to display FW bundle version instead of FW mac version.
In reply to Greg Kroah-HartmanFrom: Sameer Saurabh <[email protected]>
commit 2465c802232bc8d2b5bd83b55b08d05c11808704 upstream.
The correct way to reflect firmware version is to use bundle version. Hence populating the same instead of MAC fw version.
--- drivers/net/ethernet/aquantia/atlantic/hw_atl2/hw_atl2_utils_fw.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/net/ethernet/aquantia/atlantic/hw_atl2/hw_atl2_utils_fw.c +3 -3
@@ -500,9 +500,9 @@ u32 hw_atl2_utils_get_fw_version(structhw_atl2_shared_buffer_read_safe (self, version, &version);/* A2 FW version is stored in reverse order */ -return version.mac.major <<24 | - version.mac.minor <<16 | - version.mac.build; +return version.bundle.major <<24 | + version.bundle.minor <<16 | + version.bundle.build; } int hw_atl2_utils_get_action_resolve_table_caps(struct aq_hw_s *self,
Greg Kroah-Hartman
maintainerPATCH 148/207 atlantic: Add missing DIDs and fix 115c.
In reply to Greg Kroah-HartmanFrom: Nikita Danilov <[email protected]>
commit 413d5e09caa5a11da9c7d72401ba0588466a04c0 upstream.
At the late production stages new dev ids were introduced. These are now in production, so its important for the driver to recognize these. And also fix the board caps for AQC115C adapter.
--- drivers/net/ethernet/aquantia/atlantic/aq_common.h | 2 + drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c | 7 +++++- drivers/net/ethernet/aquantia/atlantic/hw_atl2/hw_atl2.c | 17 +++++++++++++++ drivers/net/ethernet/aquantia/atlantic/hw_atl2/hw_atl2.h | 2 + 4 files changed, 27 insertions(+), 1 deletion(-)
drivers/net/ethernet/aquantia/atlantic/aq_common.h +2 -0
@@ -40,10 +40,12 @@#define AQ_DEVICE_ID_AQC113DEV 0x00C0#define AQ_DEVICE_ID_AQC113CS 0x94C0 +#define AQ_DEVICE_ID_AQC113CA 0x34C0#define AQ_DEVICE_ID_AQC114CS 0x93C0#define AQ_DEVICE_ID_AQC113 0x04C0#define AQ_DEVICE_ID_AQC113C 0x14C0#define AQ_DEVICE_ID_AQC115C 0x12C0 +#define AQ_DEVICE_ID_AQC116C 0x11C0#define HW_ATL_NIC_NAME "Marvell (aQuantia) AQtion 10Gbit Network Adapter"
drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c +6 -1
@@ -49,6 +49,8 @@ static const struct pci_device_id aq_pci { PCI_VDEVICE(AQUANTIA, AQ_DEVICE_ID_AQC113), }, { PCI_VDEVICE(AQUANTIA, AQ_DEVICE_ID_AQC113C), }, { PCI_VDEVICE(AQUANTIA, AQ_DEVICE_ID_AQC115C), }, + { PCI_VDEVICE(AQUANTIA, AQ_DEVICE_ID_AQC113CA), }, + { PCI_VDEVICE(AQUANTIA, AQ_DEVICE_ID_AQC116C), }, {} };
@@ -85,7 +87,10 @@ static const struct aq_board_revision_s { AQ_DEVICE_ID_AQC113CS, AQ_HWREV_ANY, &hw_atl2_ops, &hw_atl2_caps_aqc113, }, { AQ_DEVICE_ID_AQC114CS, AQ_HWREV_ANY, &hw_atl2_ops, &hw_atl2_caps_aqc113, }, { AQ_DEVICE_ID_AQC113C, AQ_HWREV_ANY, &hw_atl2_ops, &hw_atl2_caps_aqc113, }, - { AQ_DEVICE_ID_AQC115C, AQ_HWREV_ANY, &hw_atl2_ops, &hw_atl2_caps_aqc113, }, + { AQ_DEVICE_ID_AQC115C, AQ_HWREV_ANY, &hw_atl2_ops, &hw_atl2_caps_aqc115c, }, + { AQ_DEVICE_ID_AQC113CA, AQ_HWREV_ANY, &hw_atl2_ops, &hw_atl2_caps_aqc113, }, + { AQ_DEVICE_ID_AQC116C, AQ_HWREV_ANY, &hw_atl2_ops, &hw_atl2_caps_aqc116c, }, + };MODULE_DEVICE_TABLE (pci, aq_pci_tbl);
drivers/net/ethernet/aquantia/atlantic/hw_atl2/hw_atl2.c +17 -0
@@ -72,6 +72,23 @@ const struct aq_hw_caps_s hw_atl2_caps_a AQ_NIC_RATE_10M_HALF, }; +const struct aq_hw_caps_s hw_atl2_caps_aqc115c = { +DEFAULT_BOARD_BASIC_CAPABILITIES , + .media_type =AQ_HW_MEDIA_TYPE_TP , + .link_speed_msk =AQ_NIC_RATE_2G5 | +AQ_NIC_RATE_1G | +AQ_NIC_RATE_100M | +AQ_NIC_RATE_10M , +}; + +const struct aq_hw_caps_s hw_atl2_caps_aqc116c = { +DEFAULT_BOARD_BASIC_CAPABILITIES , + .media_type =AQ_HW_MEDIA_TYPE_TP , + .link_speed_msk =AQ_NIC_RATE_1G | +AQ_NIC_RATE_100M | +AQ_NIC_RATE_10M , +}; +static u32 hw_atl2_sem_act_rslvr_get (struct aq_hw_s *self) {return hw_atl_reg_glb_cpu_sem_get (self,HW_ATL2_FW_SM_ACT_RSLVR );
drivers/net/ethernet/aquantia/atlantic/hw_atl2/hw_atl2.h +2 -0
@@ -9,6 +9,8 @@#include "aq_common.h" extern const struct aq_hw_caps_s hw_atl2_caps_aqc113; +extern const struct aq_hw_caps_s hw_atl2_caps_aqc115c; +extern const struct aq_hw_caps_s hw_atl2_caps_aqc116c;extern const struct aq_hw_ops hw_atl2_ops;#endif /* HW_ATL2_H */
Greg Kroah-Hartman
maintainerPATCH 149/207 Remove Half duplex mode speed capabilities.
In reply to Greg Kroah-HartmanFrom: Sameer Saurabh <[email protected]>
commit 03fa512189eb9b55ded5f3e81ad638315555b340 upstream.
Since Half Duplex mode has been deprecated by the firmware, driver should not advertise Half Duplex speed in ethtool support link speed values.
--- drivers/net/ethernet/aquantia/atlantic/hw_atl2/hw_atl2.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)
drivers/net/ethernet/aquantia/atlantic/hw_atl2/hw_atl2.c +1 -4
@@ -65,11 +65,8 @@ const struct aq_hw_caps_s hw_atl2_caps_aAQ_NIC_RATE_5G |AQ_NIC_RATE_2G5 |AQ_NIC_RATE_1G | -AQ_NIC_RATE_1G_HALF |AQ_NIC_RATE_100M | -AQ_NIC_RATE_100M_HALF | -AQ_NIC_RATE_10M | - AQ_NIC_RATE_10M_HALF, + AQ_NIC_RATE_10M, }; const struct aq_hw_caps_s hw_atl2_caps_aqc115c = {
Greg Kroah-Hartman
maintainerPATCH 150/207 atlantic: Fix statistics logic for production hardware
In reply to Greg Kroah-HartmanFrom: Dmitry Bogdanov <[email protected]>
commit 2087ced0fc3a6d45203925750a2b1bcd5402e639 upstream.
B0 is the main and widespread device revision of atlantic2 HW. In the current state, driver will incorrectly fetch the statistics for this revision.
--- drivers/net/ethernet/aquantia/atlantic/aq_hw.h | 2 drivers/net/ethernet/aquantia/atlantic/aq_nic.c | 10 drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c | 15 + drivers/net/ethernet/aquantia/atlantic/hw_atl2/hw_atl2_utils.h | 38 +++ drivers/net/ethernet/aquantia/atlantic/hw_atl2/hw_atl2_utils_fw.c | 101 ++++++++-- 5 files changed, 139 insertions(+), 27 deletions(-)
drivers/net/ethernet/aquantia/atlantic/aq_hw.h +2 -0
@@ -80,6 +80,8 @@ struct aq_hw_link_status_s { };struct aq_stats_s { +u64 brc; +u64 btc;u64 uprc;u64 mprc;u64 bprc;
drivers/net/ethernet/aquantia/atlantic/aq_nic.c +8 -2
@@ -903,8 +903,14 @@ u64 *aq_nic_get_stats(struct aq_nic_s *s data[++i] = stats->mbtc; data[++i] = stats->bbrc; data[++i] = stats->bbtc; - data[++i] = stats->ubrc + stats->mbrc + stats->bbrc; - data[++i] = stats->ubtc + stats->mbtc + stats->bbtc; +if (stats->brc) + data[++i] = stats->brc; +else + data[++i] = stats->ubrc + stats->mbrc + stats->bbrc; +if (stats->btc) + data[++i] = stats->btc; +else + data[++i] = stats->ubtc + stats->mbtc + stats->bbtc; data[++i] = stats->dma_pkt_rc; data[++i] = stats->dma_pkt_tc; data[++i] = stats->dma_oct_rc;
drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c +13 -2
@@ -867,12 +867,20 @@ static int hw_atl_fw1x_deinit(struct aq_int hw_atl_utils_update_stats (struct aq_hw_s *self) {struct aq_stats_s *cs = &self->curr_stats; +struct aq_stats_s curr_stats = *cs;struct hw_atl_utils_mbox mbox; +bool corrupted_stats = false;hw_atl_utils_mpi_read_stats (self, &mbox); -#define AQ_SDELTA (_N_) (self->curr_stats._N_ += \ - mbox.stats._N_ - self->last_stats._N_) +#define AQ_SDELTA (_N_) \ +do { \ + if (!corrupted_stats && \ + ((s64)(mbox.stats._N_ - self->last_stats._N_)) >= 0) \ + curr_stats._N_ += mbox.stats._N_ - self->last_stats._N_; \ + else \ + corrupted_stats = true; \ +} while (0)if (self->aq_link_status.mbps) {AQ_SDELTA (uprc);
@@ -892,6 +900,9 @@ int hw_atl_utils_update_stats(struct aq_AQ_SDELTA (bbrc);AQ_SDELTA (bbtc);AQ_SDELTA (dpc); + +if (!corrupted_stats) + *cs = curr_stats; }#undef AQ_SDELTA
drivers/net/ethernet/aquantia/atlantic/hw_atl2/hw_atl2_utils.h +34 -4
@@ -239,7 +239,8 @@ struct version_s {u8 minor;u16 build; } phy; -u32 rsvd; + u32 drv_iface_ver:4; + u32 rsvd:28; };struct link_status_s {
@@ -424,7 +425,7 @@ struct cable_diag_status_s {u16 rsvd2; }; -struct statistics_s { +struct statistics_a0_s {struct {u32 link_up;u32 link_down;
@@ -457,6 +458,33 @@ struct statistics_s {u32 reserve_fw_gap; }; +struct __packed statistics_b0_s { +u64 rx_good_octets; +u64 rx_pause_frames; +u64 rx_good_frames; +u64 rx_errors; +u64 rx_unicast_frames; +u64 rx_multicast_frames; +u64 rx_broadcast_frames; + +u64 tx_good_octets; +u64 tx_pause_frames; +u64 tx_good_frames; +u64 tx_errors; +u64 tx_unicast_frames; +u64 tx_multicast_frames; +u64 tx_broadcast_frames; + +u32 main_loop_cycles; +}; + +struct __packed statistics_s { +union __packed { +struct statistics_a0_s a0; +struct statistics_b0_s b0; + }; +}; +struct filter_caps_s {u8 l2_filters_base_index:6 ;u8 flexible_filter_mask:2 ;
@@ -545,7 +573,7 @@ struct management_status_s {u32 rsvd5; }; -struct fw_interface_out { +struct __packed fw_interface_out {struct transaction_counter_s transaction_id;struct version_s version;struct link_status_s link_status;
@@ -569,7 +597,6 @@ struct fw_interface_out {struct core_dump_s core_dump;u32 rsvd11;struct statistics_s stats; -u32 rsvd12;struct filter_caps_s filter_caps;struct device_caps_s device_caps;u32 rsvd13;
@@ -592,6 +619,9 @@ struct fw_interface_out {#define AQ_HOST_MODE_LOW_POWER 3U#define AQ_HOST_MODE_SHUTDOWN 4U +#define AQ_A2_FW_INTERFACE_A0 0 +#define AQ_A2_FW_INTERFACE_B0 1 +int hw_atl2_utils_initfw (struct aq_hw_s *self,const struct aq_fw_ops **fw_ops);int hw_atl2_utils_soft_reset (struct aq_hw_s *self);
drivers/net/ethernet/aquantia/atlantic/hw_atl2/hw_atl2_utils_fw.c +82 -19
117 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 151/207 atlantic: Remove warn trace message.
In reply to Greg Kroah-HartmanFrom: Sameer Saurabh <[email protected]>
commit 060a0fb721ec5bbe02ae322e434ec87dc25ed6e9 upstream.
Remove the warn trace message - it's not a correct check here, because the function can still be called on the device in DOWN state
--- drivers/net/ethernet/aquantia/atlantic/aq_vec.c | 3 --- 1 file changed, 3 deletions(-)
drivers/net/ethernet/aquantia/atlantic/aq_vec.c +0 -3
@@ -362,9 +362,6 @@ unsigned int aq_vec_get_sw_stats(struct {unsigned int count; -WARN_ONCE (!aq_vec_is_valid_tc (self, tc), -"Invalid tc %u (#rx=%u, #tx=%u)\n" , - tc, self->rx_rings, self->tx_rings);if (!aq_vec_is_valid_tc (self, tc))return 0 ;
Greg Kroah-Hartman
maintainerPATCH 152/207 KVM: x86/mmu: Skip tlb flush if it has been done in zap_gfn_range()
In reply to Greg Kroah-HartmanFrom: Hou Wenlong <[email protected]>
[ Upstream commit c7785d85b6c6cc9f3d0f1a8cab128f4062b30abb ]
If the parameter flush is set, zap_gfn_range() would flush remote tlb when yield, then tlb flush is not needed outside. So use the return value of zap_gfn_range() directly instead of OR on it in kvm_unmap_gfn_range() and kvm_tdp_mmu_unmap_gfn_range().
Message-Id: <5e16546e228877a4d974f8c0e448a93d52c7a5a9.1637140154.git.houwenlong93@linux.alibaba.com>
--- arch/x86/kvm/mmu/mmu.c | 2 +- arch/x86/kvm/mmu/tdp_mmu.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-)
arch/x86/kvm/mmu/mmu.c +1 -1
@@ -1592,7 +1592,7 @@ bool kvm_unmap_gfn_range(struct kvm *kvm, struct kvm_gfn_range *range) flush =kvm_handle_gfn_range (kvm, range, kvm_unmap_rmapp);if (is_tdp_mmu_enabled (kvm)) - flush |=kvm_tdp_mmu_unmap_gfn_range (kvm, range, flush); + flush =kvm_tdp_mmu_unmap_gfn_range (kvm, range, flush);return flush; }
arch/x86/kvm/mmu/tdp_mmu.c +2 -2
@@ -1081,8 +1081,8 @@ bool kvm_tdp_mmu_unmap_gfn_range(struct kvm *kvm, struct kvm_gfn_range *range,struct kvm_mmu_page *root;for_each_tdp_mmu_root (kvm, root, range->slot->as_id) - flush |=zap_gfn_range (kvm, root, range->start, range->end, - range->may_block, flush, false); + flush =zap_gfn_range (kvm, root, range->start, range->end, + range->may_block, flush, false);return flush; }
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 153/207 KVM: x86/mmu: Pass parameter flush as false in kvm_tdp_mmu_zap_collapsible_sptes()
In reply to Greg Kroah-HartmanFrom: Hou Wenlong <[email protected]>
[ Upstream commit 8ed716ca7dc91f058be0ba644a3048667a20db13 ]
Since tlb flush has been done for legacy MMU before kvm_tdp_mmu_zap_collapsible_sptes(), so the parameter flush should be false for kvm_tdp_mmu_zap_collapsible_sptes().
Message-Id: <21453a1d2533afb6e59fb6c729af89e771ff2e76.1637140154.git.houwenlong93@linux.alibaba.com>
--- arch/x86/kvm/mmu/mmu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/x86/kvm/mmu/mmu.c +2 -2
@@ -5855,7 +5855,7 @@ static bool kvm_mmu_zap_collapsible_spte(struct kvm *kvm,void kvm_mmu_zap_collapsible_sptes (struct kvm *kvm,const struct kvm_memory_slot *slot) { -bool flush = false; +bool flush;if (kvm_memslots_have_rmaps (kvm)) {write_lock (&kvm->mmu_lock);
@@ -5867,7 +5867,7 @@ void kvm_mmu_zap_collapsible_sptes(struct kvm *kvm,if (is_tdp_mmu_enabled (kvm)) {read_lock (&kvm->mmu_lock); - flush =kvm_tdp_mmu_zap_collapsible_sptes (kvm, slot, flush); + flush =kvm_tdp_mmu_zap_collapsible_sptes (kvm, slot, false);if (flush)kvm_arch_flush_remote_tlbs_memslot (kvm, slot);read_unlock (&kvm->mmu_lock);
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 154/207 drm/msm/devfreq: Fix OPP refcnt leak
In reply to Greg Kroah-HartmanFrom: Rob Clark <[email protected]>
[ Upstream commit 59ba1b2b4825342676300f66d785764be3fcb093 ]
--- drivers/gpu/drm/msm/msm_gpu_devfreq.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/gpu/drm/msm/msm_gpu_devfreq.c +5 -0
@@ -20,6 +20,10 @@ static int msm_devfreq_target(struct device *dev, unsigned long *freq,struct msm_gpu *gpu =dev_to_gpu (dev);struct dev_pm_opp *opp; +/* +* Note that devfreq_recommended_opp() can modify the freq +* to something that actually is in the opp table: +*/ opp =devfreq_recommended_opp (dev, freq, flags);/*
@@ -28,6 +32,7 @@ static int msm_devfreq_target(struct device *dev, unsigned long *freq,*/ if (gpu->devfreq.idle_freq) { gpu->devfreq.idle_freq = *freq; +dev_pm_opp_put (opp);return 0 ; }
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 155/207 drm/msm: Fix mmap to include VM_IO and VM_DONTDUMP
In reply to Greg Kroah-HartmanFrom: Douglas Anderson <[email protected]>
[ Upstream commit 3466d9e217b337bf473ee629c608e53f9f3ab786 ]
In commit 510410bfc034 ("drm/msm: Implement mmap as GEM object function") we switched to a new/cleaner method of doing things. That's good, but we missed a little bit.
Before that commit, we used to _first_ run through the drm_gem_mmap_obj() case where obj->funcs->mmap() was NULL. That meant that we ran:
vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP; vma->vm_page_prot = pgprot_writecombine(vm_get_page_prot(vma->vm_flags)); vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
...and _then_ we modified those mappings with our own. Now that obj->funcs->mmap() is no longer NULL we don't run the default code. It looks like the fact that the vm_flags got VM_IO / VM_DONTDUMP was important because we're now getting crashes on Chromebooks that use ARC++ while logging out. Specifically a crash that looks like this (this is on a 5.10 kernel w/ relevant backports but also seen on a 5.15 kernel):
Unable to handle kernel paging request at virtual address ffffffc008000000
Mem abort info:
ESR = 0x96000006
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000006
CM = 0, WnR = 0
swapper pgtable: 4k pages, 39-bit VAs, pgdp=000000008293d000
[ffffffc008000000] pgd=00000001002b3003, p4d=00000001002b3003,
pud=00000001002b3003, pmd=0000000000000000
Internal error: Oops: 96000006 [#1] PREEMPT SMP
[...]
CPU: 7 PID: 15734 Comm: crash_dump64 Tainted: G W 5.10.67 #1 [...]
Hardware name: Qualcomm Technologies, Inc. sc7280 IDP SKU2 platform (DT)
pstate: 80400009 (Nzcv daif +PAN -UAO -TCO BTYPE=--)
pc : __arch_copy_to_user+0xc0/0x30c
lr : copyout+0xac/0x14c
[...]
Call trace:
__arch_copy_to_user+0xc0/0x30c
copy_page_to_iter+0x1a0/0x294
process_vm_rw_core+0x240/0x408
process_vm_rw+0x110/0x16c
__arm64_sys_process_vm_readv+0x30/0x3c
el0_svc_common+0xf8/0x250
do_el0_svc+0x30/0x80
el0_svc+0x10/0x1c
el0_sync_handler+0x78/0x108
el0_sync+0x184/0x1c0
Code: f8408423 f80008c3 910020c6 36100082 (b8404423)Let's add the two flags back in.
While we're at it, the fact that we aren't running the default means that we _don't_ need to clear out VM_PFNMAP, so remove that and save an instruction.
NOTE: it was confirmed that VM_IO was the important flag to fix the problem I was seeing, but adding back VM_DONTDUMP seems like a sane thing to do so I'm doing that too.
--- drivers/gpu/drm/msm/msm_gem.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/gpu/drm/msm/msm_gem.c +1 -2
@@ -1055,8 +1055,7 @@ static int msm_gem_object_mmap(struct drm_gem_object *obj, struct vm_area_struct {struct msm_gem_object *msm_obj =to_msm_bo (obj); - vma->vm_flags &= ~VM_PFNMAP ; - vma->vm_flags |=VM_MIXEDMAP |VM_DONTEXPAND ; + vma->vm_flags |=VM_IO |VM_MIXEDMAP |VM_DONTEXPAND |VM_DONTDUMP ; vma->vm_page_prot =msm_gem_pgprot (msm_obj,vm_get_page_prot (vma->vm_flags));return 0 ;
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 156/207 drm/msm: Fix wait_fence submitqueue leak
In reply to Greg Kroah-HartmanFrom: Rob Clark <[email protected]>
[ Upstream commit ea0006d390a28012f8187717aea61498b2b341e5 ]
We weren't dropping the submitqueue reference in all paths. In particular, when the fence has already been signalled. Split out a helper to simplify handling this in the various different return paths.
--- drivers/gpu/drm/msm/msm_drv.c | 49 +++++++++++++++++++++-------------- 1 file changed, 29 insertions(+), 20 deletions(-)
drivers/gpu/drm/msm/msm_drv.c +29 -20
@@ -938,29 +938,12 @@ static int msm_ioctl_gem_info(struct drm_device *dev, void *data,return ret; } -static int msm_ioctl_wait_fence (struct drm_device *dev,void *data, -struct drm_file *file) +static int wait_fence (struct msm_gpu_submitqueue *queue,uint32_t fence_id, +ktime_t timeout) { -struct msm_drm_private *priv = dev->dev_private; -struct drm_msm_wait_fence *args = data; -ktime_t timeout =to_ktime (args->timeout); -struct msm_gpu_submitqueue *queue; -struct msm_gpu *gpu = priv->gpu;struct dma_fence *fence;int ret; -if (args->pad) { -DRM_ERROR ("invalid pad: %08x\n" , args->pad); -return -EINVAL ; - } - -if (!gpu) -return 0 ; - - queue =msm_submitqueue_get (file->driver_priv, args->queueid); -if (!queue) -return -ENOENT ; -/* * Map submitqueue scoped "seqno" (which is actually an idr key) * back to underlying dma-fence
@@ -972,7 +955,7 @@ static int msm_ioctl_wait_fence(struct drm_device *dev, void *data, ret =mutex_lock_interruptible (&queue->lock);if (ret)return ret; - fence =idr_find (&queue->fence_idr, args->fence); + fence =idr_find (&queue->fence_idr, fence_id);if (fence) fence =dma_fence_get_rcu (fence);mutex_unlock (&queue->lock);
@@ -988,6 +971,32 @@ static int msm_ioctl_wait_fence(struct drm_device *dev, void *data, }dma_fence_put (fence); + +return ret; +} + +static int msm_ioctl_wait_fence (struct drm_device *dev,void *data, +struct drm_file *file) +{ +struct msm_drm_private *priv = dev->dev_private; +struct drm_msm_wait_fence *args = data; +struct msm_gpu_submitqueue *queue; +int ret; + +if (args->pad) { +DRM_ERROR ("invalid pad: %08x\n" , args->pad); +return -EINVAL ; + } + +if (!priv->gpu) +return 0 ; + + queue =msm_submitqueue_get (file->driver_priv, args->queueid); +if (!queue) +return -ENOENT ; + + ret =wait_fence (queue, args->fence,to_ktime (args->timeout)); +msm_submitqueue_put (queue);return ret;
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 157/207 drm/msm: Restore error return on invalid fence
In reply to Greg Kroah-HartmanFrom: Rob Clark <[email protected]>
[ Upstream commit 067ecab9eef620d41040715669e5fcdc2f8ff963 ]
When converting to use an idr to map userspace fence seqno values back to a dma_fence, we lost the error return when userspace passes seqno that is larger than the last submitted fence. Restore this check.
--- drivers/gpu/drm/msm/msm_drv.c | 6 ++++++ drivers/gpu/drm/msm/msm_gem_submit.c | 1 + drivers/gpu/drm/msm/msm_gpu.h | 3 +++ 3 files changed, 10 insertions(+)
drivers/gpu/drm/msm/msm_drv.c +6 -0
@@ -944,6 +944,12 @@ static int wait_fence(struct msm_gpu_submitqueue *queue, uint32_t fence_id,struct dma_fence *fence;int ret; +if (fence_id > queue->last_fence) { +DRM_ERROR_RATELIMITED ("waiting on invalid fence: %u (of %u)\n" , + fence_id, queue->last_fence); +return -EINVAL ; + } +/* * Map submitqueue scoped "seqno" (which is actually an idr key) * back to underlying dma-fence
drivers/gpu/drm/msm/msm_gem_submit.c +1 -0
@@ -911,6 +911,7 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,drm_sched_entity_push_job (&submit->base, queue->entity); args->fence = submit->fence_id; + queue->last_fence = submit->fence_id;msm_reset_syncobjs (syncobjs_to_reset, args->nr_in_syncobjs); msm_process_post_deps(post_deps, args->nr_out_syncobjs,
drivers/gpu/drm/msm/msm_gpu.h +3 -0
@@ -352,6 +352,8 @@ static inline int msm_gpu_convert_priority(struct msm_gpu *gpu, int prio,* @ring_nr: the ringbuffer used by this submitqueue, which is determined * by the submitqueue's priority * @faults: the number of GPU hangs associated with this submitqueue +* @last_fence: the sequence number of the last allocated fence (for error +* checking) * @ctx: the per-drm_file context associated with the submitqueue (ie. * which set of pgtables do submits jobs associated with the * submitqueue use)
@@ -367,6 +369,7 @@ struct msm_gpu_submitqueue {u32 flags;u32 ring_nr;int faults; +uint32_t last_fence;struct msm_file_private *ctx;struct list_head node;struct idr fence_idr;
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 158/207 ASoC: rk817: Add module alias for rk817-codec
In reply to Greg Kroah-HartmanFrom: Nicolas Frattaroli <[email protected]>
[ Upstream commit 428ee30a05cd1362c8aa86a4c909b0d1c6bc48a4 ]
Without a module alias, autoloading the driver does not occurr when it is built as a module.
By adding a module alias, the driver now probes fine automatically and therefore analog audio output works as it should.
--- sound/soc/codecs/rk817_codec.c | 1 + 1 file changed, 1 insertion(+)
sound/soc/codecs/rk817_codec.c +1 -0
@@ -539,3 +539,4 @@ module_platform_driver(rk817_codec_driver);MODULE_DESCRIPTION ("ASoC RK817 codec driver" );MODULE_AUTHOR ("binyuan <[email protected]>" );MODULE_LICENSE ("GPL v2" ); +MODULE_ALIAS ("platform:rk817-codec" );
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 159/207 iwlwifi: Fix memory leaks in error handling path
In reply to Greg Kroah-HartmanFrom: Christophe JAILLET <[email protected]>
[ Upstream commit a571bc28326d9f3e13f5f2d9cda2883e0631b0ce ]
Should an error occur (invalid TLV len or memory allocation failure), the memory already allocated in 'reduce_power_data' should be freed before returning, otherwise it is leaking.
--- drivers/net/wireless/intel/iwlwifi/fw/uefi.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/net/wireless/intel/iwlwifi/fw/uefi.c +6 -0
@@ -86,6 +86,7 @@ static void *iwl_uefi_reduce_power_section(struct iwl_trans *trans,if (len < tlv_len) {IWL_ERR (trans,"invalid TLV len: %zd/%u\n" , len, tlv_len); +kfree (reduce_power_data); reduce_power_data =ERR_PTR (-EINVAL ); goto out; }
@@ -105,6 +106,7 @@ static void *iwl_uefi_reduce_power_section(struct iwl_trans *trans,IWL_DEBUG_FW (trans,"Couldn't allocate (more) reduce_power_data\n" ); +kfree (reduce_power_data); reduce_power_data =ERR_PTR (-ENOMEM ); goto out; }
@@ -134,6 +136,10 @@ static void *iwl_uefi_reduce_power_section(struct iwl_trans *trans, done:if (!size) {IWL_DEBUG_FW (trans,"Empty REDUCE_POWER, skipping.\n" ); +/* Better safe than sorry, but 'reduce_power_data' should +* always be NULL if !size. +*/ +kfree (reduce_power_data); reduce_power_data =ERR_PTR (-ENOENT ); goto out; }
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 160/207 KVM: X86: Fix when shadow_root_level=5 && guest root_level<4
In reply to Greg Kroah-HartmanFrom: Lai Jiangshan <[email protected]>
[ Upstream commit 12ec33a705749e18d9588b0a0e69e02821371156 ]
If the is an L1 with nNPT in 32bit, the shadow walk starts with pae_root.
Message-Id: <[email protected]>
--- arch/x86/kvm/mmu/mmu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/x86/kvm/mmu/mmu.c +2 -2
@@ -2188,10 +2188,10 @@ static void shadow_walk_init_using_root(struct kvm_shadow_walk_iterator *iterato iterator->shadow_addr = root; iterator->level = vcpu->arch.mmu->shadow_root_level; -if (iterator->level ==PT64_ROOT_4LEVEL && +if (iterator->level >=PT64_ROOT_4LEVEL && vcpu->arch.mmu->root_level <PT64_ROOT_4LEVEL && !vcpu->arch.mmu->direct_map) - --iterator->level; + iterator->level =PT32E_ROOT_LEVEL ;if (iterator->level ==PT32E_ROOT_LEVEL ) {/*
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 161/207 KVM: SEV: initialize regions_list of a mirror VM
In reply to Greg Kroah-HartmanFrom: Paolo Bonzini <[email protected]>
[ Upstream commit 2b347a387811cb4aa7bcdb96e9203c5019a6fb41 ]
This was broken before the introduction of KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM, but technically harmless because the region list was unused for a mirror VM. However, it is untidy and it now causes a NULL pointer access when attempting to move the encryption context of a mirror VM.
Message-Id: <[email protected]>
--- arch/x86/kvm/svm/sev.c | 1 + 1 file changed, 1 insertion(+)
arch/x86/kvm/svm/sev.c +1 -0
@@ -1805,6 +1805,7 @@ int svm_vm_copy_asid_from(struct kvm *kvm, unsigned int source_fd) mirror_sev->fd = source_sev.fd; mirror_sev->es_active = source_sev.es_active; mirror_sev->handle = source_sev.handle; +INIT_LIST_HEAD (&mirror_sev->regions_list);/* * Do not copy ap_jump_table. Since the mirror does not share the same * KVM contexts as the original, and they may have different
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 162/207 net/mlx5e: Fix missing IPsec statistics on uplink representor
In reply to Greg Kroah-HartmanFrom: Raed Salem <[email protected]>
[ Upstream commit 51ebf5db67f5c6aed79c05f1aa5137bdf5ca6614 ]
The cited patch added the IPsec support to uplink representor, however as uplink representors have his private statistics where IPsec stats is not part of it, that effectively makes IPsec stats hidden when uplink representor stats queried.
Resolve by adding IPsec stats to uplink representor private statistics.
--- drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c +4 -0
@@ -1070,6 +1070,10 @@ static mlx5e_stats_grp_t mlx5e_ul_rep_stats_grps[] = { &MLX5E_STATS_GRP (pme), &MLX5E_STATS_GRP (channels), &MLX5E_STATS_GRP (per_port_buff_congest), +#ifdef CONFIG_MLX5_EN_IPSEC + &MLX5E_STATS_GRP (ipsec_sw), + &MLX5E_STATS_GRP(ipsec_hw), +#endif };static unsigned int mlx5e_ul_rep_stats_grps_num (struct mlx5e_priv *priv)
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 163/207 net/mlx5: Move MODIFY_RQT command to ignore list in internal error state
In reply to Greg Kroah-HartmanFrom: Moshe Shemesh <[email protected]>
[ Upstream commit e45c0b34493c24eeeebf89f63a5293aac7728ed7 ]
When the device is in internal error state, command interface isn't accessible and the driver decides which commands to fail and which to ignore.
Move the MODIFY_RQT command to the ignore list in order to avoid the following redundant warning messages in internal error state:
mlx5_core 0000:82:00.1: mlx5e_rss_disable:419:(pid 23754): Failed to redirect RQT 0x0 to drop RQ 0xc00848: err = -5mlx5_core 0000:82:00.1: mlx5e_rx_res_channels_deactivate:598:(pid 23754): Failed to redirect direct RQT 0x1 to drop RQ 0xc00848 (channel 0): err = -5 mlx5_core 0000:82:00.1: mlx5e_rx_res_channels_deactivate:607:(pid 23754): Failed to redirect XSK RQT 0x19 to drop RQ 0xc00848 (channel 0): err = -5
--- drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/mellanox/mlx5/core/cmd.c +1 -1
@@ -336,6 +336,7 @@ static int mlx5_internal_err_ret_value(struct mlx5_core_dev *dev, u16 op,case MLX5_CMD_OP_DEALLOC_SF :case MLX5_CMD_OP_DESTROY_UCTX :case MLX5_CMD_OP_DESTROY_UMEM : +case MLX5_CMD_OP_MODIFY_RQT :return MLX5_CMD_STAT_OK ;case MLX5_CMD_OP_QUERY_HCA_CAP :
@@ -441,7 +442,6 @@ static int mlx5_internal_err_ret_value(struct mlx5_core_dev *dev, u16 op,case MLX5_CMD_OP_MODIFY_TIS :case MLX5_CMD_OP_QUERY_TIS :case MLX5_CMD_OP_CREATE_RQT : -case MLX5_CMD_OP_MODIFY_RQT :case MLX5_CMD_OP_QUERY_RQT :case MLX5_CMD_OP_CREATE_FLOW_TABLE :
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 164/207 net/mlx5: E-switch, Respect BW share of the new group
In reply to Greg Kroah-HartmanFrom: Dmytro Linkin <[email protected]>
[ Upstream commit 1e59b32e45e47c8ea5455182286ba010bfa87813 ]
To enable transmit schduler on vport FW require non-zero configuration for vport's TSAR. If vport added to the group which has configured BW share value and TX rate values of the vport are zero, then scheduler wouldn't be enabled on this vport.
Fix that by calling BW normalization if BW share of the new group is configured.
--- drivers/net/ethernet/mellanox/mlx5/core/esw/qos.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/mellanox/mlx5/core/esw/qos.c +1 -1
@@ -423,7 +423,7 @@ static int esw_qos_vport_update_group(struct mlx5_eswitch *esw,return err;/* Recalculate bw share weights of old and new groups */ -if (vport->qos.bw_share) { +if (vport->qos.bw_share || new_group->bw_share) {esw_qos_normalize_vports_min_rate (esw, curr_group, extack);esw_qos_normalize_vports_min_rate (esw, new_group, extack); }
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 165/207 net/mlx5: E-Switch, fix single FDB creation on BlueField
In reply to Greg Kroah-HartmanFrom: Mark Bloch <[email protected]>
[ Upstream commit 43a0696f11567278b9412f947e43dd7906c831a8 ]
Always use MLX5_FLOW_TABLE_OTHER_VPORT flag when creating egress ACL table for single FDB. Not doing so on BlueField will make firmware fail the command. On BlueField the E-Switch manager is the ECPF (vport 0xFFFE) which is filled in the flow table creation command but as the other_vport field wasn't set the firmware complains about a bad parameter.
This is different from a regular HCA where the E-Switch manager vport is the PF (vport 0x0). Passing MLX5_FLOW_TABLE_OTHER_VPORT will make the firmware happy both on BlueField and on regular HCAs without special condition for each.
This fixes the bellow firmware syndrome:
mlx5_cmd_check:819:(pid 571): CREATE_FLOW_TABLE(0x930) op_mod(0x0) failed, status bad parameter(0x3), syndrome (0x754a4)
--- drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c +1 -0
@@ -2471,6 +2471,7 @@ static int esw_set_master_egress_rule(struct mlx5_core_dev *master,struct mlx5_eswitch *esw = master->priv.eswitch;struct mlx5_flow_table_attr ft_attr = { .max_fte =1 , .prio =0 , .level =0 , + .flags =MLX5_FLOW_TABLE_OTHER_VPORT , };struct mlx5_flow_namespace *egress_ns;struct mlx5_flow_table *acl;
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 166/207 net/mlx5: E-Switch, Check group pointer before reading bw_share value
In reply to Greg Kroah-HartmanFrom: Dmytro Linkin <[email protected]>
[ Upstream commit 5c4e8ae7aa4875041102406801ee434e6c581aef ]
If log_esw_max_sched_depth is not supported group pointer of the vport is NULL. Hence, check the pointer before reading bw_share value.
--- drivers/net/ethernet/mellanox/mlx5/core/esw/qos.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/mellanox/mlx5/core/esw/qos.c +1 -1
@@ -130,7 +130,7 @@ static u32 esw_qos_calculate_min_rate_divider(struct mlx5_eswitch *esw,/* If vports min rate divider is 0 but their group has bw_share configured, then * need to set bw_share for vports to minimal value. */ -if (!group_level && !max_guarantee && group->bw_share) +if (!group_level && !max_guarantee && group && group->bw_share)return 1 ;return 0 ; }
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 167/207 KVM: x86/pmu: Fix reserved bits for AMD PerfEvtSeln register
In reply to Greg Kroah-HartmanFrom: Like Xu <[email protected]>
[ Upstream commit cb1d220da0faa5ca0deb93449aff953f0c2cce6d ]
If we run the following perf command in an AMD Milan guest:
perf stat \ -e cpu/event=0x1d0/ \ -e cpu/event=0x1c7/ \ -e cpu/umask=0x1f,event=0x18e/ \ -e cpu/umask=0x7,event=0x18e/ \ -e cpu/umask=0x18,event=0x18e/ \ ./workload
dmesg will report a #GP warning from an unchecked MSR access error on MSR_F15H_PERF_CTLx.
This is because according to APM (Revision: 4.03) Figure 13-7, the bits [35:32] of AMD PerfEvtSeln register is a part of the event select encoding, which extends the EVENT_SELECT field from 8 bits to 12 bits.
Opportunistically update pmu->reserved_bits for reserved bit 19.
Message-Id: <[email protected]>
--- arch/x86/kvm/svm/pmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/kvm/svm/pmu.c +1 -1
@@ -282,7 +282,7 @@ static void amd_pmu_refresh(struct kvm_vcpu *vcpu) pmu->nr_arch_gp_counters =AMD64_NUM_COUNTERS ; pmu->counter_bitmask[KVM_PMC_GP ] = ((u64 )1 <<48 ) -1 ; - pmu->reserved_bits =0xffffffff00200000ull ; + pmu->reserved_bits =0xfffffff000280000ull ; pmu->version =1 ;/* not applicable to AMD; but clean them to prevent any fall out */ pmu->counter_bitmask[KVM_PMC_FIXED ] =0 ;
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 168/207 KVM: VMX: Set failure code in prepare_vmcs02()
In reply to Greg Kroah-HartmanFrom: Dan Carpenter <[email protected]>
[ Upstream commit bfbb307c628676929c2d329da0daf9d22afa8ad2 ]
The error paths in the prepare_vmcs02() function are supposed to set *entry_failure_code but this path does not. It leads to using an uninitialized variable in the caller.
Message-Id: <20211130125337.GB24578@kili>
--- arch/x86/kvm/vmx/nested.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
arch/x86/kvm/vmx/nested.c +3 -1
@@ -2609,8 +2609,10 @@ static int prepare_vmcs02(struct kvm_vcpu *vcpu, struct vmcs12 *vmcs12,if ((vmcs12->vm_entry_controls &VM_ENTRY_LOAD_IA32_PERF_GLOBAL_CTRL ) &&WARN_ON_ONCE (kvm_set_msr (vcpu,MSR_CORE_PERF_GLOBAL_CTRL , - vmcs12->guest_ia32_perf_global_ctrl))) + vmcs12->guest_ia32_perf_global_ctrl))) { + *entry_failure_code =ENTRY_FAIL_DEFAULT ;return -EINVAL ; + }kvm_rsp_write (vcpu, vmcs12->guest_rsp);kvm_rip_write (vcpu, vmcs12->guest_rip);
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 169/207 mctp: Dont let RTM_DELROUTE delete local routes
In reply to Greg Kroah-HartmanFrom: Matt Johnston <[email protected]>
[ Upstream commit 76d001603c509562181f3787a7065b8e163bc7b9 ]
We need to test against the existing route type, not the rtm_type in the netlink request.
--- net/mctp/route.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
net/mctp/route.c +5 -4
@@ -760,7 +760,7 @@ static int mctp_route_add(struct mctp_dev *mdev, mctp_eid_t daddr_start, }static int mctp_route_remove (struct mctp_dev *mdev,mctp_eid_t daddr_start, -unsigned int daddr_extent) +unsigned int daddr_extent,unsigned char type) {struct net *net =dev_net (mdev->dev);struct mctp_route *rt, *tmp;
@@ -777,7 +777,8 @@ static int mctp_route_remove(struct mctp_dev *mdev, mctp_eid_t daddr_start,list_for_each_entry_safe (rt, tmp, &net->mctp.routes, list) {if (rt->dev == mdev && - rt->min == daddr_start && rt->max == daddr_end) { + rt->min == daddr_start && rt->max == daddr_end && + rt->type == type) {list_del_rcu (&rt->list);/* TODO: immediate RTM_DELROUTE */ mctp_route_release (rt);
@@ -795,7 +796,7 @@ int mctp_route_add_local(struct mctp_dev *mdev, mctp_eid_t addr)int mctp_route_remove_local (struct mctp_dev *mdev,mctp_eid_t addr) { -return mctp_route_remove (mdev, addr,0 ); +return mctp_route_remove (mdev, addr,0 ,RTN_LOCAL ); }/* removes all entries for a given device */
@@ -975,7 +976,7 @@ static int mctp_delroute(struct sk_buff *skb, struct nlmsghdr *nlh,if (rtm->rtm_type !=RTN_UNICAST )return -EINVAL ; - rc =mctp_route_remove (mdev, daddr_start, rtm->rtm_dst_len); + rc =mctp_route_remove (mdev, daddr_start, rtm->rtm_dst_len,RTN_UNICAST );return rc; }
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 170/207 Revert "drm/i915: Implement Wa_1508744258"
In reply to Greg Kroah-HartmanFrom: José Roberto de Souza <[email protected]>
[ Upstream commit 72641d8d60401a5f1e1a0431ceaf928680d34418 ]
This workarounds are causing hangs, because I missed the fact that it needs to be enabled for all cases and disabled when doing a resolve pass.
So KMD only needs to whitelist it and UMD will be the one setting it on per case.
This reverts commit 28ec02c9cbebf3feeaf21a59df9dfbc02bda3362.
--- drivers/gpu/drm/i915/gt/intel_workarounds.c | 7 ------- 1 file changed, 7 deletions(-)
drivers/gpu/drm/i915/gt/intel_workarounds.c +0 -7
@@ -621,13 +621,6 @@ static void gen12_ctx_workarounds_init(struct intel_engine_cs *engine,FF_MODE2_GS_TIMER_MASK ,FF_MODE2_GS_TIMER_224 , 0, false); - -/* -* Wa_14012131227:dg1 -* Wa_1508744258:tgl,rkl,dg1,adl-s,adl-p -*/ -wa_masked_en (wal,GEN7_COMMON_SLICE_CHICKEN1 , -GEN9_RHWO_OPTIMIZATION_DISABLE ); } static void dg1_ctx_workarounds_init(struct intel_engine_cs *engine,
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 171/207 io-wq: dont retry task_work creation failure on fatal conditions
In reply to Greg Kroah-HartmanFrom: Jens Axboe <[email protected]>
[ Upstream commit a226abcd5d427fe9d42efc442818a4a1821e2664 ]
We don't want to be retrying task_work creation failure if there's an actual signal pending for the parent task. If we do, then we can enter an infinite loop of perpetually retrying and each retry failing with -ERESTARTNOINTR because a signal is pending.
--- fs/io-wq.c | 7 +++++++ 1 file changed, 7 insertions(+)
fs/io-wq.c +7 -0
@@ -711,6 +711,13 @@ static bool io_wq_work_match_all(struct io_wq_work *work, void *data)static inline bool io_should_retry_thread (long err) { +/* +* Prevent perpetual task_work retry, if the task (or its group) is +* exiting. +*/ +if (fatal_signal_pending (current)) +return false; +switch (err) {case -EAGAIN :case -ERESTARTSYS :
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 172/207 x86/sev: Fix SEV-ES INS/OUTS instructions for word, dword, and qword
In reply to Greg Kroah-HartmanFrom: Michael Sterritt <[email protected]>
[ Upstream commit 1d5379d0475419085d3575bd9155f2e558e96390 ]
Properly type the operands being passed to __put_user()/__get_user(). Otherwise, these routines truncate data for dependent instructions (e.g., INSW) and only read/write one byte.
This has been tested by sending a string with REP OUTSW to a port and then reading it back in with REP INSW on the same port.
Previous behavior was to only send and receive the first char of the size. For example, word operations for "abcd" would only read/write "ac". With change, the full string is now written and read back.
--- arch/x86/kernel/sev.c | 57 +++++++++++++++++++++++++++++-------------- 1 file changed, 39 insertions(+), 18 deletions(-)
arch/x86/kernel/sev.c +39 -18
@@ -294,11 +294,6 @@ static enum es_result vc_write_mem(struct es_em_ctxt *ctxt, char *dst, char *buf, size_t size) { unsigned long error_code = X86_PF_PROT | X86_PF_WRITE; -char __user *target = (char __user *)dst; -u64 d8; -u32 d4; -u16 d2; -u8 d1;/* * This function uses __put_user() independent of whether kernel or user
@@ -320,26 +315,42 @@ static enum es_result vc_write_mem(struct es_em_ctxt *ctxt,* instructions here would cause infinite nesting. */ switch (size) { -case 1 : +case 1 : { +u8 d1; +u8 __user *target = (u8 __user *)dst; +memcpy (&d1, buf,1 );if (__put_user (d1, target)) goto fault;break ; -case 2 : + } +case 2 : { +u16 d2; +u16 __user *target = (u16 __user *)dst; +memcpy (&d2, buf,2 );if (__put_user (d2, target)) goto fault;break ; -case 4 : + } +case 4 : { +u32 d4; +u32 __user *target = (u32 __user *)dst; +memcpy (&d4, buf,4 );if (__put_user (d4, target)) goto fault;break ; -case 8 : + } +case 8 : { +u64 d8; +u64 __user *target = (u64 __user *)dst; +memcpy (&d8, buf,8 );if (__put_user (d8, target)) goto fault;break ; + }default :WARN_ONCE (1 ,"%s: Invalid size: %zu\n" , __func__, size);return ES_UNSUPPORTED ;
@@ -362,11 +373,6 @@ static enum es_result vc_read_mem(struct es_em_ctxt *ctxt, char *src, char *buf, size_t size) { unsigned long error_code = X86_PF_PROT; -char __user *s = (char __user *)src; -u64 d8; -u32 d4; -u16 d2; -u8 d1;/* * This function uses __get_user() independent of whether kernel or user
@@ -388,26 +394,41 @@ static enum es_result vc_read_mem(struct es_em_ctxt *ctxt,* instructions here would cause infinite nesting. */ switch (size) { -case 1 : +case 1 : { +u8 d1; +u8 __user *s = (u8 __user *)src; +if (__get_user (d1, s)) goto fault;memcpy (buf, &d1,1 );break ; -case 2 : + } +case 2 : { +u16 d2; +u16 __user *s = (u16 __user *)src; +if (__get_user (d2, s)) goto fault;memcpy (buf, &d2,2 );break ; -case 4 : + } +case 4 : { +u32 d4; +u32 __user *s = (u32 __user *)src; +if (__get_user (d4, s)) goto fault;memcpy (buf, &d4,4 );break ; -case 8 : + } +case 8 : { +u64 d8; +u64 __user *s = (u64 __user *)src;if (__get_user (d8, s)) goto fault;memcpy (buf, &d8,8 );break ; + }default :WARN_ONCE (1 ,"%s: Invalid size: %zu\n" , __func__, size);return ES_UNSUPPORTED ;
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 173/207 x86/entry: Add a fence for kernel entry SWAPGS in paranoid_entry()
In reply to Greg Kroah-HartmanFrom: Lai Jiangshan <[email protected]>
[ Upstream commit c07e45553da1808aa802e9f0ffa8108cfeaf7a17 ]
Commit
18ec54fdd6d18 ("x86/speculation: Prepare entry code for Spectre v1 swapgs mitigations")
added FENCE_SWAPGS_{KERNEL|USER}_ENTRY for conditional SWAPGS. In paranoid_entry(), it uses only FENCE_SWAPGS_KERNEL_ENTRY for both branches. This is because the fence is required for both cases since the CR3 write is conditional even when PTI is enabled.
But
96b2371413e8f ("x86/entry/64: Switch CR3 before SWAPGS in paranoid entry")
changed the order of SWAPGS and the CR3 write. And it missed the needed FENCE_SWAPGS_KERNEL_ENTRY for the user gsbase case.
Add it back by changing the branches so that FENCE_SWAPGS_KERNEL_ENTRY can cover both branches.
[ bp: Massage, fix typos, remove obsolete comment while at it. ]
--- arch/x86/entry/entry_64.S | 16 +++++----------- 1 file changed, 5 insertions(+), 11 deletions(-)
arch/x86/entry/entry_64.S +5 -11
@@ -890,6 +890,7 @@ SYM_CODE_START_LOCAL(paranoid_entry) .Lparanoid_entry_checkgs: /* EBX = 1 -> kernel GSBASE active, no restore required */ movl $1, %ebx + /* * The kernel-enforced convention is a negative GSBASE indicates * a kernel value. No SWAPGS needed on entry and exit.
@@ -897,21 +898,14 @@ SYM_CODE_START_LOCAL(paranoid_entry) movl $MSR_GS_BASE, %ecx rdmsr testl %edx, %edx - jns .Lparanoid_entry_swapgs - ret + js .Lparanoid_kernel_gsbase -.Lparanoid_entry_swapgs: + /* EBX = 0 -> SWAPGS required on exit */ + xorl %ebx, %ebx swapgs +.Lparanoid_kernel_gsbase: - /* - * The above SAVE_AND_SWITCH_TO_KERNEL_CR3 macro doesn't do an - * unconditional CR3 write, even in the PTI case. So do an lfence - * to prevent GS speculation, regardless of whether PTI is enabled. - */ FENCE_SWAPGS_KERNEL_ENTRY - - /* EBX = 0 -> SWAPGS required on exit */ - xorl %ebx, %ebx ret SYM_CODE_END(paranoid_entry)
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 174/207 x86/entry: Use the correct fence macro after swapgs in kernel CR3
In reply to Greg Kroah-HartmanFrom: Lai Jiangshan <[email protected]>
[ Upstream commit 1367afaa2ee90d1c956dfc224e199fcb3ff3f8cc ]
The commit
c75890700455 ("x86/entry/64: Remove unneeded kernel CR3 switching")
removed a CR3 write in the faulting path of load_gs_index().
But the path's FENCE_SWAPGS_USER_ENTRY has no fence operation if PTI is enabled, see spectre_v1_select_mitigation().
Rather, it depended on the serializing CR3 write of SWITCH_TO_KERNEL_CR3 and since it got removed, add a FENCE_SWAPGS_KERNEL_ENTRY call to make sure speculation is blocked.
[ bp: Massage commit message and comment. ]
--- arch/x86/entry/entry_64.S | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-)
arch/x86/entry/entry_64.S +8 -7
@@ -987,11 +987,6 @@ SYM_CODE_START_LOCAL(error_entry) pushq %r12 ret -.Lerror_entry_done_lfence: - FENCE_SWAPGS_KERNEL_ENTRY -.Lerror_entry_done: - ret - /* * There are two places in the kernel that can potentially fault with * usergs. Handle them here. B stepping K8s sometimes report a
@@ -1014,8 +1009,14 @@ SYM_CODE_START_LOCAL(error_entry) * .Lgs_change's error handler with kernel gsbase. */ SWAPGS - FENCE_SWAPGS_USER_ENTRY - jmp .Lerror_entry_done + + /* + * Issue an LFENCE to prevent GS speculation, regardless of whether it is a + * kernel or user gsbase. + */ +.Lerror_entry_done_lfence: + FENCE_SWAPGS_KERNEL_ENTRY + ret .Lbstep_iret: /* Fix truncated RIP */
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 175/207 x86/xen: Add xenpv_restore_regs_and_return_to_usermode()
In reply to Greg Kroah-HartmanFrom: Lai Jiangshan <[email protected]>
[ Upstream commit 5c8f6a2e316efebb3ba93d8c1af258155dcf5632 ]
In the native case, PER_CPU_VAR(cpu_tss_rw + TSS_sp0) is the trampoline stack. But XEN pv doesn't use trampoline stack, so PER_CPU_VAR(cpu_tss_rw + TSS_sp0) is also the kernel stack.
In that case, source and destination stacks are identical, which means that reusing swapgs_restore_regs_and_return_to_usermode() in XEN pv would cause %rsp to move up to the top of the kernel stack and leave the IRET frame below %rsp.
This is dangerous as it can be corrupted if #NMI / #MC hit as either of these events occurring in the middle of the stack pushing would clobber data on the (original) stack.
And, with XEN pv, swapgs_restore_regs_and_return_to_usermode() pushing the IRET frame on to the original address is useless and error-prone when there is any future attempt to modify the code.
[ bp: Massage commit message. ]
--- arch/x86/entry/entry_64.S | 4 ++++ arch/x86/xen/xen-asm.S | 20 ++++++++++++++++++++ 2 files changed, 24 insertions(+)
arch/x86/entry/entry_64.S +4 -0
@@ -574,6 +574,10 @@ SYM_INNER_LABEL(swapgs_restore_regs_and_return_to_usermode, SYM_L_GLOBAL) ud2 1: #endif +#ifdef CONFIG_XEN_PV + ALTERNATIVE "", "jmp xenpv_restore_regs_and_return_to_usermode", X86_FEATURE_XENPV +#endif + POP_REGS pop_rdi=0 /*
arch/x86/xen/xen-asm.S +20 -0
@@ -20,6 +20,7 @@ #include <linux/init.h> #include <linux/linkage.h> +#include <../entry/calling.h> /* * Enable events. This clears the event mask and tests the pending
@@ -191,6 +192,25 @@ SYM_CODE_START(xen_iret) jmp hypercall_iret SYM_CODE_END(xen_iret) +/* + * XEN pv doesn't use trampoline stack, PER_CPU_VAR(cpu_tss_rw + TSS_sp0) is + * also the kernel stack. Reusing swapgs_restore_regs_and_return_to_usermode() + * in XEN pv would cause %rsp to move up to the top of the kernel stack and + * leave the IRET frame below %rsp, which is dangerous to be corrupted if #NMI + * interrupts. And swapgs_restore_regs_and_return_to_usermode() pushing the IRET + * frame at the same address is useless. + */ +SYM_CODE_START(xenpv_restore_regs_and_return_to_usermode) + UNWIND_HINT_REGS + POP_REGS + + /* stackleak_erase() can work safely on the kernel stack. */ + STACKLEAK_ERASE_NOCLOBBER + + addq $8, %rsp /* skip regs->orig_ax */ + jmp xen_iret +SYM_CODE_END(xenpv_restore_regs_and_return_to_usermode) + /* * Xen handles syscall callbacks much like ordinary exceptions, which * means we have:
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 176/207 preempt/dynamic: Fix setup_preempt_mode() return value
In reply to Greg Kroah-HartmanFrom: Andrew Halaney <[email protected]>
[ Upstream commit 9ed20bafc85806ca6c97c9128cec46c3ef80ae86 ]
__setup() callbacks expect 1 for success and 0 for failure. Correct the usage here to reflect that.
--- kernel/sched/core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
kernel/sched/core.c +2 -2
@@ -6660,11 +6660,11 @@ static int __init setup_preempt_mode(char *str)int mode =sched_dynamic_mode (str);if (mode <0 ) {pr_warn ("Dynamic Preempt: unsupported mode: %s\n" , str); -return 1 ; +return 0 ; }sched_dynamic_update (mode); -return 0 ; +return 1 ; }__setup ("preempt=" , setup_preempt_mode);
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 177/207 sched/uclamp: Fix rq->uclamp_max not set on first enqueue
In reply to Greg Kroah-HartmanFrom: Qais Yousef <[email protected]>
[ Upstream commit 315c4f884800c45cb6bd8c90422fad554a8b9588 ]
Commit d81ae8aac85c ("sched/uclamp: Fix initialization of struct uclamp_rq") introduced a bug where uclamp_max of the rq is not reset to match the woken up task's uclamp_max when the rq is idle.
The code was relying on rq->uclamp_max initialized to zero, so on first enqueue
static inline void uclamp_rq_inc_id(struct rq *rq, struct task_struct *p,
enum uclamp_id clamp_id)
{
...
if (uc_se->value > READ_ONCE(uc_rq->value))
WRITE_ONCE(uc_rq->value, uc_se->value);
}was actually resetting it. But since commit d81ae8aac85c changed the default to 1024, this no longer works. And since rq->uclamp_flags is also initialized to 0, neither above code path nor uclamp_idle_reset() update the rq->uclamp_max on first wake up from idle.
This is only visible from first wake up(s) until the first dequeue to idle after enabling the static key. And it only matters if the uclamp_max of this task is < 1024 since only then its uclamp_max will be effectively ignored.
Fix it by properly initializing rq->uclamp_flags = UCLAMP_FLAG_IDLE to ensure uclamp_idle_reset() is called which then will update the rq uclamp_max value as expected.
--- kernel/sched/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/sched/core.c +1 -1
@@ -1914,7 +1914,7 @@ static void __init init_uclamp_rq(struct rq *rq) }; } - rq->uclamp_flags =0 ; + rq->uclamp_flags =UCLAMP_FLAG_IDLE ; }static void __init init_uclamp (void )
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 178/207 KVM: SEV: Return appropriate error codes if SEV-ES scratch setup fails
In reply to Greg Kroah-HartmanFrom: Sean Christopherson <[email protected]>
[ Upstream commit 75236f5f2299b502e4b9b267c1ce3bc14a222ceb ]
Return appropriate error codes if setting up the GHCB scratch area for an SEV-ES guest fails. In particular, returning -EINVAL instead of -ENOMEM when allocating the kernel buffer could be confusing as userspace would likely suspect a guest issue.
Message-Id: <[email protected]>
--- arch/x86/kvm/svm/sev.c | 30 +++++++++++++++++------------- 1 file changed, 17 insertions(+), 13 deletions(-)
arch/x86/kvm/svm/sev.c +17 -13
@@ -2317,7 +2317,7 @@ void pre_sev_run(struct vcpu_svm *svm, int cpu) }#define GHCB_SCRATCH_AREA_LIMIT (16ULL * PAGE_SIZE) -static bool setup_vmgexit_scratch (struct vcpu_svm *svm,bool sync,u64 len) +static int setup_vmgexit_scratch (struct vcpu_svm *svm,bool sync,u64 len) {struct vmcb_control_area *control = &svm->vmcb->control;struct ghcb *ghcb = svm->ghcb;
@@ -2328,14 +2328,14 @@ static bool setup_vmgexit_scratch(struct vcpu_svm *svm, bool sync, u64 len) scratch_gpa_beg =ghcb_get_sw_scratch (ghcb);if (!scratch_gpa_beg) {pr_err ("vmgexit: scratch gpa not provided\n" ); -return false; +return -EINVAL ; } scratch_gpa_end = scratch_gpa_beg + len;if (scratch_gpa_end < scratch_gpa_beg) {pr_err ("vmgexit: scratch length (%#llx) not valid for scratch address (%#llx)\n" , len, scratch_gpa_beg); -return false; +return -EINVAL ; }if ((scratch_gpa_beg &PAGE_MASK ) == control->ghcb_gpa) {
@@ -2353,7 +2353,7 @@ static bool setup_vmgexit_scratch(struct vcpu_svm *svm, bool sync, u64 len) scratch_gpa_end > ghcb_scratch_end) {pr_err ("vmgexit: scratch area is outside of GHCB shared buffer area (%#llx - %#llx)\n" , scratch_gpa_beg, scratch_gpa_end); -return false; +return -EINVAL ; } scratch_va = (void *)svm->ghcb;
@@ -2366,18 +2366,18 @@ static bool setup_vmgexit_scratch(struct vcpu_svm *svm, bool sync, u64 len)if (len >GHCB_SCRATCH_AREA_LIMIT ) {pr_err ("vmgexit: scratch area exceeds KVM limits (%#llx requested, %#llx limit)\n" , len,GHCB_SCRATCH_AREA_LIMIT ); -return false; +return -EINVAL ; } scratch_va =kzalloc (len,GFP_KERNEL_ACCOUNT );if (!scratch_va) -return false; +return -ENOMEM ;if (kvm_read_guest (svm->vcpu.kvm, scratch_gpa_beg, scratch_va, len)) {/* Unable to copy scratch area from guest */ pr_err ("vmgexit: kvm_read_guest for scratch area failed\n" );kfree (scratch_va); -return false; +return -EFAULT ; }/*
@@ -2393,7 +2393,7 @@ static bool setup_vmgexit_scratch(struct vcpu_svm *svm, bool sync, u64 len) svm->ghcb_sa = scratch_va; svm->ghcb_sa_len = len; -return true; +return 0 ; } static void set_ghcb_msr_bits(struct vcpu_svm *svm, u64 value, u64 mask,
@@ -2532,10 +2532,10 @@ int sev_handle_vmgexit(struct kvm_vcpu *vcpu)ghcb_set_sw_exit_info_1 (ghcb,0 );ghcb_set_sw_exit_info_2 (ghcb,0 ); - ret = -EINVAL ;switch (exit_code) {case SVM_VMGEXIT_MMIO_READ : -if (!setup_vmgexit_scratch (svm, true, control->exit_info_2)) + ret =setup_vmgexit_scratch (svm, true, control->exit_info_2); +if (ret)break ; ret = kvm_sev_es_mmio_read(vcpu,
@@ -2544,7 +2544,8 @@ int sev_handle_vmgexit(struct kvm_vcpu *vcpu) svm->ghcb_sa);break ;case SVM_VMGEXIT_MMIO_WRITE : -if (!setup_vmgexit_scratch (svm, false, control->exit_info_2)) + ret =setup_vmgexit_scratch (svm, false, control->exit_info_2); +if (ret)break ; ret = kvm_sev_es_mmio_write(vcpu,
@@ -2587,6 +2588,7 @@ int sev_handle_vmgexit(struct kvm_vcpu *vcpu)vcpu_unimpl (vcpu,"vmgexit: unsupported event - exit_info_1=%#llx, exit_info_2=%#llx\n" , control->exit_info_1, control->exit_info_2); + ret = -EINVAL ;break ;default : ret =svm_invoke_exit_handler (vcpu, exit_code);
@@ -2599,6 +2601,7 @@ int sev_es_string_io(struct vcpu_svm *svm, int size, unsigned int port, int in) {int count;int bytes; +int r;if (svm->vmcb->control.exit_info_2 >INT_MAX )return -EINVAL ;
@@ -2607,8 +2610,9 @@ int sev_es_string_io(struct vcpu_svm *svm, int size, unsigned int port, int in)if (unlikely (check_mul_overflow (count, size, &bytes)))return -EINVAL ; -if (!setup_vmgexit_scratch (svm, in, bytes)) -return -EINVAL ; + r =setup_vmgexit_scratch (svm, in, bytes); +if (r) +return r;return kvm_sev_es_string_io (&svm->vcpu, size, port, svm->ghcb_sa, count, in); }
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 179/207 KVM: x86/mmu: Rename slot_handle_leaf to slot_handle_level_4k
In reply to Greg Kroah-HartmanFrom: David Matlack <[email protected]>
[ Upstream commit 610265ea3da117db435868bd109f1861534a5634 ]
slot_handle_leaf is a misnomer because it only operates on 4K SPTEs whereas "leaf" is used to describe any valid terminal SPTE (4K or large page). Rename slot_handle_leaf to slot_handle_level_4k to avoid confusion.
Making this change makes it more obvious there is a benign discrepency between the legacy MMU and the TDP MMU when it comes to dirty logging. The legacy MMU only iterates through 4K SPTEs when zapping for collapsing and when clearing D-bits. The TDP MMU, on the other hand, iterates through SPTEs on all levels.
The TDP MMU behavior of zapping SPTEs at all levels is technically overkill for its current dirty logging implementation, which always demotes to 4k SPTES, but both the TDP MMU and legacy MMU zap if and only if the SPTE can be replaced by a larger page, i.e. will not spuriously zap 2m (or larger) SPTEs. Opportunistically add comments to explain this discrepency in the code.
Message-Id: <[email protected]>
--- arch/x86/kvm/mmu/mmu.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-)
arch/x86/kvm/mmu/mmu.c +13 -5
@@ -5474,8 +5474,8 @@ slot_handle_level(struct kvm *kvm, const struct kvm_memory_slot *memslot, } static __always_inline bool -slot_handle_leaf (struct kvm *kvm,const struct kvm_memory_slot *memslot, -slot_level_handler fn,bool flush_on_yield) +slot_handle_level_4k (struct kvm *kvm,const struct kvm_memory_slot *memslot, +slot_level_handler fn,bool flush_on_yield) {return slot_handle_level (kvm, memslot, fn,PG_LEVEL_4K ,PG_LEVEL_4K , flush_on_yield);
@@ -5859,7 +5859,12 @@ void kvm_mmu_zap_collapsible_sptes(struct kvm *kvm,if (kvm_memslots_have_rmaps (kvm)) {write_lock (&kvm->mmu_lock); - flush =slot_handle_leaf (kvm, slot, kvm_mmu_zap_collapsible_spte, true); +/* +* Zap only 4k SPTEs since the legacy MMU only supports dirty +* logging at a 4k granularity and never creates collapsible +* 2m SPTEs during dirty logging. +*/ + flush =slot_handle_level_4k (kvm, slot, kvm_mmu_zap_collapsible_spte, true);if (flush)kvm_arch_flush_remote_tlbs_memslot (kvm, slot);write_unlock (&kvm->mmu_lock);
@@ -5896,8 +5901,11 @@ void kvm_mmu_slot_leaf_clear_dirty(struct kvm *kvm,if (kvm_memslots_have_rmaps (kvm)) {write_lock (&kvm->mmu_lock); - flush =slot_handle_leaf (kvm, memslot, __rmap_clear_dirty, - false); +/* +* Clear dirty bits only on 4k SPTEs since the legacy MMU only +* support dirty logging at a 4k granularity. +*/ + flush =slot_handle_level_4k (kvm, memslot, __rmap_clear_dirty, false);write_unlock (&kvm->mmu_lock); }
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 180/207 KVM: x86/mmu: Remove spurious TLB flushes in TDP MMU zap collapsible path
In reply to Greg Kroah-HartmanFrom: Sean Christopherson <[email protected]>
[ Upstream commit 4b85c921cd393764d22c0cdab6d7d5d120aa0980 ]
Drop the "flush" param and return values to/from the TDP MMU's helper for zapping collapsible SPTEs. Because the helper runs with mmu_lock held for read, not write, it uses tdp_mmu_zap_spte_atomic(), and the atomic zap handles the necessary remote TLB flush.
Similarly, because mmu_lock is dropped and re-acquired between zapping legacy MMUs and zapping TDP MMUs, kvm_mmu_zap_collapsible_sptes() must handle remote TLB flushes from the legacy MMU before calling into the TDP MMU.
Message-Id: <[email protected]>
--- arch/x86/kvm/mmu/mmu.c | 9 ++------- arch/x86/kvm/mmu/tdp_mmu.c | 22 +++++++--------------- arch/x86/kvm/mmu/tdp_mmu.h | 5 ++--- 3 files changed, 11 insertions(+), 25 deletions(-)
arch/x86/kvm/mmu/mmu.c +2 -7
@@ -5855,8 +5855,6 @@ static bool kvm_mmu_zap_collapsible_spte(struct kvm *kvm,void kvm_mmu_zap_collapsible_sptes (struct kvm *kvm,const struct kvm_memory_slot *slot) { -bool flush; -if (kvm_memslots_have_rmaps (kvm)) {write_lock (&kvm->mmu_lock);/*
@@ -5864,17 +5862,14 @@ void kvm_mmu_zap_collapsible_sptes(struct kvm *kvm,* logging at a 4k granularity and never creates collapsible * 2m SPTEs during dirty logging. */ - flush =slot_handle_level_4k (kvm, slot, kvm_mmu_zap_collapsible_spte, true); -if (flush) +if (slot_handle_level_4k (kvm, slot, kvm_mmu_zap_collapsible_spte, true))kvm_arch_flush_remote_tlbs_memslot (kvm, slot);write_unlock (&kvm->mmu_lock); }if (is_tdp_mmu_enabled (kvm)) {read_lock (&kvm->mmu_lock); - flush =kvm_tdp_mmu_zap_collapsible_sptes (kvm, slot, false); -if (flush) -kvm_arch_flush_remote_tlbs_memslot (kvm, slot); +kvm_tdp_mmu_zap_collapsible_sptes (kvm, slot);read_unlock (&kvm->mmu_lock); } }
arch/x86/kvm/mmu/tdp_mmu.c +7 -15
@@ -1413,10 +1413,9 @@ void kvm_tdp_mmu_clear_dirty_pt_masked(struct kvm *kvm,* Clear leaf entries which could be replaced by large mappings, for * GFNs within the slot. */ -static bool zap_collapsible_spte_range (struct kvm *kvm, +static void zap_collapsible_spte_range (struct kvm *kvm,struct kvm_mmu_page *root, -const struct kvm_memory_slot *slot, -bool flush) +const struct kvm_memory_slot *slot) {gfn_t start = slot->base_gfn;gfn_t end = start + slot->npages;
@@ -1427,10 +1426,8 @@ static bool zap_collapsible_spte_range(struct kvm *kvm,tdp_root_for_each_pte (iter, root, start, end) { retry: -if (tdp_mmu_iter_cond_resched (kvm, &iter, flush, true)) { - flush = false; +if (tdp_mmu_iter_cond_resched (kvm, &iter, false, true))continue ; - }if (!is_shadow_present_pte (iter.old_spte) || !is_last_spte (iter.old_spte, iter.level))
@@ -1442,6 +1439,7 @@ static bool zap_collapsible_spte_range(struct kvm *kvm, pfn, PG_LEVEL_NUM))continue ; +/* Note, a successful atomic zap also does a remote TLB flush. */ if (!tdp_mmu_zap_spte_atomic (kvm, &iter)) {/* * The iter must explicitly re-read the SPTE because
@@ -1450,30 +1448,24 @@ static bool zap_collapsible_spte_range(struct kvm *kvm, iter.old_spte =READ_ONCE (*rcu_dereference (iter.sptep)); goto retry; } - flush = true; }rcu_read_unlock (); - -return flush; }/* * Clear non-leaf entries (and free associated page tables) which could * be replaced by large mappings, for GFNs within the slot. */ -bool kvm_tdp_mmu_zap_collapsible_sptes (struct kvm *kvm, -const struct kvm_memory_slot *slot, -bool flush) +void kvm_tdp_mmu_zap_collapsible_sptes (struct kvm *kvm, +const struct kvm_memory_slot *slot) {struct kvm_mmu_page *root;lockdep_assert_held_read (&kvm->mmu_lock);for_each_tdp_mmu_root_yield_safe (kvm, root, slot->as_id, true) - flush =zap_collapsible_spte_range (kvm, root, slot, flush); - -return flush; +zap_collapsible_spte_range (kvm, root, slot); }/*
arch/x86/kvm/mmu/tdp_mmu.h +2 -3
@@ -66,9 +66,8 @@ void kvm_tdp_mmu_clear_dirty_pt_masked(struct kvm *kvm,struct kvm_memory_slot *slot, gfn_t gfn, unsigned long mask, bool wrprot); -bool kvm_tdp_mmu_zap_collapsible_sptes (struct kvm *kvm, -const struct kvm_memory_slot *slot, -bool flush); +void kvm_tdp_mmu_zap_collapsible_sptes (struct kvm *kvm, +const struct kvm_memory_slot *slot); bool kvm_tdp_mmu_write_protect_gfn(struct kvm *kvm, struct kvm_memory_slot *slot, gfn_t gfn,
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 181/207 net/mlx5e: Rename lro_timeout to packet_merge_timeout
In reply to Greg Kroah-HartmanFrom: Ben Ben-Ishay <[email protected]>
[ Upstream commit 50f477fe9933193e960785f1192be801d7cd307a ]
TIR stands for transport interface receive, the TIR object is responsible for performing all transport related operations on the receive side like packet processing, demultiplexing the packets to different RQ's, etc.lro_timeout is a field in the TIR that is used to set the timeout for lro session, this series introduces new packet merge type, therefore rename lro_timeout to packet_merge_timeout for all packet merge types.
--- drivers/net/ethernet/mellanox/mlx5/core/en.h | 2 +- drivers/net/ethernet/mellanox/mlx5/core/en/params.c | 2 +- drivers/net/ethernet/mellanox/mlx5/core/en/tir.c | 6 +++--- drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 2 +- include/linux/mlx5/mlx5_ifc.h | 6 +++--- 5 files changed, 9 insertions(+), 9 deletions(-)
drivers/net/ethernet/mellanox/mlx5/core/en.h +1 -1
@@ -264,7 +264,7 @@ struct mlx5e_params {bool scatter_fcs_en;bool rx_dim_enabled;bool tx_dim_enabled; -u32 lro_timeout; +u32 packet_merge_timeout;u32 pflags;struct bpf_prog *xdp_prog;struct mlx5e_xsk *xsk;
drivers/net/ethernet/mellanox/mlx5/core/en/params.c +1 -1
@@ -173,7 +173,7 @@ struct mlx5e_lro_param mlx5e_get_lro_param(struct mlx5e_params *params) lro_param = (struct mlx5e_lro_param ) { .enabled = params->lro_en, - .timeout = params->lro_timeout, + .timeout = params->packet_merge_timeout, };return lro_param;
drivers/net/ethernet/mellanox/mlx5/core/en/tir.c +3 -3
@@ -82,9 +82,9 @@ void mlx5e_tir_builder_build_lro(struct mlx5e_tir_builder *builder,if (!lro_param->enabled)return ; -MLX5_SET (tirc, tirc, lro_enable_mask, -MLX5_TIRC_LRO_ENABLE_MASK_IPV4_LRO | -MLX5_TIRC_LRO_ENABLE_MASK_IPV6_LRO ); +MLX5_SET (tirc, tirc, packet_merge_mask, +MLX5_TIRC_PACKET_MERGE_MASK_IPV4_LRO | +MLX5_TIRC_PACKET_MERGE_MASK_IPV6_LRO );MLX5_SET (tirc, tirc, lro_max_ip_payload_size, (MLX5E_PARAMS_DEFAULT_LRO_WQE_SZ - rough_max_l2_l3_hdr_sz) >>8 );MLX5_SET (tirc, tirc, lro_timeout_period_usecs, lro_param->timeout);
drivers/net/ethernet/mellanox/mlx5/core/en_main.c +1 -1
@@ -4323,7 +4323,7 @@ void mlx5e_build_nic_params(struct mlx5e_priv *priv, struct mlx5e_xsk *xsk, u16if (!mlx5e_rx_mpwqe_is_linear_skb (mdev, params,NULL )) params->lro_en = !slow_pci_heuristic (mdev); } - params->lro_timeout =mlx5e_choose_lro_timeout (mdev,MLX5E_DEFAULT_LRO_TIMEOUT ); + params->packet_merge_timeout =mlx5e_choose_lro_timeout (mdev,MLX5E_DEFAULT_LRO_TIMEOUT );/* CQ moderation params */ rx_cq_period_mode = MLX5_CAP_GEN(mdev, cq_period_start_from_cqe) ?
include/linux/mlx5/mlx5_ifc.h +3 -3
@@ -3309,8 +3309,8 @@ enum { };enum { -MLX5_TIRC_LRO_ENABLE_MASK_IPV4_LRO =0x1 , -MLX5_TIRC_LRO_ENABLE_MASK_IPV6_LRO =0x2 , +MLX5_TIRC_PACKET_MERGE_MASK_IPV4_LRO =BIT (0 ), +MLX5_TIRC_PACKET_MERGE_MASK_IPV6_LRO =BIT (1 ), };enum {
@@ -3335,7 +3335,7 @@ struct mlx5_ifc_tirc_bits {u8 reserved_at_80[0x4 ];u8 lro_timeout_period_usecs[0x10 ]; -u8 lro_enable_mask[0x4 ]; +u8 packet_merge_mask[0x4 ];u8 lro_max_ip_payload_size[0x8 ];u8 reserved_at_a0[0x40 ];
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 182/207 net/mlx5e: Rename TIR lro functions to TIR packet merge functions
In reply to Greg Kroah-HartmanFrom: Khalid Manaa <[email protected]>
[ Upstream commit eaee12f046924eeb1210c7e4f3b326603ff1bd85 ]
This series introduces new packet merge type, therefore rename lro functions to packet merge to support the new merge type:
- Generalize + rename mlx5e_build_tir_ctx_lro to mlx5e_build_tir_ctx_packet_merge.
- Rename mlx5e_modify_tirs_lro to mlx5e_modify_tirs_packet_merge.
- Rename lro bit in mlx5_ifc_modify_tir_bitmask_bits to packet_merge.
- Rename lro_en in mlx5e_params to packet_merge_type type and combine packet_merge params into one struct mlx5e_packet_merge_param.
--- drivers/net/ethernet/mellanox/mlx5/core/en.h | 14 +++++- .../ethernet/mellanox/mlx5/core/en/params.c | 21 +++------ .../ethernet/mellanox/mlx5/core/en/params.h | 6 --- .../net/ethernet/mellanox/mlx5/core/en/rss.c | 23 +++++----- .../net/ethernet/mellanox/mlx5/core/en/rss.h | 7 +-- .../ethernet/mellanox/mlx5/core/en/rx_res.c | 25 +++++----- .../ethernet/mellanox/mlx5/core/en/rx_res.h | 5 +- .../net/ethernet/mellanox/mlx5/core/en/tir.c | 10 ++-- .../net/ethernet/mellanox/mlx5/core/en/tir.h | 6 +-- .../ethernet/mellanox/mlx5/core/en_ethtool.c | 4 +- .../mellanox/mlx5/core/en_fs_ethtool.c | 6 +-- .../net/ethernet/mellanox/mlx5/core/en_main.c | 46 +++++++++++-------- .../net/ethernet/mellanox/mlx5/core/en_rep.c | 5 +- .../ethernet/mellanox/mlx5/core/ipoib/ipoib.c | 7 ++- include/linux/mlx5/mlx5_ifc.h | 2 +- 15 files changed, 95 insertions(+), 92 deletions(-)
drivers/net/ethernet/mellanox/mlx5/core/en.h +12 -2
@@ -244,6 +244,17 @@ enum mlx5e_priv_flag {#define MLX5E_GET_PFLAG (params, pflag) (!!((params)->pflags & (BIT(pflag)))) +enum packet_merge { +MLX5E_PACKET_MERGE_NONE , +MLX5E_PACKET_MERGE_LRO , +MLX5E_PACKET_MERGE_SHAMPO , +}; + +struct mlx5e_packet_merge_param { +enum packet_merge type; +u32 timeout; +}; +struct mlx5e_params {u8 log_sq_size;u8 rq_wq_type;
@@ -258,13 +269,12 @@ struct mlx5e_params {bool tunneled_offload_en;struct dim_cq_moder rx_cq_moderation;struct dim_cq_moder tx_cq_moderation; -bool lro_en; +struct mlx5e_packet_merge_param packet_merge;u8 tx_min_inline_mode;bool vlan_strip_disable;bool scatter_fcs_en;bool rx_dim_enabled;bool tx_dim_enabled; -u32 packet_merge_timeout;u32 pflags;struct bpf_prog *xdp_prog;struct mlx5e_xsk *xsk;
drivers/net/ethernet/mellanox/mlx5/core/en/params.c +6 -15
@@ -87,7 +87,8 @@ bool mlx5e_rx_is_linear_skb(struct mlx5e_params *params,u32 linear_frag_sz =max (mlx5e_rx_get_linear_frag_sz (params, xsk),mlx5e_rx_get_linear_frag_sz (params,NULL )); -return !params->lro_en && linear_frag_sz <=PAGE_SIZE ; +return params->packet_merge.type ==MLX5E_PACKET_MERGE_NONE && + linear_frag_sz <=PAGE_SIZE ; } bool mlx5e_verify_rx_mpwqe_strides(struct mlx5_core_dev *mdev,
@@ -164,19 +165,8 @@ u16 mlx5e_get_rq_headroom(struct mlx5_core_dev *mdev, mlx5e_rx_is_linear_skb(params, xsk) :mlx5e_rx_mpwqe_is_linear_skb (mdev, params, xsk); -return is_linear_skb ?mlx5e_get_linear_rq_headroom (params, xsk) :0 ; -} - -struct mlx5e_lro_param mlx5e_get_lro_param (struct mlx5e_params *params) -{ -struct mlx5e_lro_param lro_param; - - lro_param = (struct mlx5e_lro_param ) { - .enabled = params->lro_en, - .timeout = params->packet_merge_timeout, - }; - -return lro_param; +return is_linear_skb || params->packet_merge.type ==MLX5E_PACKET_MERGE_SHAMPO ? +mlx5e_get_linear_rq_headroom (params, xsk) :0 ; }u16 mlx5e_calc_sq_stop_room (struct mlx5_core_dev *mdev,struct mlx5e_params *params)
@@ -485,10 +475,11 @@ static void mlx5e_build_rx_cq_param(struct mlx5_core_dev *mdev,static u8 rq_end_pad_mode (struct mlx5_core_dev *mdev,struct mlx5e_params *params) { +bool lro_en = params->packet_merge.type ==MLX5E_PACKET_MERGE_LRO ;bool ro =pcie_relaxed_ordering_enabled (mdev->pdev) &&MLX5_CAP_GEN (mdev, relaxed_ordering_write); -return ro && params->lro_en ? +return ro && lro_en ?MLX5_WQ_END_PAD_MODE_NONE :MLX5_WQ_END_PAD_MODE_ALIGN ; }
drivers/net/ethernet/mellanox/mlx5/core/en/params.h +0 -6
@@ -11,11 +11,6 @@ struct mlx5e_xsk_param {u16 chunk_size; }; -struct mlx5e_lro_param { -bool enabled; -u32 timeout; -}; -struct mlx5e_cq_param {u32 cqc[MLX5_ST_SZ_DW (cqc)];struct mlx5_wq_param wq;
@@ -125,7 +120,6 @@ u8 mlx5e_mpwqe_get_log_num_strides(struct mlx5_core_dev *mdev,u16 mlx5e_get_rq_headroom (struct mlx5_core_dev *mdev,struct mlx5e_params *params,struct mlx5e_xsk_param *xsk); -struct mlx5e_lro_param mlx5e_get_lro_param (struct mlx5e_params *params);/* Build queue parameters */
drivers/net/ethernet/mellanox/mlx5/core/en/rss.c +12 -11
@@ -127,7 +127,7 @@ mlx5e_rss_get_tt_config(struct mlx5e_rss *rss, enum mlx5_traffic_types tt)static int mlx5e_rss_create_tir (struct mlx5e_rss *rss,enum mlx5_traffic_types tt, -const struct mlx5e_lro_param *init_lro_param, +const struct mlx5e_packet_merge_param *init_pkt_merge_param,bool inner) {struct mlx5e_rss_params_traffic_type rss_tt;
@@ -161,7 +161,7 @@ static int mlx5e_rss_create_tir(struct mlx5e_rss *rss, rqtn =mlx5e_rqt_get_rqtn (&rss->rqt);mlx5e_tir_builder_build_rqt (builder, rss->mdev->mlx5e_res.hw_objs.td.tdn, rqtn, rss->inner_ft_support); -mlx5e_tir_builder_build_lro (builder, init_lro_param); +mlx5e_tir_builder_build_packet_merge (builder, init_pkt_merge_param); rss_tt =mlx5e_rss_get_tt_config (rss, tt);mlx5e_tir_builder_build_rss (builder, &rss->hash, &rss_tt, inner);
@@ -198,14 +198,14 @@ static void mlx5e_rss_destroy_tir(struct mlx5e_rss *rss, enum mlx5_traffic_types }static int mlx5e_rss_create_tirs (struct mlx5e_rss *rss, -const struct mlx5e_lro_param *init_lro_param, +const struct mlx5e_packet_merge_param *init_pkt_merge_param,bool inner) {enum mlx5_traffic_types tt, max_tt;int err;for (tt =0 ; tt <MLX5E_NUM_INDIR_TIRS ; tt++) { - err =mlx5e_rss_create_tir (rss, tt, init_lro_param, inner); + err =mlx5e_rss_create_tir (rss, tt, init_pkt_merge_param, inner);if (err) goto err_destroy_tirs; }
@@ -297,7 +297,7 @@ int mlx5e_rss_init_no_tirs(struct mlx5e_rss *rss, struct mlx5_core_dev *mdev,int mlx5e_rss_init (struct mlx5e_rss *rss,struct mlx5_core_dev *mdev,bool inner_ft_support,u32 drop_rqn, -const struct mlx5e_lro_param *init_lro_param) +const struct mlx5e_packet_merge_param *init_pkt_merge_param) {int err;
@@ -305,12 +305,12 @@ int mlx5e_rss_init(struct mlx5e_rss *rss, struct mlx5_core_dev *mdev,if (err) goto err_out; - err =mlx5e_rss_create_tirs (rss, init_lro_param, false); + err =mlx5e_rss_create_tirs (rss, init_pkt_merge_param, false);if (err) goto err_destroy_rqt;if (inner_ft_support) { - err =mlx5e_rss_create_tirs (rss, init_lro_param, true); + err =mlx5e_rss_create_tirs (rss, init_pkt_merge_param, true);if (err) goto err_destroy_tirs; }
@@ -372,7 +372,7 @@ u32 mlx5e_rss_get_tirn(struct mlx5e_rss *rss, enum mlx5_traffic_types tt,*/ int mlx5e_rss_obtain_tirn (struct mlx5e_rss *rss,enum mlx5_traffic_types tt, -const struct mlx5e_lro_param *init_lro_param, +const struct mlx5e_packet_merge_param *init_pkt_merge_param,bool inner,u32 *tirn) {struct mlx5e_tir *tir;
@@ -381,7 +381,7 @@ int mlx5e_rss_obtain_tirn(struct mlx5e_rss *rss,if (!tir) {/* TIR doesn't exist, create one */ int err; - err =mlx5e_rss_create_tir (rss, tt, init_lro_param, inner); + err =mlx5e_rss_create_tir (rss, tt, init_pkt_merge_param, inner);if (err)return err; tir =rss_get_tir (rss, tt, inner);
@@ -418,7 +418,8 @@ void mlx5e_rss_disable(struct mlx5e_rss *rss) mlx5e_rqt_get_rqtn(&rss->rqt), rss->drop_rqn, err); } -int mlx5e_rss_lro_set_param (struct mlx5e_rss *rss,struct mlx5e_lro_param *lro_param) +int mlx5e_rss_packet_merge_set_param (struct mlx5e_rss *rss, +struct mlx5e_packet_merge_param *pkt_merge_param) {struct mlx5e_tir_builder *builder;enum mlx5_traffic_types tt;
@@ -428,7 +429,7 @@ int mlx5e_rss_lro_set_param(struct mlx5e_rss *rss, struct mlx5e_lro_param *lro_pif (!builder)return -ENOMEM ; -mlx5e_tir_builder_build_lro (builder, lro_param); +mlx5e_tir_builder_build_packet_merge (builder, pkt_merge_param); final_err =0 ;
drivers/net/ethernet/mellanox/mlx5/core/en/rss.h +4 -3
@@ -17,7 +17,7 @@ struct mlx5e_rss *mlx5e_rss_alloc(void);void mlx5e_rss_free (struct mlx5e_rss *rss);int mlx5e_rss_init (struct mlx5e_rss *rss,struct mlx5_core_dev *mdev,bool inner_ft_support,u32 drop_rqn, -const struct mlx5e_lro_param *init_lro_param); +const struct mlx5e_packet_merge_param *init_pkt_merge_param);int mlx5e_rss_init_no_tirs (struct mlx5e_rss *rss,struct mlx5_core_dev *mdev,bool inner_ft_support,u32 drop_rqn);int mlx5e_rss_cleanup (struct mlx5e_rss *rss);
@@ -30,13 +30,14 @@ u32 mlx5e_rss_get_tirn(struct mlx5e_rss *rss, enum mlx5_traffic_types tt, bool inner);int mlx5e_rss_obtain_tirn (struct mlx5e_rss *rss,enum mlx5_traffic_types tt, -const struct mlx5e_lro_param *init_lro_param, +const struct mlx5e_packet_merge_param *init_pkt_merge_param,bool inner,u32 *tirn);void mlx5e_rss_enable (struct mlx5e_rss *rss,u32 *rqns,unsigned int num_rqns);void mlx5e_rss_disable (struct mlx5e_rss *rss); -int mlx5e_rss_lro_set_param (struct mlx5e_rss *rss,struct mlx5e_lro_param *lro_param); +int mlx5e_rss_packet_merge_set_param (struct mlx5e_rss *rss, +struct mlx5e_packet_merge_param *pkt_merge_param);int mlx5e_rss_get_rxfh (struct mlx5e_rss *rss,u32 *indir,u8 *key,u8 *hfunc); int mlx5e_rss_set_rxfh(struct mlx5e_rss *rss, const u32 *indir, const u8 *key, const u8 *hfunc,
drivers/net/ethernet/mellanox/mlx5/core/en/rx_res.c +13 -12
@@ -34,7 +34,7 @@ struct mlx5e_rx_res {/* API for rx_res_rss_* */ static int mlx5e_rx_res_rss_init_def (struct mlx5e_rx_res *res, -const struct mlx5e_lro_param *init_lro_param, +const struct mlx5e_packet_merge_param *init_pkt_merge_param,unsigned int init_nch) {bool inner_ft_support = res->features &MLX5E_RX_RES_FEATURE_INNER_FT ;
@@ -49,7 +49,7 @@ static int mlx5e_rx_res_rss_init_def(struct mlx5e_rx_res *res,return -ENOMEM ; err =mlx5e_rss_init (rss, res->mdev, inner_ft_support, res->drop_rqn, - init_lro_param); + init_pkt_merge_param);if (err) goto err_rss_free;
@@ -275,7 +275,7 @@ struct mlx5e_rx_res *mlx5e_rx_res_alloc(void) }static int mlx5e_rx_res_channels_init (struct mlx5e_rx_res *res, -const struct mlx5e_lro_param *init_lro_param) +const struct mlx5e_packet_merge_param *init_pkt_merge_param) {bool inner_ft_support = res->features &MLX5E_RX_RES_FEATURE_INNER_FT ;struct mlx5e_tir_builder *builder;
@@ -306,7 +306,7 @@ static int mlx5e_rx_res_channels_init(struct mlx5e_rx_res *res,mlx5e_tir_builder_build_rqt (builder, res->mdev->mlx5e_res.hw_objs.td.tdn,mlx5e_rqt_get_rqtn (&res->channels[ix].direct_rqt), inner_ft_support); -mlx5e_tir_builder_build_lro (builder, init_lro_param); +mlx5e_tir_builder_build_packet_merge (builder, init_pkt_merge_param);mlx5e_tir_builder_build_direct (builder); err =mlx5e_tir_init (&res->channels[ix].direct_tir, builder, res->mdev, true);
@@ -336,7 +336,7 @@ static int mlx5e_rx_res_channels_init(struct mlx5e_rx_res *res,mlx5e_tir_builder_build_rqt (builder, res->mdev->mlx5e_res.hw_objs.td.tdn,mlx5e_rqt_get_rqtn (&res->channels[ix].xsk_rqt), inner_ft_support); -mlx5e_tir_builder_build_lro (builder, init_lro_param); +mlx5e_tir_builder_build_packet_merge (builder, init_pkt_merge_param);mlx5e_tir_builder_build_direct (builder); err =mlx5e_tir_init (&res->channels[ix].xsk_tir, builder, res->mdev, true);
@@ -437,7 +437,7 @@ static void mlx5e_rx_res_ptp_destroy(struct mlx5e_rx_res *res)int mlx5e_rx_res_init (struct mlx5e_rx_res *res,struct mlx5_core_dev *mdev,enum mlx5e_rx_res_features features,unsigned int max_nch, -u32 drop_rqn,const struct mlx5e_lro_param *init_lro_param, +u32 drop_rqn,const struct mlx5e_packet_merge_param *init_pkt_merge_param,unsigned int init_nch) {int err;
@@ -447,11 +447,11 @@ int mlx5e_rx_res_init(struct mlx5e_rx_res *res, struct mlx5_core_dev *mdev, res->max_nch = max_nch; res->drop_rqn = drop_rqn; - err =mlx5e_rx_res_rss_init_def (res, init_lro_param, init_nch); + err =mlx5e_rx_res_rss_init_def (res, init_pkt_merge_param, init_nch);if (err) goto err_out; - err =mlx5e_rx_res_channels_init (res, init_lro_param); + err =mlx5e_rx_res_channels_init (res, init_pkt_merge_param);if (err) goto err_rss_destroy;
@@ -645,7 +645,8 @@ int mlx5e_rx_res_xsk_deactivate(struct mlx5e_rx_res *res, unsigned int ix)return err; } -int mlx5e_rx_res_lro_set_param (struct mlx5e_rx_res *res,struct mlx5e_lro_param *lro_param) +int mlx5e_rx_res_packet_merge_set_param (struct mlx5e_rx_res *res, +struct mlx5e_packet_merge_param *pkt_merge_param) {struct mlx5e_tir_builder *builder;int err, final_err;
@@ -655,7 +656,7 @@ int mlx5e_rx_res_lro_set_param(struct mlx5e_rx_res *res, struct mlx5e_lro_paramif (!builder)return -ENOMEM ; -mlx5e_tir_builder_build_lro (builder, lro_param); +mlx5e_tir_builder_build_packet_merge (builder, pkt_merge_param); final_err =0 ;
@@ -665,7 +666,7 @@ int mlx5e_rx_res_lro_set_param(struct mlx5e_rx_res *res, struct mlx5e_lro_paramif (!rss)continue ; - err =mlx5e_rss_lro_set_param (rss, lro_param); + err =mlx5e_rss_packet_merge_set_param (rss, pkt_merge_param);if (err) final_err = final_err ? : err; }
@@ -673,7 +674,7 @@ int mlx5e_rx_res_lro_set_param(struct mlx5e_rx_res *res, struct mlx5e_lro_paramfor (ix =0 ; ix < res->max_nch; ix++) { err =mlx5e_tir_modify (&res->channels[ix].direct_tir, builder);if (err) { -mlx5_core_warn (res->mdev,"Failed to update LRO state of direct TIR %#x for channel %u: err = %d\n" , +mlx5_core_warn (res->mdev,"Failed to update packet merge state of direct TIR %#x for channel %u: err = %d\n" ,mlx5e_tir_get_tirn (&res->channels[ix].direct_tir), ix, err);if (!final_err) final_err = err;
drivers/net/ethernet/mellanox/mlx5/core/en/rx_res.h +3 -2
@@ -25,7 +25,7 @@ enum mlx5e_rx_res_features {struct mlx5e_rx_res *mlx5e_rx_res_alloc (void );int mlx5e_rx_res_init (struct mlx5e_rx_res *res,struct mlx5_core_dev *mdev,enum mlx5e_rx_res_features features,unsigned int max_nch, -u32 drop_rqn,const struct mlx5e_lro_param *init_lro_param, +u32 drop_rqn,const struct mlx5e_packet_merge_param *init_pkt_merge_param,unsigned int init_nch);void mlx5e_rx_res_destroy (struct mlx5e_rx_res *res);void mlx5e_rx_res_free (struct mlx5e_rx_res *res);
@@ -57,7 +57,8 @@ int mlx5e_rx_res_rss_set_rxfh(struct mlx5e_rx_res *res, u32 rss_idx,u8 mlx5e_rx_res_rss_get_hash_fields (struct mlx5e_rx_res *res,enum mlx5_traffic_types tt);int mlx5e_rx_res_rss_set_hash_fields (struct mlx5e_rx_res *res,enum mlx5_traffic_types tt,u8 rx_hash_fields); -int mlx5e_rx_res_lro_set_param (struct mlx5e_rx_res *res,struct mlx5e_lro_param *lro_param); +int mlx5e_rx_res_packet_merge_set_param (struct mlx5e_rx_res *res, +struct mlx5e_packet_merge_param *pkt_merge_param);int mlx5e_rx_res_rss_init (struct mlx5e_rx_res *res,u32 *rss_idx,unsigned int init_nch);int mlx5e_rx_res_rss_destroy (struct mlx5e_rx_res *res,u32 rss_idx);
drivers/net/ethernet/mellanox/mlx5/core/en/tir.c +5 -5
@@ -70,16 +70,16 @@ void mlx5e_tir_builder_build_rqt(struct mlx5e_tir_builder *builder, u32 tdn,MLX5_SET (tirc, tirc, tunneled_offload_en, inner_ft_support); } -void mlx5e_tir_builder_build_lro (struct mlx5e_tir_builder *builder, -const struct mlx5e_lro_param *lro_param) +void mlx5e_tir_builder_build_packet_merge (struct mlx5e_tir_builder *builder, +const struct mlx5e_packet_merge_param *pkt_merge_param) {void *tirc =mlx5e_tir_builder_get_tirc (builder);const unsigned int rough_max_l2_l3_hdr_sz =256 ;if (builder->modify) -MLX5_SET (modify_tir_in, builder->in, bitmask.lro,1 ); +MLX5_SET (modify_tir_in, builder->in, bitmask.packet_merge,1 ); -if (!lro_param->enabled) +if (pkt_merge_param->type ==MLX5E_PACKET_MERGE_NONE )return ; MLX5_SET(tirc, tirc, packet_merge_mask,
@@ -87,7 +87,7 @@ void mlx5e_tir_builder_build_lro(struct mlx5e_tir_builder *builder, MLX5_TIRC_PACKET_MERGE_MASK_IPV6_LRO);MLX5_SET (tirc, tirc, lro_max_ip_payload_size, (MLX5E_PARAMS_DEFAULT_LRO_WQE_SZ - rough_max_l2_l3_hdr_sz) >>8 ); -MLX5_SET (tirc, tirc, lro_timeout_period_usecs, lro_param->timeout); +MLX5_SET (tirc, tirc, lro_timeout_period_usecs, pkt_merge_param->timeout); }static int mlx5e_hfunc_to_hw (u8 hfunc)
drivers/net/ethernet/mellanox/mlx5/core/en/tir.h +3 -3
@@ -18,7 +18,7 @@ struct mlx5e_rss_params_traffic_type { };struct mlx5e_tir_builder ; -struct mlx5e_lro_param ; +struct mlx5e_packet_merge_param ;struct mlx5e_tir_builder *mlx5e_tir_builder_alloc (bool modify);void mlx5e_tir_builder_free (struct mlx5e_tir_builder *builder);
@@ -27,8 +27,8 @@ void mlx5e_tir_builder_clear(struct mlx5e_tir_builder *builder);void mlx5e_tir_builder_build_inline (struct mlx5e_tir_builder *builder,u32 tdn,u32 rqn);void mlx5e_tir_builder_build_rqt (struct mlx5e_tir_builder *builder,u32 tdn,u32 rqtn,bool inner_ft_support); -void mlx5e_tir_builder_build_lro (struct mlx5e_tir_builder *builder, -const struct mlx5e_lro_param *lro_param); +void mlx5e_tir_builder_build_packet_merge (struct mlx5e_tir_builder *builder, +const struct mlx5e_packet_merge_param *pkt_merge_param); void mlx5e_tir_builder_build_rss(struct mlx5e_tir_builder *builder, const struct mlx5e_rss_params_hash *rss_hash, const struct mlx5e_rss_params_traffic_type *rss_tt,
drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c +2 -2
@@ -1954,8 +1954,8 @@ static int set_pflag_rx_striding_rq(struct net_device *netdev, bool enable)return -EOPNOTSUPP ;if (!mlx5e_striding_rq_possible (mdev, &priv->channels.params))return -EINVAL ; - }else if (priv->channels.params.lro_en) { -netdev_warn (netdev,"Can't set legacy RQ with LRO, disable LRO first\n" ); + }else if (priv->channels.params.packet_merge.type !=MLX5E_PACKET_MERGE_NONE ) { +netdev_warn (netdev,"Can't set legacy RQ with HW-GRO/LRO, disable them first\n" );return -EINVAL ; }
drivers/net/ethernet/mellanox/mlx5/core/en_fs_ethtool.c +3 -3
@@ -411,7 +411,7 @@ static int flow_get_tirn(struct mlx5e_priv *priv, u32 rss_context, u32 *tirn) {if (fs->flow_type &FLOW_RSS ) { -struct mlx5e_lro_param lro_param; +struct mlx5e_packet_merge_param pkt_merge_param;struct mlx5e_rss *rss;u32 flow_type;int err;
@@ -426,8 +426,8 @@ static int flow_get_tirn(struct mlx5e_priv *priv,if (tt <0 )return -EINVAL ; - lro_param =mlx5e_get_lro_param (&priv->channels.params); - err =mlx5e_rss_obtain_tirn (rss, tt, &lro_param, false, tirn); + pkt_merge_param = priv->channels.params.packet_merge; + err =mlx5e_rss_obtain_tirn (rss, tt, &pkt_merge_param, false, tirn);if (err)return err; eth_rule->rss = rss;
drivers/net/ethernet/mellanox/mlx5/core/en_main.c +26 -20
99 lines not on this page · raw message
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c +2 -3
@@ -793,7 +793,6 @@ int mlx5e_rep_bond_update(struct mlx5e_priv *priv, bool cleanup)static int mlx5e_init_rep_rx (struct mlx5e_priv *priv) {struct mlx5_core_dev *mdev = priv->mdev; -struct mlx5e_lro_param lro_param;int err; priv->rx_res =mlx5e_rx_res_alloc ();
@@ -808,9 +807,9 @@ static int mlx5e_init_rep_rx(struct mlx5e_priv *priv)return err; } - lro_param =mlx5e_get_lro_param (&priv->channels.params); err =mlx5e_rx_res_init (priv->rx_res, priv->mdev,0 , - priv->max_nch, priv->drop_rq.rqn, &lro_param, + priv->max_nch, priv->drop_rq.rqn, + &priv->channels.params.packet_merge, priv->channels.params.num_channels);if (err) goto err_close_drop_rq;
drivers/net/ethernet/mellanox/mlx5/core/ipoib/ipoib.c +3 -4
@@ -67,7 +67,7 @@ static void mlx5i_build_nic_params(struct mlx5_core_dev *mdev, MLX5E_PARAMS_MINIMUM_LOG_RQ_SIZE :MLX5I_PARAMS_DEFAULT_LOG_RQ_SIZE ; - params->lro_en = false; + params->packet_merge.type =MLX5E_PACKET_MERGE_NONE ; params->hard_mtu =MLX5_IB_GRH_BYTES +MLX5_IPOIB_HARD_LEN ; params->tunneled_offload_en = false; }
@@ -353,7 +353,6 @@ static void mlx5i_destroy_flow_steering(struct mlx5e_priv *priv)static int mlx5i_init_rx (struct mlx5e_priv *priv) {struct mlx5_core_dev *mdev = priv->mdev; -struct mlx5e_lro_param lro_param;int err; priv->rx_res =mlx5e_rx_res_alloc ();
@@ -368,9 +367,9 @@ static int mlx5i_init_rx(struct mlx5e_priv *priv) goto err_destroy_q_counters; } - lro_param =mlx5e_get_lro_param (&priv->channels.params); err =mlx5e_rx_res_init (priv->rx_res, priv->mdev,0 , - priv->max_nch, priv->drop_rq.rqn, &lro_param, + priv->max_nch, priv->drop_rq.rqn, + &priv->channels.params.packet_merge, priv->channels.params.num_channels);if (err) goto err_close_drop_rq;
include/linux/mlx5/mlx5_ifc.h +1 -1
@@ -6369,7 +6369,7 @@ struct mlx5_ifc_modify_tir_bitmask_bits {u8 reserved_at_3c[0x1 ];u8 hash[0x1 ];u8 reserved_at_3e[0x1 ]; -u8 lro[0x1 ]; +u8 packet_merge[0x1 ]; };struct mlx5_ifc_modify_tir_out_bits {
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 183/207 net/mlx5e: Sync TIR params updates against concurrent create/modify
In reply to Greg Kroah-HartmanFrom: Tariq Toukan <[email protected]>
[ Upstream commit 4cce2ccf08fbc27ae34ce0e72db15166e7b5f6a7 ]
Transport Interface Receive (TIR) objects perform the packet processing and reassembly and is also responsible for demultiplexing the packets into the different RQs.
There are certain TIR context attributes that propagate to the pointed RQs and applied to them (like packet_merge offloads (LRO/SHAMPO) and tunneled_offload_en). When TIRs do not agree on attributes values, a "last one wins" policy is applied. Hence, if not synced properly, a race between TIR params update and a concurrent TIR create/modify operation might yield to a mismatch between the shadow parameters in SW and the actual applied state of the RQs in HW.
tunneled_offload_en is a fixed attribute per profile, while packet merge offload state might be toggled and get out-of-sync. When this happens, packet_merge offload might be working although not requested, or the opposite.
All updates to packet_merge state and all create/modify operations of regular redirection/steering TIRs are done under the same priv->state_lock, so they do not run in parallel, and no race is possible.
However, there are other kind of TIRs (acceleration offloads TIRs, like TLS TIRs) which are created on demand for each new connection without holding the coarse priv->state_lock, hence might race.
Fix this by synchronizing all packet_merge state reads and writes against all TIR create/modify operations. Include the modify operations of the regular redirection steering TIRs under the new lock, for better code layering and division of responsibilities.
--- .../ethernet/mellanox/mlx5/core/en/rx_res.c | 41 ++++++++++++++++++- .../ethernet/mellanox/mlx5/core/en/rx_res.h | 6 +-- .../mellanox/mlx5/core/en_accel/ktls_rx.c | 24 +---------- 3 files changed, 44 insertions(+), 27 deletions(-)
drivers/net/ethernet/mellanox/mlx5/core/en/rx_res.c +40 -1
@@ -13,6 +13,9 @@ struct mlx5e_rx_res {unsigned int max_nch;u32 drop_rqn; +struct mlx5e_packet_merge_param pkt_merge_param; +struct rw_semaphore pkt_merge_param_sem; +struct mlx5e_rss *rss[MLX5E_MAX_NUM_RSS ];bool rss_active;u32 rss_rqns[MLX5E_INDIR_RQT_SIZE ];
@@ -392,6 +395,7 @@ static int mlx5e_rx_res_ptp_init(struct mlx5e_rx_res *res)if (err) goto out; +/* Separated from the channels RQs, does not share pkt_merge state with them */ mlx5e_tir_builder_build_rqt (builder, res->mdev->mlx5e_res.hw_objs.td.tdn,mlx5e_rqt_get_rqtn (&res->ptp.rqt), inner_ft_support);
@@ -447,6 +451,9 @@ int mlx5e_rx_res_init(struct mlx5e_rx_res *res, struct mlx5_core_dev *mdev, res->max_nch = max_nch; res->drop_rqn = drop_rqn; + res->pkt_merge_param = *init_pkt_merge_param; +init_rwsem (&res->pkt_merge_param_sem); + err =mlx5e_rx_res_rss_init_def (res, init_pkt_merge_param, init_nch);if (err) goto err_out;
@@ -513,7 +520,7 @@ u32 mlx5e_rx_res_get_tirn_ptp(struct mlx5e_rx_res *res)return mlx5e_tir_get_tirn (&res->ptp.tir); } -u32 mlx5e_rx_res_get_rqtn_direct (struct mlx5e_rx_res *res,unsigned int ix) +static u32 mlx5e_rx_res_get_rqtn_direct (struct mlx5e_rx_res *res,unsigned int ix) {return mlx5e_rqt_get_rqtn (&res->channels[ix].direct_rqt); }
@@ -656,6 +663,9 @@ int mlx5e_rx_res_packet_merge_set_param(struct mlx5e_rx_res *res,if (!builder)return -ENOMEM ; +down_write (&res->pkt_merge_param_sem); + res->pkt_merge_param = *pkt_merge_param; +mlx5e_tir_builder_build_packet_merge (builder, pkt_merge_param); final_err =0 ;
@@ -681,6 +691,7 @@ int mlx5e_rx_res_packet_merge_set_param(struct mlx5e_rx_res *res, } } +up_write (&res->pkt_merge_param_sem);mlx5e_tir_builder_free (builder);return final_err; }
@@ -689,3 +700,31 @@ struct mlx5e_rss_params_hash mlx5e_rx_res_get_current_hash(struct mlx5e_rx_res * {return mlx5e_rss_get_hash (res->rss[0 ]); } + +int mlx5e_rx_res_tls_tir_create (struct mlx5e_rx_res *res,unsigned int rxq, +struct mlx5e_tir *tir) +{ +bool inner_ft_support = res->features &MLX5E_RX_RES_FEATURE_INNER_FT ; +struct mlx5e_tir_builder *builder; +u32 rqtn; +int err; + + builder =mlx5e_tir_builder_alloc (false); +if (!builder) +return -ENOMEM ; + + rqtn =mlx5e_rx_res_get_rqtn_direct (res, rxq); + +mlx5e_tir_builder_build_rqt (builder, res->mdev->mlx5e_res.hw_objs.td.tdn, rqtn, + inner_ft_support); +mlx5e_tir_builder_build_direct (builder); +mlx5e_tir_builder_build_tls (builder); +down_read (&res->pkt_merge_param_sem); +mlx5e_tir_builder_build_packet_merge (builder, &res->pkt_merge_param); + err =mlx5e_tir_init (tir, builder, res->mdev, false); +up_read (&res->pkt_merge_param_sem); + +mlx5e_tir_builder_free (builder); + +return err; +}
drivers/net/ethernet/mellanox/mlx5/core/en/rx_res.h +3 -3
@@ -37,9 +37,6 @@ u32 mlx5e_rx_res_get_tirn_rss(struct mlx5e_rx_res *res, enum mlx5_traffic_typesu32 mlx5e_rx_res_get_tirn_rss_inner (struct mlx5e_rx_res *res,enum mlx5_traffic_types tt);u32 mlx5e_rx_res_get_tirn_ptp (struct mlx5e_rx_res *res); -/* RQTN getters for modules that create their own TIRs */ -u32 mlx5e_rx_res_get_rqtn_direct (struct mlx5e_rx_res *res,unsigned int ix); -/* Activate/deactivate API */ void mlx5e_rx_res_channels_activate (struct mlx5e_rx_res *res,struct mlx5e_channels *chs);void mlx5e_rx_res_channels_deactivate (struct mlx5e_rx_res *res);
@@ -69,4 +66,7 @@ struct mlx5e_rss *mlx5e_rx_res_rss_get(struct mlx5e_rx_res *res, u32 rss_idx);/* Workaround for hairpin */ struct mlx5e_rss_params_hash mlx5e_rx_res_get_current_hash (struct mlx5e_rx_res *res); +/* Accel TIRs */ +int mlx5e_rx_res_tls_tir_create (struct mlx5e_rx_res *res,unsigned int rxq, +struct mlx5e_tir *tir);#endif /* __MLX5_EN_RX_RES_H__ */
drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c +1 -23
@@ -100,25 +100,6 @@ mlx5e_ktls_rx_resync_create_resp_list(void)return resp_list; } -static int mlx5e_ktls_create_tir (struct mlx5_core_dev *mdev,struct mlx5e_tir *tir,u32 rqtn) -{ -struct mlx5e_tir_builder *builder; -int err; - - builder =mlx5e_tir_builder_alloc (false); -if (!builder) -return -ENOMEM ; - -mlx5e_tir_builder_build_rqt (builder, mdev->mlx5e_res.hw_objs.td.tdn, rqtn, false); -mlx5e_tir_builder_build_direct (builder); -mlx5e_tir_builder_build_tls (builder); - err =mlx5e_tir_init (tir, builder, mdev, false); - -mlx5e_tir_builder_free (builder); - -return err; -} -static void accel_rule_handle_work (struct work_struct *work) {struct mlx5e_ktls_offload_context_rx *priv_rx;
@@ -609,7 +590,6 @@ int mlx5e_ktls_add_rx(struct net_device *netdev, struct sock *sk,struct mlx5_core_dev *mdev;struct mlx5e_priv *priv;int rxq, err; -u32 rqtn; tls_ctx =tls_get_ctx (sk); priv =netdev_priv (netdev);
@@ -635,9 +615,7 @@ int mlx5e_ktls_add_rx(struct net_device *netdev, struct sock *sk, priv_rx->sw_stats = &priv->tls->sw_stats;mlx5e_set_ktls_rx_priv_ctx (tls_ctx, priv_rx); - rqtn =mlx5e_rx_res_get_rqtn_direct (priv->rx_res, rxq); - - err =mlx5e_ktls_create_tir (mdev, &priv_rx->tir, rqtn); + err =mlx5e_rx_res_tls_tir_create (priv->rx_res, rxq, &priv_rx->tir);if (err) goto err_create_tir;
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 184/207 serial: 8250_bcm7271: UART errors after resuming from S2
In reply to Greg Kroah-HartmanFrom: Al Cooper <[email protected]>
[ Upstream commit 9cabe26e65a893afd5846908aa393bd283ab6609 ]
There is a small window in time during resume where the hardware flow control signal RTS can be asserted (which allows a sender to resume sending data to the UART) but the baud rate has not yet been restored. This will cause corrupted data and FRAMING, OVERRUN and BREAK errors. This is happening because the MCTRL register is shadowed in uart_port struct and is later used during resume to set the MCTRL register during both serial8250_do_startup() and uart_resume_port(). Unfortunately, serial8250_do_startup() happens before the UART baud rate is restored. The fix is to clear the shadowed mctrl value at the end of suspend and restore it at the end of resume.
--- drivers/tty/serial/8250/8250_bcm7271.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)
drivers/tty/serial/8250/8250_bcm7271.c +13 -0
@@ -237,6 +237,7 @@ struct brcmuart_priv {u32 rx_err;u32 rx_timeout;u32 rx_abort; +u32 saved_mctrl; };static struct dentry *brcmuart_debugfs_root;
@@ -1133,16 +1134,27 @@ static int brcmuart_remove(struct platform_device *pdev)static int __maybe_unused brcmuart_suspend (struct device *dev) {struct brcmuart_priv *priv =dev_get_drvdata (dev); +struct uart_8250_port *up =serial8250_get_port (priv->line); +struct uart_port *port = &up->port;serial8250_suspend_port (priv->line);clk_disable_unprepare (priv->baud_mux_clk); +/* +* This will prevent resume from enabling RTS before the +* baud rate has been resored. +*/ + priv->saved_mctrl = port->mctrl; + port->mctrl =0 ; +return 0 ; }static int __maybe_unused brcmuart_resume (struct device *dev) {struct brcmuart_priv *priv =dev_get_drvdata (dev); +struct uart_8250_port *up =serial8250_get_port (priv->line); +struct uart_port *port = &up->port;int ret; ret =clk_prepare_enable (priv->baud_mux_clk);
@@ -1165,6 +1177,7 @@ static int __maybe_unused brcmuart_resume(struct device *dev)start_rx_dma (serial8250_get_port (priv->line)); }serial8250_resume_port (priv->line); + port->mctrl = priv->saved_mctrl;return 0 ; }
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 185/207 parisc: Fix KBUILD_IMAGE for self-extracting kernel
In reply to Greg Kroah-HartmanFrom: Helge Deller <[email protected]>
commit 1d7c29b77725d05faff6754d2f5e7c147aedcf93 upstream.
Default KBUILD_IMAGE to $(boot)/bzImage if a self-extracting (CONFIG_PARISC_SELF_EXTRACT=y) kernel is to be built. This fixes the bindeb-pkg make target.
--- arch/parisc/Makefile | 5 +++++ 1 file changed, 5 insertions(+)
arch/parisc/Makefile +5 -0
@@ -17,7 +17,12 @@ # Mike Shaver, Helge Deller and Martin K. Petersen # +ifdef CONFIG_PARISC_SELF_EXTRACT +boot := arch/parisc/boot +KBUILD_IMAGE := $(boot)/bzImage +else KBUILD_IMAGE := vmlinuz +endif NM = sh $(srctree)/arch/parisc/nm CHECKFLAGS += -D__hppa__=1
Greg Kroah-Hartman
maintainerPATCH 186/207 parisc: Fix "make install" on newer debian releases
In reply to Greg Kroah-HartmanFrom: Helge Deller <[email protected]>
commit 0f9fee4cdebfbe695c297e5b603a275e2557c1cc upstream.
On newer debian releases the debian-provided "installkernel" script is installed in /usr/sbin. Fix the kernel install.sh script to look for the script in this directory as well.
--- arch/parisc/install.sh | 1 + 1 file changed, 1 insertion(+)
arch/parisc/install.sh +1 -0
@@ -39,6 +39,7 @@ verify "$3" if [ -n "${INSTALLKERNEL}" ]; then if [ -x ~/bin/${INSTALLKERNEL} ]; then exec ~/bin/${INSTALLKERNEL} "$@"; fi if [ -x /sbin/${INSTALLKERNEL} ]; then exec /sbin/${INSTALLKERNEL} "$@"; fi + if [ -x /usr/sbin/${INSTALLKERNEL} ]; then exec /usr/sbin/${INSTALLKERNEL} "$@"; fi fi # Default install
Greg Kroah-Hartman
maintainerPATCH 187/207 parisc: Mark cr16 CPU clocksource unstable on all SMP machines
In reply to Greg Kroah-HartmanFrom: Helge Deller <[email protected]>
commit afdb4a5b1d340e4afffc65daa21cc71890d7d589 upstream.
In commit c8c3735997a3 ("parisc: Enhance detection of synchronous cr16 clocksources") I assumed that CPUs on the same physical core are syncronous. While booting up the kernel on two different C8000 machines, one with a dual-core PA8800 and one with a dual-core PA8900 CPU, this turned out to be wrong. The symptom was that I saw a jump in the internal clocks printed to the syslog and strange overall behaviour. On machines which have 4 cores (2 dual-cores) the problem isn't visible, because the current logic already marked the cr16 clocksource unstable in this case.
This patch now marks the cr16 interval timers unstable if we have more than one CPU in the system, and it fixes this issue.
--- arch/parisc/kernel/time.c | 28 +++++++--------------------- 1 file changed, 7 insertions(+), 21 deletions(-)
arch/parisc/kernel/time.c +7 -21
@@ -249,30 +249,16 @@ void __init time_init(void)static int __init init_cr16_clocksource (void ) {/* -* The cr16 interval timers are not syncronized across CPUs on -* different sockets, so mark them unstable and lower rating on -* multi-socket SMP systems. +* The cr16 interval timers are not syncronized across CPUs, even if +* they share the same socket. */ if (num_online_cpus () >1 && !running_on_qemu) { -int cpu; -unsigned long cpu0_loc; - cpu0_loc =per_cpu (cpu_data,0 ).cpu_loc; +/* mark sched_clock unstable */ +clear_sched_clock_stable (); -for_each_online_cpu (cpu) { -if (cpu ==0 ) -continue ; -if ((cpu0_loc !=0 ) && - (cpu0_loc ==per_cpu (cpu_data, cpu).cpu_loc)) -continue ; - -/* mark sched_clock unstable */ -clear_sched_clock_stable (); - - clocksource_cr16.name ="cr16_unstable" ; - clocksource_cr16.flags =CLOCK_SOURCE_UNSTABLE ; - clocksource_cr16.rating =0 ; -break ; - } + clocksource_cr16.name ="cr16_unstable" ; + clocksource_cr16.flags =CLOCK_SOURCE_UNSTABLE ; + clocksource_cr16.rating =0 ; }/* register at clocksource framework */
Greg Kroah-Hartman
maintainerPATCH 188/207 vgacon: Propagate console boot parameters before calling `vc_resize
In reply to Greg Kroah-HartmanFrom: Maciej W. Rozycki <[email protected]>
commit 3dfac26e2ef29ff2abc2a75aa4cd48fce25a2c4b upstream.
Fix a division by zero in `vgacon_resize' with a backtrace like:
vgacon_resizevc_do_resizevgacon_initdo_bind_con_driverdo_unbind_con_driverfbcon_fb_unbinddo_unregister_framebufferdo_register_framebufferregister_framebuffer__drm_fb_helper_initial_config_and_unlockdrm_helper_hpd_irq_eventdw_hdmi_irqirq_thread
kthread
caused by `c->vc_cell_height' not having been initialized. This has only started to trigger with commit 860dafa90259 ("vt: Fix character height handling with VT_RESIZEX"), however the ultimate offender is commit 50ec42edd978 ("[PATCH] Detaching fbcon: fix vgacon to allow retaking of the console").
Said commit has added a call to vc_resize' whenever vgacon_init' is called with the init' argument set to 0, which did not happen before. And the call is made before a key vgacon boot parameter retrieved in vgacon_startup' has been propagated in vgacon_init' for vc_resize' to use to the console structure being worked on. Previously the parameter was c->vc_font.height' and now it is c->vc_cell_height'.
In this particular scenario the registration of fbcon has failed and vt resorts to vgacon. Now fbcon does have initialized c->vc_font.height' somehow, unlike c->vc_cell_height', which is why this code did not crash before, but either way the boot parameters should have been copied to the console structure ahead of the call to vc_resize' rather than afterwards, so that first the call has a chance to use them and second they do not change the console structure to something possibly different from what was used by vc_resize'.
Move the propagation of the vgacon boot parameters ahead of the call to `vc_resize' then. Adjust the comment accordingly.
--- drivers/video/console/vgacon.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-)
drivers/video/console/vgacon.c +9 -5
@@ -366,11 +366,17 @@ static void vgacon_init(struct vc_data *struct uni_pagedir *p;/* -* We cannot be loaded as a module, therefore init is always 1, -* but vgacon_init can be called more than once, and init will -* not be 1. +* We cannot be loaded as a module, therefore init will be 1 +* if we are the default console, however if we are a fallback +* console, for example if fbcon has failed registration, then +* init will be 0, so we need to make sure our boot parameters +* have been copied to the console structure for vgacon_resize +* ultimately called by vc_resize. Any subsequent calls to +* vgacon_init init will have init set to 0 too. */ c->vc_can_do_color = vga_can_do_color; + c->vc_scan_lines = vga_scan_lines; + c->vc_font.height = c->vc_cell_height = vga_video_font_height;/* set dimensions manually if init != 0 since vc_resize() will fail */ if (init) {
@@ -379,8 +385,6 @@ static void vgacon_init(struct vc_data * }else vc_resize (c, vga_video_num_columns, vga_video_num_lines); - c->vc_scan_lines = vga_scan_lines; - c->vc_font.height = c->vc_cell_height = vga_video_font_height; c->vc_complement_mask =0x7700 ;if (vga_512_chars) c->vc_hi_font_mask =0x0800 ;
Greg Kroah-Hartman
maintainerPATCH 189/207 xhci: Fix commad ring abort, write all 64 bits to CRCR register.
In reply to Greg Kroah-HartmanFrom: Mathias Nyman <[email protected]>
commit 09f736aa95476631227d2dc0e6b9aeee1ad7ed58 upstream.
Turns out some xHC controllers require all 64 bits in the CRCR register to be written to execute a command abort.
The lower 32 bits containing the command abort bit is written first. In case the command ring stops before we write the upper 32 bits then hardware may use these upper bits to set the commnd ring dequeue pointer.
Solve this by making sure the upper 32 bits contain a valid command ring dequeue pointer.
The original patch that only wrote the first 32 to stop the ring went to stable, so this fix should go there as well.
--- drivers/usb/host/xhci-ring.c | 21 ++++++++++++++------- 1 file changed, 14 insertions(+), 7 deletions(-)
drivers/usb/host/xhci-ring.c +14 -7
@@ -366,7 +366,9 @@ static void xhci_handle_stopped_cmd_ring/* Must be called with xhci->lock held, releases and aquires lock back */ static int xhci_abort_cmd_ring (struct xhci_hcd *xhci,unsigned long flags) { -u32 temp_32; +struct xhci_segment *new_seg = xhci->cmd_ring->deq_seg; +union xhci_trb *new_deq = xhci->cmd_ring->dequeue; +u64 crcr;int ret;xhci_dbg (xhci,"Abort command ring\n" );
@@ -375,13 +377,18 @@ static int xhci_abort_cmd_ring(struct xh/* * The control bits like command stop, abort are located in lower -* dword of the command ring control register. Limit the write -* to the lower dword to avoid corrupting the command ring pointer -* in case if the command ring is stopped by the time upper dword -* is written. +* dword of the command ring control register. +* Some controllers require all 64 bits to be written to abort the ring. +* Make sure the upper dword is valid, pointing to the next command, +* avoiding corrupting the command ring pointer in case the command ring +* is stopped by the time the upper dword is written. */ - temp_32 =readl (&xhci->op_regs->cmd_ring); -writel (temp_32 |CMD_RING_ABORT , &xhci->op_regs->cmd_ring); +next_trb (xhci,NULL , &new_seg, &new_deq); +if (trb_is_link (new_deq)) +next_trb (xhci,NULL , &new_seg, &new_deq); + + crcr =xhci_trb_virt_to_dma (new_seg, new_deq); +xhci_write_64 (xhci, crcr |CMD_RING_ABORT , &xhci->op_regs->cmd_ring);/* Section 4.6.1.2 of xHCI 1.0 spec says software should also time the * completion of the Command Abort operation. If CRR is not negated in 5
Greg Kroah-Hartman
maintainerPATCH 190/207 USB: NO_LPM quirk Lenovo Powered USB-C Travel Hub
In reply to Greg Kroah-HartmanFrom: Ole Ernst <[email protected]>
commit d2a004037c3c6afd36d40c384d2905f47cd51c57 upstream.
This is another branded 8153 device that doesn't work well with LPM:
r8152 2-2.1:1.0 enp0s13f0u2u1: Stop submitting intr, status -71
Disable LPM to resolve the issue.
--- drivers/usb/core/quirks.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/usb/core/quirks.c +3 -0
@@ -434,6 +434,9 @@ static const struct usb_device_id usb_qu { USB_DEVICE(0x1532, 0x0116), .driver_info = USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL }, + /* Lenovo Powered USB-C Travel Hub (4X90S92381, RTL8153 GigE) */ + { USB_DEVICE(0x17ef, 0x721e), .driver_info = USB_QUIRK_NO_LPM }, + /* Lenovo ThinkCenter A630Z TI024Gen3 usb-audio */ { USB_DEVICE(0x17ef, 0xa012), .driver_info = USB_QUIRK_DISCONNECT_SUSPEND },
Greg Kroah-Hartman
maintainerPATCH 191/207 usb: typec: tcpm: Wait in SNK_DEBOUNCED until disconnect
In reply to Greg Kroah-HartmanFrom: Badhri Jagan Sridharan <[email protected]>
commit fbcd13df1e78eb2ba83a3c160eefe2d6f574beaf upstream.
Stub from the spec:
"4.5.2.2.4.2 Exiting from AttachWait.SNK State
A Sink shall transition to Unattached.SNK when the state of both the CC1 and CC2 pins is SNK.Open for at least tPDDebounce. A DRP shall transition to Unattached.SRC when the state of both the CC1 and CC2 pins is SNK.Open for at least tPDDebounce."
This change makes TCPM to wait in SNK_DEBOUNCED state until CC1 and CC2 pins is SNK.Open for at least tPDDebounce. Previously, TCPM resets the port if vbus is not present in PD_T_PS_SOURCE_ON. This causes TCPM to loop continuously when connected to a faulty power source that does not present vbus. Waiting in SNK_DEBOUNCED also ensures that TCPM is adherant to "4.5.2.2.4.2 Exiting from AttachWait.SNK State" requirements.
[ 6169.280751] CC1: 0 -> 0, CC2: 0 -> 5 [state TOGGLING, polarity 0, connected] [ 6169.280759] state change TOGGLING -> SNK_ATTACH_WAIT [rev2 NONE_AMS] [ 6169.280771] pending state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED @ 170 ms [rev2 NONE_AMS] [ 6169.282427] CC1: 0 -> 0, CC2: 5 -> 5 [state SNK_ATTACH_WAIT, polarity 0, connected] [ 6169.450825] state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED [delayed 170 ms] [ 6169.450834] pending state change SNK_DEBOUNCED -> PORT_RESET @ 480 ms [rev2 NONE_AMS] [ 6169.930892] state change SNK_DEBOUNCED -> PORT_RESET [delayed 480 ms] [ 6169.931296] disable vbus discharge ret:0 [ 6169.931301] Setting usb_comm capable false [ 6169.932783] Setting voltage/current limit 0 mV 0 mA [ 6169.932802] polarity 0 [ 6169.933706] Requesting mux state 0, usb-role 0, orientation 0 [ 6169.936689] cc:=0 [ 6169.936812] pending state change PORT_RESET -> PORT_RESET_WAIT_OFF @ 100 ms [rev2 NONE_AMS] [ 6169.937157] CC1: 0 -> 0, CC2: 5 -> 0 [state PORT_RESET, polarity 0, disconnected] [ 6170.036880] state change PORT_RESET -> PORT_RESET_WAIT_OFF [delayed 100 ms] [ 6170.036890] state change PORT_RESET_WAIT_OFF -> SNK_UNATTACHED [rev2 NONE_AMS] [ 6170.036896] Start toggling [ 6170.041412] CC1: 0 -> 0, CC2: 0 -> 0 [state TOGGLING, polarity 0, disconnected] [ 6170.042973] CC1: 0 -> 0, CC2: 0 -> 5 [state TOGGLING, polarity 0, connected] [ 6170.042976] state change TOGGLING -> SNK_ATTACH_WAIT [rev2 NONE_AMS] [ 6170.042981] pending state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED @ 170 ms [rev2 NONE_AMS] [ 6170.213014] state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED [delayed 170 ms] [ 6170.213019] pending state change SNK_DEBOUNCED -> PORT_RESET @ 480 ms [rev2 NONE_AMS] [ 6170.693068] state change SNK_DEBOUNCED -> PORT_RESET [delayed 480 ms] [ 6170.693304] disable vbus discharge ret:0 [ 6170.693308] Setting usb_comm capable false [ 6170.695193] Setting voltage/current limit 0 mV 0 mA [ 6170.695210] polarity 0 [ 6170.695990] Requesting mux state 0, usb-role 0, orientation 0 [ 6170.701896] cc:=0 [ 6170.702181] pending state change PORT_RESET -> PORT_RESET_WAIT_OFF @ 100 ms [rev2 NONE_AMS] [ 6170.703343] CC1: 0 -> 0, CC2: 5 -> 0 [state PORT_RESET, polarity 0, disconnected]
--- drivers/usb/typec/tcpm/tcpm.c | 4 ---- 1 file changed, 4 deletions(-)
drivers/usb/typec/tcpm/tcpm.c +0 -4
@@ -4110,11 +4110,7 @@ static void run_state_machine(struct tcptcpm_try_src (port) ?SRC_TRY :SNK_ATTACHED , 0); - else -/* Wait for VBUS, but not forever */ -tcpm_set_state (port ,PORT_RESET ,PD_T_PS_SOURCE_ON );break ; -case SRC_TRY : port->try_src_count++;tcpm_set_cc (port,tcpm_rp_cc (port));
Greg Kroah-Hartman
maintainerPATCH 192/207 usb: cdns3: gadget: fix new urb never complete if ep cancel previous requests
In reply to Greg Kroah-HartmanFrom: Frank Li <[email protected]>
commit 387c2b6ba197c6df28e75359f7d892f7c8dec204 upstream.
This issue was found at android12 MTP.
1. MTP submit many out urb request.
2. Cancel left requests (>20) when enough data get from host
3. Send ACK by IN endpoint.
4. MTP submit new out urb request.
5. 4's urb never complete.
TRACE LOG:
MtpServer-2157 [000] d..3 1287.150391: cdns3_ep_dequeue: ep1out: req: 00000000299e6836, req buff 000000009df42287, length: 0/16384 zsi, status: -115, trb: [start:87, end:87: virt addr 0x80004000ffd50420], flags:1 SID: 0 MtpServer-2157 [000] d..3 1287.150410: cdns3_gadget_giveback: ep1out: req: 00000000299e6836, req buff 000000009df42287, length: 0/16384 zsi, status: -104, trb: [start:87, end:87: virt addr 0x80004000ffd50420], flags:0 SID: 0 MtpServer-2157 [000] d..3 1287.150433: cdns3_ep_dequeue: ep1out: req: 0000000080b7bde6, req buff 000000009ed5c556, length: 0/16384 zsi, status: -115, trb: [start:88, end:88: virt addr 0x80004000ffd5042c], flags:1 SID: 0 MtpServer-2157 [000] d..3 1287.150446: cdns3_gadget_giveback: ep1out: req: 0000000080b7bde6, req buff 000000009ed5c556, length: 0/16384 zsi, status: -104, trb: [start:88, end:88: virt addr 0x80004000ffd5042c], flags:0 SID: 0 .... MtpServer-2157 [000] d..1 1293.630410: cdns3_alloc_request: ep1out: req: 00000000afbccb7d, req buff 0000000000000000, length: 0/0 zsi, status: 0, trb: [start:0, end:0: virt addr (null)], flags:0 SID: 0 MtpServer-2157 [000] d..2 1293.630421: cdns3_ep_queue: ep1out: req: 00000000afbccb7d, req buff 00000000871caf90, length: 0/512 zsi, status: -115, trb: [start:0, end:0: virt addr (null)], flags:0 SID: 0 MtpServer-2157 [000] d..2 1293.630445: cdns3_wa1: WA1: ep1out set guard MtpServer-2157 [000] d..2 1293.630450: cdns3_wa1: WA1: ep1out restore cycle bit MtpServer-2157 [000] d..2 1293.630453: cdns3_prepare_trb: ep1out: trb 000000007317b3ee, dma buf: 0xffd5bc00, size: 512, burst: 128 ctrl: 0x00000424 (C=0, T=0, ISP, IOC, Normal) SID:0 LAST_SID:0 MtpServer-2157 [000] d..2 1293.630460: cdns3_doorbell_epx: ep1out, ep_trbaddr ffd50414 .... irq/241-5b13000-2154 [000] d..1 1293.680849: cdns3_epx_irq: IRQ for ep1out: 01000408 ISP , ep_traddr: ffd508ac ep_last_sid: 00000000 use_streams: 0 irq/241-5b13000-2154 [000] d..1 1293.680858: cdns3_complete_trb: ep1out: trb 0000000021a11b54, dma buf: 0xffd50420, size: 16384, burst: 128 ctrl: 0x00001810 (C=0, T=0, CHAIN, LINK) SID:0 LAST_SID:0 irq/241-5b13000-2154 [000] d..1 1293.680865: cdns3_request_handled: Req: 00000000afbccb7d not handled, DMA pos: 185, ep deq: 88, ep enq: 185, start trb: 184, end trb: 184
Actually DMA pos already bigger than previous submit request afbccb7d's TRB (184-184). The reason of (not handled) is that deq position is wrong.
The TRB link is below when irq happen.
DEQ LINK LINK LINK LINK LINK .... TRB(afbccb7d):START DMA(EP_TRADDR).
Original code check LINK TRB, but DEQ just move one step.
LINK DEQ LINK LINK LINK LINK .... TRB(afbccb7d):START DMA(EP_TRADDR).
This patch skip all LINK TRB and sync DEQ to trb's start.
LINK LINK LINK LINK LINK .... DEQ = TRB(afbccb7d):START DMA(EP_TRADDR).
--- drivers/usb/cdns3/cdns3-gadget.c | 20 ++++---------------- 1 file changed, 4 insertions(+), 16 deletions(-)
drivers/usb/cdns3/cdns3-gadget.c +4 -16
@@ -337,19 +337,6 @@ static void cdns3_ep_inc_deq(struct cdnscdns3_ep_inc_trb (&priv_ep->dequeue, &priv_ep->ccs, priv_ep->num_trbs); } -static void cdns3_move_deq_to_next_trb (struct cdns3_request *priv_req) -{ -struct cdns3_endpoint *priv_ep = priv_req->priv_ep; -int current_trb = priv_req->start_trb; - -while (current_trb != priv_req->end_trb) { -cdns3_ep_inc_deq (priv_ep); - current_trb = priv_ep->dequeue; - } - -cdns3_ep_inc_deq (priv_ep); -} -/** * cdns3_allow_enable_l1 - enable/disable permits to transition to L1. * @priv_dev: Extended gadget object
@@ -1517,10 +1504,11 @@ static void cdns3_transfer_completed(str trb = priv_ep->trb_pool + priv_ep->dequeue; -/* Request was dequeued and TRB was changed to TRB_LINK. */ -if (TRB_FIELD_TO_TYPE (le32_to_cpu (trb->control)) ==TRB_LINK ) { +/* The TRB was changed as link TRB, and the request was handled at ep_dequeue */ +while (TRB_FIELD_TO_TYPE (le32_to_cpu (trb->control)) ==TRB_LINK ) {trace_cdns3_complete_trb (priv_ep, trb); -cdns3_move_deq_to_next_trb (priv_req); +cdns3_ep_inc_deq (priv_ep); + trb = priv_ep->trb_pool + priv_ep->dequeue; }if (!request->stream_id) {
Greg Kroah-Hartman
maintainerPATCH 193/207 usb: cdnsp: Fix a NULL pointer dereference in cdnsp_endpoint_init()
In reply to Greg Kroah-HartmanFrom: Zhou Qingyang <[email protected]>
commit 37307f7020ab38dde0892a578249bf63d00bca64 upstream.
In cdnsp_endpoint_init(), cdnsp_ring_alloc() is assigned to pep->ring and there is a dereference of it in cdnsp_endpoint_init(), which could lead to a NULL pointer dereference on failure of cdnsp_ring_alloc().
Fix this bug by adding a check of pep->ring.
This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs.
Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug.
Builds with CONFIG_USB_CDNSP_GADGET=y show no new warnings, and our static analyzer no longer warns about this code.
--- drivers/usb/cdns3/cdnsp-mem.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/usb/cdns3/cdnsp-mem.c +3 -0
@@ -987,6 +987,9 @@ int cdnsp_endpoint_init(struct cdnsp_dev/* Set up the endpoint ring. */ pep->ring =cdnsp_ring_alloc (pdev,2 , ring_type, max_packet, mem_flags); +if (!pep->ring) +return -ENOMEM ; + pep->skip = false;/* Fill the endpoint context */
Greg Kroah-Hartman
maintainerPATCH 194/207 x86/tsc: Add a timer to make sure TSC_adjust is always checked
In reply to Greg Kroah-HartmanFrom: Feng Tang <[email protected]>
commit c7719e79347803b8e3b6b50da8c6db410a3012b5 upstream.
The TSC_ADJUST register is checked every time a CPU enters idle state, but Thomas Gleixner mentioned there is still a caveat that a system won't enter idle [1], either because it's too busy or configured purposely to not enter idle.
Setup a periodic timer (every 10 minutes) to make sure the check is happening on a regular base.
[1] https://lore.kernel.org/lkml/[email protected]/
--- arch/x86/kernel/tsc_sync.c | 41 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+)
arch/x86/kernel/tsc_sync.c +41 -0
@@ -30,6 +30,7 @@ struct tsc_adjust { }; static DEFINE_PER_CPU(struct tsc_adjust, tsc_adjust); +static struct timer_list tsc_sync_check_timer;/* * TSC's on different sockets may be reset asynchronously.
@@ -77,6 +78,46 @@ void tsc_verify_tsc_adjust(bool resume) } } +/* +* Normally the tsc_sync will be checked every time system enters idle +* state, but there is still caveat that a system won't enter idle, +* either because it's too busy or configured purposely to not enter +* idle. +* +* So setup a periodic timer (every 10 minutes) to make sure the check +* is always on. +*/ + +#define SYNC_CHECK_INTERVAL (HZ * 600) + +static void tsc_sync_check_timer_fn (struct timer_list *unused) +{ +int next_cpu; + +tsc_verify_tsc_adjust (false); + +/* Run the check for all onlined CPUs in turn */ + next_cpu =cpumask_next (raw_smp_processor_id (), cpu_online_mask); +if (next_cpu >= nr_cpu_ids) + next_cpu =cpumask_first (cpu_online_mask); + + tsc_sync_check_timer.expires +=SYNC_CHECK_INTERVAL ; +add_timer_on (&tsc_sync_check_timer, next_cpu); +} + +static int __init start_sync_check_timer (void ) +{ +if (!cpu_feature_enabled (X86_FEATURE_TSC_ADJUST ) || tsc_clocksource_reliable) +return 0 ; + +timer_setup (&tsc_sync_check_timer, tsc_sync_check_timer_fn,0 ); + tsc_sync_check_timer.expires = jiffies +SYNC_CHECK_INTERVAL ; +add_timer (&tsc_sync_check_timer); + +return 0 ; +} +late_initcall (start_sync_check_timer); +static void tsc_sanitize_first_cpu (struct tsc_adjust *cur,s64 bootval,unsigned int cpu,bool bootcpu) {
Greg Kroah-Hartman
maintainerPATCH 195/207 x86/tsc: Disable clocksource watchdog for TSC on qualified platorms
In reply to Greg Kroah-HartmanFrom: Feng Tang <[email protected]>
commit b50db7095fe002fa3e16605546cba66bf1b68a3e upstream.
There are cases that the TSC clocksource is wrongly judged as unstable by the clocksource watchdog mechanism which tries to validate the TSC against HPET, PM_TIMER or jiffies. While there is hardly a general reliable way to check the validity of a watchdog, Thomas Gleixner proposed [1]:
"I'm inclined to lift that requirement when the CPU has:
1) X86_FEATURE_CONSTANT_TSC
2) X86_FEATURE_NONSTOP_TSC
3) X86_FEATURE_NONSTOP_TSC_S3
4) X86_FEATURE_TSC_ADJUST
5) At max. 4 sockets
After two decades of horrors we're finally at a point where TSC seems to be halfway reliable and less abused by BIOS tinkerers. TSC_ADJUST was really key as we can now detect even small modifications reliably and the important point is that we can cure them as well (not pretty but better than all other options)."
As feature #3 X86_FEATURE_NONSTOP_TSC_S3 only exists on several generations of Atom processorz, and is always coupled with X86_FEATURE_CONSTANT_TSC and X86_FEATURE_NONSTOP_TSC, skip checking it, and also be more defensive to use maximal 2 sockets.
The check is done inside tsc_init() before registering 'tsc-early' and 'tsc' clocksources, as there were cases that both of them had been wrongly judged as unreliable.
For more background of tsc/watchdog, there is a good summary in [2]
[tglx} Update vs. jiffies:
On systems where the only remaining clocksource aside of TSC is jiffies there is no way to make this work because that creates a circular dependency. Jiffies accuracy depends on not missing a periodic timer interrupt, which is not guaranteed. That could be detected by TSC, but as TSC is not trusted this cannot be compensated. The consequence is a circulus vitiosus which results in shutting down TSC and falling back to the jiffies clocksource which is even more unreliable.
[1]. https://lore.kernel.org/lkml/[email protected]/
[2]. https://lore.kernel.org/lkml/[email protected]/
[ tglx: Refine comment and amend changelog ]
--- arch/x86/kernel/tsc.c | 28 ++++++++++++++++++++++++---- 1 file changed, 24 insertions(+), 4 deletions(-)
arch/x86/kernel/tsc.c +24 -4
@@ -1180,6 +1180,12 @@ void mark_tsc_unstable(char *reason)EXPORT_SYMBOL_GPL (mark_tsc_unstable); +static void __init tsc_disable_clocksource_watchdog (void ) +{ + clocksource_tsc_early.flags &= ~CLOCK_SOURCE_MUST_VERIFY ; + clocksource_tsc.flags &= ~CLOCK_SOURCE_MUST_VERIFY ; +} +static void __init check_system_tsc_reliable (void ) {#if defined(CONFIG_MGEODEGX1 ) || defined(CONFIG_MGEODE_LX ) || defined(CONFIG_X86_GENERIC )
@@ -1196,6 +1202,23 @@ static void __init check_system_tsc_reli#endif if (boot_cpu_has (X86_FEATURE_TSC_RELIABLE )) tsc_clocksource_reliable =1 ; + +/* +* Disable the clocksource watchdog when the system has: +* - TSC running at constant frequency +* - TSC which does not stop in C-States +* - the TSC_ADJUST register which allows to detect even minimal +* modifications +* - not more than two sockets. As the number of sockets cannot be +* evaluated at the early boot stage where this has to be +* invoked, check the number of online memory nodes as a +* fallback solution which is an reasonable estimate. +*/ +if (boot_cpu_has (X86_FEATURE_CONSTANT_TSC ) && +boot_cpu_has (X86_FEATURE_NONSTOP_TSC ) && +boot_cpu_has (X86_FEATURE_TSC_ADJUST ) && + nr_online_nodes <=2 ) +tsc_disable_clocksource_watchdog (); }/*
@@ -1387,9 +1410,6 @@ static int __init init_tsc_clocksource(vif (tsc_unstable) goto unreg; -if (tsc_clocksource_reliable || no_tsc_watchdog) - clocksource_tsc.flags &= ~CLOCK_SOURCE_MUST_VERIFY ; -if (boot_cpu_has (X86_FEATURE_NONSTOP_TSC_S3 )) clocksource_tsc.flags |=CLOCK_SOURCE_SUSPEND_NONSTOP ;
@@ -1527,7 +1547,7 @@ void __init tsc_init(void) }if (tsc_clocksource_reliable || no_tsc_watchdog) - clocksource_tsc_early.flags &= ~CLOCK_SOURCE_MUST_VERIFY ; +tsc_disable_clocksource_watchdog ();clocksource_register_khz (&clocksource_tsc_early, tsc_khz);detect_art ();
Greg Kroah-Hartman
maintainerPATCH 196/207 x86/64/mm: Map all kernel memory into trampoline_pgd
In reply to Greg Kroah-HartmanFrom: Joerg Roedel <[email protected]>
commit 51523ed1c26758de1af7e58730a656875f72f783 upstream.
The trampoline_pgd only maps the 0xfffffff000000000-0xffffffffffffffff range of kernel memory (with 4-level paging). This range contains the kernel's text+data+bss mappings and the module mapping space but not the direct mapping and the vmalloc area.
This is enough to get the application processors out of real-mode, but for code that switches back to real-mode the trampoline_pgd is missing important parts of the address space. For example, consider this code from arch/x86/kernel/reboot.c, function machine_real_restart() for a 64-bit kernel:
#ifdef CONFIG_X86_32
load_cr3(initial_page_table);
#else
write_cr3(real_mode_header->trampoline_pgd);
/* Exiting long mode will fail if CR4.PCIDE is set. */
if (boot_cpu_has(X86_FEATURE_PCID))
cr4_clear_bits(X86_CR4_PCIDE);
#endif
/* Jump to the identity-mapped low memory code */
#ifdef CONFIG_X86_32
asm volatile("jmpl *%0" : :
"rm" (real_mode_header->machine_real_restart_asm),
"a" (type));
#else
asm volatile("ljmpl *%0" : :
"m" (real_mode_header->machine_real_restart_asm),
"D" (type));
#endifThe code switches to the trampoline_pgd, which unmaps the direct mapping and also the kernel stack. The call to cr4_clear_bits() will find no stack and crash the machine. The real_mode_header pointer below points into the direct mapping, and dereferencing it also causes a crash.
The reason this does not crash always is only that kernel mappings are global and the CR3 switch does not flush those mappings. But if theses mappings are not in the TLB already, the above code will crash before it can jump to the real-mode stub.
Extend the trampoline_pgd to contain all kernel mappings to prevent these crashes and to make code which runs on this page-table more robust.
--- arch/x86/realmode/init.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)
arch/x86/realmode/init.c +11 -1
@@ -72,6 +72,7 @@ static void __init setup_real_mode(void)#ifdef CONFIG_X86_64 u64 *trampoline_pgd;u64 efer; +int i;#endif base = (unsigned char *)real_mode_header;
@@ -128,8 +129,17 @@ static void __init setup_real_mode(void) trampoline_header->flags =0 ; trampoline_pgd = (u64 *)__va (real_mode_header->trampoline_pgd); + +/* Map the real mode stub as virtual == physical */ trampoline_pgd[0 ] = trampoline_pgd_entry.pgd; - trampoline_pgd[511 ] = init_top_pgt[511 ].pgd; + +/* +* Include the entirety of the kernel mapping into the trampoline +* PGD. This way, all mappings present in the normal kernel page +* tables are usable while running on trampoline_pgd. +*/ +for (i =pgd_index (__PAGE_OFFSET); i <PTRS_PER_PGD ; i++) + trampoline_pgd[i] = init_top_pgt[i].pgd;#endif sme_sev_setup_real_mode (trampoline_header);
Greg Kroah-Hartman
maintainerPATCH 197/207 tty: serial: msm_serial: Deactivate RX DMA for polling support
In reply to Greg Kroah-HartmanFrom: Sven Eckelmann <[email protected]>
commit 7492ffc90fa126afb67d4392d56cb4134780194a upstream.
The CONSOLE_POLLING mode is used for tools like k(g)db. In this kind of setup, it is often sharing a serial device with the normal system console. This is usually no problem because the polling helpers can consume input values directly (when in kgdb context) and the normal Linux handlers can only consume new input values after kgdb switched back.
This is not true anymore when RX DMA is enabled for UARTDM controllers. Single input values can no longer be received correctly. Instead following seems to happen:
* on 1. input, some old input is read (continuously)
* on 2. input, two old inputs are read (continuously)
* on 3. input, three old input values are read (continuously)
* on 4. input, 4 previous inputs are received
This repeats then for each group of 4 input values.
This behavior changes slightly depending on what state the controller was when the first input was received. But this makes working with kgdb basically impossible because control messages are always corrupted when kgdboc tries to parse them.
RX DMA should therefore be off when CONSOLE_POLLING is enabled to avoid these kind of problems. No such problem was noticed for TX DMA.
--- drivers/tty/serial/msm_serial.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/tty/serial/msm_serial.c +3 -0
@@ -598,6 +598,9 @@ static void msm_start_rx_dma(struct msm_u32 val;int ret; +if (IS_ENABLED (CONFIG_CONSOLE_POLL )) +return ; +if (!dma->chan)return ;
Greg Kroah-Hartman
maintainerPATCH 198/207 serial: pl011: Add ACPI SBSA UART match id
In reply to Greg Kroah-HartmanFrom: Pierre Gondois <[email protected]>
commit ac442a077acf9a6bf1db4320ec0c3f303be092b3 upstream.
The document 'ACPI for Arm Components 1.0' defines the following _HID mappings:
-'Prime cell UART (PL011)': ARMH0011
-'SBSA UART': ARMHB000
Use the sbsa-uart driver when a device is described with the 'ARMHB000' _HID.
Note:
PL011 devices currently use the sbsa-uart driver instead of the uart-pl011 driver. Indeed, PL011 devices are not bound to a clock in ACPI. It is not possible to change their baudrate.
--- drivers/tty/serial/amba-pl011.c | 1 + 1 file changed, 1 insertion(+)
drivers/tty/serial/amba-pl011.c +1 -0
@@ -2947,6 +2947,7 @@ MODULE_DEVICE_TABLE(of, sbsa_uart_of_matstatic const struct acpi_device_id __maybe_unused sbsa_uart_acpi_match[] = { {"ARMH0011" ,0 }, + {"ARMHB000" ,0 }, {}, };MODULE_DEVICE_TABLE (acpi, sbsa_uart_acpi_match);
Greg Kroah-Hartman
maintainerPATCH 199/207 serial: tegra: Change lower tolerance baud rate limit for tegra20 and tegra30
In reply to Greg Kroah-HartmanFrom: Patrik John <[email protected]>
commit b40de7469ef135161c80af0e8c462298cc5dac00 upstream.
The current implementation uses 0 as lower limit for the baud rate tolerance for tegra20 and tegra30 chips which causes isses on UART initialization as soon as baud rate clock is lower than required even when within the standard UART tolerance of +/- 4%.
This fix aligns the implementation with the initial commit description of +/- 4% tolerance for tegra chips other than tegra186 and tegra194.
--- drivers/tty/serial/serial-tegra.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/tty/serial/serial-tegra.c +2 -2
@@ -1506,7 +1506,7 @@ static struct tegra_uart_chip_data tegra .fifo_mode_enable_status = false, .uart_max_port = 5, .max_dma_burst_bytes = 4, - .error_tolerance_low_range = 0, + .error_tolerance_low_range = -4, .error_tolerance_high_range = 4, };
@@ -1517,7 +1517,7 @@ static struct tegra_uart_chip_data tegra .fifo_mode_enable_status = false, .uart_max_port = 5, .max_dma_burst_bytes = 4, - .error_tolerance_low_range = 0, + .error_tolerance_low_range = -4, .error_tolerance_high_range = 4, };
Greg Kroah-Hartman
maintainerPATCH 200/207 serial: core: fix transmit-buffer reset and memleak
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit 00de977f9e0aa9760d9a79d1e41ff780f74e3424 upstream.
Commit 761ed4a94582 ("tty: serial_core: convert uart_close to use tty_port_close") converted serial core to use tty_port_close() but failed to notice that the transmit buffer still needs to be freed on final close.
Not freeing the transmit buffer means that the buffer is no longer cleared on next open so that any ioctl() waiting for the buffer to drain might wait indefinitely (e.g. on termios changes) or that stale data can end up being transmitted in case tx is restarted.
Furthermore, the buffer of any port that has been opened would leak on driver unbind.
Note that the port lock is held when clearing the buffer pointer due to the ldisc race worked around by commit a5ba1d95e46e ("uart: fix race between uart_put_char() and uart_shutdown()").
Also note that the tty-port shutdown() callback is not called for console ports so it is not strictly necessary to free the buffer page after releasing the lock (cf. d72402145ace ("tty/serial: do not free trasnmit buffer page under port lock")).
--- drivers/tty/serial/serial_core.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)
drivers/tty/serial/serial_core.c +12 -1
@@ -1549,6 +1549,7 @@ static void uart_tty_port_shutdown(struc { struct uart_state *state = container_of(port, struct uart_state, port);struct uart_port *uport =uart_port_check (state); +char *buf;/* * At this point, we stop accepting input. To do this, we
@@ -1570,8 +1571,18 @@ static void uart_tty_port_shutdown(struc*/ tty_port_set_suspended (port,0 ); -uart_change_pm (state,UART_PM_STATE_OFF ); +/* +* Free the transmit buffer. +*/ +spin_lock_irq (&uport->lock); + buf = state->xmit.buf; + state->xmit.buf =NULL ; +spin_unlock_irq (&uport->lock); + +if (buf) +free_page ((unsigned long )buf); +uart_change_pm (state,UART_PM_STATE_OFF ); }static void uart_wait_until_sent (struct tty_struct *tty,int timeout)
Greg Kroah-Hartman
maintainerPATCH 201/207 serial: 8250_pci: Fix ACCES entries in pci_serial_quirks array
In reply to Greg Kroah-HartmanFrom: Jay Dolan <[email protected]>
commit c525c5d2437f93520388920baac6d9340c65d239 upstream.
Fix error in table for PCI_DEVICE_ID_ACCESIO_PCIE_ICM_4S that caused it and PCI_DEVICE_ID_ACCESIO_PCIE_ICM232_4 to be missing their fourth port.
--- drivers/tty/serial/8250/8250_pci.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
drivers/tty/serial/8250/8250_pci.c +8 -1
@@ -2317,11 +2317,18 @@ static struct pci_serial_quirk pci_seria .setup = pci_pericom_setup_four_at_eight, }, { - .vendor = PCI_DEVICE_ID_ACCESIO_PCIE_ICM_4S, + .vendor = PCI_VENDOR_ID_ACCESIO, .device = PCI_DEVICE_ID_ACCESIO_PCIE_ICM232_4, .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID, .setup = pci_pericom_setup_four_at_eight, + }, + { + .vendor = PCI_VENDOR_ID_ACCESIO, + .device = PCI_DEVICE_ID_ACCESIO_PCIE_ICM_4S, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, + .setup = pci_pericom_setup_four_at_eight, }, { .vendor = PCI_VENDOR_ID_ACCESIO,
Greg Kroah-Hartman
maintainerPATCH 202/207 serial: 8250_pci: rewrite pericom_do_set_divisor()
In reply to Greg Kroah-HartmanFrom: Jay Dolan <[email protected]>
commit bb1201d4b38ec67bd9a871cf86b0cc10f28b15b5 upstream.
Have pericom_do_set_divisor() use the uartclk instead of a hard coded value to work with different speed crystals. Tested with 14.7456 and 24 MHz crystals.
Have pericom_do_set_divisor() always calculate the divisor rather than call serial8250_do_set_divisor() for rates below baud_base.
Do not write registers or call serial8250_do_set_divisor() if valid divisors could not be found.
--- drivers/tty/serial/8250/8250_pci.c | 30 +++++++++++++++++------------- 1 file changed, 17 insertions(+), 13 deletions(-)
drivers/tty/serial/8250/8250_pci.c +17 -13
@@ -1349,29 +1349,33 @@ pericom_do_set_divisor(struct uart_port {int scr;int lcr; -int actual_baud; -int tolerance; -for (scr =5 ; scr <=15 ; scr++) { - actual_baud =921600 *16 / scr; - tolerance = actual_baud /50 ; +for (scr =16 ; scr >4 ; scr--) { +unsigned int maxrate = port->uartclk / scr; +unsigned int divisor =max (maxrate / baud,1U ); +int delta = maxrate / divisor - baud; -if ((baud < actual_baud + tolerance) && - (baud > actual_baud - tolerance)) { +if (baud > maxrate + baud /50 ) +continue ; +if (delta > baud /50 ) + divisor++; + +if (divisor >0xffff ) +continue ; + +/* Update delta due to possible divisor change */ + delta = maxrate / divisor - baud; +if (abs (delta) < baud /50 ) { lcr =serial_port_in (port,UART_LCR );serial_port_out (port,UART_LCR , lcr |0x80 ); - -serial_port_out (port,UART_DLL ,1 ); -serial_port_out (port,UART_DLM ,0 ); +serial_port_out (port,UART_DLL , divisor &0xff ); +serial_port_out (port,UART_DLM , divisor >>8 &0xff );serial_port_out (port,2 ,16 - scr);serial_port_out (port,UART_LCR , lcr);return ; - }else if (baud > actual_baud) { -break ; } } -serial8250_do_set_divisor (port, baud, quot, quot_frac); } static int pci_pericom_setup(struct serial_private *priv, const struct pciserial_board *board,
Greg Kroah-Hartman
maintainerPATCH 203/207 serial: 8250: Fix RTS modem control while in rs485 mode
In reply to Greg Kroah-HartmanFrom: Lukas Wunner <[email protected]>
commit f85e04503f369b3f2be28c83fc48b74e19936ebc upstream.
Commit f45709df7731 ("serial: 8250: Don't touch RTS modem control while in rs485 mode") sought to prevent user space from interfering with rs485 communication by ignoring a TIOCMSET ioctl() which changes RTS polarity.
It did so in serial8250_do_set_mctrl(), which turns out to be too deep in the call stack: When a uart_port is opened, RTS polarity is set by the rs485-aware function uart_port_dtr_rts(). It calls down to serial8250_do_set_mctrl() and that particular RTS polarity change should *not* be ignored.
The user-visible result is that on 8250_omap ports which use rs485 with inverse polarity (RTS bit in MCR register is 1 to receive, 0 to send), a newly opened port initially sets up RTS for sending instead of receiving. That's because omap_8250_startup() sets the cached value up->mcr to 0 and omap_8250_restore_regs() subsequently writes it to the MCR register. Due to the commit, serial8250_do_set_mctrl() preserves that incorrect register value:
do_sys_openat2
do_filp_open
path_openat
vfs_open
do_dentry_open
chrdev_open
tty_open
uart_open
tty_port_open
uart_port_activate
uart_startup
uart_port_startup
serial8250_startup
omap_8250_startup # up->mcr = 0
uart_change_speed
serial8250_set_termios
omap_8250_set_termios
omap_8250_restore_regs
serial8250_out_MCR # up->mcr written
tty_port_block_til_ready
uart_dtr_rts
uart_port_dtr_rts
serial8250_set_mctrl
omap8250_set_mctrl
serial8250_do_set_mctrl # mcr[1] = 1 ignoredFix by intercepting RTS changes from user space in uart_tiocmset() instead.
--- drivers/tty/serial/8250/8250_port.c | 7 ------- drivers/tty/serial/serial_core.c | 5 +++++ 2 files changed, 5 insertions(+), 7 deletions(-)
drivers/tty/serial/8250/8250_port.c +0 -7
@@ -2024,13 +2024,6 @@ void serial8250_do_set_mctrl(struct uartstruct uart_8250_port *up =up_to_u8250p (port);unsigned char mcr; -if (port->rs485.flags &SER_RS485_ENABLED ) { -if (serial8250_in_MCR (up) &UART_MCR_RTS ) - mctrl |=TIOCM_RTS ; -else - mctrl &= ~TIOCM_RTS ; - } - mcr =serial8250_TIOCM_to_MCR (mctrl); mcr = (mcr & up->mcr_mask) | up->mcr_force | up->mcr;
drivers/tty/serial/serial_core.c +5 -0
@@ -1075,6 +1075,11 @@ uart_tiocmset(struct tty_struct *tty, un goto out;if (!tty_io_error (tty)) { +if (uport->rs485.flags &SER_RS485_ENABLED ) { + set &= ~TIOCM_RTS ; + clear &= ~TIOCM_RTS ; + } +uart_update_mctrl (uport, set, clear); ret =0 ; }
Greg Kroah-Hartman
maintainerPATCH 204/207 serial: liteuart: Fix NULL pointer dereference in ->remove()
In reply to Greg Kroah-HartmanFrom: Ilia Sergachev <[email protected]>
commit 0f55f89d98c8b3e12b4f55f71c127a173e29557c upstream.
drvdata has to be set in _probe() - otherwise platform_get_drvdata() causes null pointer dereference BUG in _remove().
--- drivers/tty/serial/liteuart.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/tty/serial/liteuart.c +2 -0
@@ -285,6 +285,8 @@ static int liteuart_probe(struct platfor port->line = dev_id;spin_lock_init (&port->lock); +platform_set_drvdata (pdev, port); +return uart_add_one_port (&liteuart_driver, &uart->port); }
Greg Kroah-Hartman
maintainerPATCH 205/207 serial: liteuart: fix use-after-free and memleak on unbind
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit 05f929b395dec8957b636ff14e66b277ed022ed9 upstream.
Deregister the port when unbinding the driver to prevent it from being used after releasing the driver data and leaking memory allocated by serial core.
--- drivers/tty/serial/liteuart.c | 1 + 1 file changed, 1 insertion(+)
drivers/tty/serial/liteuart.c +1 -0
@@ -295,6 +295,7 @@ static int liteuart_remove(struct platfostruct uart_port *port =platform_get_drvdata (pdev);struct liteuart_port *uart =to_liteuart_port (port); +uart_remove_one_port (&liteuart_driver, port);xa_erase (&liteuart_array, uart->id);return 0 ;
Greg Kroah-Hartman
maintainerPATCH 206/207 serial: liteuart: fix minor-number leak on probe errors
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit dd5e90b16cca8a697cbe17b72e2a5f49291cabb2 upstream.
Make sure to release the allocated minor number before returning on probe errors.
--- drivers/tty/serial/liteuart.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-)
drivers/tty/serial/liteuart.c +14 -3
@@ -270,8 +270,10 @@ static int liteuart_probe(struct platfor/* get membase */ port->membase =devm_platform_get_and_ioremap_resource (pdev,0 ,NULL ); -if (IS_ERR (port->membase)) -return PTR_ERR (port->membase); +if (IS_ERR (port->membase)) { + ret =PTR_ERR (port->membase); + goto err_erase_id; + }/* values not from device tree */ port->dev = &pdev->dev;
@@ -287,7 +289,16 @@ static int liteuart_probe(struct platforplatform_set_drvdata (pdev, port); -return uart_add_one_port (&liteuart_driver, &uart->port); + ret =uart_add_one_port (&liteuart_driver, &uart->port); +if (ret) + goto err_erase_id; + +return 0 ; + +err_erase_id: +xa_erase (&liteuart_array, uart->id); + +return ret; }static int liteuart_remove (struct platform_device *pdev)
Greg Kroah-Hartman
maintainerPATCH 207/207 ipmi: msghandler: Make symbol remove_work_wq static
In reply to Greg Kroah-HartmanFrom: Wei Yongjun <[email protected]>
commit 5a3ba99b62d8486de0316334e72ac620d4b94fdd upstream.
The sparse tool complains as follows:
drivers/char/ipmi/ipmi_msghandler.c:194:25: warning:
symbol 'remove_work_wq' was not declared. Should it be static?
This symbol is not used outside of ipmi_msghandler.c, so marks it static.
Message-Id: <[email protected]>
--- drivers/char/ipmi/ipmi_msghandler.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/char/ipmi/ipmi_msghandler.c +1 -1
@@ -191,7 +191,7 @@ struct ipmi_user {struct work_struct remove_work; }; -struct workqueue_struct *remove_work_wq; +static struct workqueue_struct *remove_work_wq;static struct ipmi_user *acquire_ipmi_user (struct ipmi_user *user,int *index) __acquires(user->release_barrier)
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.7 release. There are 207 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, 08 Dec 2021 14:55:37 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels:
Signature · 1 line
Florian
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.7 release. There are 207 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, 08 Dec 2021 14:55:37 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.7 release. There are 207 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, 08 Dec 2021 14:55:37 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
5.15.7-rc1 Successfully Compiled and booted on my Raspberry PI 4b (8g) (bcm2711)
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.7 release. There are 207 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, 08 Dec 2021 14:55:37 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
## Build
* kernel: 5.15.7-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git branch: linux-5.15.y
* git commit: 47c02c404f4a01320618263ee704576959e3de43
* git describe: v5.15.6-208-g47c02c404f4a
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.15.y/build/v5.15.6-208-g47c02c404f4a
## No Test Regressions (compared to v5.15.6)
## No Test Fixes (compared to v5.15.6)
## Test result summary
total: 96420, pass: 81828, fail: 1003, skip: 12755, xfail: 834
## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 260 total, 260 passed, 0 failed
* arm64: 42 total, 37 passed, 5 failed
* dragonboard-410c: 1 total, 1 passed, 0 failed
* hi6220-hikey: 1 total, 1 passed, 0 failed
* i386: 40 total, 37 passed, 3 failed
* juno-r2: 1 total, 1 passed, 0 failed
* mips: 37 total, 35 passed, 2 failed
* parisc: 14 total, 14 passed, 0 failed
* powerpc: 49 total, 44 passed, 5 failed
* riscv: 27 total, 25 passed, 2 failed
* s390: 22 total, 20 passed, 2 failed
* sh: 22 total, 20 passed, 2 failed
* sparc: 14 total, 14 passed, 0 failed
* x15: 1 total, 1 passed, 0 failed
* x86: 1 total, 1 passed, 0 failed
* x86_64: 42 total, 40 passed, 2 failed
## Test suites summary
* fwts
* kselftest-android
* kselftest-arm64
* kselftest-arm64/arm64.btitest.bti_c_func
* kselftest-arm64/arm64.btitest.bti_j_func
* kselftest-arm64/arm64.btitest.bti_jc_func
* kselftest-arm64/arm64.btitest.bti_none_func
* kselftest-arm64/arm64.btitest.nohint_func
* kselftest-arm64/arm64.btitest.paciasp_func
* kselftest-arm64/arm64.nobtitest.bti_c_func
* kselftest-arm64/arm64.nobtitest.bti_j_func
* kselftest-arm64/arm64.nobtitest.bti_jc_func
* kselftest-arm64/arm64.nobtitest.bti_none_func
* kselftest-arm64/arm64.nobtitest.nohint_func
* kselftest-arm64/arm64.nobtitest.paciasp_func
* kselftest-bpf
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-lkdtm
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mque[
* kselftest-mqueue
* kselftest-net
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* packetdrill
* perf
* perf/Zstd-perf.data-compression
* rcutorture
* ssuite
* v4l2-compliance
--
Linaro LKFT
https://lkft.linaro.org
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.7 release. There are 207 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, 08 Dec 2021 14:55:37 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
No new regressions.
Test results for stable-v5.15:
10 builds: 10 pass, 0 fail
28 boots: 28 pass, 0 fail
114 tests: 107 pass, 7 failLinux version: 5.15.7-rc1-g47c02c404f4a
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
tegra20-ventana, tegra210-p2371-2180,
tegra210-p3450-0000, tegra30-cardhu-a04Test failures: tegra194-p2972-0000: boot.py
tegra194-p2972-0000: tegra-audio-boot-sanity.sh
tegra194-p2972-0000: tegra-audio-hda-playback.sh
tegra194-p3509-0000+p3668-0000: devices
tegra194-p3509-0000+p3668-0000: tegra-audio-boot-sanity.sh
tegra194-p3509-0000+p3668-0000: tegra-audio-hda-playback.sh
tegra20-ventana: pm-system-suspend.shStill waiting for the necessary fixes to trickle into the mainline. There are 2 fixes still missing from the mainline but should be on their way.
Jon
Signature · 1 line
nvpublic
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.7 release. There are 207 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.
Quoted 8 lines
Responses should be made by Wed, 08 Dec 2021 14:55:37 +0000. 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.15.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.
Hi Greg,
Looking good.
Run tested on:
- Intel Tiger Lake x86_64 (nuc11 i7-1165G7)
In addition build tested on:
- Allwinner A64
- Allwinner H3
- Allwinner H5
- Allwinner H6
- NXP iMX6
- NXP iMX8
- Qualcomm Dragonboard
- Rockchip RK3288
- Rockchip RK3328
- Rockchip RK3399pro
- Samsung Exynos
Signature · 1 line
Rudi
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.7 release. There are 207 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, 08 Dec 2021 14:55:37 +0000. Anything received after that time might be too late.
Build results:
total: 154 pass: 154 fail: 0 Qemu test results: total: 482 pass: 482 fail: 0
Guenter