* Re: [PATCH] drm/amdgpu: Don't warn on destroying a pinned BO
From: Alex Deucher @ 2018-07-23 17:05 UTC (permalink / raw)
To: Michel Dänzer; +Cc: amd-gfx list
In-Reply-To: <b39b0ced-3a54-b18c-0e90-e829b21afd17-otUistvHUpPR7s880joybQ@public.gmane.org>
On Mon, Jul 23, 2018 at 12:50 PM, Michel Dänzer <michel@daenzer.net> wrote:
> On 2018-07-19 05:39 PM, Michel Dänzer wrote:
>> From: Michel Dänzer <michel.daenzer@amd.com>
>>
>> The warning turned out to be not so useful, as BO destruction tends to
>> be deferred to a workqueue.
>>
>> Also, we should be preventing any damage from this now, so not really
>> important anymore to fix code doing this.
>>
>> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> index b12526ce1a9d..3010f0136de9 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> @@ -89,7 +89,7 @@ static void amdgpu_ttm_bo_destroy(struct ttm_buffer_object *tbo)
>> struct amdgpu_device *adev = amdgpu_ttm_adev(tbo->bdev);
>> struct amdgpu_bo *bo = ttm_to_amdgpu_bo(tbo);
>>
>> - if (WARN_ON_ONCE(bo->pin_count > 0))
>> + if (bo->pin_count > 0)
>> amdgpu_bo_subtract_pin_size(bo);
>>
>> if (bo->kfd_bo)
>>
>
> Any feedback?
Acked-by: Alex Deucher <alexander.deucher@amd.com>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* [PATCH 6/9] ath9k: report tx status on EOSP
From: Felix Fietkau @ 2018-07-23 16:02 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo
In-Reply-To: <20180723160300.58024-1-nbd@nbd.name>
Fixes missed indications of end of U-APSD service period to mac80211
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
drivers/net/wireless/ath/ath9k/xmit.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 56a0d1b7527a..d366170f01cf 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -86,7 +86,8 @@ static void ath_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct ieee80211_sta *sta = info->status.status_driver_data[0];
- if (info->flags & IEEE80211_TX_CTL_REQ_TX_STATUS) {
+ if (info->flags & (IEEE80211_TX_CTL_REQ_TX_STATUS |
+ IEEE80211_TX_STATUS_EOSP)) {
ieee80211_tx_status(hw, skb);
return;
}
--
2.17.0
^ permalink raw reply related
* [PATCH 4/9] ath9k: fix moredata bit in PS buffered frame release
From: Felix Fietkau @ 2018-07-23 16:02 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo
In-Reply-To: <20180723160300.58024-1-nbd@nbd.name>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
drivers/net/wireless/ath/ath9k/xmit.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 7fdb152be0bb..cab24b43ac88 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -1659,6 +1659,22 @@ void ath_tx_aggr_wakeup(struct ath_softc *sc, struct ath_node *an)
}
}
+
+static void
+ath9k_set_moredata(struct ath_softc *sc, struct ath_buf *bf, bool val)
+{
+ struct ieee80211_hdr *hdr;
+ u16 mask = cpu_to_le16(IEEE80211_FCTL_MOREDATA);
+ u16 mask_val = mask * val;
+
+ hdr = (struct ieee80211_hdr *) bf->bf_mpdu->data;
+ if ((hdr->frame_control & mask) != mask_val) {
+ hdr->frame_control = (hdr->frame_control & ~mask) | mask_val;
+ dma_sync_single_for_device(sc->dev, bf->bf_buf_addr,
+ sizeof(*hdr), DMA_TO_DEVICE);
+ }
+}
+
void ath9k_release_buffered_frames(struct ieee80211_hw *hw,
struct ieee80211_sta *sta,
u16 tids, int nframes,
@@ -1689,6 +1705,7 @@ void ath9k_release_buffered_frames(struct ieee80211_hw *hw,
if (!bf)
break;
+ ath9k_set_moredata(sc, bf, true);
list_add_tail(&bf->list, &bf_q);
ath_set_rates(tid->an->vif, tid->an->sta, bf);
if (bf_isampdu(bf)) {
@@ -1712,6 +1729,9 @@ void ath9k_release_buffered_frames(struct ieee80211_hw *hw,
if (list_empty(&bf_q))
return;
+ if (!more_data)
+ ath9k_set_moredata(sc, bf_tail, false);
+
info = IEEE80211_SKB_CB(bf_tail->bf_mpdu);
info->flags |= IEEE80211_TX_STATUS_EOSP;
--
2.17.0
^ permalink raw reply related
* [PATCH 1/9] ath9k_hw: set spectral scan enable bit on trigger for AR9003+
From: Felix Fietkau @ 2018-07-23 16:02 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo
AR9002 code and the QCA AR9003+ reference code do the same.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.c b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
index fe5102ca5010..98c5f524a360 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
@@ -1800,6 +1800,8 @@ static void ar9003_hw_spectral_scan_config(struct ath_hw *ah,
static void ar9003_hw_spectral_scan_trigger(struct ath_hw *ah)
{
+ REG_SET_BIT(ah, AR_PHY_SPECTRAL_SCAN,
+ AR_PHY_SPECTRAL_SCAN_ENABLE);
/* Activate spectral scan */
REG_SET_BIT(ah, AR_PHY_SPECTRAL_SCAN,
AR_PHY_SPECTRAL_SCAN_ACTIVE);
--
2.17.0
^ permalink raw reply related
* [PATCH 3/9] ath9k: force rx_clear when disabling rx
From: Felix Fietkau @ 2018-07-23 16:02 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Felix Fietkau
In-Reply-To: <20180723160300.58024-1-nbd@nbd.name>
From: Felix Fietkau <nbd@openwrt.org>
This makes stopping Rx more reliable and should reduce the frequency of
Rx related DMA stop warnings. Don't use rx_clear in TX99 mode.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
---
drivers/net/wireless/ath/ath9k/mac.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/mac.c b/drivers/net/wireless/ath/ath9k/mac.c
index 58d02c19b6d0..c9d2bf3fa135 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -678,13 +678,18 @@ void ath9k_hw_startpcureceive(struct ath_hw *ah, bool is_scanning)
ath9k_ani_reset(ah, is_scanning);
- REG_CLR_BIT(ah, AR_DIAG_SW, (AR_DIAG_RX_DIS | AR_DIAG_RX_ABORT));
+ REG_CLR_BIT(ah, AR_DIAG_SW,
+ AR_DIAG_RX_DIS | AR_DIAG_RX_ABORT | AR_DIAG_FORCE_RX_CLEAR);
}
EXPORT_SYMBOL(ath9k_hw_startpcureceive);
void ath9k_hw_abortpcurecv(struct ath_hw *ah)
{
- REG_SET_BIT(ah, AR_DIAG_SW, AR_DIAG_RX_ABORT | AR_DIAG_RX_DIS);
+ u32 reg = AR_DIAG_RX_DIS | AR_DIAG_RX_ABORT;
+
+ if (!IS_ENABLED(CPTCFG_ATH9K_TX99))
+ reg |= AR_DIAG_FORCE_RX_CLEAR;
+ REG_SET_BIT(ah, AR_DIAG_SW, reg);
ath9k_hw_disable_mib_counters(ah);
}
--
2.17.0
^ permalink raw reply related
* [PATCH 8/9] ath9k_hw: fix channel maximum power level test
From: Felix Fietkau @ 2018-07-23 16:02 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo
In-Reply-To: <20180723160300.58024-1-nbd@nbd.name>
The tx power applied by set_txpower is limited by the CTL (conformance
test limit) entries in the EEPROM. These can change based on the user
configured regulatory domain.
Depending on the EEPROM data this can cause the tx power to become too
limited, if the original regdomain CTLs impose lower limits than the CTLs
of the user configured regdomain.
To fix this issue, set the initial channel limits without any CTL
restrictions and only apply the CTL at run time when setting the channel
and the real tx power.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
drivers/net/wireless/ath/ath9k/hw.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 1665066f4e24..9dc866404eca 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -2942,16 +2942,19 @@ void ath9k_hw_apply_txpower(struct ath_hw *ah, struct ath9k_channel *chan,
struct ath_regulatory *reg = ath9k_hw_regulatory(ah);
struct ieee80211_channel *channel;
int chan_pwr, new_pwr;
+ u16 ctl = NO_CTL;
if (!chan)
return;
+ if (!test)
+ ctl = ath9k_regd_get_ctl(reg, chan);
+
channel = chan->chan;
chan_pwr = min_t(int, channel->max_power * 2, MAX_RATE_POWER);
new_pwr = min_t(int, chan_pwr, reg->power_limit);
- ah->eep_ops->set_txpower(ah, chan,
- ath9k_regd_get_ctl(reg, chan),
+ ah->eep_ops->set_txpower(ah, chan, ctl,
get_antenna_gain(ah, chan), new_pwr, test);
}
--
2.17.0
^ permalink raw reply related
* [PATCH 5/9] ath9k: clear potentially stale EOSP status bit in intermediate queues
From: Felix Fietkau @ 2018-07-23 16:02 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo
In-Reply-To: <20180723160300.58024-1-nbd@nbd.name>
Prevents spurious ieee80211_sta_eosp calls.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
drivers/net/wireless/ath/ath9k/xmit.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index cab24b43ac88..56a0d1b7527a 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -969,7 +969,8 @@ ath_tx_get_tid_subframe(struct ath_softc *sc, struct ath_txq *txq,
bf->bf_lastbf = bf;
tx_info = IEEE80211_SKB_CB(skb);
- tx_info->flags &= ~IEEE80211_TX_CTL_CLEAR_PS_FILT;
+ tx_info->flags &= ~(IEEE80211_TX_CTL_CLEAR_PS_FILT |
+ IEEE80211_TX_STATUS_EOSP);
/*
* No aggregation session is running, but there may be frames
--
2.17.0
^ permalink raw reply related
* [PATCH 7/9] ath9k: fix block-ack window tracking issues
From: Felix Fietkau @ 2018-07-23 16:02 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo
In-Reply-To: <20180723160300.58024-1-nbd@nbd.name>
Ensure that a buffer gets tracked as part of the block-ack window as
soon as it's dequeued from the tid for the first time. Ensure that
double calls to ath_tx_addto_baw (e.g. on retransmission) don't cause
any issues.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
drivers/net/wireless/ath/ath9k/xmit.c | 29 +++++++++++++++++----------
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index d366170f01cf..bae0f6c045e1 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -62,7 +62,7 @@ static void ath_tx_rc_status(struct ath_softc *sc, struct ath_buf *bf,
struct ath_tx_status *ts, int nframes, int nbad,
int txok);
static void ath_tx_update_baw(struct ath_softc *sc, struct ath_atx_tid *tid,
- int seqno);
+ struct ath_buf *bf);
static struct ath_buf *ath_tx_setup_buffer(struct ath_softc *sc,
struct ath_txq *txq,
struct ath_atx_tid *tid,
@@ -296,7 +296,7 @@ static void ath_tx_flush_tid(struct ath_softc *sc, struct ath_atx_tid *tid)
}
if (fi->baw_tracked) {
- ath_tx_update_baw(sc, tid, bf->bf_state.seqno);
+ ath_tx_update_baw(sc, tid, bf);
sendbar = true;
}
@@ -312,10 +312,15 @@ static void ath_tx_flush_tid(struct ath_softc *sc, struct ath_atx_tid *tid)
}
static void ath_tx_update_baw(struct ath_softc *sc, struct ath_atx_tid *tid,
- int seqno)
+ struct ath_buf *bf)
{
+ struct ath_frame_info *fi = get_frame_info(bf->bf_mpdu);
+ u16 seqno = bf->bf_state.seqno;
int index, cindex;
+ if (!fi->baw_tracked)
+ return;
+
index = ATH_BA_INDEX(tid->seq_start, seqno);
cindex = (tid->baw_head + index) & (ATH_TID_MAX_BUFS - 1);
@@ -336,6 +341,9 @@ static void ath_tx_addto_baw(struct ath_softc *sc, struct ath_atx_tid *tid,
u16 seqno = bf->bf_state.seqno;
int index, cindex;
+ if (fi->baw_tracked)
+ return;
+
index = ATH_BA_INDEX(tid->seq_start, seqno);
cindex = (tid->baw_head + index) & (ATH_TID_MAX_BUFS - 1);
__set_bit(cindex, tid->tx_buf);
@@ -612,7 +620,7 @@ static void ath_tx_complete_aggr(struct ath_softc *sc, struct ath_txq *txq,
* complete the acked-ones/xretried ones; update
* block-ack window
*/
- ath_tx_update_baw(sc, tid, seqno);
+ ath_tx_update_baw(sc, tid, bf);
if (rc_update && (acked_cnt == 1 || txfail_cnt == 1)) {
memcpy(tx_info->control.rates, rates, sizeof(rates));
@@ -642,7 +650,7 @@ static void ath_tx_complete_aggr(struct ath_softc *sc, struct ath_txq *txq,
* run out of tx buf.
*/
if (!tbf) {
- ath_tx_update_baw(sc, tid, seqno);
+ ath_tx_update_baw(sc, tid, bf);
ath_tx_complete_buf(sc, bf, txq,
&bf_head, NULL, ts,
@@ -1011,11 +1019,14 @@ ath_tx_get_tid_subframe(struct ath_softc *sc, struct ath_txq *txq,
INIT_LIST_HEAD(&bf_head);
list_add(&bf->list, &bf_head);
- ath_tx_update_baw(sc, tid, seqno);
+ ath_tx_update_baw(sc, tid, bf);
ath_tx_complete_buf(sc, bf, txq, &bf_head, NULL, &ts, 0);
continue;
}
+ if (bf_isampdu(bf))
+ ath_tx_addto_baw(sc, tid, bf);
+
return bf;
}
@@ -1073,8 +1084,6 @@ ath_tx_form_aggr(struct ath_softc *sc, struct ath_txq *txq,
bf->bf_next = NULL;
/* link buffers of this frame to the aggregate */
- if (!fi->baw_tracked)
- ath_tx_addto_baw(sc, tid, bf);
bf->bf_state.ndelim = ndelim;
list_add_tail(&bf->list, bf_q);
@@ -1710,10 +1719,8 @@ void ath9k_release_buffered_frames(struct ieee80211_hw *hw,
ath9k_set_moredata(sc, bf, true);
list_add_tail(&bf->list, &bf_q);
ath_set_rates(tid->an->vif, tid->an->sta, bf);
- if (bf_isampdu(bf)) {
- ath_tx_addto_baw(sc, tid, bf);
+ if (bf_isampdu(bf))
bf->bf_state.bf_type &= ~BUF_AGGR;
- }
if (bf_tail)
bf_tail->bf_next = bf;
--
2.17.0
^ permalink raw reply related
* [PATCH 2/9] ath9k: don't run periodic and nf calibation at the same time
From: Felix Fietkau @ 2018-07-23 16:02 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo
In-Reply-To: <20180723160300.58024-1-nbd@nbd.name>
The checks already prevents periodic cal from being started while noise
floor calibration runs. It is missing checks for the other way around.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
drivers/net/wireless/ath/ath9k/ar9002_calib.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9002_calib.c b/drivers/net/wireless/ath/ath9k/ar9002_calib.c
index 50fcd343c41a..fd9db8ca99d7 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_calib.c
+++ b/drivers/net/wireless/ath/ath9k/ar9002_calib.c
@@ -676,10 +676,10 @@ static int ar9002_hw_calibrate(struct ath_hw *ah, struct ath9k_channel *chan,
return 0;
ah->cal_list_curr = currCal = currCal->calNext;
- if (currCal->calState == CAL_WAITING) {
+ if (currCal->calState == CAL_WAITING)
ath9k_hw_reset_calibration(ah, currCal);
- return 0;
- }
+
+ return 0;
}
/* Do NF cal only at longer intervals */
--
2.17.0
^ permalink raw reply related
* [PATCH 9/9] ath9k: fix more-data flag for buffered multicast packets
From: Felix Fietkau @ 2018-07-23 16:03 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo
In-Reply-To: <20180723160300.58024-1-nbd@nbd.name>
The flag needs to be cleared for the last packet in the list, not the
first one. Fixes some issues with multicast packet loss for powersave
clients connected to an ath9k AP.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
drivers/net/wireless/ath/ath9k/xmit.c | 12 +++---------
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index bae0f6c045e1..43b6c8508e49 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2436,7 +2436,6 @@ void ath_tx_cabq(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
.txq = sc->beacon.cabq
};
struct ath_tx_info info = {};
- struct ieee80211_hdr *hdr;
struct ath_buf *bf_tail = NULL;
struct ath_buf *bf;
LIST_HEAD(bf_q);
@@ -2480,15 +2479,10 @@ void ath_tx_cabq(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
if (list_empty(&bf_q))
return;
- bf = list_first_entry(&bf_q, struct ath_buf, list);
- hdr = (struct ieee80211_hdr *) bf->bf_mpdu->data;
-
- if (hdr->frame_control & cpu_to_le16(IEEE80211_FCTL_MOREDATA)) {
- hdr->frame_control &= ~cpu_to_le16(IEEE80211_FCTL_MOREDATA);
- dma_sync_single_for_device(sc->dev, bf->bf_buf_addr,
- sizeof(*hdr), DMA_TO_DEVICE);
- }
+ bf = list_last_entry(&bf_q, struct ath_buf, list);
+ ath9k_set_moredata(sc, bf, false);
+ bf = list_first_entry(&bf_q, struct ath_buf, list);
ath_txq_lock(sc, txctl.txq);
ath_tx_fill_desc(sc, bf, txctl.txq, 0);
ath_tx_txqaddbuf(sc, txctl.txq, &bf_q, false);
--
2.17.0
^ permalink raw reply related
* [PATCH] gpu/drm/vkms: Use new return type vm_fault_t
From: Souptick Joarder @ 2018-07-23 17:04 UTC (permalink / raw)
To: willy, airlied, daniel.vetter, rodrigosiqueiramelo,
gustavo.padovan, hamohammed.sa, jrdr.linux
Cc: dri-devel, linux-kernel
Use new return type vm_fault_t for fault handler.
Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
---
drivers/gpu/drm/vkms/vkms_drv.h | 2 +-
drivers/gpu/drm/vkms/vkms_gem.c | 5 ++---
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index 07be29f..d5d04a8 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -65,7 +65,7 @@ struct drm_gem_object *vkms_gem_create(struct drm_device *dev,
u32 *handle,
u64 size);
-int vkms_gem_fault(struct vm_fault *vmf);
+vm_fault_t vkms_gem_fault(struct vm_fault *vmf);
int vkms_dumb_create(struct drm_file *file, struct drm_device *dev,
struct drm_mode_create_dumb *args);
diff --git a/drivers/gpu/drm/vkms/vkms_gem.c b/drivers/gpu/drm/vkms/vkms_gem.c
index c7e3836..62e05dc 100644
--- a/drivers/gpu/drm/vkms/vkms_gem.c
+++ b/drivers/gpu/drm/vkms/vkms_gem.c
@@ -43,14 +43,14 @@ void vkms_gem_free_object(struct drm_gem_object *obj)
kfree(gem);
}
-int vkms_gem_fault(struct vm_fault *vmf)
+vm_fault_t vkms_gem_fault(struct vm_fault *vmf)
{
struct vm_area_struct *vma = vmf->vma;
struct vkms_gem_object *obj = vma->vm_private_data;
unsigned long vaddr = vmf->address;
pgoff_t page_offset;
loff_t num_pages;
- int ret;
+ vm_fault_t ret = VM_FAULT_SIGBUS;
page_offset = (vaddr - vma->vm_start) >> PAGE_SHIFT;
num_pages = DIV_ROUND_UP(obj->gem.size, PAGE_SIZE);
@@ -58,7 +58,6 @@ int vkms_gem_fault(struct vm_fault *vmf)
if (page_offset > num_pages)
return VM_FAULT_SIGBUS;
- ret = -ENOENT;
mutex_lock(&obj->pages_lock);
if (obj->pages) {
get_page(obj->pages[page_offset]);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v11 11/15] arm64: kexec_file: add crash dump support
From: James Morse @ 2018-07-23 17:04 UTC (permalink / raw)
To: AKASHI Takahiro
Cc: catalin.marinas, will.deacon, dhowells, vgoyal, herbert, davem,
dyoung, bhe, arnd, ard.biesheuvel, bhsharma, kexec,
linux-arm-kernel, linux-kernel
In-Reply-To: <20180723053923.GN11258@linaro.org>
Hi Akashi,
On 23/07/18 06:39, AKASHI Takahiro wrote:
> On Wed, Jul 18, 2018 at 05:50:22PM +0100, James Morse wrote:
>> On 11/07/18 08:41, AKASHI Takahiro wrote:
>>> Enabling crash dump (kdump) includes
>>> * prepare contents of ELF header of a core dump file, /proc/vmcore,
>>> using crash_prepare_elf64_headers(), and
>>> * add two device tree properties, "linux,usable-memory-range" and
>>> "linux,elfcorehdr", which represent respectively a memory range
>>> to be used by crash dump kernel and the header's location
>>
>>> diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
>>> index 69333694e3e2..eeb5766928b0 100644
>>> --- a/arch/arm64/include/asm/kexec.h
>>> +++ b/arch/arm64/include/asm/kexec.h
>>> @@ -99,6 +99,10 @@ static inline void crash_post_resume(void) {}
>>> struct kimage_arch {
>>> phys_addr_t dtb_mem;
>>> void *dtb_buf;
>>> + /* Core ELF header buffer */
>>
>>> + void *elf_headers;
>>
>> Shouldn't this be a phys_addr_t if it comes from kbuf.mem?
>
> Do you mean elf_load_addr? You're right.
> But kexec_buf defined mem as unsigned long and so I'd rather change
> dtb_mem to unsigned long instead of elf_load_addr, which will also be
> renamed to elf_headers_mem for clarification.
>> (dtb_mem is, and they type tells us which way round the runtime/kexec-time
>> pointers are)
My preference would be for physical addresses to always be phys_addr_t, but as
long as we can easily spot the difference kexec-time versus runtime addresses,
it will save bugs where we use the wrong one.
>>> diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
>>> index a0b44fe18b95..261564df7210 100644
>>> --- a/arch/arm64/kernel/machine_kexec_file.c
>>> +++ b/arch/arm64/kernel/machine_kexec_file.c
>>> @@ -132,6 +173,45 @@ static int setup_dtb(struct kimage *image,
>>> + kbuf.buf_min = crashk_res.start;
>>> + kbuf.buf_max = crashk_res.end + 1;
>>> + kbuf.top_down = true;
>>> +
>>> + ret = kexec_add_buffer(&kbuf);
>>> + if (ret) {
>>> + vfree(hdrs_addr);
>>> + goto out_err;
>>> + }
>>> + image->arch.elf_headers = hdrs_addr;
>>> + image->arch.elf_headers_sz = hdrs_sz;
>>> + image->arch.elf_load_addr = kbuf.mem;
>>> +
>>> + pr_debug("Loaded elf core header at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
>>> + image->arch.elf_load_addr, hdrs_sz, hdrs_sz);
>>> + }
>>> +
>>> kbuf.image = image;
>>> /* not allocate anything below the kernel */
>>> kbuf.buf_min = kernel_load_addr + kernel_size;
>> I think the initramfs can escape the crash kernel range because you add to the
>> buf_max region:
>> | /* within 1GB-aligned window of up to 32GB in size */
>> | kbuf.buf_max = round_down(kernel_load_addr, SZ_1G)
>> | + (unsigned long)SZ_1G * 32;
>
> No worries.
> kexec_add_buffer() will limit the search only within crashk_res anyway.
via arch_kexec_walk_mem()? Got it.
But strangely the buf_min and buf_max still matter because
locate_mem_hole_callback() uses them.
> Are you reviewing other patches in my v11?
> If not, I will post v12 tomorrow.
No, (I try to batch replies to avoid that happening).
I'm reading up on Secure-boot and trying to test the pe_verification stuff...
Thanks,
James
^ permalink raw reply
* Re: [PATCH xf86-video-ati] Remove drmmode_terminate_leases
From: Alex Deucher @ 2018-07-23 17:04 UTC (permalink / raw)
To: Michel Dänzer; +Cc: amd-gfx list
In-Reply-To: <20180723165614.27160-1-michel-otUistvHUpPR7s880joybQ@public.gmane.org>
On Mon, Jul 23, 2018 at 12:56 PM, Michel Dänzer <michel@daenzer.net> wrote:
> From: Michel Dänzer <michel.daenzer@amd.com>
>
> The RandR screen private is already freed when our CloseScreen runs, so
> this can't do anything useful. This cleanup has to be done by the X
> server itself.
>
> (Ported from amdgpu commit 5f06d6b8ba570b500956ad26fee711d5ac427818)
>
> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
> ---
> src/drmmode_display.c | 20 --------------------
> src/drmmode_display.h | 2 --
> src/radeon_kms.c | 1 -
> 3 files changed, 23 deletions(-)
>
> diff --git a/src/drmmode_display.c b/src/drmmode_display.c
> index ff098975f..60c1cdc18 100644
> --- a/src/drmmode_display.c
> +++ b/src/drmmode_display.c
> @@ -2522,26 +2522,6 @@ drmmode_terminate_lease(RRLeasePtr lease)
>
> #endif // XF86_LEASE_VERSION
>
> -void
> -drmmode_terminate_leases(ScrnInfoPtr pScrn)
> -{
> -#ifdef XF86_LEASE_VERSION
> - ScreenPtr screen = xf86ScrnToScreen(pScrn);
> - RADEONEntPtr pRADEONEnt = RADEONEntPriv(pScrn);
> - rrScrPrivPtr scr_priv = rrGetScrPriv(screen);
> - RRLeasePtr lease, next;
> -
> - xorg_list_for_each_entry_safe(lease, next, &scr_priv->leases, list) {
> - drmmode_lease_private_ptr lease_private = lease->devPrivate;
> - drmModeRevokeLease(pRADEONEnt->fd, lease_private->lessee_id);
> - free(lease_private);
> - lease->devPrivate = NULL;
> - RRLeaseTerminated(lease);
> - RRLeaseFree(lease);
> - }
> -#endif
> -}
> -
> static const xf86CrtcConfigFuncsRec drmmode_xf86crtc_config_funcs = {
> .resize = drmmode_xf86crtc_resize,
> #ifdef XF86_LEASE_VERSION
> diff --git a/src/drmmode_display.h b/src/drmmode_display.h
> index 4551e0c77..c5a55891a 100644
> --- a/src/drmmode_display.h
> +++ b/src/drmmode_display.h
> @@ -227,8 +227,6 @@ PixmapPtr drmmode_crtc_scanout_create(xf86CrtcPtr crtc,
> extern void drmmode_uevent_init(ScrnInfoPtr scrn, drmmode_ptr drmmode);
> extern void drmmode_uevent_fini(ScrnInfoPtr scrn, drmmode_ptr drmmode);
>
> -extern void drmmode_terminate_leases(ScrnInfoPtr scrn);
> -
> Bool drmmode_set_mode(xf86CrtcPtr crtc, struct drmmode_fb *fb,
> DisplayModePtr mode, int x, int y);
>
> diff --git a/src/radeon_kms.c b/src/radeon_kms.c
> index c8a5726ad..36840ad36 100644
> --- a/src/radeon_kms.c
> +++ b/src/radeon_kms.c
> @@ -2154,7 +2154,6 @@ static Bool RADEONCloseScreen_KMS(ScreenPtr pScreen)
> /* Clear mask of assigned crtc's in this generation */
> pRADEONEnt->assigned_crtcs = 0;
>
> - drmmode_terminate_leases(pScrn);
> drmmode_uevent_fini(pScrn, &info->drmmode);
> radeon_drm_queue_close(pScrn);
> radeon_cs_flush_indirect(pScrn);
> --
> 2.18.0
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* [PATCH v11 11/15] arm64: kexec_file: add crash dump support
From: James Morse @ 2018-07-23 17:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180723053923.GN11258@linaro.org>
Hi Akashi,
On 23/07/18 06:39, AKASHI Takahiro wrote:
> On Wed, Jul 18, 2018 at 05:50:22PM +0100, James Morse wrote:
>> On 11/07/18 08:41, AKASHI Takahiro wrote:
>>> Enabling crash dump (kdump) includes
>>> * prepare contents of ELF header of a core dump file, /proc/vmcore,
>>> using crash_prepare_elf64_headers(), and
>>> * add two device tree properties, "linux,usable-memory-range" and
>>> "linux,elfcorehdr", which represent respectively a memory range
>>> to be used by crash dump kernel and the header's location
>>
>>> diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
>>> index 69333694e3e2..eeb5766928b0 100644
>>> --- a/arch/arm64/include/asm/kexec.h
>>> +++ b/arch/arm64/include/asm/kexec.h
>>> @@ -99,6 +99,10 @@ static inline void crash_post_resume(void) {}
>>> struct kimage_arch {
>>> phys_addr_t dtb_mem;
>>> void *dtb_buf;
>>> + /* Core ELF header buffer */
>>
>>> + void *elf_headers;
>>
>> Shouldn't this be a phys_addr_t if it comes from kbuf.mem?
>
> Do you mean elf_load_addr? You're right.
> But kexec_buf defined mem as unsigned long and so I'd rather change
> dtb_mem to unsigned long instead of elf_load_addr, which will also be
> renamed to elf_headers_mem for clarification.
>> (dtb_mem is, and they type tells us which way round the runtime/kexec-time
>> pointers are)
My preference would be for physical addresses to always be phys_addr_t, but as
long as we can easily spot the difference kexec-time versus runtime addresses,
it will save bugs where we use the wrong one.
>>> diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
>>> index a0b44fe18b95..261564df7210 100644
>>> --- a/arch/arm64/kernel/machine_kexec_file.c
>>> +++ b/arch/arm64/kernel/machine_kexec_file.c
>>> @@ -132,6 +173,45 @@ static int setup_dtb(struct kimage *image,
>>> + kbuf.buf_min = crashk_res.start;
>>> + kbuf.buf_max = crashk_res.end + 1;
>>> + kbuf.top_down = true;
>>> +
>>> + ret = kexec_add_buffer(&kbuf);
>>> + if (ret) {
>>> + vfree(hdrs_addr);
>>> + goto out_err;
>>> + }
>>> + image->arch.elf_headers = hdrs_addr;
>>> + image->arch.elf_headers_sz = hdrs_sz;
>>> + image->arch.elf_load_addr = kbuf.mem;
>>> +
>>> + pr_debug("Loaded elf core header at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
>>> + image->arch.elf_load_addr, hdrs_sz, hdrs_sz);
>>> + }
>>> +
>>> kbuf.image = image;
>>> /* not allocate anything below the kernel */
>>> kbuf.buf_min = kernel_load_addr + kernel_size;
>> I think the initramfs can escape the crash kernel range because you add to the
>> buf_max region:
>> | /* within 1GB-aligned window of up to 32GB in size */
>> | kbuf.buf_max = round_down(kernel_load_addr, SZ_1G)
>> | ?+ (unsigned long)SZ_1G * 32;
>
> No worries.
> kexec_add_buffer() will limit the search only within crashk_res anyway.
via arch_kexec_walk_mem()? Got it.
But strangely the buf_min and buf_max still matter because
locate_mem_hole_callback() uses them.
> Are you reviewing other patches in my v11?
> If not, I will post v12 tomorrow.
No, (I try to batch replies to avoid that happening).
I'm reading up on Secure-boot and trying to test the pe_verification stuff...
Thanks,
James
^ permalink raw reply
* Re: [PATCH v11 11/15] arm64: kexec_file: add crash dump support
From: James Morse @ 2018-07-23 17:04 UTC (permalink / raw)
To: AKASHI Takahiro
Cc: herbert, bhe, ard.biesheuvel, catalin.marinas, bhsharma,
will.deacon, linux-kernel, dhowells, arnd, linux-arm-kernel,
kexec, dyoung, davem, vgoyal
In-Reply-To: <20180723053923.GN11258@linaro.org>
Hi Akashi,
On 23/07/18 06:39, AKASHI Takahiro wrote:
> On Wed, Jul 18, 2018 at 05:50:22PM +0100, James Morse wrote:
>> On 11/07/18 08:41, AKASHI Takahiro wrote:
>>> Enabling crash dump (kdump) includes
>>> * prepare contents of ELF header of a core dump file, /proc/vmcore,
>>> using crash_prepare_elf64_headers(), and
>>> * add two device tree properties, "linux,usable-memory-range" and
>>> "linux,elfcorehdr", which represent respectively a memory range
>>> to be used by crash dump kernel and the header's location
>>
>>> diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
>>> index 69333694e3e2..eeb5766928b0 100644
>>> --- a/arch/arm64/include/asm/kexec.h
>>> +++ b/arch/arm64/include/asm/kexec.h
>>> @@ -99,6 +99,10 @@ static inline void crash_post_resume(void) {}
>>> struct kimage_arch {
>>> phys_addr_t dtb_mem;
>>> void *dtb_buf;
>>> + /* Core ELF header buffer */
>>
>>> + void *elf_headers;
>>
>> Shouldn't this be a phys_addr_t if it comes from kbuf.mem?
>
> Do you mean elf_load_addr? You're right.
> But kexec_buf defined mem as unsigned long and so I'd rather change
> dtb_mem to unsigned long instead of elf_load_addr, which will also be
> renamed to elf_headers_mem for clarification.
>> (dtb_mem is, and they type tells us which way round the runtime/kexec-time
>> pointers are)
My preference would be for physical addresses to always be phys_addr_t, but as
long as we can easily spot the difference kexec-time versus runtime addresses,
it will save bugs where we use the wrong one.
>>> diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
>>> index a0b44fe18b95..261564df7210 100644
>>> --- a/arch/arm64/kernel/machine_kexec_file.c
>>> +++ b/arch/arm64/kernel/machine_kexec_file.c
>>> @@ -132,6 +173,45 @@ static int setup_dtb(struct kimage *image,
>>> + kbuf.buf_min = crashk_res.start;
>>> + kbuf.buf_max = crashk_res.end + 1;
>>> + kbuf.top_down = true;
>>> +
>>> + ret = kexec_add_buffer(&kbuf);
>>> + if (ret) {
>>> + vfree(hdrs_addr);
>>> + goto out_err;
>>> + }
>>> + image->arch.elf_headers = hdrs_addr;
>>> + image->arch.elf_headers_sz = hdrs_sz;
>>> + image->arch.elf_load_addr = kbuf.mem;
>>> +
>>> + pr_debug("Loaded elf core header at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
>>> + image->arch.elf_load_addr, hdrs_sz, hdrs_sz);
>>> + }
>>> +
>>> kbuf.image = image;
>>> /* not allocate anything below the kernel */
>>> kbuf.buf_min = kernel_load_addr + kernel_size;
>> I think the initramfs can escape the crash kernel range because you add to the
>> buf_max region:
>> | /* within 1GB-aligned window of up to 32GB in size */
>> | kbuf.buf_max = round_down(kernel_load_addr, SZ_1G)
>> | + (unsigned long)SZ_1G * 32;
>
> No worries.
> kexec_add_buffer() will limit the search only within crashk_res anyway.
via arch_kexec_walk_mem()? Got it.
But strangely the buf_min and buf_max still matter because
locate_mem_hole_callback() uses them.
> Are you reviewing other patches in my v11?
> If not, I will post v12 tomorrow.
No, (I try to batch replies to avoid that happening).
I'm reading up on Secure-boot and trying to test the pe_verification stuff...
Thanks,
James
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* Re: [PATCH v1 0/3] [RFC] Speeding up checkout (and merge, rebase, etc)
From: Duy Nguyen @ 2018-07-23 17:03 UTC (permalink / raw)
To: Ben Peart; +Cc: Jeff King, Ben Peart, Git Mailing List, Junio C Hamano
In-Reply-To: <a2ad0044-f317-69f7-f2bb-488111c626fb@gmail.com>
On Mon, Jul 23, 2018 at 5:50 PM Ben Peart <peartben@gmail.com> wrote:
> > Anyway, on to the actual discussion:
> >
> >> Here is a checkout command with tracing turned on to demonstrate where the
> >> time is spent. Note, this is somewhat of a �best case� as I�m simply
> >> checking out the current commit:
> >>
> >> benpeart@gvfs-perf MINGW64 /f/os/src (official/rs_es_debug_dev)
> >> $ /usr/src/git/git.exe checkout
> >> 12:31:50.419016 read-cache.c:2006 performance: 1.180966800 s: read cache .git/index
> >> 12:31:51.184636 name-hash.c:605 performance: 0.664575200 s: initialize name hash
> >> 12:31:51.200280 preload-index.c:111 performance: 0.019811600 s: preload index
> >> 12:31:51.294012 read-cache.c:1543 performance: 0.094515600 s: refresh index
> >> 12:32:29.731344 unpack-trees.c:1358 performance: 33.889840200 s: traverse_trees
> >> 12:32:37.512555 read-cache.c:2541 performance: 1.564438300 s: write index, changed mask = 28
> >> 12:32:44.918730 unpack-trees.c:1358 performance: 7.243155600 s: traverse_trees
> >> 12:32:44.965611 diff-lib.c:527 performance: 7.374729200 s: diff-index
> >> Waiting for GVFS to parse index and update placeholder files...Succeeded
> >> 12:32:46.824986 trace.c:420 performance: 57.715656000 s: git command: 'C:\git-sdk-64\usr\src\git\git.exe' checkout
> >
> > What's the current state of the index before this checkout?
>
> This was after running "git checkout" multiple times so there was really
> nothing for git to do.
Hmm.. this means cache-tree is fully valid, unless you have changes in
index. We're quite aggressive in repairing cache-tree since aecf567cbf
(cache-tree: create/update cache-tree on checkout - 2014-07-05). If we
have very good cache-tree records and still spend 33s on
traverse_trees, maybe there's something else.
> >> ODB cache
> >> =========
> >> Since traverse_trees() hits the ODB for each tree object (of which there are
> >> over 500K in this repo) I wrote and tested having an in-memory ODB cache
> >> that cached all tree objects. This resulted in a > 50% hit ratio (largely
> >> due to the fact we traverse the tree twice during checkout) but resulted in
> >> only a minimal savings (1.3 seconds).
> >
> > In my experience, one major cost of object access is decompression, both
> > delta and zlib. Trees in particular tend to delta very well across
> > versions. We have a cache to try to reuse intermediate delta results,
> > but the default size is probably woefully undersized for your repository
> > (I know from past tests it's undersized a bit even for the linux
> > kernel).
> >
> > Try bumping core.deltaBaseCacheLimit to see if that has any impact. It's
> > 96MB by default.
> >
> > There may also be some possible work in making it more aggressive about
> > storing the intermediate results. I seem to recall from past
> > explorations that it doesn't keep everything, and I don't know if its
> > heuristics have ever been proven sane.
Could we be a bit more flexible about cache size? Say if we know
there's 8 GB memory still available, we should be able to use like 1
GB at least (and that's done automatically without tinkering with
config).
--
Duy
^ permalink raw reply
* Re: [PATCH] ARM: dts: iwg23s-sbc: Add pinctl support for scif1
From: Simon Horman @ 2018-07-23 16:01 UTC (permalink / raw)
To: Biju Das
Cc: Rob Herring, Mark Rutland, Magnus Damm, Chris Paterson,
Fabrizio Castro, devicetree, linux-renesas-soc
In-Reply-To: <1532092411-7723-1-git-send-email-biju.das@bp.renesas.com>
On Fri, Jul 20, 2018 at 02:13:31PM +0100, Biju Das wrote:
> Adding pinctrl support for scif1 interface.
>
> Signed-off-by: Biju Das <biju.das@bp.renesas.com>
> Reviewed-by: Chris Paterson <chris.paterson2@renesas.com>
Thanks,
This looks fine to me but I will wait to see if there are other reviews
before applying.
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v3 38/40] gdbstub: Disable handling of nanoMIPS ISA bit in the MIPS gdbstub
From: Richard Henderson @ 2018-07-23 17:03 UTC (permalink / raw)
To: Stefan Markovic, qemu-devel
Cc: laurent, riku.voipio, philippe.mathieu.daude, aurelien, amarkovic,
smarkovic, pjovanovic, pburton
In-Reply-To: <1532004912-13899-39-git-send-email-stefan.markovic@rt-rk.com>
On 07/19/2018 05:55 AM, Stefan Markovic wrote:
> From: James Hogan <james.hogan@mips.com>
>
> nanoMIPS has no ISA bit in the PC, so remove the handling of the low bit
> of the PC in the MIPS gdbstub for nanoMIPS. This prevents the PC being
> read as e.g. 0xbfc00001, and prevents writing to the PC clearing
> MIPS_HFLAG_M16.
>
> Signed-off-by: James Hogan <james.hogan@mips.com>
> Signed-off-by: Yongbok Kim <yongbok.kim@mips.com>
> Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com>
> Signed-off-by: Stefan Markovic <smarkovic@wavecomp.com>
> ---
> target/mips/gdbstub.c | 13 ++++++++-----
> 1 file changed, 8 insertions(+), 5 deletions(-)
See my comments for 28/40.
r~
^ permalink raw reply
* [Intel-wired-lan] [RFC 03/13] ice: Prevent control queue operations during reset
From: Shannon Nelson @ 2018-07-23 17:03 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <20180720205353.13296-4-anirudh.venkataramanan@intel.com>
On 7/20/2018 1:53 PM, Anirudh Venkataramanan wrote:
> Once reset is issued, the driver loses all control queue interfaces.
> Exercising control queue operations during reset is incorrect and
> may result in long timeouts.
>
> This patch introduces a new field 'reset_ongoing' in the hw structure.
> This is set to 1 by the core driver when it receives a reset interrupt.
> ice_sq_send_cmd checks reset_ongoing before actually issuing the control
> queue operation. If a reset is in progress, it returns a soft error code
> (ICE_ERR_RESET_PENDING) to the caller. The caller may or may not have to
> take any action based on this return. Once the driver knows that the
> reset is done, it has to set reset_ongoing back to 0. This will allow
> control queue operations to be posted to the hardware again.
>
> This "bail out" logic was specifically added to ice_sq_send_cmd (which
> is pretty low level function) so that we have one solution in one place
> that applies to all types of control queues.
>
> Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
> ---
> drivers/net/ethernet/intel/ice/ice_controlq.c | 3 +++
> drivers/net/ethernet/intel/ice/ice_main.c | 34 +++++++++++++++++++++++----
> drivers/net/ethernet/intel/ice/ice_status.h | 1 +
> drivers/net/ethernet/intel/ice/ice_type.h | 1 +
> 4 files changed, 34 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_controlq.c b/drivers/net/ethernet/intel/ice/ice_controlq.c
> index 62be72fdc8f3..1fe026a65d75 100644
> --- a/drivers/net/ethernet/intel/ice/ice_controlq.c
> +++ b/drivers/net/ethernet/intel/ice/ice_controlq.c
> @@ -806,6 +806,9 @@ ice_sq_send_cmd(struct ice_hw *hw, struct ice_ctl_q_info *cq,
> u16 retval = 0;
> u32 val = 0;
>
> + /* if reset is in progress return a soft error */
> + if (hw->reset_ongoing)
> + return ICE_ERR_RESET_ONGOING;
> mutex_lock(&cq->sq_lock);
>
> cq->sq_last_status = ICE_AQ_RC_OK;
> diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
> index 3782569b450a..23bffa3cbf7f 100644
> --- a/drivers/net/ethernet/intel/ice/ice_main.c
> +++ b/drivers/net/ethernet/intel/ice/ice_main.c
> @@ -535,10 +535,13 @@ static void ice_reset_subtask(struct ice_pf *pf)
> ice_prepare_for_reset(pf);
>
> /* make sure we are ready to rebuild */
> - if (ice_check_reset(&pf->hw))
> + if (ice_check_reset(&pf->hw)) {
> set_bit(__ICE_RESET_FAILED, pf->state);
> - else
> + } else {
> + /* done with reset. start rebuild */
> + pf->hw.reset_ongoing = false;
> ice_rebuild(pf);
> + }
> clear_bit(__ICE_RESET_RECOVERY_PENDING, pf->state);
> goto unlock;
> }
> @@ -1752,7 +1755,8 @@ static irqreturn_t ice_misc_intr(int __always_unused irq, void *data)
> * We also make note of which reset happened so that peer
> * devices/drivers can be informed.
> */
> - if (!test_bit(__ICE_RESET_RECOVERY_PENDING, pf->state)) {
> + if (!test_and_set_bit(__ICE_RESET_RECOVERY_PENDING,
> + pf->state)) {
> if (reset == ICE_RESET_CORER)
> set_bit(__ICE_CORER_RECV, pf->state);
> else if (reset == ICE_RESET_GLOBR)
> @@ -1760,7 +1764,20 @@ static irqreturn_t ice_misc_intr(int __always_unused irq, void *data)
> else
> set_bit(__ICE_EMPR_RECV, pf->state);
>
> - set_bit(__ICE_RESET_RECOVERY_PENDING, pf->state);
> + /* There are couple of different bits at play here.
> + * hw->reset_ongoing indicates whether the hardware is
> + * in reset. This is set to true when a reset interrupt
> + * is received and set back to false after the driver
> + * has determined that the hardware is out of reset.
> + *
> + * __ICE_RESET_RECOVERY_PENDING in pf->state indicates
> + * that a post reset rebuild is required before the
> + * driver is operational again. This is set above.
> + *
> + * As this is the start of the reset/rebuild cycle, set
> + * both to indicate that.
> + */
> + hw->reset_ongoing = true;
> }
> }
>
> @@ -4187,7 +4204,14 @@ static int ice_vsi_stop_tx_rings(struct ice_vsi *vsi)
> }
> status = ice_dis_vsi_txq(vsi->port_info, vsi->num_txq, q_ids, q_teids,
> NULL);
> - if (status) {
> + /* if the disable queue command was exercised during an active reset
> + * flow, ICE_ERR_RESET_ONGOING is returned. This is not an error as
> + * the reset operation disables queues at the hardware level anyway.
> + */
> + if (status == ICE_ERR_RESET_ONGOING) {
> + dev_info(&pf->pdev->dev,
> + "Reset in progress. LAN Tx queues already disabled\n");
Unnecessary log message - make this a debug message if you really want
to keep it around.
> + } else if (status) {
> dev_err(&pf->pdev->dev,
> "Failed to disable LAN Tx queues, error: %d\n",
> status);
> diff --git a/drivers/net/ethernet/intel/ice/ice_status.h b/drivers/net/ethernet/intel/ice/ice_status.h
> index 9a95c4ffd7d7..d2dae913d81e 100644
> --- a/drivers/net/ethernet/intel/ice/ice_status.h
> +++ b/drivers/net/ethernet/intel/ice/ice_status.h
> @@ -20,6 +20,7 @@ enum ice_status {
> ICE_ERR_ALREADY_EXISTS = -14,
> ICE_ERR_DOES_NOT_EXIST = -15,
> ICE_ERR_MAX_LIMIT = -17,
> + ICE_ERR_RESET_ONGOING = -18,
> ICE_ERR_BUF_TOO_SHORT = -52,
> ICE_ERR_NVM_BLANK_MODE = -53,
> ICE_ERR_AQ_ERROR = -100,
> diff --git a/drivers/net/ethernet/intel/ice/ice_type.h b/drivers/net/ethernet/intel/ice/ice_type.h
> index f5aff99bbb61..bc31d1069cab 100644
> --- a/drivers/net/ethernet/intel/ice/ice_type.h
> +++ b/drivers/net/ethernet/intel/ice/ice_type.h
> @@ -289,6 +289,7 @@ struct ice_hw {
> u8 sw_entry_point_layer;
>
> u8 evb_veb; /* true for VEB, false for VEPA */
> + u8 reset_ongoing; /* true if hw is in reset, false otherwise */
> struct ice_bus_info bus;
> struct ice_nvm_info nvm;
> struct ice_hw_dev_caps dev_caps; /* device capabilities */
>
^ permalink raw reply
* Re: [PATCH -next v4 1/3] regmap: add SCCB support
From: Mark Brown @ 2018-07-23 17:02 UTC (permalink / raw)
To: Wolfram Sang
Cc: Akinobu Mita, linux-media, linux-i2c, linux-kernel, Peter Rosin,
Sebastian Reichel, Sylwester Nawrocki, Jacopo Mondi,
Laurent Pinchart, Hans Verkuil, Sakari Ailus,
Mauro Carvalho Chehab
In-Reply-To: <20180720215344.6it2k5wckxvwx25p@ninjato>
[-- Attachment #1: Type: text/plain, Size: 196 bytes --]
On Fri, Jul 20, 2018 at 11:53:44PM +0200, Wolfram Sang wrote:
> Here is it:
> git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/smbus_xfer_unlock-immutable
Thanks, pulled in now.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v3 34/40] linux-user: Don't check FCR31_NAN2008 bit for nanoMIPS
From: Richard Henderson @ 2018-07-23 17:02 UTC (permalink / raw)
To: Stefan Markovic, qemu-devel
Cc: laurent, riku.voipio, philippe.mathieu.daude, aurelien, amarkovic,
smarkovic, pjovanovic, pburton
In-Reply-To: <1532004912-13899-35-git-send-email-stefan.markovic@rt-rk.com>
On 07/19/2018 05:55 AM, Stefan Markovic wrote:
> From: Aleksandar Markovic <amarkovic@wavecomp.com>
>
> Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com>
> Signed-off-by: Stefan Markovic <smarkovic@wavecomp.com>
> ---
> linux-user/mips/cpu_loop.c | 3 +++
> 1 file changed, 3 insertions(+)
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
r~
^ permalink raw reply
* [virtio-dev] [PATCH v2] content: Introduce VIRTIO_NET_F_STANDBY feature
From: Sridhar Samudrala @ 2018-07-23 17:02 UTC (permalink / raw)
To: mst, cohuck, virtio-dev
Cc: Sridhar, "Samudrala <sridhar.samudrala"
VIRTIO_NET_F_STANDBY feature enables hypervisor to indicate virtio_net
device to act as a standby for a primary device with the same MAC address.
Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com
---
content.tex | 8 ++++++++
1 file changed, 8 insertions(+)
v2: updated standby description based on Cornelia's feedback.
diff --git a/content.tex b/content.tex
index be18234..b729857 100644
--- a/content.tex
+++ b/content.tex
@@ -2525,6 +2525,9 @@ features.
\item[VIRTIO_NET_F_CTRL_MAC_ADDR(23)] Set MAC address through control
channel.
+
+\item[VIRTIO_NET_F_STANDBY(62)] Device MAY act as a standby for a primary
+ device with the same MAC
\end{description}
\subsubsection{Feature bit requirements}\label{sec:Device Types / Network Device / Feature bits / Feature bit requirements}
@@ -2636,6 +2639,11 @@ If the driver negotiates VIRTIO_NET_F_MTU, it MUST NOT transmit packets of
size exceeding the value of \field{mtu} (plus low level ethernet header length)
with \field{gso_type} NONE or ECN.
+A driver SHOULD negotiate VIRTIO_NET_F_STANDBY feature if the device offers it.
+
+If the driver negotiates VIRTIO_NET_F_STANDBY, the device MAY act as a standby
+device for a primary device with the same MAC address.
+
\subsubsection{Legacy Interface: Device configuration layout}\label{sec:Device Types / Network Device / Device configuration layout / Legacy Interface: Device configuration layout}
\label{sec:Device Types / Block Device / Feature bits / Device configuration layout / Legacy Interface: Device configuration layout}
When using the legacy interface, transitional devices and drivers
--
2.14.4
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply related
* Re: arch/arc/ allmodconfig
From: Leon Romanovsky @ 2018-07-23 16:51 UTC (permalink / raw)
To: Vineet Gupta
Cc: Ofer Levi(SW), Randy Dunlap, LKML,
linux-snps-arc@lists.infradead.org, Meir Lichtinger
In-Reply-To: <C2D7FE5348E1B147BCA15975FBA23075012B07F319@us01wembx1.internal.synopsys.com>
On Mon, Jul 23, 2018 at 04:36:57PM +0000, Vineet Gupta wrote:
> Hi Ofer,
>
> On 07/23/2018 01:34 AM, Ofer Levi(SW) wrote:
> > Hi Vineet, randy
> >
> > Indeed this structure is missing, following is a patch based on linux-4.17.9.
> > Sorry about that.
> >
> > Thanks
> >
> >
> > diff -uprN linux-4.17.9.org/arch/arc/plat-eznps/include/plat/ctop.h linux-4.17.9/arch/arc/plat-eznps/include/plat/ctop.h
> > --- linux-4.17.9.org/arch/arc/plat-eznps/include/plat/ctop.h 2018-07-22 16:16:09.000000000 +0300
> > +++ linux-4.17.9/arch/arc/plat-eznps/include/plat/ctop.h 2018-07-23 11:18:12.179402620 +0300
> > @@ -143,6 +143,15 @@ struct nps_host_reg_gim_p_int_dst {
> > };
> >
> > /* AUX registers definition */
> > +struct nps_host_reg_aux_dpc {
> > + union {
> > + struct {
> > + u32 ien:1, men:1, hen:1, reserved:29;
> > + };
> > + u32 value;
> > + };
> > +};
> > +
> > struct nps_host_reg_aux_udmc {
> > union {
> > struct {
>
> Thx for this change. Can you please send a proper patch with changelog, citing the
> issue as Reported-by etc.
> Also if Mellanox is interested in maintaining the NPS port going fwd, someone (you
> ?) should add their name to MAINTAINERS file under arch/arc/plat-eznps and send
> that patch as well.
Hi Vineet,
Thanks for your feedback, I'll work with Ofer to make it happen.
>
> Thx,
> -Vineet
>
>
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: Meir Lichtinger
> >> Sent: Friday, July 20, 2018 10:19
> >> To: Vineet Gupta <Vineet.Gupta1@synopsys.com>; Randy Dunlap
> >> <rdunlap@infradead.org>; LKML <linux-kernel@vger.kernel.org>; linux-
> >> snps-arc@lists.infradead.org; Ofer Levi(SW) <oferle@mellanox.com>
> >> Cc: Leon Romanovsky <leonro@mellanox.com>
> >> Subject: RE: arch/arc/ allmodconfig
> >>
> >> Hi Vineet,
> >> Ofer Levi is now the maintainer of arch/arc/plat-eznps
> >>
> >> Ofer,
> >> Please take care of the issue below
> >>
> >> Thanks
> >>
> >>
> >> -----Original Message-----
> >> From: Vineet Gupta [mailto:Vineet.Gupta1@synopsys.com]
> >> Sent: Thursday, July 19, 2018 19:22
> >> To: Randy Dunlap <rdunlap@infradead.org>; LKML <linux-
> >> kernel@vger.kernel.org>; Vineet Gupta <Vineet.Gupta1@synopsys.com>;
> >> linux-snps-arc@lists.infradead.org
> >> Cc: Elad Kanfi <eladkan@mellanox.com>; Leon Romanovsky
> >> <leonro@mellanox.com>
> >> Subject: Re: arch/arc/ allmodconfig
> >>
> >> +CC some folks from Mellanox
> >>
> >> On 07/18/2018 10:37 PM, Randy Dunlap wrote:
> >>> Hi,
> >>>
> >>> When I try to (cross-)build arch/arc/ allmodconfig, I get a syntax error here:
> >>>
> >>> ./arch/arc/plat-eznps/mtm.c: In function 'mtm_enable_core':
> >>> ../arch/arc/plat-eznps/mtm.c:113:30: error: storage size of 'dpc' isn't known
> >>> struct nps_host_reg_aux_dpc dpc;
> >>> ^~~
> >>>
> >>> There is no struct nps_host_reg_aux_dpc in the kernel tree.
> >>>
> >>> Can you do something about this, please?
> >> Thx for the report Randy. I'm calling out Mellanox folks to see if they can
> >> provide a fixup, else we will revert the corresponding change.
> >>
> >> @Elad, upstream commit 3f9cd874dcc8705 "ARC: [plat-eznps] avoid toggling
> >> of DPC register" added reference to struct nps_host_reg_aux_dpc but the
> >> definition is missing. Can you please provide a fixup as I have no idea of that
> >> platform specific struct.
> >>
> >> @ Leon, reaching our to you, since it seems you removed Elad from
> >> MAINTAINERS file, so I'm not sure if he is still at Mellanox.
> >> The two folks I worked with on EZCHiip Linux port Noam Camus and Gilad
> >> have left Mellanox.
> >> If you or someone from Mellanox are interested in maintaining this platform,
> >> please update the arch/arc/plat-eznps section of MAINTAINERS file.
> >>
> >>
> >> Thx,
> >> -Vineet
>
^ permalink raw reply
* Re: t7406-submodule-update shaky ?
From: Stefan Beller @ 2018-07-23 17:01 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: git
In-Reply-To: <208b2ede-4833-f062-16f2-f35b8a8ce099@web.de>
On Sun, Jul 22, 2018 at 2:05 PM Torsten Bögershausen <tboegi@web.de> wrote:
>
> It seems that t7406 is sometimes shaky - when checking stderr in test
> case 4.
>
> The order of the submodules may vary, sorting the stderr output makes it
>
> more reliable (and somewhat funny to read).
>
> Does anybody have a better idea ?
DScho just posted a fix for this, see:
https://public-inbox.org/git/pull.12.git.gitgitgadget@gmail.com/
^ permalink raw reply
* Re: [PATCH 1/2] Add sw2_sw4 voltage table to cpcap regulator.
From: Mark Brown @ 2018-07-23 17:01 UTC (permalink / raw)
To: Peter Geis
Cc: girdwood, robh+dt, mark.rutland, linux-kernel, devicetree,
linux-tegra
In-Reply-To: <d38d3fea-dc7d-09fe-651e-386b36befde1@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 605 bytes --]
On Fri, Jul 20, 2018 at 08:43:49PM -0400, Peter Geis wrote:
> SW2 and SW4 use a shared table to provide voltage to the cpu core and
> devices on Tegra hardware.
> Added this table to the cpcap regulator driver as the first step to
> supporting this device on Tegra.
This fails to apply with:
Applying: Add sw2_sw4 voltage table to cpcap regulator.
.git/rebase-apply/patch:37: trailing whitespace.
1437500, 1450000,
error: corrupt patch at line 38
Patch failed at 0001 Add sw2_sw4 voltage table to cpcap regulator.
Please check and resend.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.