This is a note to let you know that I've just added the patch titled
btrfs: Fix flush bio leak
to the 4.14-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:
btrfs-fix-flush-bio-leak.patch
and it can be found in the queue-4.14 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 Feb 28 16:23:28 CET 2018
From: Nikolay Borisov <nborisov(a)suse.com>
Date: Wed, 13 Dec 2017 13:50:07 +0200
Subject: btrfs: Fix flush bio leak
From: Nikolay Borisov <nborisov(a)suse.com>
[ Upstream commit beed9263f4000c48a5c48912f26576f6fa091181 ]
Commit e0ae99941423 ("btrfs: preallocate device flush bio") reworked
the way the flush bio is allocated and used. Concretely it allocates
the bio in __alloc_device and then re-uses it multiple times with a
very simple endio routine that just calls complete() without consuming
a reference. Allocated bios by default come with a ref count of 1,
which is then consumed by the endio routine (or not, in which case they
should be bio_put by the caller). The way the impleementation works now
is that the flush bio has a refcount of 2 and we only ever bio_put it
once, leaving it to hang indefinitely. Fix this by removing the extra
bio_get in __alloc_device.
Fixes: e0ae99941423 ("btrfs: preallocate device flush bio")
Signed-off-by: Nikolay Borisov <nborisov(a)suse.com>
Reviewed-by: Liu Bo <bo.li.liu(a)oracle.com>
Reviewed-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/volumes.c | 1 -
1 file changed, 1 deletion(-)
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -236,7 +236,6 @@ static struct btrfs_device *__alloc_devi
kfree(dev);
return ERR_PTR(-ENOMEM);
}
- bio_get(dev->flush_bio);
INIT_LIST_HEAD(&dev->dev_list);
INIT_LIST_HEAD(&dev->dev_alloc_list);
Patches currently in stable-queue which might be from nborisov(a)suse.com are
queue-4.14/btrfs-fix-flush-bio-leak.patch
This is a note to let you know that I've just added the patch titled
bpf: sockmap missing NULL psock check
to the 4.14-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:
bpf-sockmap-missing-null-psock-check.patch
and it can be found in the queue-4.14 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 Feb 28 16:23:28 CET 2018
From: John Fastabend <john.fastabend(a)gmail.com>
Date: Thu, 4 Jan 2018 20:02:09 -0800
Subject: bpf: sockmap missing NULL psock check
From: John Fastabend <john.fastabend(a)gmail.com>
[ Upstream commit 5731a879d03bdaa00265f8ebc32dfd0e65d25276 ]
Add psock NULL check to handle a racing sock event that can get the
sk_callback_lock before this case but after xchg happens causing the
refcnt to hit zero and sock user data (psock) to be null and queued
for garbage collection.
Also add a comment in the code because this is a bit subtle and
not obvious in my opinion.
Signed-off-by: John Fastabend <john.fastabend(a)gmail.com>
Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/bpf/sockmap.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
--- a/kernel/bpf/sockmap.c
+++ b/kernel/bpf/sockmap.c
@@ -588,8 +588,15 @@ static void sock_map_free(struct bpf_map
write_lock_bh(&sock->sk_callback_lock);
psock = smap_psock_sk(sock);
- smap_list_remove(psock, &stab->sock_map[i]);
- smap_release_sock(psock, sock);
+ /* This check handles a racing sock event that can get the
+ * sk_callback_lock before this case but after xchg happens
+ * causing the refcnt to hit zero and sock user data (psock)
+ * to be null and queued for garbage collection.
+ */
+ if (likely(psock)) {
+ smap_list_remove(psock, &stab->sock_map[i]);
+ smap_release_sock(psock, sock);
+ }
write_unlock_bh(&sock->sk_callback_lock);
}
rcu_read_unlock();
Patches currently in stable-queue which might be from john.fastabend(a)gmail.com are
queue-4.14/bpf-sockmap-missing-null-psock-check.patch
This is a note to let you know that I've just added the patch titled
bnxt_en: Fix the 'Invalid VF' id check in bnxt_vf_ndo_prep routine.
to the 4.14-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:
bnxt_en-fix-the-invalid-vf-id-check-in-bnxt_vf_ndo_prep-routine.patch
and it can be found in the queue-4.14 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 Feb 28 16:23:28 CET 2018
From: Venkat Duvvuru <venkatkumar.duvvuru(a)broadcom.com>
Date: Thu, 4 Jan 2018 18:46:55 -0500
Subject: bnxt_en: Fix the 'Invalid VF' id check in bnxt_vf_ndo_prep routine.
From: Venkat Duvvuru <venkatkumar.duvvuru(a)broadcom.com>
[ Upstream commit 78f300049335ae81a5cc6b4b232481dc5e1f9d41 ]
In bnxt_vf_ndo_prep (which is called by bnxt_get_vf_config ndo), there is a
check for "Invalid VF id". Currently, the check is done against max_vfs.
However, the user doesn't always create max_vfs. So, the check should be
against the created number of VFs. The number of bnxt_vf_info structures
that are allocated in bnxt_alloc_vf_resources routine is the "number of
requested VFs". So, if an "invalid VF id" falls between the requested
number of VFs and the max_vfs, the driver will be dereferencing an invalid
pointer.
Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.")
Signed-off-by: Venkat Devvuru <venkatkumar.duvvuru(a)broadcom.com>
Signed-off-by: Michael Chan <michael.chan(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/broadcom/bnxt/bnxt_sriov.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
@@ -70,7 +70,7 @@ static int bnxt_vf_ndo_prep(struct bnxt
netdev_err(bp->dev, "vf ndo called though sriov is disabled\n");
return -EINVAL;
}
- if (vf_id >= bp->pf.max_vfs) {
+ if (vf_id >= bp->pf.active_vfs) {
netdev_err(bp->dev, "Invalid VF id %d\n", vf_id);
return -EINVAL;
}
Patches currently in stable-queue which might be from venkatkumar.duvvuru(a)broadcom.com are
queue-4.14/bnxt_en-fix-population-of-flow_type-in-bnxt_hwrm_cfa_flow_alloc.patch
queue-4.14/bnxt_en-fix-the-invalid-vf-id-check-in-bnxt_vf_ndo_prep-routine.patch
This is a note to let you know that I've just added the patch titled
bnxt_en: Fix population of flow_type in bnxt_hwrm_cfa_flow_alloc()
to the 4.14-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:
bnxt_en-fix-population-of-flow_type-in-bnxt_hwrm_cfa_flow_alloc.patch
and it can be found in the queue-4.14 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 Feb 28 16:23:28 CET 2018
From: Sunil Challa <sunilkumar.challa(a)broadcom.com>
Date: Thu, 4 Jan 2018 18:46:54 -0500
Subject: bnxt_en: Fix population of flow_type in bnxt_hwrm_cfa_flow_alloc()
From: Sunil Challa <sunilkumar.challa(a)broadcom.com>
[ Upstream commit 7deea450eb912f269d999de62c8ab922d1461748 ]
flow_type in HWRM_FLOW_ALLOC is not being populated correctly due to
incorrect passing of pointer and size of l3_mask argument of is_wildcard().
Fixed this.
Fixes: db1d36a27324 ("bnxt_en: add TC flower offload flow_alloc/free FW cmds")
Signed-off-by: Sunil Challa <sunilkumar.challa(a)broadcom.com>
Reviewed-by: Sathya Perla <sathya.perla(a)broadcom.com>
Reviewed-by: Venkat Duvvuru <venkatkumar.duvvuru(a)broadcom.com>
Signed-off-by: Michael Chan <michael.chan(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/broadcom/bnxt/bnxt_tc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c
@@ -327,7 +327,7 @@ static int bnxt_hwrm_cfa_flow_alloc(stru
}
/* If all IP and L4 fields are wildcarded then this is an L2 flow */
- if (is_wildcard(&l3_mask, sizeof(l3_mask)) &&
+ if (is_wildcard(l3_mask, sizeof(*l3_mask)) &&
is_wildcard(&flow->l4_mask, sizeof(flow->l4_mask))) {
flow_flags |= CFA_FLOW_ALLOC_REQ_FLAGS_FLOWTYPE_L2;
} else {
Patches currently in stable-queue which might be from sunilkumar.challa(a)broadcom.com are
queue-4.14/bnxt_en-fix-population-of-flow_type-in-bnxt_hwrm_cfa_flow_alloc.patch
This is a note to let you know that I've just added the patch titled
bnx2x: Improve reliability in case of nested PCI errors
to the 4.14-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:
bnx2x-improve-reliability-in-case-of-nested-pci-errors.patch
and it can be found in the queue-4.14 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 Feb 28 16:23:28 CET 2018
From: "Guilherme G. Piccoli" <gpiccoli(a)linux.vnet.ibm.com>
Date: Fri, 22 Dec 2017 13:01:39 -0200
Subject: bnx2x: Improve reliability in case of nested PCI errors
From: "Guilherme G. Piccoli" <gpiccoli(a)linux.vnet.ibm.com>
[ Upstream commit f7084059a9cb9e56a186e1677b1dcffd76c2cd24 ]
While in recovery process of PCI error (called EEH on PowerPC arch),
another PCI transaction could be corrupted causing a situation of
nested PCI errors. Also, this scenario could be reproduced with
error injection mechanisms (for debug purposes).
We observe that in case of nested PCI errors, bnx2x might attempt to
initialize its shmem and cause a kernel crash due to bad addresses
read from MCP. Multiple different stack traces were observed depending
on the point the second PCI error happens.
This patch avoids the crashes by:
* failing PCI recovery in case of nested errors (since multiple
PCI errors in a row are not expected to lead to a functional
adapter anyway), and by,
* preventing access to adapter FW when MCP is failed (we mark it as
failed when shmem cannot get initialized properly).
Reported-by: Abdul Haleem <abdhalee(a)linux.vnet.ibm.com>
Signed-off-by: Guilherme G. Piccoli <gpiccoli(a)linux.vnet.ibm.com>
Acked-by: Shahed Shaikh <Shahed.Shaikh(a)cavium.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/broadcom/bnx2x/bnx2x_cmn.c | 4 ++--
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 14 +++++++++++++-
2 files changed, 15 insertions(+), 3 deletions(-)
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
@@ -3030,7 +3030,7 @@ int bnx2x_nic_unload(struct bnx2x *bp, i
del_timer_sync(&bp->timer);
- if (IS_PF(bp)) {
+ if (IS_PF(bp) && !BP_NOMCP(bp)) {
/* Set ALWAYS_ALIVE bit in shmem */
bp->fw_drv_pulse_wr_seq |= DRV_PULSE_ALWAYS_ALIVE;
bnx2x_drv_pulse(bp);
@@ -3116,7 +3116,7 @@ int bnx2x_nic_unload(struct bnx2x *bp, i
bp->cnic_loaded = false;
/* Clear driver version indication in shmem */
- if (IS_PF(bp))
+ if (IS_PF(bp) && !BP_NOMCP(bp))
bnx2x_update_mng_version(bp);
/* Check if there are pending parity attentions. If there are - set
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -9578,6 +9578,15 @@ static int bnx2x_init_shmem(struct bnx2x
do {
bp->common.shmem_base = REG_RD(bp, MISC_REG_SHARED_MEM_ADDR);
+
+ /* If we read all 0xFFs, means we are in PCI error state and
+ * should bail out to avoid crashes on adapter's FW reads.
+ */
+ if (bp->common.shmem_base == 0xFFFFFFFF) {
+ bp->flags |= NO_MCP_FLAG;
+ return -ENODEV;
+ }
+
if (bp->common.shmem_base) {
val = SHMEM_RD(bp, validity_map[BP_PORT(bp)]);
if (val & SHR_MEM_VALIDITY_MB)
@@ -14315,7 +14324,10 @@ static pci_ers_result_t bnx2x_io_slot_re
BNX2X_ERR("IO slot reset --> driver unload\n");
/* MCP should have been reset; Need to wait for validity */
- bnx2x_init_shmem(bp);
+ if (bnx2x_init_shmem(bp)) {
+ rtnl_unlock();
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
if (IS_PF(bp) && SHMEM2_HAS(bp, drv_capabilities_flag)) {
u32 v;
Patches currently in stable-queue which might be from gpiccoli(a)linux.vnet.ibm.com are
queue-4.14/bnx2x-improve-reliability-in-case-of-nested-pci-errors.patch
This is a note to let you know that I've just added the patch titled
block: drain queue before waiting for q_usage_counter becoming zero
to the 4.14-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:
block-drain-queue-before-waiting-for-q_usage_counter-becoming-zero.patch
and it can be found in the queue-4.14 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 Feb 28 16:23:28 CET 2018
From: Ming Lei <ming.lei(a)redhat.com>
Date: Thu, 30 Nov 2017 07:56:35 +0800
Subject: block: drain queue before waiting for q_usage_counter becoming zero
From: Ming Lei <ming.lei(a)redhat.com>
[ Upstream commit 454be724f6f99cc7e7bbf15067128be9868186c6 ]
Now we track legacy requests with .q_usage_counter in commit 055f6e18e08f
("block: Make q_usage_counter also track legacy requests"), but that
commit never runs and drains legacy queue before waiting for this counter
becoming zero, then IO hang is caused in the test of pulling disk during IO.
This patch fixes the issue by draining requests before waiting for
q_usage_counter becoming zero, both Mauricio and chenxiang reported this
issue, and observed that it can be fixed by this patch.
Link: https://marc.info/?l=linux-block&m=151192424731797&w=2
Fixes: 055f6e18e08f("block: Make q_usage_counter also track legacy requests")
Cc: Wen Xiong <wenxiong(a)us.ibm.com>
Tested-by: "chenxiang (M)" <chenxiang66(a)hisilicon.com>
Tested-by: Mauricio Faria de Oliveira <mauricfo(a)linux.vnet.ibm.com>
Signed-off-by: Ming Lei <ming.lei(a)redhat.com>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
block/blk-core.c | 9 +++++++--
block/blk-mq.c | 2 ++
block/blk.h | 2 ++
3 files changed, 11 insertions(+), 2 deletions(-)
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -531,6 +531,13 @@ static void __blk_drain_queue(struct req
}
}
+void blk_drain_queue(struct request_queue *q)
+{
+ spin_lock_irq(q->queue_lock);
+ __blk_drain_queue(q, true);
+ spin_unlock_irq(q->queue_lock);
+}
+
/**
* blk_queue_bypass_start - enter queue bypass mode
* @q: queue of interest
@@ -655,8 +662,6 @@ void blk_cleanup_queue(struct request_qu
*/
blk_freeze_queue(q);
spin_lock_irq(lock);
- if (!q->mq_ops)
- __blk_drain_queue(q, true);
queue_flag_set(QUEUE_FLAG_DEAD, q);
spin_unlock_irq(lock);
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -159,6 +159,8 @@ void blk_freeze_queue(struct request_que
* exported to drivers as the only user for unfreeze is blk_mq.
*/
blk_freeze_queue_start(q);
+ if (!q->mq_ops)
+ blk_drain_queue(q);
blk_mq_freeze_queue_wait(q);
}
--- a/block/blk.h
+++ b/block/blk.h
@@ -362,4 +362,6 @@ static inline void blk_queue_bounce(stru
}
#endif /* CONFIG_BOUNCE */
+extern void blk_drain_queue(struct request_queue *q);
+
#endif /* BLK_INTERNAL_H */
Patches currently in stable-queue which might be from ming.lei(a)redhat.com are
queue-4.14/block-drain-queue-before-waiting-for-q_usage_counter-becoming-zero.patch
This is a note to let you know that I've just added the patch titled
ASoC: nau8825: fix issue that pop noise when start capture
to the 4.14-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:
asoc-nau8825-fix-issue-that-pop-noise-when-start-capture.patch
and it can be found in the queue-4.14 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 Feb 28 16:23:28 CET 2018
From: Abhijeet Kumar <abhijeet.kumar(a)intel.com>
Date: Tue, 12 Dec 2017 00:40:25 +0530
Subject: ASoC: nau8825: fix issue that pop noise when start capture
From: Abhijeet Kumar <abhijeet.kumar(a)intel.com>
[ Upstream commit d070f7c703ef26e3db613f24206823f916272fc6 ]
In skylake platform, we hear a loud pop noise(0 dB) at start of
audio capture power up sequence. This patch removes the pop noise
from the recording by adding a delay before enabling ADC.
Signed-off-by: Abhijeet Kumar <abhijeet.kumar(a)intel.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/codecs/nau8825.c | 1 +
1 file changed, 1 insertion(+)
--- a/sound/soc/codecs/nau8825.c
+++ b/sound/soc/codecs/nau8825.c
@@ -905,6 +905,7 @@ static int nau8825_adc_event(struct snd_
switch (event) {
case SND_SOC_DAPM_POST_PMU:
+ msleep(125);
regmap_update_bits(nau8825->regmap, NAU8825_REG_ENA_CTRL,
NAU8825_ENABLE_ADC, NAU8825_ENABLE_ADC);
break;
Patches currently in stable-queue which might be from abhijeet.kumar(a)intel.com are
queue-4.14/asoc-nau8825-fix-issue-that-pop-noise-when-start-capture.patch
This is a note to let you know that I've just added the patch titled
ASoC: rsnd: fixup ADG register mask
to the 4.14-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:
asoc-rsnd-fixup-adg-register-mask.patch
and it can be found in the queue-4.14 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 Feb 28 16:23:28 CET 2018
From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com>
Date: Wed, 20 Dec 2017 06:11:59 +0000
Subject: ASoC: rsnd: fixup ADG register mask
From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com>
[ Upstream commit d5aa24825da5711f8cb829f873160ddf1a29b19c ]
BRGCKR should use 0x80770000, instead of 0x80FF0000.
R-Car Gen2 xxx_TIMSEL should use 0x0F1F,
R-Car Gen3 xxx_TIMSEL should use 0x1F1F.
Here, Gen3 doesn't support AVD, thus, both case can use 0x0F1F.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com>
Reviewed-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx(a)renesas.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/sh/rcar/adg.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/sound/soc/sh/rcar/adg.c
+++ b/sound/soc/sh/rcar/adg.c
@@ -216,7 +216,7 @@ int rsnd_adg_set_cmd_timsel_gen2(struct
NULL, &val, NULL);
val = val << shift;
- mask = 0xffff << shift;
+ mask = 0x0f1f << shift;
rsnd_mod_bset(adg_mod, CMDOUT_TIMSEL, mask, val);
@@ -244,7 +244,7 @@ int rsnd_adg_set_src_timesel_gen2(struct
in = in << shift;
out = out << shift;
- mask = 0xffff << shift;
+ mask = 0x0f1f << shift;
switch (id / 2) {
case 0:
@@ -374,7 +374,7 @@ int rsnd_adg_ssi_clk_try_start(struct rs
ckr = 0x80000000;
}
- rsnd_mod_bset(adg_mod, BRGCKR, 0x80FF0000, adg->ckr | ckr);
+ rsnd_mod_bset(adg_mod, BRGCKR, 0x80770000, adg->ckr | ckr);
rsnd_mod_write(adg_mod, BRRA, adg->rbga);
rsnd_mod_write(adg_mod, BRRB, adg->rbgb);
Patches currently in stable-queue which might be from kuninori.morimoto.gx(a)renesas.com are
queue-4.14/asoc-rsnd-fixup-adg-register-mask.patch
This is a note to let you know that I've just added the patch titled
arm64: dts: renesas: ulcb: Remove renesas, no-ether-link property
to the 4.14-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:
arm64-dts-renesas-ulcb-remove-renesas-no-ether-link-property.patch
and it can be found in the queue-4.14 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 Feb 28 16:23:28 CET 2018
From: Bogdan Mirea <Bogdan-Stefan_Mirea(a)mentor.com>
Date: Thu, 21 Dec 2017 17:18:59 +0200
Subject: arm64: dts: renesas: ulcb: Remove renesas, no-ether-link property
From: Bogdan Mirea <Bogdan-Stefan_Mirea(a)mentor.com>
[ Upstream commit 7d2901f809c110bd9a261e879d59efe62e3bc758 ]
The present change is a bug fix for AVB link iteratively up/down.
Steps to reproduce:
- start AVB TX stream (Using aplay via MSE),
- disconnect+reconnect the eth cable,
- after a reconnection the eth connection goes iteratively up/down
without user interaction,
- this may heal after some seconds or even stay for minutes.
As the documentation specifies, the "renesas,no-ether-link" option
should be used when a board does not provide a proper AVB_LINK signal.
There is no need for this option enabled on RCAR H3/M3 Salvator-X/XS
and ULCB starter kits since the AVB_LINK is correctly handled by HW.
Choosing to keep or remove the "renesas,no-ether-link" option will
have impact on the code flow in the following ways:
- keeping this option enabled may lead to unexpected behavior since
the RX & TX are enabled/disabled directly from adjust_link function
without any HW interrogation,
- removing this option, the RX & TX will only be enabled/disabled after
HW interrogation. The HW check is made through the LMON pin in PSR
register which specifies AVB_LINK signal value (0 - at low level;
1 - at high level).
In conclusion, the present change is also a safety improvement because
it removes the "renesas,no-ether-link" option leading to a proper way
of detecting the link state based on HW interrogation and not on
software heuristic.
Fixes: dc36965a8905 ("arm64: dts: r8a7796: salvator-x: Enable EthernetAVB")
Fixes: 6fa501c549aa ("arm64: dts: r8a7795: enable EthernetAVB on Salvator-X")
Signed-off-by: Bogdan Mirea <Bogdan-Stefan_Mirea(a)mentor.com>
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy(a)mentor.com>
Signed-off-by: Simon Horman <horms+renesas(a)verge.net.au>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/boot/dts/renesas/ulcb.dtsi | 1 -
1 file changed, 1 deletion(-)
--- a/arch/arm64/boot/dts/renesas/ulcb.dtsi
+++ b/arch/arm64/boot/dts/renesas/ulcb.dtsi
@@ -145,7 +145,6 @@
&avb {
pinctrl-0 = <&avb_pins>;
pinctrl-names = "default";
- renesas,no-ether-link;
phy-handle = <&phy0>;
status = "okay";
Patches currently in stable-queue which might be from Bogdan-Stefan_Mirea(a)mentor.com are
queue-4.14/arm64-dts-renesas-ulcb-remove-renesas-no-ether-link-property.patch