This is a note to let you know that I've just added the patch titled
EDAC, sb_edac: Fix missing break in switch
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
edac-sb_edac-fix-missing-break-in-switch.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com>
Date: Mon, 16 Oct 2017 12:40:29 -0500
Subject: EDAC, sb_edac: Fix missing break in switch
From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com>
[ Upstream commit a8e9b186f153a44690ad0363a56716e7077ad28c ]
Add missing break statement in order to prevent the code from falling
through.
Signed-off-by: Gustavo A. R. Silva <garsilva(a)embeddedor.com>
Cc: Qiuxu Zhuo <qiuxu.zhuo(a)intel.com>
Cc: linux-edac <linux-edac(a)vger.kernel.org>
Link: http://lkml.kernel.org/r/20171016174029.GA19757@embeddedor.com
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/edac/sb_edac.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/edac/sb_edac.c
+++ b/drivers/edac/sb_edac.c
@@ -2510,6 +2510,7 @@ static int ibridge_mci_bind_devs(struct
break;
case PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA0_TA:
pvt->pci_ta = pdev;
+ break;
case PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA0_RAS:
pvt->pci_ras = pdev;
break;
Patches currently in stable-queue which might be from garsilva(a)embeddedor.com are
queue-4.9/edac-sb_edac-fix-missing-break-in-switch.patch
This is a note to let you know that I've just added the patch titled
drm/exynos/decon5433: update shadow registers iff there are active windows
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-exynos-decon5433-update-shadow-registers-iff-there-are-active-windows.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Andrzej Hajda <a.hajda(a)samsung.com>
Date: Mon, 9 Jan 2017 15:33:02 +0100
Subject: drm/exynos/decon5433: update shadow registers iff there are active windows
From: Andrzej Hajda <a.hajda(a)samsung.com>
[ Upstream commit f65a7c9cb3770ed4d3e7c57c66d7032689081b5e ]
Improper usage of DECON_UPDATE register leads to subtle errors.
If it set in decon_commit when there are no active windows it results
in slow registry updates - all subsequent shadow registry updates takes more
than full vblank. On the other side if it is not set when there are
active windows it results in garbage on the screen after suspend/resume of
FB console.
The patch hopefully fixes it.
Signed-off-by: Andrzej Hajda <a.hajda(a)samsung.com>
Signed-off-by: Inki Dae <inki.dae(a)samsung.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -188,8 +188,6 @@ static void decon_commit(struct exynos_d
/* enable output and display signal */
decon_set_bits(ctx, DECON_VIDCON0, VIDCON0_ENVID | VIDCON0_ENVID_F, ~0);
-
- decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
}
static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int win,
@@ -340,8 +338,9 @@ static void decon_atomic_flush(struct ex
for (i = ctx->first_win; i < WINDOWS_NR; i++)
decon_shadow_protect_win(ctx, i, false);
- /* standalone update */
- decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
+ /* update iff there are active windows */
+ if (crtc->base.state->plane_mask)
+ decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
if (ctx->out_type & IFTYPE_I80)
set_bit(BIT_WIN_UPDATED, &ctx->flags);
Patches currently in stable-queue which might be from a.hajda(a)samsung.com are
queue-4.9/drm-exynos-decon5433-set-standalone_update_f-also-if-planes-are-disabled.patch
queue-4.9/drm-exynos-decon5433-update-shadow-registers-iff-there-are-active-windows.patch
queue-4.9/drm-exynos-decon5433-set-standalone_update_f-on-output-enablement.patch
This is a note to let you know that I've just added the patch titled
drm/exynos/decon5433: set STANDALONE_UPDATE_F on output enablement
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-exynos-decon5433-set-standalone_update_f-on-output-enablement.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Andrzej Hajda <a.hajda(a)samsung.com>
Date: Tue, 17 Jan 2017 15:15:20 +0100
Subject: drm/exynos/decon5433: set STANDALONE_UPDATE_F on output enablement
From: Andrzej Hajda <a.hajda(a)samsung.com>
[ Upstream commit 11d8bcef7a0399e1d2519f207fd575fc404306b4 ]
DECON_TV requires STANDALONE_UPDATE after output enabling, otherwise it does
not start. This change is neutral for DECON.
Signed-off-by: Andrzej Hajda <a.hajda(a)samsung.com>
Signed-off-by: Inki Dae <inki.dae(a)samsung.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -189,6 +189,8 @@ static void decon_commit(struct exynos_d
/* enable output and display signal */
decon_set_bits(ctx, DECON_VIDCON0, VIDCON0_ENVID | VIDCON0_ENVID_F, ~0);
+
+ decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
}
static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int win,
Patches currently in stable-queue which might be from a.hajda(a)samsung.com are
queue-4.9/drm-exynos-decon5433-set-standalone_update_f-also-if-planes-are-disabled.patch
queue-4.9/drm-exynos-decon5433-update-shadow-registers-iff-there-are-active-windows.patch
queue-4.9/drm-exynos-decon5433-set-standalone_update_f-on-output-enablement.patch
This is a note to let you know that I've just added the patch titled
drm/exynos/decon5433: set STANDALONE_UPDATE_F also if planes are disabled
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-exynos-decon5433-set-standalone_update_f-also-if-planes-are-disabled.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Andrzej Hajda <a.hajda(a)samsung.com>
Date: Fri, 13 Jan 2017 10:20:58 +0100
Subject: drm/exynos/decon5433: set STANDALONE_UPDATE_F also if planes are disabled
From: Andrzej Hajda <a.hajda(a)samsung.com>
[ Upstream commit 821b40b79db7dedbfe15ab330dfd181e661a533f ]
STANDALONE_UPDATE_F should be set if something changed in plane configurations,
including plane disable.
The patch fixes page-faults bugs, caused by decon still using framebuffers
of disabled planes.
v2: fixed clear-bit code (Thx Marek)
v3: use test_and_clear_bit (Thx Joonyoung)
Signed-off-by: Andrzej Hajda <a.hajda(a)samsung.com>
Tested-by: Joonyoung Shim <jy0922.shim(a)samsung.com>
Signed-off-by: Inki Dae <inki.dae(a)samsung.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -46,7 +46,8 @@ enum decon_flag_bits {
BIT_CLKS_ENABLED,
BIT_IRQS_ENABLED,
BIT_WIN_UPDATED,
- BIT_SUSPENDED
+ BIT_SUSPENDED,
+ BIT_REQUEST_UPDATE
};
struct decon_context {
@@ -313,6 +314,7 @@ static void decon_update_plane(struct ex
/* window enable */
decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_ENWIN_F, ~0);
+ set_bit(BIT_REQUEST_UPDATE, &ctx->flags);
}
static void decon_disable_plane(struct exynos_drm_crtc *crtc,
@@ -325,6 +327,7 @@ static void decon_disable_plane(struct e
return;
decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_ENWIN_F, 0);
+ set_bit(BIT_REQUEST_UPDATE, &ctx->flags);
}
static void decon_atomic_flush(struct exynos_drm_crtc *crtc)
@@ -338,8 +341,7 @@ static void decon_atomic_flush(struct ex
for (i = ctx->first_win; i < WINDOWS_NR; i++)
decon_shadow_protect_win(ctx, i, false);
- /* update iff there are active windows */
- if (crtc->base.state->plane_mask)
+ if (test_and_clear_bit(BIT_REQUEST_UPDATE, &ctx->flags))
decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
if (ctx->out_type & IFTYPE_I80)
Patches currently in stable-queue which might be from a.hajda(a)samsung.com are
queue-4.9/drm-exynos-decon5433-set-standalone_update_f-also-if-planes-are-disabled.patch
queue-4.9/drm-exynos-decon5433-update-shadow-registers-iff-there-are-active-windows.patch
queue-4.9/drm-exynos-decon5433-set-standalone_update_f-on-output-enablement.patch
This is a note to let you know that I've just added the patch titled
drm/amdgpu: fix unload driver issue for virtual display
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-amdgpu-fix-unload-driver-issue-for-virtual-display.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Xiangliang Yu <Xiangliang.Yu(a)amd.com>
Date: Thu, 19 Jan 2017 09:57:41 +0800
Subject: drm/amdgpu: fix unload driver issue for virtual display
From: Xiangliang Yu <Xiangliang.Yu(a)amd.com>
[ Upstream commit 3a1d19a29670aa7eb58576a31883d0aa9fb77549 ]
Virtual display doesn't allocate amdgpu_encoder when initializing,
so will get invaild pointer if try to free amdgpu_encoder when
unloading driver.
Signed-off-by: Xiangliang Yu <Xiangliang.Yu(a)amd.com>
Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com>
Acked-by: Christian König <christian.koenig(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
--- a/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
@@ -565,11 +565,8 @@ static const struct drm_encoder_helper_f
static void dce_virtual_encoder_destroy(struct drm_encoder *encoder)
{
- struct amdgpu_encoder *amdgpu_encoder = to_amdgpu_encoder(encoder);
-
- kfree(amdgpu_encoder->enc_priv);
drm_encoder_cleanup(encoder);
- kfree(amdgpu_encoder);
+ kfree(encoder);
}
static const struct drm_encoder_funcs dce_virtual_encoder_funcs = {
Patches currently in stable-queue which might be from Xiangliang.Yu(a)amd.com are
queue-4.9/drm-amdgpu-fix-unload-driver-issue-for-virtual-display.patch
This is a note to let you know that I've just added the patch titled
drm/amdgpu: fix bug set incorrect value to vce register
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-amdgpu-fix-bug-set-incorrect-value-to-vce-register.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Rex Zhu <Rex.Zhu(a)amd.com>
Date: Tue, 10 Jan 2017 20:00:40 +0800
Subject: drm/amdgpu: fix bug set incorrect value to vce register
From: Rex Zhu <Rex.Zhu(a)amd.com>
[ Upstream commit e05208ded1905e500cd5b369d624b071951c68b9 ]
Set the proper bits for clockgating setup.
Signed-off-by: Rex Zhu <Rex.Zhu(a)amd.com>
Acked-by: Christian König <christian.koenig(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/vce_v3_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
@@ -182,7 +182,7 @@ static void vce_v3_0_set_vce_sw_clock_ga
WREG32(mmVCE_UENC_CLOCK_GATING_2, data);
data = RREG32(mmVCE_UENC_REG_CLOCK_GATING);
- data &= ~0xffc00000;
+ data &= ~0x3ff;
WREG32(mmVCE_UENC_REG_CLOCK_GATING, data);
data = RREG32(mmVCE_UENC_DMA_DCLK_CTRL);
Patches currently in stable-queue which might be from Rex.Zhu(a)amd.com are
queue-4.9/drm-amdgpu-fix-bug-set-incorrect-value-to-vce-register.patch
This is a note to let you know that I've just added the patch titled
dmaengine: stm32-dma: Set correct args number for DMA request from DT
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
dmaengine-stm32-dma-set-correct-args-number-for-dma-request-from-dt.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: M'boumba Cedric Madianga <cedric.madianga(a)gmail.com>
Date: Tue, 13 Dec 2016 14:40:43 +0100
Subject: dmaengine: stm32-dma: Set correct args number for DMA request from DT
From: M'boumba Cedric Madianga <cedric.madianga(a)gmail.com>
[ Upstream commit 7e96304d99477de1f70db42035071e56439da817 ]
This patch sets the right number of arguments to be used for DMA clients
which request channels from DT.
Signed-off-by: M'boumba Cedric Madianga <cedric.madianga(a)gmail.com>
Reviewed-by: Ludovic BARRE <ludovic.barre(a)st.com>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/stm32-dma.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
--- a/drivers/dma/stm32-dma.c
+++ b/drivers/dma/stm32-dma.c
@@ -976,21 +976,18 @@ static struct dma_chan *stm32_dma_of_xla
struct stm32_dma_chan *chan;
struct dma_chan *c;
- if (dma_spec->args_count < 3)
+ if (dma_spec->args_count < 4)
return NULL;
cfg.channel_id = dma_spec->args[0];
cfg.request_line = dma_spec->args[1];
cfg.stream_config = dma_spec->args[2];
- cfg.threshold = 0;
+ cfg.threshold = dma_spec->args[3];
if ((cfg.channel_id >= STM32_DMA_MAX_CHANNELS) || (cfg.request_line >=
STM32_DMA_MAX_REQUEST_ID))
return NULL;
- if (dma_spec->args_count > 3)
- cfg.threshold = dma_spec->args[3];
-
chan = &dmadev->chan[cfg.channel_id];
c = dma_get_slave_channel(&chan->vchan.chan);
Patches currently in stable-queue which might be from cedric.madianga(a)gmail.com are
queue-4.9/dmaengine-stm32-dma-fix-null-pointer-dereference-in-stm32_dma_tx_status.patch
queue-4.9/dmaengine-stm32-dma-set-correct-args-number-for-dma-request-from-dt.patch
This is a note to let you know that I've just added the patch titled
dmaengine: stm32-dma: Fix null pointer dereference in stm32_dma_tx_status
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
dmaengine-stm32-dma-fix-null-pointer-dereference-in-stm32_dma_tx_status.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: M'boumba Cedric Madianga <cedric.madianga(a)gmail.com>
Date: Tue, 13 Dec 2016 14:40:46 +0100
Subject: dmaengine: stm32-dma: Fix null pointer dereference in stm32_dma_tx_status
From: M'boumba Cedric Madianga <cedric.madianga(a)gmail.com>
[ Upstream commit 57b5a32135c813f2ab669039fb4ec16b30cb3305 ]
chan->desc is always set to NULL when a DMA transfer is complete.
As a DMA transfer could be complete during the call of stm32_dma_tx_status,
we need to be sure that chan->desc is not NULL before using this variable
to avoid a null pointer deference issue.
Signed-off-by: M'boumba Cedric Madianga <cedric.madianga(a)gmail.com>
Reviewed-by: Ludovic BARRE <ludovic.barre(a)st.com>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/stm32-dma.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
--- a/drivers/dma/stm32-dma.c
+++ b/drivers/dma/stm32-dma.c
@@ -884,7 +884,7 @@ static enum dma_status stm32_dma_tx_stat
struct virt_dma_desc *vdesc;
enum dma_status status;
unsigned long flags;
- u32 residue;
+ u32 residue = 0;
status = dma_cookie_status(c, cookie, state);
if ((status == DMA_COMPLETE) || (!state))
@@ -892,16 +892,12 @@ static enum dma_status stm32_dma_tx_stat
spin_lock_irqsave(&chan->vchan.lock, flags);
vdesc = vchan_find_desc(&chan->vchan, cookie);
- if (cookie == chan->desc->vdesc.tx.cookie) {
+ if (chan->desc && cookie == chan->desc->vdesc.tx.cookie)
residue = stm32_dma_desc_residue(chan, chan->desc,
chan->next_sg);
- } else if (vdesc) {
+ else if (vdesc)
residue = stm32_dma_desc_residue(chan,
to_stm32_dma_desc(vdesc), 0);
- } else {
- residue = 0;
- }
-
dma_set_residue(state, residue);
spin_unlock_irqrestore(&chan->vchan.lock, flags);
Patches currently in stable-queue which might be from cedric.madianga(a)gmail.com are
queue-4.9/dmaengine-stm32-dma-fix-null-pointer-dereference-in-stm32_dma_tx_status.patch
queue-4.9/dmaengine-stm32-dma-set-correct-args-number-for-dma-request-from-dt.patch
This is a note to let you know that I've just added the patch titled
dmaengine: pl330: fix double lock
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
dmaengine-pl330-fix-double-lock.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Iago Abal <mail(a)iagoabal.eu>
Date: Wed, 11 Jan 2017 14:00:21 +0100
Subject: dmaengine: pl330: fix double lock
From: Iago Abal <mail(a)iagoabal.eu>
[ Upstream commit 91539eb1fda2d530d3b268eef542c5414e54bf1a ]
The static bug finder EBA (http://www.iagoabal.eu/eba/) reported the
following double-lock bug:
Double lock:
1. spin_lock_irqsave(pch->lock, flags) at pl330_free_chan_resources:2236;
2. call to function `pl330_release_channel' immediately after;
3. call to function `dma_pl330_rqcb' in line 1753;
4. spin_lock_irqsave(pch->lock, flags) at dma_pl330_rqcb:1505.
I have fixed it as suggested by Marek Szyprowski.
First, I have replaced `pch->lock' with `pl330->lock' in functions
`pl330_alloc_chan_resources' and `pl330_free_chan_resources'. This avoids
the double-lock by acquiring a different lock than `dma_pl330_rqcb'.
NOTE that, as a result, `pl330_free_chan_resources' executes
`list_splice_tail_init' on `pch->work_list' under lock `pl330->lock',
whereas in the rest of the code `pch->work_list' is protected by
`pch->lock'. I don't know if this may cause race conditions. Similarly
`pch->cyclic' is written by `pl330_alloc_chan_resources' under
`pl330->lock' but read by `pl330_tx_submit' under `pch->lock'.
Second, I have removed locking from `pl330_request_channel' and
`pl330_release_channel' functions. Function `pl330_request_channel' is
only called from `pl330_alloc_chan_resources', so the lock is already
held. Function `pl330_release_channel' is called from
`pl330_free_chan_resources', which already holds the lock, and from
`pl330_del'. Function `pl330_del' is called in an error path of
`pl330_probe' and at the end of `pl330_remove', but I assume that there
cannot be concurrent accesses to the protected data at those points.
Signed-off-by: Iago Abal <mail(a)iagoabal.eu>
Reviewed-by: Marek Szyprowski <m.szyprowski(a)samsung.com>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/pl330.c | 19 ++++++-------------
1 file changed, 6 insertions(+), 13 deletions(-)
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -1694,7 +1694,6 @@ static bool _chan_ns(const struct pl330_
static struct pl330_thread *pl330_request_channel(struct pl330_dmac *pl330)
{
struct pl330_thread *thrd = NULL;
- unsigned long flags;
int chans, i;
if (pl330->state == DYING)
@@ -1702,8 +1701,6 @@ static struct pl330_thread *pl330_reques
chans = pl330->pcfg.num_chan;
- spin_lock_irqsave(&pl330->lock, flags);
-
for (i = 0; i < chans; i++) {
thrd = &pl330->channels[i];
if ((thrd->free) && (!_manager_ns(thrd) ||
@@ -1721,8 +1718,6 @@ static struct pl330_thread *pl330_reques
thrd = NULL;
}
- spin_unlock_irqrestore(&pl330->lock, flags);
-
return thrd;
}
@@ -1740,7 +1735,6 @@ static inline void _free_event(struct pl
static void pl330_release_channel(struct pl330_thread *thrd)
{
struct pl330_dmac *pl330;
- unsigned long flags;
if (!thrd || thrd->free)
return;
@@ -1752,10 +1746,8 @@ static void pl330_release_channel(struct
pl330 = thrd->dmac;
- spin_lock_irqsave(&pl330->lock, flags);
_free_event(thrd, thrd->ev);
thrd->free = true;
- spin_unlock_irqrestore(&pl330->lock, flags);
}
/* Initialize the structure for PL330 configuration, that can be used
@@ -2120,20 +2112,20 @@ static int pl330_alloc_chan_resources(st
struct pl330_dmac *pl330 = pch->dmac;
unsigned long flags;
- spin_lock_irqsave(&pch->lock, flags);
+ spin_lock_irqsave(&pl330->lock, flags);
dma_cookie_init(chan);
pch->cyclic = false;
pch->thread = pl330_request_channel(pl330);
if (!pch->thread) {
- spin_unlock_irqrestore(&pch->lock, flags);
+ spin_unlock_irqrestore(&pl330->lock, flags);
return -ENOMEM;
}
tasklet_init(&pch->task, pl330_tasklet, (unsigned long) pch);
- spin_unlock_irqrestore(&pch->lock, flags);
+ spin_unlock_irqrestore(&pl330->lock, flags);
return 1;
}
@@ -2236,12 +2228,13 @@ static int pl330_pause(struct dma_chan *
static void pl330_free_chan_resources(struct dma_chan *chan)
{
struct dma_pl330_chan *pch = to_pchan(chan);
+ struct pl330_dmac *pl330 = pch->dmac;
unsigned long flags;
tasklet_kill(&pch->task);
pm_runtime_get_sync(pch->dmac->ddma.dev);
- spin_lock_irqsave(&pch->lock, flags);
+ spin_lock_irqsave(&pl330->lock, flags);
pl330_release_channel(pch->thread);
pch->thread = NULL;
@@ -2249,7 +2242,7 @@ static void pl330_free_chan_resources(st
if (pch->cyclic)
list_splice_tail_init(&pch->work_list, &pch->dmac->desc_pool);
- spin_unlock_irqrestore(&pch->lock, flags);
+ spin_unlock_irqrestore(&pl330->lock, flags);
pm_runtime_mark_last_busy(pch->dmac->ddma.dev);
pm_runtime_put_autosuspend(pch->dmac->ddma.dev);
}
Patches currently in stable-queue which might be from mail(a)iagoabal.eu are
queue-4.9/dmaengine-pl330-fix-double-lock.patch
This is a note to let you know that I've just added the patch titled
dax: Avoid page invalidation races and unnecessary radix tree traversals
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
dax-avoid-page-invalidation-races-and-unnecessary-radix-tree-traversals.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Jan Kara <jack(a)suse.cz>
Date: Wed, 10 Aug 2016 17:10:28 +0200
Subject: dax: Avoid page invalidation races and unnecessary radix tree traversals
From: Jan Kara <jack(a)suse.cz>
[ Upstream commit e3fce68cdbed297d927e993b3ea7b8b1cee545da ]
Currently dax_iomap_rw() takes care of invalidating page tables and
evicting hole pages from the radix tree when write(2) to the file
happens. This invalidation is only necessary when there is some block
allocation resulting from write(2). Furthermore in current place the
invalidation is racy wrt page fault instantiating a hole page just after
we have invalidated it.
So perform the page invalidation inside dax_iomap_actor() where we can
do it only when really necessary and after blocks have been allocated so
nobody will be instantiating new hole pages anymore.
Reviewed-by: Christoph Hellwig <hch(a)lst.de>
Reviewed-by: Ross Zwisler <ross.zwisler(a)linux.intel.com>
Signed-off-by: Jan Kara <jack(a)suse.cz>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/dax.c | 28 +++++++++++-----------------
1 file changed, 11 insertions(+), 17 deletions(-)
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -1265,6 +1265,17 @@ iomap_dax_actor(struct inode *inode, lof
if (WARN_ON_ONCE(iomap->type != IOMAP_MAPPED))
return -EIO;
+ /*
+ * Write can allocate block for an area which has a hole page mapped
+ * into page tables. We have to tear down these mappings so that data
+ * written by write(2) is visible in mmap.
+ */
+ if ((iomap->flags & IOMAP_F_NEW) && inode->i_mapping->nrpages) {
+ invalidate_inode_pages2_range(inode->i_mapping,
+ pos >> PAGE_SHIFT,
+ (end - 1) >> PAGE_SHIFT);
+ }
+
while (pos < end) {
unsigned offset = pos & (PAGE_SIZE - 1);
struct blk_dax_ctl dax = { 0 };
@@ -1329,23 +1340,6 @@ iomap_dax_rw(struct kiocb *iocb, struct
if (iov_iter_rw(iter) == WRITE)
flags |= IOMAP_WRITE;
- /*
- * Yes, even DAX files can have page cache attached to them: A zeroed
- * page is inserted into the pagecache when we have to serve a write
- * fault on a hole. It should never be dirtied and can simply be
- * dropped from the pagecache once we get real data for the page.
- *
- * XXX: This is racy against mmap, and there's nothing we can do about
- * it. We'll eventually need to shift this down even further so that
- * we can check if we allocated blocks over a hole first.
- */
- if (mapping->nrpages) {
- ret = invalidate_inode_pages2_range(mapping,
- pos >> PAGE_SHIFT,
- (pos + iov_iter_count(iter) - 1) >> PAGE_SHIFT);
- WARN_ON_ONCE(ret);
- }
-
while (iov_iter_count(iter)) {
ret = iomap_apply(inode, pos, iov_iter_count(iter), flags, ops,
iter, iomap_dax_actor);
Patches currently in stable-queue which might be from jack(a)suse.cz are
queue-4.9/mm-avoid-returning-vm_fault_retry-from-page_mkwrite-handlers.patch
queue-4.9/dax-avoid-page-invalidation-races-and-unnecessary-radix-tree-traversals.patch
This is a note to let you know that I've just added the patch titled
[media] cec: initiator should be the same as the destination for, poll
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
cec-initiator-should-be-the-same-as-the-destination-for-poll.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Hans Verkuil <hverkuil(a)xs4all.nl>
Date: Sat, 11 Feb 2017 09:24:46 -0200
Subject: [media] cec: initiator should be the same as the destination for, poll
From: Hans Verkuil <hverkuil(a)xs4all.nl>
[ Upstream commit 42980da2eb7eb9695d8efc0c0ef145cbbb993b2c ]
Poll messages that are used to allocate a logical address should
use the same initiator as the destination. Instead, it expected that
the initiator was 0xf which is not according to the standard.
This also had consequences for the message checks in cec_transmit_msg_fh
that incorrectly rejected poll messages with the same initiator and
destination.
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/media/cec/cec-adap.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
--- a/drivers/staging/media/cec/cec-adap.c
+++ b/drivers/staging/media/cec/cec-adap.c
@@ -608,8 +608,7 @@ int cec_transmit_msg_fh(struct cec_adapt
}
memset(msg->msg + msg->len, 0, sizeof(msg->msg) - msg->len);
if (msg->len == 1) {
- if (cec_msg_initiator(msg) != 0xf ||
- cec_msg_destination(msg) == 0xf) {
+ if (cec_msg_destination(msg) == 0xf) {
dprintk(1, "cec_transmit_msg: invalid poll message\n");
return -EINVAL;
}
@@ -634,7 +633,7 @@ int cec_transmit_msg_fh(struct cec_adapt
dprintk(1, "cec_transmit_msg: destination is the adapter itself\n");
return -EINVAL;
}
- if (cec_msg_initiator(msg) != 0xf &&
+ if (msg->len > 1 && adap->is_configured &&
!cec_has_log_addr(adap, cec_msg_initiator(msg))) {
dprintk(1, "cec_transmit_msg: initiator has unknown logical address %d\n",
cec_msg_initiator(msg));
@@ -883,7 +882,7 @@ static int cec_config_log_addr(struct ce
/* Send poll message */
msg.len = 1;
- msg.msg[0] = 0xf0 | log_addr;
+ msg.msg[0] = (log_addr << 4) | log_addr;
err = cec_transmit_msg_fh(adap, &msg, NULL, true);
/*
Patches currently in stable-queue which might be from hverkuil(a)xs4all.nl are
queue-4.9/cec-initiator-should-be-the-same-as-the-destination-for-poll.patch
This is a note to let you know that I've just added the patch titled
be2net: fix initial MAC setting
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
be2net-fix-initial-mac-setting.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Ivan Vecera <cera(a)cera.cz>
Date: Tue, 31 Jan 2017 20:01:31 +0100
Subject: be2net: fix initial MAC setting
From: Ivan Vecera <cera(a)cera.cz>
[ Upstream commit 4993b39ab04b083ff6ee1147e7e7f120feb6bf7f ]
Recent commit 34393529163a ("be2net: fix MAC addr setting on privileged
BE3 VFs") allows privileged BE3 VFs to set its MAC address during
initialization. Although the initial MAC for such VFs is already
programmed by parent PF the subsequent setting performed by VF is OK,
but in certain cases (after fresh boot) this command in VF can fail.
The MAC should be initialized only when:
1) no MAC is programmed (always except BE3 VFs during first init)
2) programmed MAC is different from requested (e.g. MAC is set when
interface is down). In this case the initial MAC programmed by PF
needs to be deleted.
The adapter->dev_mac contains MAC address currently programmed in HW so
it should be zeroed when the MAC is deleted from HW and should not be
filled when MAC is set when interface is down in be_mac_addr_set() as
no programming is performed in this case.
Example of failure without the fix (immediately after fresh boot):
# ip link set eth0 up <- eth0 is BE3 PF
be2net 0000:01:00.0 eth0: Link is Up
# echo 1 > /sys/class/net/eth0/device/sriov_numvfs <- Create 1 VF
...
be2net 0000:01:04.0: Emulex OneConnect(be3): VF port 0
# ip link set eth8 up <- eth8 is created privileged VF
be2net 0000:01:04.0: opcode 59-1 failed:status 1-76
RTNETLINK answers: Input/output error
# echo 0 > /sys/class/net/eth0/device/sriov_numvfs <- Delete VF
iommu: Removing device 0000:01:04.0 from group 33
...
# echo 1 > /sys/class/net/eth0/device/sriov_numvfs <- Create it again
iommu: Removing device 0000:01:04.0 from group 33
...
# ip link set eth8 up
be2net 0000:01:04.0 eth8: Link is Up
Initialization is now OK.
v2 - Corrected the comment and condition check suggested by Suresh & Harsha
Fixes: 34393529163a ("be2net: fix MAC addr setting on privileged BE3 VFs")
Cc: Sathya Perla <sathya.perla(a)broadcom.com>
Cc: Ajit Khaparde <ajit.khaparde(a)broadcom.com>
Cc: Sriharsha Basavapatna <sriharsha.basavapatna(a)broadcom.com>
Cc: Somnath Kotur <somnath.kotur(a)broadcom.com>
Signed-off-by: Ivan Vecera <cera(a)cera.cz>
Acked-by: Sriharsha Basavapatna <sriharsha.basavapatna(a)broadcom.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/emulex/benet/be_main.c | 33 +++++++++++++++++++++++-----
1 file changed, 28 insertions(+), 5 deletions(-)
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -362,8 +362,10 @@ static int be_mac_addr_set(struct net_de
status = -EPERM;
goto err;
}
-done:
+
+ /* Remember currently programmed MAC */
ether_addr_copy(adapter->dev_mac, addr->sa_data);
+done:
ether_addr_copy(netdev->dev_addr, addr->sa_data);
dev_info(dev, "MAC address changed to %pM\n", addr->sa_data);
return 0;
@@ -3635,8 +3637,10 @@ static void be_disable_if_filters(struct
{
/* Don't delete MAC on BE3 VFs without FILTMGMT privilege */
if (!BEx_chip(adapter) || !be_virtfn(adapter) ||
- check_privilege(adapter, BE_PRIV_FILTMGMT))
+ check_privilege(adapter, BE_PRIV_FILTMGMT)) {
be_dev_mac_del(adapter, adapter->pmac_id[0]);
+ eth_zero_addr(adapter->dev_mac);
+ }
be_clear_uc_list(adapter);
be_clear_mc_list(adapter);
@@ -3790,12 +3794,27 @@ static int be_enable_if_filters(struct b
if (status)
return status;
- /* Don't add MAC on BE3 VFs without FILTMGMT privilege */
- if (!BEx_chip(adapter) || !be_virtfn(adapter) ||
- check_privilege(adapter, BE_PRIV_FILTMGMT)) {
+ /* Normally this condition usually true as the ->dev_mac is zeroed.
+ * But on BE3 VFs the initial MAC is pre-programmed by PF and
+ * subsequent be_dev_mac_add() can fail (after fresh boot)
+ */
+ if (!ether_addr_equal(adapter->dev_mac, adapter->netdev->dev_addr)) {
+ int old_pmac_id = -1;
+
+ /* Remember old programmed MAC if any - can happen on BE3 VF */
+ if (!is_zero_ether_addr(adapter->dev_mac))
+ old_pmac_id = adapter->pmac_id[0];
+
status = be_dev_mac_add(adapter, adapter->netdev->dev_addr);
if (status)
return status;
+
+ /* Delete the old programmed MAC as we successfully programmed
+ * a new MAC
+ */
+ if (old_pmac_id >= 0 && old_pmac_id != adapter->pmac_id[0])
+ be_dev_mac_del(adapter, old_pmac_id);
+
ether_addr_copy(adapter->dev_mac, adapter->netdev->dev_addr);
}
@@ -4569,6 +4588,10 @@ static int be_mac_setup(struct be_adapte
memcpy(adapter->netdev->dev_addr, mac, ETH_ALEN);
memcpy(adapter->netdev->perm_addr, mac, ETH_ALEN);
+
+ /* Initial MAC for BE3 VFs is already programmed by PF */
+ if (BEx_chip(adapter) && be_virtfn(adapter))
+ memcpy(adapter->dev_mac, mac, ETH_ALEN);
}
return 0;
Patches currently in stable-queue which might be from cera(a)cera.cz are
queue-4.9/be2net-fix-accesses-to-unicast-list.patch
queue-4.9/be2net-fix-initial-mac-setting.patch
queue-4.9/be2net-fix-unicast-list-filling.patch
This is a note to let you know that I've just added the patch titled
be2net: fix unicast list filling
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
be2net-fix-unicast-list-filling.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Ivan Vecera <cera(a)cera.cz>
Date: Fri, 6 Jan 2017 21:59:30 +0100
Subject: be2net: fix unicast list filling
From: Ivan Vecera <cera(a)cera.cz>
[ Upstream commit 6052cd1af86f9833b6b0b60d5d4787c4a06d65ea ]
The adapter->pmac_id[0] item is used for primary MAC address but
this is not true for adapter->uc_list[0] as is assumed in
be_set_uc_list(). There are N UC addresses copied first from net_device
to adapter->uc_list[1..N] and then N UC addresses from
adapter->uc_list[0..N-1] are sent to HW. So the last UC address is never
stored into HW and address 00:00:00:00;00:00 (from uc_list[0]) is used
instead.
Cc: Sathya Perla <sathya.perla(a)broadcom.com>
Cc: Ajit Khaparde <ajit.khaparde(a)broadcom.com>
Cc: Sriharsha Basavapatna <sriharsha.basavapatna(a)broadcom.com>
Cc: Somnath Kotur <somnath.kotur(a)broadcom.com>
Fixes: b717241 be2net: replace polling with sleeping in the FW completion path
Signed-off-by: Ivan Vecera <cera(a)cera.cz>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/emulex/benet/be_main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -1719,9 +1719,8 @@ static void be_set_uc_list(struct be_ada
}
if (adapter->update_uc_list) {
- i = 1; /* First slot is claimed by the Primary MAC */
-
/* cache the uc-list in adapter array */
+ i = 0;
netdev_for_each_uc_addr(ha, netdev) {
ether_addr_copy(adapter->uc_list[i].mac, ha->addr);
i++;
Patches currently in stable-queue which might be from cera(a)cera.cz are
queue-4.9/be2net-fix-accesses-to-unicast-list.patch
queue-4.9/be2net-fix-initial-mac-setting.patch
queue-4.9/be2net-fix-unicast-list-filling.patch
This is a note to let you know that I've just added the patch titled
ARM: OMAP2+: Fix WL1283 Bluetooth Baud Rate
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-omap2-fix-wl1283-bluetooth-baud-rate.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Adam Ford <aford173(a)gmail.com>
Date: Tue, 3 Jan 2017 11:37:48 -0600
Subject: ARM: OMAP2+: Fix WL1283 Bluetooth Baud Rate
From: Adam Ford <aford173(a)gmail.com>
[ Upstream commit a3ac350793d90d1da631c8beeee9352387974ed5 ]
Commit 485fa1261f78 ("ARM: OMAP2+: LogicPD Torpedo + Wireless: Add Bluetooth")
set the wrong baud rate for the UART. The Baud rate was 300,000 and it should
be 3,000,000 for WL1283.
Signed-off-by: Adam Ford <aford173(a)gmail.com>
Signed-off-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/mach-omap2/pdata-quirks.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -147,7 +147,7 @@ static struct ti_st_plat_data wilink_pda
.nshutdown_gpio = 137,
.dev_name = "/dev/ttyO1",
.flow_cntrl = 1,
- .baud_rate = 300000,
+ .baud_rate = 3000000,
};
static struct platform_device wl18xx_device = {
Patches currently in stable-queue which might be from aford173(a)gmail.com are
queue-4.9/arm-omap2-fix-wl1283-bluetooth-baud-rate.patch
This is a note to let you know that I've just added the patch titled
ARM: OMAP1: DMA: Correct the number of logical channels
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-omap1-dma-correct-the-number-of-logical-channels.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
Date: Tue, 3 Jan 2017 13:22:34 +0200
Subject: ARM: OMAP1: DMA: Correct the number of logical channels
From: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
[ Upstream commit 657279778af54f35e54b07b6687918f254a2992c ]
OMAP1510, OMAP5910 and OMAP310 have only 9 logical channels.
OMAP1610, OMAP5912, OMAP1710, OMAP730, and OMAP850 have 16 logical channels
available.
The wired 17 for the lch_count must have been used to cover the 16 + 1
dedicated LCD channel, in reality we can only use 9 or 16 channels.
The d->chan_count is not used by the omap-dma stack, so we can skip the
setup. chan_count was configured to the number of logical channels and not
the actual number of physical channels anyways.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
Acked-by: Aaro Koskinen <aaro.koskinen(a)iki.fi>
Signed-off-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/mach-omap1/dma.c | 16 +++++++---------
1 file changed, 7 insertions(+), 9 deletions(-)
--- a/arch/arm/mach-omap1/dma.c
+++ b/arch/arm/mach-omap1/dma.c
@@ -32,7 +32,6 @@
#include "soc.h"
#define OMAP1_DMA_BASE (0xfffed800)
-#define OMAP1_LOGICAL_DMA_CH_COUNT 17
static u32 enable_1510_mode;
@@ -348,8 +347,6 @@ static int __init omap1_system_dma_init(
goto exit_iounmap;
}
- d->lch_count = OMAP1_LOGICAL_DMA_CH_COUNT;
-
/* Valid attributes for omap1 plus processors */
if (cpu_is_omap15xx())
d->dev_caps = ENABLE_1510_MODE;
@@ -366,13 +363,14 @@ static int __init omap1_system_dma_init(
d->dev_caps |= CLEAR_CSR_ON_READ;
d->dev_caps |= IS_WORD_16;
- if (cpu_is_omap15xx())
- d->chan_count = 9;
- else if (cpu_is_omap16xx() || cpu_is_omap7xx()) {
- if (!(d->dev_caps & ENABLE_1510_MODE))
- d->chan_count = 16;
+ /* available logical channels */
+ if (cpu_is_omap15xx()) {
+ d->lch_count = 9;
+ } else {
+ if (d->dev_caps & ENABLE_1510_MODE)
+ d->lch_count = 9;
else
- d->chan_count = 9;
+ d->lch_count = 16;
}
p = dma_plat_info;
Patches currently in stable-queue which might be from peter.ujfalusi(a)ti.com are
queue-4.9/arm-omap1-dma-correct-the-number-of-logical-channels.patch
This is a note to let you know that I've just added the patch titled
be2net: fix accesses to unicast list
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
be2net-fix-accesses-to-unicast-list.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Ivan Vecera <cera(a)cera.cz>
Date: Fri, 6 Jan 2017 20:30:02 +0100
Subject: be2net: fix accesses to unicast list
From: Ivan Vecera <cera(a)cera.cz>
[ Upstream commit 1d0f110a2c6c4bca3dbcc4b0e27f1e3dc2d44a2c ]
Commit 988d44b "be2net: Avoid redundant addition of mac address in HW"
introduced be_dev_mac_add & be_uc_mac_add helpers that incorrectly
access adapter->uc_list as an array of bytes instead of an array of
be_eth_addr. Consequently NIC is not filled with valid data so unicast
filtering is broken.
Cc: Sathya Perla <sathya.perla(a)broadcom.com>
Cc: Ajit Khaparde <ajit.khaparde(a)broadcom.com>
Cc: Sriharsha Basavapatna <sriharsha.basavapatna(a)broadcom.com>
Cc: Somnath Kotur <somnath.kotur(a)broadcom.com>
Fixes: 988d44b be2net: Avoid redundant addition of mac address in HW
Signed-off-by: Ivan Vecera <cera(a)cera.cz>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/emulex/benet/be_main.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -275,8 +275,7 @@ static int be_dev_mac_add(struct be_adap
/* Check if mac has already been added as part of uc-list */
for (i = 0; i < adapter->uc_macs; i++) {
- if (ether_addr_equal((u8 *)&adapter->uc_list[i * ETH_ALEN],
- mac)) {
+ if (ether_addr_equal(adapter->uc_list[i].mac, mac)) {
/* mac already added, skip addition */
adapter->pmac_id[0] = adapter->pmac_id[i + 1];
return 0;
@@ -1679,14 +1678,12 @@ static void be_clear_mc_list(struct be_a
static int be_uc_mac_add(struct be_adapter *adapter, int uc_idx)
{
- if (ether_addr_equal((u8 *)&adapter->uc_list[uc_idx * ETH_ALEN],
- adapter->dev_mac)) {
+ if (ether_addr_equal(adapter->uc_list[uc_idx].mac, adapter->dev_mac)) {
adapter->pmac_id[uc_idx + 1] = adapter->pmac_id[0];
return 0;
}
- return be_cmd_pmac_add(adapter,
- (u8 *)&adapter->uc_list[uc_idx * ETH_ALEN],
+ return be_cmd_pmac_add(adapter, adapter->uc_list[uc_idx].mac,
adapter->if_handle,
&adapter->pmac_id[uc_idx + 1], 0);
}
Patches currently in stable-queue which might be from cera(a)cera.cz are
queue-4.9/be2net-fix-accesses-to-unicast-list.patch
queue-4.9/be2net-fix-initial-mac-setting.patch
queue-4.9/be2net-fix-unicast-list-filling.patch
On Tue, Dec 05, 2017 at 04:10:59PM +0800, Qu Wenruo wrote:
>
>
> On 2017年12月05日 15:29, Nikolay Borisov wrote:
> > This function was introduced by 247e743cbe6e ("Btrfs: Use async helpers to deal
> > with pages that have been improperly dirtied") and it didn't do any error
> > handling then. This function might very well fail in ENOMEM situation, yet
> > it's not handled, this could lead to inconsistent state. So let's handle the
> > failure by setting the mapping error bit.
> >
> > Signed-off-by: Nikolay Borisov <nborisov(a)suse.com>
> > Cc: stable(a)vger.kernel.org
>
> Reviewed-by: Qu Wenruo <wqu(a)suse.com>
>
> That's the only missing one. Nice catch.
You mean the only unhandled call of btrfs_set_extent_delalloc? There's
one more in relocate_file_extent_cluster.
This is a note to let you know that I've just added the patch titled
Revert "ocfs2: should wait dio before inode lock in ocfs2_setattr()"
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
revert-ocfs2-should-wait-dio-before-inode-lock-in-ocfs2_setattr.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 02b359b1331a9fd96f43028cee5500dfac4454b9 Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Date: Wed, 6 Dec 2017 17:33:18 +0100
Subject: Revert "ocfs2: should wait dio before inode lock in ocfs2_setattr()"
From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
This reverts commit c4baa4a5870cb02f713def1620052bfca7a82bbb which is
commit 28f5a8a7c033cbf3e32277f4cc9c6afd74f05300 upstream.
It shouldn't be applied to the 4.4-stable tree.
Ben and Alex write:
> Now that ocfs2_setattr() calls this outside of the inode locked region,
> what prevents another task adding a new dio request immediately
> afterward?
>
In the kernel 4.6, firstly, we use the inode_lock() in do_truncate() to
prevent another bio to be issued from this node.
Furthermore, we use the ocfs2_rw_lock() and ocfs2_inode_lock() in ocfs2_setattr()
to guarantee no more bio will be issued from the other nodes in this cluster.
> Also, ocfs2_dio_end_io_write() was introduced in 4.6 and it looks like
> the dio completion path didn't previously take the inode lock. So it
> doesn't look this fix is needed in 3.18 or 4.4.
Yes, ocfs2_dio_end_io_write() was introduced in 4.6 and the problem this patch
fixes is only exist in the kernel 4.6 and above 4.6.
Reported-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Cc: Alex Chen <alex.chen(a)huawei.com>
Cc: Jun Piao <piaojun(a)huawei.com>
Cc: Joseph Qi <jiangqi903(a)gmail.com>
Cc: Changwei Ge <ge.changwei(a)h3c.com>
Cc: Mark Fasheh <mfasheh(a)versity.com>
Cc: Joel Becker <jlbec(a)evilplan.org>
Cc: Junxiao Bi <junxiao.bi(a)oracle.com>
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/ocfs2/file.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
--- a/fs/ocfs2/file.c
+++ b/fs/ocfs2/file.c
@@ -1166,13 +1166,6 @@ int ocfs2_setattr(struct dentry *dentry,
}
size_change = S_ISREG(inode->i_mode) && attr->ia_valid & ATTR_SIZE;
if (size_change) {
- /*
- * Here we should wait dio to finish before inode lock
- * to avoid a deadlock between ocfs2_setattr() and
- * ocfs2_dio_end_io_write()
- */
- inode_dio_wait(inode);
-
status = ocfs2_rw_lock(inode, 1);
if (status < 0) {
mlog_errno(status);
@@ -1193,6 +1186,8 @@ int ocfs2_setattr(struct dentry *dentry,
if (status)
goto bail_unlock;
+ inode_dio_wait(inode);
+
if (i_size_read(inode) >= attr->ia_size) {
if (ocfs2_should_order_data(inode)) {
status = ocfs2_begin_ordered_truncate(inode,
Patches currently in stable-queue which might be from gregkh(a)linuxfoundation.org are
queue-4.4/xen-netfront-improve-error-handling-during-initialization.patch
queue-4.4/net-systemport-pad-packet-before-inserting-tsb.patch
queue-4.4/kvm-arm-arm64-fix-occasional-warning-from-the-timer-work-function.patch
queue-4.4/s390-pci-do-not-require-ais-facility.patch
queue-4.4/ima-fix-hash-algorithm-initialization.patch
queue-4.4/usb-phy-tahvo-fix-error-handling-in-tahvo_usb_probe.patch
queue-4.4/spi-sh-msiof-fix-dma-transfer-size-check.patch
queue-4.4/usb-dwc2-error-out-of-dwc2_hsotg_ep_disable-if-we-re-in-host-mode.patch
queue-4.4/net-appletalk-fix-kernel-memory-disclosure.patch
queue-4.4/selftests-x86-ldt_get-add-a-few-additional-tests-for-limits.patch
queue-4.4/nfsv4-fix-client-recovery-when-server-reboots-multiple-times.patch
queue-4.4/tipc-fix-cleanup-at-module-unload.patch
queue-4.4/bcache-only-permit-to-recovery-read-error-when-cache-device-is-clean.patch
queue-4.4/ravb-remove-rx-overflow-log-messages.patch
queue-4.4/usb-quirks-add-no-lpm-quirk-for-ky-688-usb-3.1-type-c-hub.patch
queue-4.4/nfs-don-t-take-a-reference-on-fl-fl_file-for-lock-operation.patch
queue-4.4/serial-8250-preserve-dld-for-port_xr17v35x.patch
queue-4.4/arm-omap1-dma-correct-the-number-of-logical-channels.patch
queue-4.4/usb-dwc2-fix-udc-state-tracking.patch
queue-4.4/mm-avoid-returning-vm_fault_retry-from-page_mkwrite-handlers.patch
queue-4.4/dmaengine-pl330-fix-double-lock.patch
queue-4.4/revert-ocfs2-should-wait-dio-before-inode-lock-in-ocfs2_setattr.patch
queue-4.4/bcache-recover-data-from-backing-when-data-is-clean.patch
queue-4.4/perf-test-attr-fix-ignored-test-case-result.patch
queue-4.4/s390-runtime-instrumentation-simplify-task-exit-handling.patch
queue-4.4/serial-8250_fintek-fix-rs485-disablement-on-invalid-ioctl.patch
queue-4.4/net-systemport-utilize-skb_put_padto.patch
queue-4.4/usbip-tools-install-all-headers-needed-for-libusbip-development.patch
queue-4.4/serial-8250_pci-add-amazon-pci-serial-device-id.patch
queue-4.4/sysrq-fix-show-regs-call-trace-on-arm.patch
queue-4.4/tcp-correct-memory-barrier-usage-in-tcp_check_space.patch
queue-4.4/net-fec-fix-multicast-filtering-hardware-setup.patch
queue-4.4/x86-entry-use-syscall_define-macros-for-sys_modify_ldt.patch
queue-4.4/uas-always-apply-us_fl_no_ata_1x-quirk-to-seagate-devices.patch
queue-4.4/vti6-fix-device-register-to-report-ifla_info_kind.patch
queue-4.4/kprobes-x86-disable-preemption-in-ftrace-based-jprobes.patch
queue-4.4/usb-serial-option-add-quectel-bg96-id.patch
queue-4.4/drm-exynos-decon5433-set-standalone_update_f-on-output-enablement.patch
queue-4.4/edac-sb_edac-fix-missing-break-in-switch.patch
queue-4.4/net-sctp-fix-array-overrun-read-on-sctp_timer_tbl.patch
This is a note to let you know that I've just added the patch titled
xen-netfront: Improve error handling during initialization
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
xen-netfront-improve-error-handling-during-initialization.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 16:43:17 CET 2017
From: Ross Lagerwall <ross.lagerwall(a)citrix.com>
Date: Wed, 8 Feb 2017 10:57:37 +0000
Subject: xen-netfront: Improve error handling during initialization
From: Ross Lagerwall <ross.lagerwall(a)citrix.com>
[ Upstream commit e2e004acc7cbe3c531e752a270a74e95cde3ea48 ]
This fixes a crash when running out of grant refs when creating many
queues across many netdevs.
* If creating queues fails (i.e. there are no grant refs available),
call xenbus_dev_fatal() to ensure that the xenbus device is set to the
closed state.
* If no queues are created, don't call xennet_disconnect_backend as
netdev->real_num_tx_queues will not have been set correctly.
* If setup_netfront() fails, ensure that all the queues created are
cleaned up, not just those that have been set up.
* If any queues were set up and an error occurs, call
xennet_destroy_queues() to clean up the napi context.
* If any fatal error occurs, unregister and destroy the netdev to avoid
leaving around a half setup network device.
Signed-off-by: Ross Lagerwall <ross.lagerwall(a)citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/xen-netfront.c | 29 +++++++++++------------------
1 file changed, 11 insertions(+), 18 deletions(-)
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1840,27 +1840,19 @@ static int talk_to_netback(struct xenbus
xennet_destroy_queues(info);
err = xennet_create_queues(info, &num_queues);
- if (err < 0)
- goto destroy_ring;
+ if (err < 0) {
+ xenbus_dev_fatal(dev, err, "creating queues");
+ kfree(info->queues);
+ info->queues = NULL;
+ goto out;
+ }
/* Create shared ring, alloc event channel -- for each queue */
for (i = 0; i < num_queues; ++i) {
queue = &info->queues[i];
err = setup_netfront(dev, queue, feature_split_evtchn);
- if (err) {
- /* setup_netfront() will tidy up the current
- * queue on error, but we need to clean up
- * those already allocated.
- */
- if (i > 0) {
- rtnl_lock();
- netif_set_real_num_tx_queues(info->netdev, i);
- rtnl_unlock();
- goto destroy_ring;
- } else {
- goto out;
- }
- }
+ if (err)
+ goto destroy_ring;
}
again:
@@ -1950,9 +1942,10 @@ abort_transaction_no_dev_fatal:
xenbus_transaction_end(xbt, 1);
destroy_ring:
xennet_disconnect_backend(info);
- kfree(info->queues);
- info->queues = NULL;
+ xennet_destroy_queues(info);
out:
+ unregister_netdev(info->netdev);
+ xennet_free_netdev(info->netdev);
return err;
}
Patches currently in stable-queue which might be from ross.lagerwall(a)citrix.com are
queue-4.4/xen-netfront-improve-error-handling-during-initialization.patch
This is a note to let you know that I've just added the patch titled
x86/entry: Use SYSCALL_DEFINE() macros for sys_modify_ldt()
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-entry-use-syscall_define-macros-for-sys_modify_ldt.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 16:43:17 CET 2017
From: Dave Hansen <dave.hansen(a)linux.intel.com>
Date: Wed, 18 Oct 2017 10:21:07 -0700
Subject: x86/entry: Use SYSCALL_DEFINE() macros for sys_modify_ldt()
From: Dave Hansen <dave.hansen(a)linux.intel.com>
[ Upstream commit da20ab35180780e4a6eadc804544f1fa967f3567 ]
We do not have tracepoints for sys_modify_ldt() because we define
it directly instead of using the normal SYSCALL_DEFINEx() macros.
However, there is a reason sys_modify_ldt() does not use the macros:
it has an 'int' return type instead of 'unsigned long'. This is
a bug, but it's a bug cemented in the ABI.
What does this mean? If we return -EINVAL from a function that
returns 'int', we have 0x00000000ffffffea in %rax. But, if we
return -EINVAL from a function returning 'unsigned long', we end
up with 0xffffffffffffffea in %rax, which is wrong.
To work around this and maintain the 'int' behavior while using
the SYSCALL_DEFINEx() macros, so we add a cast to 'unsigned int'
in both implementations of sys_modify_ldt().
Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com>
Reviewed-by: Andy Lutomirski <luto(a)kernel.org>
Reviewed-by: Brian Gerst <brgerst(a)gmail.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Link: http://lkml.kernel.org/r/20171018172107.1A79C532@viggo.jf.intel.com
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/include/asm/syscalls.h | 2 +-
arch/x86/kernel/ldt.c | 16 +++++++++++++---
arch/x86/um/ldt.c | 7 +++++--
3 files changed, 19 insertions(+), 6 deletions(-)
--- a/arch/x86/include/asm/syscalls.h
+++ b/arch/x86/include/asm/syscalls.h
@@ -21,7 +21,7 @@ asmlinkage long sys_ioperm(unsigned long
asmlinkage long sys_iopl(unsigned int);
/* kernel/ldt.c */
-asmlinkage int sys_modify_ldt(int, void __user *, unsigned long);
+asmlinkage long sys_modify_ldt(int, void __user *, unsigned long);
/* kernel/signal.c */
asmlinkage long sys_rt_sigreturn(void);
--- a/arch/x86/kernel/ldt.c
+++ b/arch/x86/kernel/ldt.c
@@ -12,6 +12,7 @@
#include <linux/string.h>
#include <linux/mm.h>
#include <linux/smp.h>
+#include <linux/syscalls.h>
#include <linux/slab.h>
#include <linux/vmalloc.h>
#include <linux/uaccess.h>
@@ -271,8 +272,8 @@ out:
return error;
}
-asmlinkage int sys_modify_ldt(int func, void __user *ptr,
- unsigned long bytecount)
+SYSCALL_DEFINE3(modify_ldt, int , func , void __user * , ptr ,
+ unsigned long , bytecount)
{
int ret = -ENOSYS;
@@ -290,5 +291,14 @@ asmlinkage int sys_modify_ldt(int func,
ret = write_ldt(ptr, bytecount, 0);
break;
}
- return ret;
+ /*
+ * The SYSCALL_DEFINE() macros give us an 'unsigned long'
+ * return type, but tht ABI for sys_modify_ldt() expects
+ * 'int'. This cast gives us an int-sized value in %rax
+ * for the return code. The 'unsigned' is necessary so
+ * the compiler does not try to sign-extend the negative
+ * return codes into the high half of the register when
+ * taking the value from int->long.
+ */
+ return (unsigned int)ret;
}
--- a/arch/x86/um/ldt.c
+++ b/arch/x86/um/ldt.c
@@ -6,6 +6,7 @@
#include <linux/mm.h>
#include <linux/sched.h>
#include <linux/slab.h>
+#include <linux/syscalls.h>
#include <linux/uaccess.h>
#include <asm/unistd.h>
#include <os.h>
@@ -369,7 +370,9 @@ void free_ldt(struct mm_context *mm)
mm->arch.ldt.entry_count = 0;
}
-int sys_modify_ldt(int func, void __user *ptr, unsigned long bytecount)
+SYSCALL_DEFINE3(modify_ldt, int , func , void __user * , ptr ,
+ unsigned long , bytecount)
{
- return do_modify_ldt_skas(func, ptr, bytecount);
+ /* See non-um modify_ldt() for why we do this cast */
+ return (unsigned int)do_modify_ldt_skas(func, ptr, bytecount);
}
Patches currently in stable-queue which might be from dave.hansen(a)linux.intel.com are
queue-4.4/x86-entry-use-syscall_define-macros-for-sys_modify_ldt.patch
This is a note to let you know that I've just added the patch titled
vti6: fix device register to report IFLA_INFO_KIND
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
vti6-fix-device-register-to-report-ifla_info_kind.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 16:43:17 CET 2017
From: David Forster <dforster(a)brocade.com>
Date: Fri, 6 Jan 2017 10:27:59 +0000
Subject: vti6: fix device register to report IFLA_INFO_KIND
From: David Forster <dforster(a)brocade.com>
[ Upstream commit 93e246f783e6bd1bc64fdfbfe68b18161f69b28e ]
vti6 interface is registered before the rtnl_link_ops block
is attached. As a result the resulting RTM_NEWLINK is missing
IFLA_INFO_KIND. Re-order attachment of rtnl_link_ops block to fix.
Signed-off-by: Dave Forster <dforster(a)brocade.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv6/ip6_vti.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/ipv6/ip6_vti.c
+++ b/net/ipv6/ip6_vti.c
@@ -189,12 +189,12 @@ static int vti6_tnl_create2(struct net_d
struct vti6_net *ip6n = net_generic(net, vti6_net_id);
int err;
+ dev->rtnl_link_ops = &vti6_link_ops;
err = register_netdevice(dev);
if (err < 0)
goto out;
strcpy(t->parms.name, dev->name);
- dev->rtnl_link_ops = &vti6_link_ops;
dev_hold(dev);
vti6_tnl_link(ip6n, t);
Patches currently in stable-queue which might be from dforster(a)brocade.com are
queue-4.4/vti6-fix-device-register-to-report-ifla_info_kind.patch
This is a note to let you know that I've just added the patch titled
USB: serial: option: add Quectel BG96 id
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-serial-option-add-quectel-bg96-id.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From c654b21ede93845863597de9ad774fd30db5f2ab Mon Sep 17 00:00:00 2001
From: Sebastian Sjoholm <ssjoholm(a)mac.com>
Date: Mon, 20 Nov 2017 19:29:32 +0100
Subject: USB: serial: option: add Quectel BG96 id
From: Sebastian Sjoholm <ssjoholm(a)mac.com>
commit c654b21ede93845863597de9ad774fd30db5f2ab upstream.
Quectel BG96 is an Qualcomm MDM9206 based IoT modem, supporting both
CAT-M and NB-IoT. Tested hardware is BG96 mounted on Quectel
development board (EVB). The USB id is added to option.c to allow
DIAG,GPS,AT and modem communication with the BG96.
Signed-off-by: Sebastian Sjoholm <ssjoholm(a)mac.com>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/serial/option.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -241,6 +241,7 @@ static void option_instat_callback(struc
/* These Quectel products use Quectel's vendor ID */
#define QUECTEL_PRODUCT_EC21 0x0121
#define QUECTEL_PRODUCT_EC25 0x0125
+#define QUECTEL_PRODUCT_BG96 0x0296
#define CMOTECH_VENDOR_ID 0x16d8
#define CMOTECH_PRODUCT_6001 0x6001
@@ -1185,6 +1186,8 @@ static const struct usb_device_id option
.driver_info = (kernel_ulong_t)&net_intf4_blacklist },
{ USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EC25),
.driver_info = (kernel_ulong_t)&net_intf4_blacklist },
+ { USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_BG96),
+ .driver_info = (kernel_ulong_t)&net_intf4_blacklist },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6001) },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CMU_300) },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6003),
Patches currently in stable-queue which might be from ssjoholm(a)mac.com are
queue-4.4/usb-serial-option-add-quectel-bg96-id.patch
This is a note to let you know that I've just added the patch titled
usbip: tools: Install all headers needed for libusbip development
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usbip-tools-install-all-headers-needed-for-libusbip-development.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 16:43:17 CET 2017
From: Ben Hutchings <ben(a)decadent.org.uk>
Date: Sun, 1 Oct 2017 02:18:37 +0100
Subject: usbip: tools: Install all headers needed for libusbip development
From: Ben Hutchings <ben(a)decadent.org.uk>
[ Upstream commit c15562c0dcb2c7f26e891923b784cf1926b8c833 ]
usbip_host_driver.h now depends on several additional headers, which
need to be installed along with it.
Fixes: 021aed845303 ("staging: usbip: userspace: migrate usbip_host_driver ...")
Fixes: 3391ba0e2792 ("usbip: tools: Extract generic code to be shared with ...")
Signed-off-by: Ben Hutchings <ben(a)decadent.org.uk>
Acked-by: Shuah Khan <shuahkh(a)osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/usb/usbip/Makefile.am | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/tools/usb/usbip/Makefile.am
+++ b/tools/usb/usbip/Makefile.am
@@ -1,6 +1,7 @@
SUBDIRS := libsrc src
includedir = @includedir@/usbip
include_HEADERS := $(addprefix libsrc/, \
- usbip_common.h vhci_driver.h usbip_host_driver.h)
+ usbip_common.h vhci_driver.h usbip_host_driver.h \
+ list.h sysfs_utils.h usbip_host_common.h)
dist_man_MANS := $(addprefix doc/, usbip.8 usbipd.8)
Patches currently in stable-queue which might be from ben(a)decadent.org.uk are
queue-4.4/usbip-tools-install-all-headers-needed-for-libusbip-development.patch
This is a note to let you know that I've just added the patch titled
usb: phy: tahvo: fix error handling in tahvo_usb_probe()
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-phy-tahvo-fix-error-handling-in-tahvo_usb_probe.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 16:43:17 CET 2017
From: Alexey Khoroshilov <khoroshilov(a)ispras.ru>
Date: Sat, 21 Oct 2017 01:02:07 +0300
Subject: usb: phy: tahvo: fix error handling in tahvo_usb_probe()
From: Alexey Khoroshilov <khoroshilov(a)ispras.ru>
[ Upstream commit ce035409bfa892a2fabb89720b542e1b335c3426 ]
If devm_extcon_dev_allocate() fails, we should disable clk before return.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov(a)ispras.ru>
Fixes: 860d2686fda7 ("usb: phy: tahvo: Use devm_extcon_dev_[allocate|register]() and replace deprecated API")
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/phy/phy-tahvo.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/usb/phy/phy-tahvo.c
+++ b/drivers/usb/phy/phy-tahvo.c
@@ -368,7 +368,8 @@ static int tahvo_usb_probe(struct platfo
tu->extcon = devm_extcon_dev_allocate(&pdev->dev, tahvo_cable);
if (IS_ERR(tu->extcon)) {
dev_err(&pdev->dev, "failed to allocate memory for extcon\n");
- return -ENOMEM;
+ ret = PTR_ERR(tu->extcon);
+ goto err_disable_clk;
}
ret = devm_extcon_dev_register(&pdev->dev, tu->extcon);
Patches currently in stable-queue which might be from khoroshilov(a)ispras.ru are
queue-4.4/usb-phy-tahvo-fix-error-handling-in-tahvo_usb_probe.patch