This is a note to let you know that I've just added the patch titled
GFS2: Take inode off order_write list when setting jdata flag
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:
gfs2-take-inode-off-order_write-list-when-setting-jdata-flag.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 Mon Dec 18 14:47:43 CET 2017
From: Bob Peterson <rpeterso(a)redhat.com>
Date: Wed, 20 Sep 2017 08:30:04 -0500
Subject: GFS2: Take inode off order_write list when setting jdata flag
From: Bob Peterson <rpeterso(a)redhat.com>
[ Upstream commit cc555b09d8c3817aeebda43a14ab67049a5653f7 ]
This patch fixes a deadlock caused when the jdata flag is set for
inodes that are already on the ordered write list. Since it is
on the ordered write list, log_flush calls gfs2_ordered_write which
calls filemap_fdatawrite. But since the inode had the jdata flag
set, that calls gfs2_jdata_writepages, which tries to start a new
transaction. A new transaction cannot be started because it tries
to acquire the log_flush rwsem which is already locked by the log
flush operation.
The bottom line is: We cannot switch an inode from ordered to jdata
until we eliminate any ordered data pages (via log flush) or any
log_flush operation afterward will create the circular dependency
above. So we need to flush the log before setting the diskflags to
switch the file mode, then we need to remove the inode from the
ordered writes list.
Before this patch, the log flush was done for jdata->ordered, but
that's wrong. If we're going from jdata to ordered, we don't need
to call gfs2_log_flush because the call to filemap_fdatawrite will
do it for us:
filemap_fdatawrite() -> __filemap_fdatawrite_range()
__filemap_fdatawrite_range() -> do_writepages()
do_writepages() -> gfs2_jdata_writepages()
gfs2_jdata_writepages() -> gfs2_log_flush()
This patch modifies function do_gfs2_set_flags so that if a file
has its jdata flag set, and it's already on the ordered write list,
the log will be flushed and it will be removed from the list
before setting the flag.
Signed-off-by: Bob Peterson <rpeterso(a)redhat.com>
Signed-off-by: Andreas Gruenbacher <agruenba(a)redhat.com>
Acked-by: Abhijith Das <adas(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/gfs2/file.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/fs/gfs2/file.c
+++ b/fs/gfs2/file.c
@@ -255,7 +255,7 @@ static int do_gfs2_set_flags(struct file
goto out;
}
if ((flags ^ new_flags) & GFS2_DIF_JDATA) {
- if (flags & GFS2_DIF_JDATA)
+ if (new_flags & GFS2_DIF_JDATA)
gfs2_log_flush(sdp, ip->i_gl, NORMAL_FLUSH);
error = filemap_fdatawrite(inode->i_mapping);
if (error)
@@ -263,6 +263,8 @@ static int do_gfs2_set_flags(struct file
error = filemap_fdatawait(inode->i_mapping);
if (error)
goto out;
+ if (new_flags & GFS2_DIF_JDATA)
+ gfs2_ordered_del_inode(ip);
}
error = gfs2_trans_begin(sdp, RES_DINODE, 0);
if (error)
Patches currently in stable-queue which might be from rpeterso(a)redhat.com are
queue-4.4/gfs2-take-inode-off-order_write-list-when-setting-jdata-flag.patch
This is a note to let you know that I've just added the patch titled
fjes: Fix wrong netdevice feature flags
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:
fjes-fix-wrong-netdevice-feature-flags.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 Mon Dec 18 14:47:43 CET 2017
From: Taku Izumi <izumi.taku(a)jp.fujitsu.com>
Date: Wed, 15 Mar 2017 13:47:50 +0900
Subject: fjes: Fix wrong netdevice feature flags
From: Taku Izumi <izumi.taku(a)jp.fujitsu.com>
[ Upstream commit fe8daf5fa715f7214952f06a387e4b7de818c5be ]
This patch fixes netdev->features for Extended Socket network device.
Currently Extended Socket network device's netdev->feature claims
NETIF_F_HW_CSUM, however this is completely wrong. There's no feature
of checksum offloading.
That causes invalid TCP/UDP checksum and packet rejection when IP
forwarding from Extended Socket network device to other network device.
NETIF_F_HW_CSUM should be omitted.
Signed-off-by: Taku Izumi <izumi.taku(a)jp.fujitsu.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/fjes/fjes_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/fjes/fjes_main.c
+++ b/drivers/net/fjes/fjes_main.c
@@ -1205,7 +1205,7 @@ static void fjes_netdev_setup(struct net
fjes_set_ethtool_ops(netdev);
netdev->mtu = fjes_support_mtu[0];
netdev->flags |= IFF_BROADCAST;
- netdev->features |= NETIF_F_HW_CSUM | NETIF_F_HW_VLAN_CTAG_FILTER;
+ netdev->features |= NETIF_F_HW_VLAN_CTAG_FILTER;
}
static void fjes_irq_watch_task(struct work_struct *work)
Patches currently in stable-queue which might be from izumi.taku(a)jp.fujitsu.com are
queue-4.4/fjes-fix-wrong-netdevice-feature-flags.patch
This is a note to let you know that I've just added the patch titled
fbdev: controlfb: Add missing modes to fix out of bounds access
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:
fbdev-controlfb-add-missing-modes-to-fix-out-of-bounds-access.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 Mon Dec 18 14:47:43 CET 2017
From: Geert Uytterhoeven <geert(a)linux-m68k.org>
Date: Thu, 9 Nov 2017 18:09:33 +0100
Subject: fbdev: controlfb: Add missing modes to fix out of bounds access
From: Geert Uytterhoeven <geert(a)linux-m68k.org>
[ Upstream commit ac831a379d34109451b3c41a44a20ee10ecb615f ]
Dan's static analysis says:
drivers/video/fbdev/controlfb.c:560 control_setup()
error: buffer overflow 'control_mac_modes' 20 <= 21
Indeed, control_mac_modes[] has only 20 elements, while VMODE_MAX is 22,
which may lead to an out of bounds read when parsing vmode commandline
options.
The bug was introduced in v2.4.5.6, when 2 new modes were added to
macmodes.h, but control_mac_modes[] wasn't updated:
https://kernel.opensuse.org/cgit/kernel/diff/include/video/macmodes.h?h=v2.…
Augment control_mac_modes[] with the two new video modes to fix this.
Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Signed-off-by: Geert Uytterhoeven <geert(a)linux-m68k.org>
Cc: Dan Carpenter <dan.carpenter(a)oracle.com>
Cc: Benjamin Herrenschmidt <benh(a)kernel.crashing.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/video/fbdev/controlfb.h | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/video/fbdev/controlfb.h
+++ b/drivers/video/fbdev/controlfb.h
@@ -141,5 +141,7 @@ static struct max_cmodes control_mac_mod
{{ 1, 2}}, /* 1152x870, 75Hz */
{{ 0, 1}}, /* 1280x960, 75Hz */
{{ 0, 1}}, /* 1280x1024, 75Hz */
+ {{ 1, 2}}, /* 1152x768, 60Hz */
+ {{ 0, 1}}, /* 1600x1024, 60Hz */
};
Patches currently in stable-queue which might be from geert(a)linux-m68k.org are
queue-4.4/fbdev-controlfb-add-missing-modes-to-fix-out-of-bounds-access.patch
This is a note to let you know that I've just added the patch titled
efi/esrt: Cleanup bad memory map log messages
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:
efi-esrt-cleanup-bad-memory-map-log-messages.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 Mon Dec 18 14:47:43 CET 2017
From: Daniel Drake <drake(a)endlessm.com>
Date: Tue, 7 Feb 2017 13:08:23 -0600
Subject: efi/esrt: Cleanup bad memory map log messages
From: Daniel Drake <drake(a)endlessm.com>
[ Upstream commit 822f5845f710e57d7e2df1fd1ee00d6e19d334fe ]
The Intel Compute Stick STCK1A8LFC and Weibu F3C platforms both
log 2 error messages during boot:
efi: requested map not found.
esrt: ESRT header is not in the memory map.
Searching the web, this seems to affect many other platforms too.
Since these messages are logged as errors, they appear on-screen during
the boot process even when using the "quiet" boot parameter used by
distros.
Demote the ESRT error to a warning so that it does not appear on-screen,
and delete the error logging from efi_mem_desc_lookup; both callsites
of that function log more specific messages upon failure.
Out of curiosity I looked closer at the Weibu F3C. There is no entry in
the UEFI-provided memory map which corresponds to the ESRT pointer, but
hacking the code to map it anyway, the ESRT does appear to be valid with
2 entries.
Signed-off-by: Daniel Drake <drake(a)endlessm.com>
Cc: Matt Fleming <matt(a)codeblueprint.co.uk>
Acked-by: Peter Jones <pjones(a)redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/firmware/efi/efi.c | 1 -
drivers/firmware/efi/esrt.c | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -310,7 +310,6 @@ int __init efi_mem_desc_lookup(u64 phys_
early_memunmap(md, sizeof (*md));
}
- pr_err_once("requested map not found.\n");
return -ENOENT;
}
--- a/drivers/firmware/efi/esrt.c
+++ b/drivers/firmware/efi/esrt.c
@@ -253,7 +253,7 @@ void __init efi_esrt_init(void)
rc = efi_mem_desc_lookup(efi.esrt, &md);
if (rc < 0) {
- pr_err("ESRT header is not in the memory map.\n");
+ pr_warn("ESRT header is not in the memory map.\n");
return;
}
Patches currently in stable-queue which might be from drake(a)endlessm.com are
queue-4.4/efi-esrt-cleanup-bad-memory-map-log-messages.patch
This is a note to let you know that I've just added the patch titled
drm/radeon/si: add dpm quirk for Oland
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:
drm-radeon-si-add-dpm-quirk-for-oland.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 Mon Dec 18 14:47:43 CET 2017
From: Alex Deucher <alexander.deucher(a)amd.com>
Date: Tue, 14 Mar 2017 14:42:03 -0400
Subject: drm/radeon/si: add dpm quirk for Oland
From: Alex Deucher <alexander.deucher(a)amd.com>
[ Upstream commit 0f424de1fd9bc4ab24bd1fe5430ab5618e803e31 ]
OLAND 0x1002:0x6604 0x1028:0x066F 0x00 seems to have problems
with higher sclks.
Acked-by: Christian König <christian.koenig(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/radeon/si_dpm.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -3029,6 +3029,12 @@ static void si_apply_state_adjust_rules(
max_sclk = 75000;
max_mclk = 80000;
}
+ } else if (rdev->family == CHIP_OLAND) {
+ if ((rdev->pdev->device == 0x6604) &&
+ (rdev->pdev->subsystem_vendor == 0x1028) &&
+ (rdev->pdev->subsystem_device == 0x066F)) {
+ max_sclk = 75000;
+ }
}
/* Apply dpm quirks */
while (p && p->chip_device != 0) {
Patches currently in stable-queue which might be from alexander.deucher(a)amd.com are
queue-4.4/drm-radeon-reinstate-oland-workaround-for-sclk.patch
queue-4.4/drm-radeon-si-add-dpm-quirk-for-oland.patch
This is a note to let you know that I've just added the patch titled
drm/radeon: reinstate oland workaround for sclk
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:
drm-radeon-reinstate-oland-workaround-for-sclk.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 Mon Dec 18 14:47:43 CET 2017
From: Alex Deucher <alexander.deucher(a)amd.com>
Date: Wed, 15 Mar 2017 21:11:46 -0400
Subject: drm/radeon: reinstate oland workaround for sclk
From: Alex Deucher <alexander.deucher(a)amd.com>
[ Upstream commit 66822d815ae61ecb2d9dba9031517e8a8476969d ]
Higher sclks seem to be unstable on some boards.
bug: https://bugs.freedesktop.org/show_bug.cgi?id=100222
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/radeon/si_dpm.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -3030,9 +3030,13 @@ static void si_apply_state_adjust_rules(
max_mclk = 80000;
}
} else if (rdev->family == CHIP_OLAND) {
- if ((rdev->pdev->device == 0x6604) &&
- (rdev->pdev->subsystem_vendor == 0x1028) &&
- (rdev->pdev->subsystem_device == 0x066F)) {
+ if ((rdev->pdev->revision == 0xC7) ||
+ (rdev->pdev->revision == 0x80) ||
+ (rdev->pdev->revision == 0x81) ||
+ (rdev->pdev->revision == 0x83) ||
+ (rdev->pdev->revision == 0x87) ||
+ (rdev->pdev->device == 0x6604) ||
+ (rdev->pdev->device == 0x6605)) {
max_sclk = 75000;
}
}
Patches currently in stable-queue which might be from alexander.deucher(a)amd.com are
queue-4.4/drm-radeon-reinstate-oland-workaround-for-sclk.patch
queue-4.4/drm-radeon-si-add-dpm-quirk-for-oland.patch
This is a note to let you know that I've just added the patch titled
drm/omap: fix dmabuf mmap for dma_alloc'ed buffers
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:
drm-omap-fix-dmabuf-mmap-for-dma_alloc-ed-buffers.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 Mon Dec 18 14:47:43 CET 2017
From: Tomi Valkeinen <tomi.valkeinen(a)ti.com>
Date: Tue, 28 Feb 2017 10:11:45 +0200
Subject: drm/omap: fix dmabuf mmap for dma_alloc'ed buffers
From: Tomi Valkeinen <tomi.valkeinen(a)ti.com>
[ Upstream commit 9fa1d7537242bd580ffa99c4725a0407096aad26 ]
omap_gem_dmabuf_mmap() returns an error (with a WARN) when called for a
buffer which is allocated with dma_alloc_*(). This prevents dmabuf mmap
from working on SoCs without DMM, e.g. AM4 and OMAP3.
I could not find any reason for omap_gem_dmabuf_mmap() rejecting such
buffers, and just removing the if() fixes the limitation.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen(a)ti.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 3 ---
1 file changed, 3 deletions(-)
--- a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
@@ -142,9 +142,6 @@ static int omap_gem_dmabuf_mmap(struct d
struct drm_gem_object *obj = buffer->priv;
int ret = 0;
- if (WARN_ON(!obj->filp))
- return -EINVAL;
-
ret = drm_gem_mmap_obj(obj, omap_gem_mmap_size(obj), vma);
if (ret < 0)
return ret;
Patches currently in stable-queue which might be from tomi.valkeinen(a)ti.com are
queue-4.4/drm-omap-fix-dmabuf-mmap-for-dma_alloc-ed-buffers.patch
This is a note to let you know that I've just added the patch titled
dmaengine: ti-dma-crossbar: Correct am335x/am43xx mux value type
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:
dmaengine-ti-dma-crossbar-correct-am335x-am43xx-mux-value-type.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 Mon Dec 18 14:47:43 CET 2017
From: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
Date: Wed, 8 Nov 2017 12:02:25 +0200
Subject: dmaengine: ti-dma-crossbar: Correct am335x/am43xx mux value type
From: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
[ Upstream commit 288e7560e4d3e259aa28f8f58a8dfe63627a1bf6 ]
The used 0x1f mask is only valid for am335x family of SoC, different family
using this type of crossbar might have different number of electable
events. In case of am43xx family 0x3f mask should have been used for
example.
Instead of trying to handle each family's mask, just use u8 type to store
the mux value since the event offsets are aligned to byte offset.
Fixes: 42dbdcc6bf965 ("dmaengine: ti-dma-crossbar: Add support for crossbar on AM33xx/AM43xx")
Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.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/ti-dma-crossbar.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -46,12 +46,12 @@ struct ti_am335x_xbar_data {
struct ti_am335x_xbar_map {
u16 dma_line;
- u16 mux_val;
+ u8 mux_val;
};
-static inline void ti_am335x_xbar_write(void __iomem *iomem, int event, u16 val)
+static inline void ti_am335x_xbar_write(void __iomem *iomem, int event, u8 val)
{
- writeb_relaxed(val & 0x1f, iomem + event);
+ writeb_relaxed(val, iomem + event);
}
static void ti_am335x_xbar_free(struct device *dev, void *route_data)
@@ -102,7 +102,7 @@ static void *ti_am335x_xbar_route_alloca
}
map->dma_line = (u16)dma_spec->args[0];
- map->mux_val = (u16)dma_spec->args[2];
+ map->mux_val = (u8)dma_spec->args[2];
dma_spec->args[2] = 0;
dma_spec->args_count = 2;
Patches currently in stable-queue which might be from peter.ujfalusi(a)ti.com are
queue-4.4/dmaengine-ti-dma-crossbar-correct-am335x-am43xx-mux-value-type.patch
This is a note to let you know that I've just added the patch titled
dmaengine: rcar-dmac: use TCRB instead of TCR for residue
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:
dmaengine-rcar-dmac-use-tcrb-instead-of-tcr-for-residue.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 Mon Dec 18 14:47:43 CET 2017
From: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx(a)renesas.com>
Date: Thu, 19 Oct 2017 01:15:13 +0000
Subject: dmaengine: rcar-dmac: use TCRB instead of TCR for residue
From: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx(a)renesas.com>
[ Upstream commit 847449f23dcbff68234525f90dd53c7c7db18cad ]
SYS/RT/Audio DMAC includes independent data buffers for reading
and writing. Therefore, the read transfer counter and write transfer
counter have different values.
TCR indicates read counter, and TCRB indicates write counter.
The relationship is like below.
TCR TCRB
[SOURCE] -> [DMAC] -> [SINK]
In the MEM_TO_DEV direction, what really matters is how much data has
been written to the device. If the DMA is interrupted between read and
write, then, the data doesn't end up in the destination, so shouldn't
be counted. TCRB is thus the register we should use in this cases.
In the DEV_TO_MEM direction, the situation is more complex. Both the
read and write side are important. What matters from a data consumer
point of view is how much data has been written to memory.
On the other hand, if the transfer is interrupted between read and
write, we'll end up losing data. It can also be important to report.
In the MEM_TO_MEM direction, what matters is of course how much data
has been written to memory from data consumer point of view.
Here, because read and write have independent data buffers, it will
take a while for TCR and TCRB to become equal. Thus we should check
TCRB in this case, too.
Thus, all cases we should check TCRB instead of TCR.
Without this patch, Sound Capture has noise after PluseAudio support
(= 07b7acb51d2 ("ASoC: rsnd: update pointer more accurate")), because
the recorder will use wrong residue counter which indicates transferred
from sound device, but in reality the data was not yet put to memory
and recorder will record it.
Signed-off-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx(a)renesas.com>
[Kuninori: added detail information in log]
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.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/sh/rcar-dmac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/dma/sh/rcar-dmac.c
+++ b/drivers/dma/sh/rcar-dmac.c
@@ -1180,7 +1180,7 @@ static unsigned int rcar_dmac_chan_get_r
}
/* Add the residue for the current chunk. */
- residue += rcar_dmac_chan_read(chan, RCAR_DMATCR) << desc->xfer_shift;
+ residue += rcar_dmac_chan_read(chan, RCAR_DMATCRB) << desc->xfer_shift;
return residue;
}
Patches currently in stable-queue which might be from hiroyuki.yokoyama.vx(a)renesas.com are
queue-4.4/dmaengine-rcar-dmac-use-tcrb-instead-of-tcr-for-residue.patch
This is a note to let you know that I've just added the patch titled
dmaengine: Fix array index out of bounds warning in __get_unmap_pool()
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:
dmaengine-fix-array-index-out-of-bounds-warning-in-__get_unmap_pool.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 Mon Dec 18 14:47:43 CET 2017
From: Matthias Kaehlcke <mka(a)chromium.org>
Date: Mon, 13 Mar 2017 14:30:29 -0700
Subject: dmaengine: Fix array index out of bounds warning in __get_unmap_pool()
From: Matthias Kaehlcke <mka(a)chromium.org>
[ Upstream commit 23f963e91fd81f44f6b316b1c24db563354c6be8 ]
This fixes the following warning when building with clang and
CONFIG_DMA_ENGINE_RAID=n :
drivers/dma/dmaengine.c:1102:11: error: array index 2 is past the end of the array (which contains 1 element) [-Werror,-Warray-bounds]
return &unmap_pool[2];
^ ~
drivers/dma/dmaengine.c:1083:1: note: array 'unmap_pool' declared here
static struct dmaengine_unmap_pool unmap_pool[] = {
^
drivers/dma/dmaengine.c:1104:11: error: array index 3 is past the end of the array (which contains 1 element) [-Werror,-Warray-bounds]
return &unmap_pool[3];
^ ~
drivers/dma/dmaengine.c:1083:1: note: array 'unmap_pool' declared here
static struct dmaengine_unmap_pool unmap_pool[] = {
Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org>
Reviewed-by: Dan Williams <dan.j.williams(a)intel.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/dmaengine.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -1023,12 +1023,14 @@ static struct dmaengine_unmap_pool *__ge
switch (order) {
case 0 ... 1:
return &unmap_pool[0];
+#if IS_ENABLED(CONFIG_DMA_ENGINE_RAID)
case 2 ... 4:
return &unmap_pool[1];
case 5 ... 7:
return &unmap_pool[2];
case 8:
return &unmap_pool[3];
+#endif
default:
BUG();
return NULL;
Patches currently in stable-queue which might be from mka(a)chromium.org are
queue-4.4/bluetooth-btusb-driver-to-enable-the-usb-wakeup-feature.patch
queue-4.4/dmaengine-fix-array-index-out-of-bounds-warning-in-__get_unmap_pool.patch