This is the start of the stable review cycle for the 4.19.166 release. There are 8 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 09 Jan 2021 14:30:35 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.166-rc... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y and the diffstat can be found below.
thanks,
greg k-h
------------- Pseudo-Shortlog of commits:
Greg Kroah-Hartman gregkh@linuxfoundation.org Linux 4.19.166-rc1
Zhang Xiaohui ruc_zhangxiaohui@163.com mwifiex: Fix possible buffer overflows in mwifiex_cmd_802_11_ad_hoc_start
Jonathan Cameron Jonathan.Cameron@huawei.com iio:magnetometer:mag3110: Fix alignment and data leak issues.
Jonathan Cameron Jonathan.Cameron@huawei.com iio:imu:bmi160: Fix alignment and data leak issues
Josh Poimboeuf jpoimboe@redhat.com kdev_t: always inline major/minor helper functions
Yu Kuai yukuai3@huawei.com dmaengine: at_hdmac: add missing kfree() call in at_dma_xlate()
Yu Kuai yukuai3@huawei.com dmaengine: at_hdmac: add missing put_device() call in at_dma_xlate()
Tudor Ambarus tudor.ambarus@microchip.com dmaengine: at_hdmac: Substitute kzalloc with kmalloc
Felix Fietkau nbd@nbd.name Revert "mtd: spinand: Fix OOB read"
-------------
Diffstat:
Makefile | 4 ++-- drivers/dma/at_hdmac.c | 11 ++++++++--- drivers/iio/imu/bmi160/bmi160_core.c | 13 +++++++++---- drivers/iio/magnetometer/mag3110.c | 13 +++++++++---- drivers/mtd/nand/spi/core.c | 4 ---- drivers/net/wireless/marvell/mwifiex/join.c | 2 ++ include/linux/kdev_t.h | 22 +++++++++++----------- 7 files changed, 41 insertions(+), 28 deletions(-)
From: Felix Fietkau nbd@nbd.name
This reverts stable commit baad618d078c857f99cc286ea249e9629159901f.
This commit is adding lines to spinand_write_to_cache_op, wheras the upstream commit 868cbe2a6dcee451bd8f87cbbb2a73cf463b57e5 that this was supposed to backport was touching spinand_read_from_cache_op. It causes a crash on writing OOB data by attempting to write to read-only kernel memory.
Cc: Miquel Raynal miquel.raynal@bootlin.com Signed-off-by: Felix Fietkau nbd@nbd.name Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/mtd/nand/spi/core.c | 4 ---- 1 file changed, 4 deletions(-)
--- a/drivers/mtd/nand/spi/core.c +++ b/drivers/mtd/nand/spi/core.c @@ -378,10 +378,6 @@ static int spinand_write_to_cache_op(str } }
- if (req->ooblen) - memcpy(req->oobbuf.in, spinand->oobbuf + req->ooboffs, - req->ooblen); - return 0; }
From: Tudor Ambarus tudor.ambarus@microchip.com
commit a6e7f19c910068cb54983f36acebedb376f3a9ac upstream.
All members of the structure are initialized below in the function, there is no need to use kzalloc.
Signed-off-by: Tudor Ambarus tudor.ambarus@microchip.com Acked-by: Ludovic Desroches ludovic.desroches@microchip.com Link: https://lore.kernel.org/r/20200123140237.125799-1-tudor.ambarus@microchip.co... Signed-off-by: Vinod Koul vkoul@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/dma/at_hdmac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/dma/at_hdmac.c +++ b/drivers/dma/at_hdmac.c @@ -1683,7 +1683,7 @@ static struct dma_chan *at_dma_xlate(str dma_cap_zero(mask); dma_cap_set(DMA_SLAVE, mask);
- atslave = kzalloc(sizeof(*atslave), GFP_KERNEL); + atslave = kmalloc(sizeof(*atslave), GFP_KERNEL); if (!atslave) return NULL;
From: Yu Kuai yukuai3@huawei.com
commit 3832b78b3ec2cf51e07102f9b4480e343459b20f upstream.
If of_find_device_by_node() succeed, at_dma_xlate() doesn't have a corresponding put_device(). Thus add put_device() to fix the exception handling for this function implementation.
Fixes: bbe89c8e3d59 ("at_hdmac: move to generic DMA binding") Signed-off-by: Yu Kuai yukuai3@huawei.com Link: https://lore.kernel.org/r/20200817115728.1706719-3-yukuai3@huawei.com Signed-off-by: Vinod Koul vkoul@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/dma/at_hdmac.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
--- a/drivers/dma/at_hdmac.c +++ b/drivers/dma/at_hdmac.c @@ -1684,8 +1684,10 @@ static struct dma_chan *at_dma_xlate(str dma_cap_set(DMA_SLAVE, mask);
atslave = kmalloc(sizeof(*atslave), GFP_KERNEL); - if (!atslave) + if (!atslave) { + put_device(&dmac_pdev->dev); return NULL; + }
atslave->cfg = ATC_DST_H2SEL_HW | ATC_SRC_H2SEL_HW; /* @@ -1714,8 +1716,10 @@ static struct dma_chan *at_dma_xlate(str atslave->dma_dev = &dmac_pdev->dev;
chan = dma_request_channel(mask, at_dma_filter, atslave); - if (!chan) + if (!chan) { + put_device(&dmac_pdev->dev); return NULL; + }
atchan = to_at_dma_chan(chan); atchan->per_if = dma_spec->args[0] & 0xff;
From: Yu Kuai yukuai3@huawei.com
commit e097eb7473d9e70da9e03276f61cd392ccb9d79f upstream.
If memory allocation for 'atslave' succeed, at_dma_xlate() doesn't have a corresponding kfree() in exception handling. Thus add kfree() for this function implementation.
Fixes: bbe89c8e3d59 ("at_hdmac: move to generic DMA binding") Signed-off-by: Yu Kuai yukuai3@huawei.com Link: https://lore.kernel.org/r/20200817115728.1706719-4-yukuai3@huawei.com Signed-off-by: Vinod Koul vkoul@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/dma/at_hdmac.c | 1 + 1 file changed, 1 insertion(+)
--- a/drivers/dma/at_hdmac.c +++ b/drivers/dma/at_hdmac.c @@ -1718,6 +1718,7 @@ static struct dma_chan *at_dma_xlate(str chan = dma_request_channel(mask, at_dma_filter, atslave); if (!chan) { put_device(&dmac_pdev->dev); + kfree(atslave); return NULL; }
From: Josh Poimboeuf jpoimboe@redhat.com
commit aa8c7db494d0a83ecae583aa193f1134ef25d506 upstream.
Silly GCC doesn't always inline these trivial functions.
Fixes the following warning:
arch/x86/kernel/sys_ia32.o: warning: objtool: cp_stat64()+0xd8: call to new_encode_dev() with UACCESS enabled
Link: https://lkml.kernel.org/r/984353b44a4484d86ba9f73884b7306232e25e30.160873742... Signed-off-by: Josh Poimboeuf jpoimboe@redhat.com Reported-by: Randy Dunlap rdunlap@infradead.org Acked-by: Randy Dunlap rdunlap@infradead.org [build-tested] Cc: Peter Zijlstra peterz@infradead.org Cc: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Andrew Morton akpm@linux-foundation.org Signed-off-by: Linus Torvalds torvalds@linux-foundation.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- include/linux/kdev_t.h | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-)
--- a/include/linux/kdev_t.h +++ b/include/linux/kdev_t.h @@ -21,61 +21,61 @@ })
/* acceptable for old filesystems */ -static inline bool old_valid_dev(dev_t dev) +static __always_inline bool old_valid_dev(dev_t dev) { return MAJOR(dev) < 256 && MINOR(dev) < 256; }
-static inline u16 old_encode_dev(dev_t dev) +static __always_inline u16 old_encode_dev(dev_t dev) { return (MAJOR(dev) << 8) | MINOR(dev); }
-static inline dev_t old_decode_dev(u16 val) +static __always_inline dev_t old_decode_dev(u16 val) { return MKDEV((val >> 8) & 255, val & 255); }
-static inline u32 new_encode_dev(dev_t dev) +static __always_inline u32 new_encode_dev(dev_t dev) { unsigned major = MAJOR(dev); unsigned minor = MINOR(dev); return (minor & 0xff) | (major << 8) | ((minor & ~0xff) << 12); }
-static inline dev_t new_decode_dev(u32 dev) +static __always_inline dev_t new_decode_dev(u32 dev) { unsigned major = (dev & 0xfff00) >> 8; unsigned minor = (dev & 0xff) | ((dev >> 12) & 0xfff00); return MKDEV(major, minor); }
-static inline u64 huge_encode_dev(dev_t dev) +static __always_inline u64 huge_encode_dev(dev_t dev) { return new_encode_dev(dev); }
-static inline dev_t huge_decode_dev(u64 dev) +static __always_inline dev_t huge_decode_dev(u64 dev) { return new_decode_dev(dev); }
-static inline int sysv_valid_dev(dev_t dev) +static __always_inline int sysv_valid_dev(dev_t dev) { return MAJOR(dev) < (1<<14) && MINOR(dev) < (1<<18); }
-static inline u32 sysv_encode_dev(dev_t dev) +static __always_inline u32 sysv_encode_dev(dev_t dev) { return MINOR(dev) | (MAJOR(dev) << 18); }
-static inline unsigned sysv_major(u32 dev) +static __always_inline unsigned sysv_major(u32 dev) { return (dev >> 18) & 0x3fff; }
-static inline unsigned sysv_minor(u32 dev) +static __always_inline unsigned sysv_minor(u32 dev) { return dev & 0x3ffff; }
From: Jonathan Cameron Jonathan.Cameron@huawei.com
commit 7b6b51234df6cd8b04fe736b0b89c25612d896b8 upstream
One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable array in the iio_priv() data with alignment explicitly requested. This data is allocated with kzalloc() so no data can leak apart from previous readings.
In this driver, depending on which channels are enabled, the timestamp can be in a number of locations. Hence we cannot use a structure to specify the data layout without it being misleading.
Fixes: 77c4ad2d6a9b ("iio: imu: Add initial support for Bosch BMI160") Reported-by: Lars-Peter Clausen lars@metafoo.de Signed-off-by: Jonathan Cameron Jonathan.Cameron@huawei.com Reviewed-by: Alexandru Ardelean alexandru.ardelean@analog.com Cc: Daniel Baluta daniel.baluta@gmail.com Cc: Daniel Baluta daniel.baluta@oss.nxp.com Cc: Stable@vger.kernel.org Link: https://lore.kernel.org/r/20200920112742.170751-6-jic23@kernel.org [sudip: adjust context and use bmi160_data in old location] Signed-off-by: Sudip Mukherjee sudipm.mukherjee@gmail.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/iio/imu/bmi160/bmi160_core.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-)
--- a/drivers/iio/imu/bmi160/bmi160_core.c +++ b/drivers/iio/imu/bmi160/bmi160_core.c @@ -110,6 +110,13 @@ enum bmi160_sensor_type {
struct bmi160_data { struct regmap *regmap; + /* + * Ensure natural alignment for timestamp if present. + * Max length needed: 2 * 3 channels + 4 bytes padding + 8 byte ts. + * If fewer channels are enabled, less space may be needed, as + * long as the timestamp is still aligned to 8 bytes. + */ + __le16 buf[12] __aligned(8); };
const struct regmap_config bmi160_regmap_config = { @@ -385,8 +392,6 @@ static irqreturn_t bmi160_trigger_handle struct iio_poll_func *pf = p; struct iio_dev *indio_dev = pf->indio_dev; struct bmi160_data *data = iio_priv(indio_dev); - __le16 buf[12]; - /* 2 sens x 3 axis x __le16 + 2 x __le16 pad + 4 x __le16 tstamp */ int i, ret, j = 0, base = BMI160_REG_DATA_MAGN_XOUT_L; __le16 sample;
@@ -396,10 +401,10 @@ static irqreturn_t bmi160_trigger_handle &sample, sizeof(sample)); if (ret < 0) goto done; - buf[j++] = sample; + data->buf[j++] = sample; }
- iio_push_to_buffers_with_timestamp(indio_dev, buf, + iio_push_to_buffers_with_timestamp(indio_dev, data->buf, iio_get_time_ns(indio_dev)); done: iio_trigger_notify_done(indio_dev->trig);
From: Jonathan Cameron Jonathan.Cameron@huawei.com
commit 89deb1334252ea4a8491d47654811e28b0790364 upstream
One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp() assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv() data. This data is allocated with kzalloc() so no data can leak apart from previous readings.
The explicit alignment of ts is not necessary in this case but does make the code slightly less fragile so I have included it.
Fixes: 39631b5f9584 ("iio: Add Freescale mag3110 magnetometer driver") Reported-by: Lars-Peter Clausen lars@metafoo.de Signed-off-by: Jonathan Cameron Jonathan.Cameron@huawei.com Reviewed-by: Alexandru Ardelean alexandru.ardelean@analog.com Cc: Stable@vger.kernel.org Link: https://lore.kernel.org/r/20200920112742.170751-4-jic23@kernel.org [sudip: adjust context] Signed-off-by: Sudip Mukherjee sudipm.mukherjee@gmail.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/iio/magnetometer/mag3110.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-)
--- a/drivers/iio/magnetometer/mag3110.c +++ b/drivers/iio/magnetometer/mag3110.c @@ -56,6 +56,12 @@ struct mag3110_data { struct mutex lock; u8 ctrl_reg1; int sleep_val; + /* Ensure natural alignment of timestamp */ + struct { + __be16 channels[3]; + u8 temperature; + s64 ts __aligned(8); + } scan; };
static int mag3110_request(struct mag3110_data *data) @@ -387,10 +393,9 @@ static irqreturn_t mag3110_trigger_handl struct iio_poll_func *pf = p; struct iio_dev *indio_dev = pf->indio_dev; struct mag3110_data *data = iio_priv(indio_dev); - u8 buffer[16]; /* 3 16-bit channels + 1 byte temp + padding + ts */ int ret;
- ret = mag3110_read(data, (__be16 *) buffer); + ret = mag3110_read(data, data->scan.channels); if (ret < 0) goto done;
@@ -399,10 +404,10 @@ static irqreturn_t mag3110_trigger_handl MAG3110_DIE_TEMP); if (ret < 0) goto done; - buffer[6] = ret; + data->scan.temperature = ret; }
- iio_push_to_buffers_with_timestamp(indio_dev, buffer, + iio_push_to_buffers_with_timestamp(indio_dev, &data->scan, iio_get_time_ns(indio_dev));
done:
From: Zhang Xiaohui ruc_zhangxiaohui@163.com
[ Upstream commit 5c455c5ab332773464d02ba17015acdca198f03d ]
mwifiex_cmd_802_11_ad_hoc_start() calls memcpy() without checking the destination size may trigger a buffer overflower, which a local user could use to cause denial of service or the execution of arbitrary code. Fix it by putting the length check before calling memcpy().
Signed-off-by: Zhang Xiaohui ruc_zhangxiaohui@163.com Signed-off-by: Kalle Valo kvalo@codeaurora.org Link: https://lore.kernel.org/r/20201206084801.26479-1-ruc_zhangxiaohui@163.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/net/wireless/marvell/mwifiex/join.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/join.c b/drivers/net/wireless/marvell/mwifiex/join.c index d87aeff70cefb..c2cb1e711c06e 100644 --- a/drivers/net/wireless/marvell/mwifiex/join.c +++ b/drivers/net/wireless/marvell/mwifiex/join.c @@ -877,6 +877,8 @@ mwifiex_cmd_802_11_ad_hoc_start(struct mwifiex_private *priv,
memset(adhoc_start->ssid, 0, IEEE80211_MAX_SSID_LEN);
+ if (req_ssid->ssid_len > IEEE80211_MAX_SSID_LEN) + req_ssid->ssid_len = IEEE80211_MAX_SSID_LEN; memcpy(adhoc_start->ssid, req_ssid->ssid, req_ssid->ssid_len);
mwifiex_dbg(adapter, INFO, "info: ADHOC_S_CMD: SSID = %s\n",
Hi!
This is the start of the stable review cycle for the 4.19.166 release. There are 8 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
This was tested by CIP project, and we did not find anything wrong.
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-4...
Tested-by: Pavel Machek (CIP) pavel@denx.de
Best regards, Pavel
On Thu, Jan 07, 2021 at 06:58:01PM +0100, Pavel Machek wrote:
Hi!
This is the start of the stable review cycle for the 4.19.166 release. There are 8 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
This was tested by CIP project, and we did not find anything wrong.
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-4...
Tested-by: Pavel Machek (CIP) pavel@denx.de
Thanks for testing two of these and letting me know.
greg k-h
On Thu, 07 Jan 2021 15:32:00 +0100, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.166 release. There are 8 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 09 Jan 2021 14:30:35 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.166-rc... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y and the diffstat can be found below.
thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v4.19: 12 builds: 12 pass, 0 fail 22 boots: 22 pass, 0 fail 38 tests: 38 pass, 0 fail
Linux version: 4.19.166-rc1-g0f2782448d9a Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000, tegra194-p2972-0000, tegra20-ventana, tegra210-p2371-2180, tegra30-cardhu-a04
Tested-by: Jon Hunter jonathanh@nvidia.com
Jon
On 1/7/21 7:32 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.166 release. There are 8 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 09 Jan 2021 14:30:35 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.166-rc... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y and the diffstat can be found below.
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
Tested-by: Shuah Khan skhan@linuxfoundation.org
thanks, -- Shuah
On Thu, 7 Jan 2021 at 20:01, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 4.19.166 release. There are 8 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 09 Jan 2021 14:30:35 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.166-rc... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y and the diffstat can be found below.
thanks,
greg k-h
Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386.
Tested-by: Linux Kernel Functional Testing lkft@linaro.org
Summary ------------------------------------------------------------------------
kernel: 4.19.166-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.19.y git commit: 0f2782448d9a6522601ffabef0f3304a50d99857 git describe: v4.19.165-9-g0f2782448d9a Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.19.y/build/v4.19....
No regressions (compared to build v4.19.165)
No fixes (compared to build v4.19.165)
Ran 47163 total tests in the following environments and test suites.
Environments -------------- - arm - arm64 - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - juno-r2-compat - juno-r2-kasan - mips - nxp-ls2088 - qemu-arm64-clang - qemu-arm64-kasan - qemu-x86_64-clang - qemu-x86_64-kasan - qemu_arm - qemu_arm64 - qemu_arm64-compat - qemu_i386 - qemu_x86_64 - qemu_x86_64-compat - s390 - sparc - x15 - arm - x86_64 - x86-kasan
Test Suites ----------- * build * linux-log-parser * igt-gpu-tools * install-android-platform-tools-r2600 * kselftest * libhugetlbfs * ltp-containers-tests * ltp-cve-tests * ltp-ipc-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * perf * fwts * ltp-cap_bounds-tests * ltp-commands-tests * ltp-controllers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-math-tests * ltp-mm-tests * ltp-syscalls-tests * ltp-tracing-tests * network-basic-tests * v4l2-compliance * ltp-fs-tests * ltp-open-posix-tests * kvm-unit-tests * rcutorture * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none
On Thu, Jan 07, 2021 at 03:32:00PM +0100, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.166 release. There are 8 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 09 Jan 2021 14:30:35 +0000. Anything received after that time might be too late.
Build results: total: 155 pass: 155 fail: 0 Qemu test results: total: 418 pass: 418 fail: 0
Tested-by: Guenter Roeck linux@roeck-us.net
Guenter
linux-stable-mirror@lists.linaro.org