* [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
* [PATCH v2 2/4] staging:fsl-mc: Move DPIO from staging to drivers/soc/fsl
From: Roy Pledge @ 2018-07-23 17:00 UTC (permalink / raw)
To: devel, linux-arm-kernel, gregkh, leoyang.li
Cc: laurentiu.tudor, ruxandra.radulescu, horia.geanta, linux-kernel,
arnd, catalin.marinas, robin.murphy, Roy Pledge
In-Reply-To: <20180723170025.2259-1-roy.pledge@nxp.com>
Move the NXP DPIO (Datapath I/O Driver) out of the
drivers/staging directory and into the drivers/soc/fsl directory.
The DPIO driver enables access to Queue and Buffer Manager (QBMAN)
hardware on NXP DPAA2 devices. This is a prerequisite to moving the
DPAA2 Ethernet driver out of staging.
Signed-off-by: Roy Pledge <roy.pledge@nxp.com>
---
MAINTAINERS | 2 +-
drivers/crypto/caam/sg_sw_qm2.h | 2 +-
drivers/crypto/caam/sg_sw_sec4.h | 2 +-
drivers/soc/fsl/Kconfig | 10 ++++++++++
drivers/soc/fsl/Makefile | 1 +
drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/Makefile | 0
drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-cmd.h | 0
drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-driver.c | 2 +-
drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-driver.txt | 0
drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-service.c | 2 +-
drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio.c | 0
drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio.h | 0
drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/qbman-portal.c | 2 +-
drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/qbman-portal.h | 2 +-
drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.h | 4 ++--
drivers/staging/fsl-mc/bus/Kconfig | 9 ---------
drivers/staging/fsl-mc/bus/Makefile | 2 --
{drivers/staging/fsl-mc/include => include/soc/fsl}/dpaa2-fd.h | 0
.../staging/fsl-mc/include => include/soc/fsl}/dpaa2-global.h | 0
{drivers/staging/fsl-mc/include => include/soc/fsl}/dpaa2-io.h | 0
20 files changed, 20 insertions(+), 20 deletions(-)
rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/Makefile (100%)
rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-cmd.h (100%)
rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-driver.c (99%)
rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-driver.txt (100%)
rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-service.c (99%)
rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio.c (100%)
rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio.h (100%)
rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/qbman-portal.c (99%)
rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/qbman-portal.h (99%)
rename {drivers/staging/fsl-mc/include => include/soc/fsl}/dpaa2-fd.h (100%)
rename {drivers/staging/fsl-mc/include => include/soc/fsl}/dpaa2-global.h (100%)
rename {drivers/staging/fsl-mc/include => include/soc/fsl}/dpaa2-io.h (100%)
diff --git a/MAINTAINERS b/MAINTAINERS
index 0fe4228..34ce842 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4418,7 +4418,7 @@ DPAA2 DATAPATH I/O (DPIO) DRIVER
M: Roy Pledge <Roy.Pledge@nxp.com>
L: linux-kernel@vger.kernel.org
S: Maintained
-F: drivers/staging/fsl-mc/bus/dpio
+F: drivers/soc/fsl/dpio
DPAA2 ETHERNET DRIVER
M: Ioana Radulescu <ruxandra.radulescu@nxp.com>
diff --git a/drivers/crypto/caam/sg_sw_qm2.h b/drivers/crypto/caam/sg_sw_qm2.h
index 31b4407..b5b4c12 100644
--- a/drivers/crypto/caam/sg_sw_qm2.h
+++ b/drivers/crypto/caam/sg_sw_qm2.h
@@ -35,7 +35,7 @@
#ifndef _SG_SW_QM2_H_
#define _SG_SW_QM2_H_
-#include "../../../drivers/staging/fsl-mc/include/dpaa2-fd.h"
+#include <soc/fsl/dpaa2-fd.h>
static inline void dma_to_qm_sg_one(struct dpaa2_sg_entry *qm_sg_ptr,
dma_addr_t dma, u32 len, u16 offset)
diff --git a/drivers/crypto/caam/sg_sw_sec4.h b/drivers/crypto/caam/sg_sw_sec4.h
index e586ffa..dbfa9fc 100644
--- a/drivers/crypto/caam/sg_sw_sec4.h
+++ b/drivers/crypto/caam/sg_sw_sec4.h
@@ -12,7 +12,7 @@
#include "ctrl.h"
#include "regs.h"
#include "sg_sw_qm2.h"
-#include "../../../drivers/staging/fsl-mc/include/dpaa2-fd.h"
+#include <soc/fsl/dpaa2-fd.h>
struct sec4_sg_entry {
u64 ptr;
diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
index 7a9fb9b..c17bf38 100644
--- a/drivers/soc/fsl/Kconfig
+++ b/drivers/soc/fsl/Kconfig
@@ -16,3 +16,13 @@ config FSL_GUTS
Initially only reading SVR and registering soc device are supported.
Other guts accesses, such as reading RCW, should eventually be moved
into this driver as well.
+
+config FSL_MC_DPIO
+ tristate "QorIQ DPAA2 DPIO driver"
+ depends on FSL_MC_BUS
+ help
+ Driver for the DPAA2 DPIO object. A DPIO provides queue and
+ buffer management facilities for software to interact with
+ other DPAA2 objects. This driver does not expose the DPIO
+ objects individually, but groups them under a service layer
+ API.
diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
index 44b3beb..803ef1b 100644
--- a/drivers/soc/fsl/Makefile
+++ b/drivers/soc/fsl/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_FSL_DPAA) += qbman/
obj-$(CONFIG_QUICC_ENGINE) += qe/
obj-$(CONFIG_CPM) += qe/
obj-$(CONFIG_FSL_GUTS) += guts.o
+obj-$(CONFIG_FSL_MC_DPIO) += dpio/
diff --git a/drivers/staging/fsl-mc/bus/dpio/Makefile b/drivers/soc/fsl/dpio/Makefile
similarity index 100%
rename from drivers/staging/fsl-mc/bus/dpio/Makefile
rename to drivers/soc/fsl/dpio/Makefile
diff --git a/drivers/staging/fsl-mc/bus/dpio/dpio-cmd.h b/drivers/soc/fsl/dpio/dpio-cmd.h
similarity index 100%
rename from drivers/staging/fsl-mc/bus/dpio/dpio-cmd.h
rename to drivers/soc/fsl/dpio/dpio-cmd.h
diff --git a/drivers/staging/fsl-mc/bus/dpio/dpio-driver.c b/drivers/soc/fsl/dpio/dpio-driver.c
similarity index 99%
rename from drivers/staging/fsl-mc/bus/dpio/dpio-driver.c
rename to drivers/soc/fsl/dpio/dpio-driver.c
index 11a90a9..b60b77b 100644
--- a/drivers/staging/fsl-mc/bus/dpio/dpio-driver.c
+++ b/drivers/soc/fsl/dpio/dpio-driver.c
@@ -16,7 +16,7 @@
#include <linux/io.h>
#include <linux/fsl/mc.h>
-#include "../../include/dpaa2-io.h"
+#include <soc/fsl/dpaa2-io.h>
#include "qbman-portal.h"
#include "dpio.h"
diff --git a/drivers/staging/fsl-mc/bus/dpio/dpio-driver.txt b/drivers/soc/fsl/dpio/dpio-driver.txt
similarity index 100%
rename from drivers/staging/fsl-mc/bus/dpio/dpio-driver.txt
rename to drivers/soc/fsl/dpio/dpio-driver.txt
diff --git a/drivers/staging/fsl-mc/bus/dpio/dpio-service.c b/drivers/soc/fsl/dpio/dpio-service.c
similarity index 99%
rename from drivers/staging/fsl-mc/bus/dpio/dpio-service.c
rename to drivers/soc/fsl/dpio/dpio-service.c
index 14ed2be..9b17f72 100644
--- a/drivers/staging/fsl-mc/bus/dpio/dpio-service.c
+++ b/drivers/soc/fsl/dpio/dpio-service.c
@@ -6,7 +6,7 @@
*/
#include <linux/types.h>
#include <linux/fsl/mc.h>
-#include "../../include/dpaa2-io.h"
+#include <soc/fsl/dpaa2-io.h>
#include <linux/init.h>
#include <linux/module.h>
#include <linux/platform_device.h>
diff --git a/drivers/staging/fsl-mc/bus/dpio/dpio.c b/drivers/soc/fsl/dpio/dpio.c
similarity index 100%
rename from drivers/staging/fsl-mc/bus/dpio/dpio.c
rename to drivers/soc/fsl/dpio/dpio.c
diff --git a/drivers/staging/fsl-mc/bus/dpio/dpio.h b/drivers/soc/fsl/dpio/dpio.h
similarity index 100%
rename from drivers/staging/fsl-mc/bus/dpio/dpio.h
rename to drivers/soc/fsl/dpio/dpio.h
diff --git a/drivers/staging/fsl-mc/bus/dpio/qbman-portal.c b/drivers/soc/fsl/dpio/qbman-portal.c
similarity index 99%
rename from drivers/staging/fsl-mc/bus/dpio/qbman-portal.c
rename to drivers/soc/fsl/dpio/qbman-portal.c
index 116fafb..cf1d448 100644
--- a/drivers/staging/fsl-mc/bus/dpio/qbman-portal.c
+++ b/drivers/soc/fsl/dpio/qbman-portal.c
@@ -8,7 +8,7 @@
#include <asm/cacheflush.h>
#include <linux/io.h>
#include <linux/slab.h>
-#include "../../include/dpaa2-global.h"
+#include <soc/fsl/dpaa2-global.h>
#include "qbman-portal.h"
diff --git a/drivers/staging/fsl-mc/bus/dpio/qbman-portal.h b/drivers/soc/fsl/dpio/qbman-portal.h
similarity index 99%
rename from drivers/staging/fsl-mc/bus/dpio/qbman-portal.h
rename to drivers/soc/fsl/dpio/qbman-portal.h
index 69db3c8..89d1dd9 100644
--- a/drivers/staging/fsl-mc/bus/dpio/qbman-portal.h
+++ b/drivers/soc/fsl/dpio/qbman-portal.h
@@ -7,7 +7,7 @@
#ifndef __FSL_QBMAN_PORTAL_H
#define __FSL_QBMAN_PORTAL_H
-#include "../../include/dpaa2-fd.h"
+#include <soc/fsl/dpaa2-fd.h>
struct dpaa2_dq;
struct qbman_swp;
diff --git a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.h b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.h
index 9269cb0..f2917b5 100644
--- a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.h
+++ b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.h
@@ -37,8 +37,8 @@
#include <linux/if_vlan.h>
#include <linux/fsl/mc.h>
-#include "../../fsl-mc/include/dpaa2-io.h"
-#include "../../fsl-mc/include/dpaa2-fd.h"
+#include <soc/fsl/dpaa2-io.h>
+#include <soc/fsl/dpaa2-fd.h>
#include "dpni.h"
#include "dpni-cmd.h"
diff --git a/drivers/staging/fsl-mc/bus/Kconfig b/drivers/staging/fsl-mc/bus/Kconfig
index 3424530..90f234d 100644
--- a/drivers/staging/fsl-mc/bus/Kconfig
+++ b/drivers/staging/fsl-mc/bus/Kconfig
@@ -5,12 +5,3 @@
# Copyright (C) 2014-2016 Freescale Semiconductor, Inc.
#
-config FSL_MC_DPIO
- tristate "QorIQ DPAA2 DPIO driver"
- depends on FSL_MC_BUS
- help
- Driver for the DPAA2 DPIO object. A DPIO provides queue and
- buffer management facilities for software to interact with
- other DPAA2 objects. This driver does not expose the DPIO
- objects individually, but groups them under a service layer
- API.
diff --git a/drivers/staging/fsl-mc/bus/Makefile b/drivers/staging/fsl-mc/bus/Makefile
index 21d8ebc..2141e4b 100644
--- a/drivers/staging/fsl-mc/bus/Makefile
+++ b/drivers/staging/fsl-mc/bus/Makefile
@@ -5,5 +5,3 @@
# Copyright (C) 2014 Freescale Semiconductor, Inc.
#
-# MC DPIO driver
-obj-$(CONFIG_FSL_MC_DPIO) += dpio/
diff --git a/drivers/staging/fsl-mc/include/dpaa2-fd.h b/include/soc/fsl/dpaa2-fd.h
similarity index 100%
rename from drivers/staging/fsl-mc/include/dpaa2-fd.h
rename to include/soc/fsl/dpaa2-fd.h
diff --git a/drivers/staging/fsl-mc/include/dpaa2-global.h b/include/soc/fsl/dpaa2-global.h
similarity index 100%
rename from drivers/staging/fsl-mc/include/dpaa2-global.h
rename to include/soc/fsl/dpaa2-global.h
diff --git a/drivers/staging/fsl-mc/include/dpaa2-io.h b/include/soc/fsl/dpaa2-io.h
similarity index 100%
rename from drivers/staging/fsl-mc/include/dpaa2-io.h
rename to include/soc/fsl/dpaa2-io.h
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v3] PCI: Check for PCIe downtraining conditions
From: Alex G. @ 2018-07-23 17:01 UTC (permalink / raw)
To: Tal Gilboa, Bjorn Helgaas
Cc: bhelgaas, alex_gagniuc, austin_bolen, shyam_iyer, keith.busch,
linux-pci, linux-kernel, Jeff Kirsher, Ariel Elior, Michael Chan,
Ganesh Goudar, Tariq Toukan, Jakub Kicinski, Dave Airlie,
Alex Deucher
In-Reply-To: <9d752b75-eab2-6fd1-f9da-09985966436c@mellanox.com>
On 07/23/2018 12:21 AM, Tal Gilboa wrote:
> On 7/19/2018 6:49 PM, Alex G. wrote:
>>
>>
>> On 07/18/2018 08:38 AM, Tal Gilboa wrote:
>>> On 7/16/2018 5:17 PM, Bjorn Helgaas wrote:
>>>> [+cc maintainers of drivers that already use pcie_print_link_status()
>>>> and GPU folks]
>> [snip]
>>>>
>>>>> + /* Multi-function PCIe share the same link/status. */
>>>>> + if ((PCI_FUNC(dev->devfn) != 0) || dev->is_virtfn)
>>>>> + return;
>>>>> +
>>>>> + pcie_print_link_status(dev);
>>>>> +}
>>>
>>> Is this function called by default for every PCIe device? What about
>>> VFs? We make an exception for them on our driver since a VF doesn't
>>> have access to the needed information in order to provide a
>>> meaningful message.
>>
>> I'm assuming VF means virtual function. pcie_print_link_status()
>> doesn't care if it's passed a virtual function. It will try to do its
>> job. That's why I bail out three lines above, with 'dev->is_virtfn'
>> check.
>>
>> Alex
>
> That's the point - we don't want to call pcie_print_link_status() for
> virtual functions. We make the distinction in our driver. If you want to
> change the code to call this function by default it shouldn't affect the
> current usage.
I'm not understanding very well what you're asking. I understand you
want to avoid printing this message on virtual functions, and that's
already taken care of. I'm also not changing current behavior. Let's
get v2 out and start the discussion again based on that.
Alex
^ permalink raw reply
* [PATCH v2 4/4] drivers/soc/fsl/dpio: Convert DPIO documentation to .rst
From: Roy Pledge @ 2018-07-23 17:00 UTC (permalink / raw)
To: devel, linux-arm-kernel, gregkh, leoyang.li
Cc: laurentiu.tudor, ruxandra.radulescu, horia.geanta, linux-kernel,
arnd, catalin.marinas, robin.murphy, Roy Pledge
In-Reply-To: <20180723170025.2259-1-roy.pledge@nxp.com>
Convert the Datapath I/O documentation to .rst format
and move to the Documation/networking/dpaa2 directory
Signed-off-by: Roy Pledge <roy.pledge@nxp.com>
---
.../networking/dpaa2/dpio-driver.rst | 30 +++++++++++++++++++---
Documentation/networking/dpaa2/index.rst | 1 +
2 files changed, 28 insertions(+), 3 deletions(-)
rename drivers/soc/fsl/dpio/dpio-driver.txt => Documentation/networking/dpaa2/dpio-driver.rst (94%)
diff --git a/drivers/soc/fsl/dpio/dpio-driver.txt b/Documentation/networking/dpaa2/dpio-driver.rst
similarity index 94%
rename from drivers/soc/fsl/dpio/dpio-driver.txt
rename to Documentation/networking/dpaa2/dpio-driver.rst
index 72ba9da..3a33a33 100644
--- a/drivers/soc/fsl/dpio/dpio-driver.txt
+++ b/Documentation/networking/dpaa2/dpio-driver.rst
@@ -1,7 +1,16 @@
-Copyright 2016 NXP
+.. include:: <isonum.txt>
+
+DPAA2 DPIO (Data Path I/O) Overview
+===================================
+
+:Copyright: |copy| 2015 Freescale Semiconductor Inc.
+:Copyright: |copy| 2018 NXP
+
+This document provides an overview of the Freescale DPAA2 DPIO
+drivers
Introduction
-------------
+============
A DPAA2 DPIO (Data Path I/O) is a hardware object that provides
interfaces to enqueue and dequeue frames to/from network interfaces
@@ -27,8 +36,11 @@ provides services that:
The Linux DPIO driver consists of 3 primary components--
DPIO object driver-- fsl-mc driver that manages the DPIO object
+
DPIO service-- provides APIs to other Linux drivers for services
+
QBman portal interface-- sends portal commands, gets responses
+::
fsl-mc other
bus drivers
@@ -45,8 +57,9 @@ The Linux DPIO driver consists of 3 primary components--
|
hardware
+
The diagram below shows how the DPIO driver components fit with the other
-DPAA2 Linux driver components:
+DPAA2 Linux driver components::
+------------+
| OS Network |
| Stack |
@@ -98,20 +111,29 @@ DPIO service (dpio-service.c, dpaa2-io.h)
Notification handling
dpaa2_io_service_register()
+
dpaa2_io_service_deregister()
+
dpaa2_io_service_rearm()
Queuing
dpaa2_io_service_pull_fq()
+
dpaa2_io_service_pull_channel()
+
dpaa2_io_service_enqueue_fq()
+
dpaa2_io_service_enqueue_qd()
+
dpaa2_io_store_create()
+
dpaa2_io_store_destroy()
+
dpaa2_io_store_next()
Buffer pool management
dpaa2_io_service_release()
+
dpaa2_io_service_acquire()
QBman portal interface (qbman-portal.c)
@@ -120,7 +142,9 @@ QBman portal interface (qbman-portal.c)
The qbman-portal component provides APIs to do the low level hardware
bit twiddling for operations such as:
-initializing Qman software portals
+
-building and sending portal commands
+
-portal interrupt configuration and processing
The qbman-portal APIs are not public to other drivers, and are
diff --git a/Documentation/networking/dpaa2/index.rst b/Documentation/networking/dpaa2/index.rst
index 4c6586c..10bea11 100644
--- a/Documentation/networking/dpaa2/index.rst
+++ b/Documentation/networking/dpaa2/index.rst
@@ -6,3 +6,4 @@ DPAA2 Documentation
:maxdepth: 1
overview
+ dpio-driver
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/4] drivers/staging: Remove fsl-mc driver from staging
From: Roy Pledge @ 2018-07-23 17:00 UTC (permalink / raw)
To: devel, linux-arm-kernel, gregkh, leoyang.li
Cc: laurentiu.tudor, ruxandra.radulescu, horia.geanta, linux-kernel,
arnd, catalin.marinas, robin.murphy, Roy Pledge
In-Reply-To: <20180723170025.2259-1-roy.pledge@nxp.com>
Remove the staging/drivers/fsl-mc directory from the staging
area now that all the components have been moved to the main
kernel areas.
Signed-off-by: Roy Pledge <roy.pledge@nxp.com>
---
drivers/staging/Kconfig | 2 --
drivers/staging/Makefile | 1 -
drivers/staging/fsl-mc/Kconfig | 2 --
drivers/staging/fsl-mc/Makefile | 3 ---
drivers/staging/fsl-mc/bus/Kconfig | 7 -------
drivers/staging/fsl-mc/bus/Makefile | 7 -------
6 files changed, 22 deletions(-)
delete mode 100644 drivers/staging/fsl-mc/Kconfig
delete mode 100644 drivers/staging/fsl-mc/Makefile
delete mode 100644 drivers/staging/fsl-mc/bus/Kconfig
delete mode 100644 drivers/staging/fsl-mc/bus/Makefile
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 75a4804..47b61c3 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -92,8 +92,6 @@ source "drivers/staging/clocking-wizard/Kconfig"
source "drivers/staging/fbtft/Kconfig"
-source "drivers/staging/fsl-mc/Kconfig"
-
source "drivers/staging/fsl-dpaa2/Kconfig"
source "drivers/staging/wilc1000/Kconfig"
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index e84959a..bfef8f2 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -37,7 +37,6 @@ obj-$(CONFIG_CRYPTO_SKEIN) += skein/
obj-$(CONFIG_UNISYSSPAR) += unisys/
obj-$(CONFIG_COMMON_CLK_XLNX_CLKWZRD) += clocking-wizard/
obj-$(CONFIG_FB_TFT) += fbtft/
-obj-$(CONFIG_FSL_MC_BUS) += fsl-mc/
obj-$(CONFIG_FSL_DPAA2) += fsl-dpaa2/
obj-$(CONFIG_WILC1000) += wilc1000/
obj-$(CONFIG_MOST) += most/
diff --git a/drivers/staging/fsl-mc/Kconfig b/drivers/staging/fsl-mc/Kconfig
deleted file mode 100644
index 3002229..0000000
--- a/drivers/staging/fsl-mc/Kconfig
+++ /dev/null
@@ -1,2 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-source "drivers/staging/fsl-mc/bus/Kconfig"
diff --git a/drivers/staging/fsl-mc/Makefile b/drivers/staging/fsl-mc/Makefile
deleted file mode 100644
index 1468388..0000000
--- a/drivers/staging/fsl-mc/Makefile
+++ /dev/null
@@ -1,3 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-# Freescale Management Complex (MC) bus drivers
-obj-$(CONFIG_FSL_MC_BUS) += bus/
diff --git a/drivers/staging/fsl-mc/bus/Kconfig b/drivers/staging/fsl-mc/bus/Kconfig
deleted file mode 100644
index 90f234d..0000000
--- a/drivers/staging/fsl-mc/bus/Kconfig
+++ /dev/null
@@ -1,7 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-#
-# DPAA2 fsl-mc bus
-#
-# Copyright (C) 2014-2016 Freescale Semiconductor, Inc.
-#
-
diff --git a/drivers/staging/fsl-mc/bus/Makefile b/drivers/staging/fsl-mc/bus/Makefile
deleted file mode 100644
index 2141e4b..0000000
--- a/drivers/staging/fsl-mc/bus/Makefile
+++ /dev/null
@@ -1,7 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-#
-# Freescale Management Complex (MC) bus drivers
-#
-# Copyright (C) 2014 Freescale Semiconductor, Inc.
-#
-
--
2.7.4
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH v3 33/40] elf: Relax MIPS' elf_check_arch() to accept EM_NANOMIPS too
From: Richard Henderson @ 2018-07-23 17:01 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-34-git-send-email-stefan.markovic@rt-rk.com>
On 07/19/2018 05:55 AM, Stefan Markovic wrote:
> From: Aleksandar Markovic <amarkovic@wavecomp.com>
>
> Starting from nanoMIPS introduction, machine variant can be
> EM_MIPS or EM_NANOMIPS.
>
> Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com>
> Signed-off-by: Stefan Markovic <smarkovic@wavecomp.com>
> ---
> linux-user/elfload.c | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
r~
^ permalink raw reply
* [PATCH] packagegroup-core-full-cmdline: clean up system-services dependencies
From: Ross Burton @ 2018-07-23 17:01 UTC (permalink / raw)
To: openembedded-core
The 'system services' packagegroup depends on a number of packages which are not
system services, so remove them from the list.
Signed-off-by: Ross Burton <ross.burton@intel.com>
---
.../packagegroups/packagegroup-core-full-cmdline.bb | 8 --------
1 file changed, 8 deletions(-)
diff --git a/meta/recipes-extended/packagegroups/packagegroup-core-full-cmdline.bb b/meta/recipes-extended/packagegroups/packagegroup-core-full-cmdline.bb
index 1b938fb849c..e8616880248 100644
--- a/meta/recipes-extended/packagegroups/packagegroup-core-full-cmdline.bb
+++ b/meta/recipes-extended/packagegroups/packagegroup-core-full-cmdline.bb
@@ -133,16 +133,8 @@ RDEPENDS_packagegroup-core-full-cmdline-multiuser = "\
RDEPENDS_packagegroup-core-full-cmdline-sys-services = "\
at \
- bzip2 \
cronie \
- dbus \
- elfutils \
- gzip \
- less \
logrotate \
nfs-utils \
- pciutils \
rpcbind \
- tcp-wrappers \
- tzdata \
"
--
2.11.0
^ permalink raw reply related
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.