- Linux-stable-mirror - lists.linaro.org

[PATCH 3/4] ASoC: dpcm: allow start or stop during pause for backend

by Gyeongtaek Lee

soc_compr_trigger_fe() allows start or stop after pause_push. In dpcm_be_dai_trigger(), however, only pause_release is allowed command after pause_push. So, start or stop after pause in compress offload is always returned as error if the compress offload is used with dpcm. To fix the problem, SND_SOC_DPCM_STATE_PAUSED should be allowed for start or stop command. Signed-off-by: Gyeongtaek Lee <gt82.lee(a)samsung.com> Reviewed-by: Vinod Koul <vkoul(a)kernel.org> Link: https://lore.kernel.org/r/004d01d607c1$7a3d5250$6eb7f6f0$@samsung.com Signed-off-by: Mark Brown <broonie(a)kernel.org> --- sound/soc/soc-pcm.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c index d978df95c5c6..cc4e9aa80fb0 100644 --- a/sound/soc/soc-pcm.c +++ b/sound/soc/soc-pcm.c @@ -2222,7 +2222,8 @@ int dpcm_be_dai_trigger(struct snd_soc_pcm_runtime *fe, int stream, switch (cmd) { case SNDRV_PCM_TRIGGER_START: if ((be->dpcm[stream].state != SND_SOC_DPCM_STATE_PREPARE) && - (be->dpcm[stream].state != SND_SOC_DPCM_STATE_STOP)) + (be->dpcm[stream].state != SND_SOC_DPCM_STATE_STOP) && + (be->dpcm[stream].state != SND_SOC_DPCM_STATE_PAUSED)) continue; ret = dpcm_do_trigger(dpcm, be_substream, cmd); @@ -2252,7 +2253,8 @@ int dpcm_be_dai_trigger(struct snd_soc_pcm_runtime *fe, int stream, be->dpcm[stream].state = SND_SOC_DPCM_STATE_START; break; case SNDRV_PCM_TRIGGER_STOP: - if (be->dpcm[stream].state != SND_SOC_DPCM_STATE_START) + if ((be->dpcm[stream].state != SND_SOC_DPCM_STATE_START) && + (be->dpcm[stream].state != SND_SOC_DPCM_STATE_PAUSED)) continue; if (!snd_soc_dpcm_can_be_free_stop(fe, be, stream)) -- 2.21.0

5 years, 8 months

1
0
0 0

[PATCH 2/4] ASoC: dapm: connect virtual mux with default value

by Gyeongtaek Lee

Since a virtual mixer has no backing registers to decide which path to connect, it will try to match with initial state. This is to ensure that the default mixer choice will be correctly powered up during initialization. Invert flag is used to select initial state of the virtual switch. Since actual hardware can't be disconnected by virtual switch, connected is better choice as initial state in many cases. Signed-off-by: Gyeongtaek Lee <gt82.lee(a)samsung.com> Link: https://lore.kernel.org/r/01a301d60731$b724ea10$256ebe30$@samsung.com Signed-off-by: Mark Brown <broonie(a)kernel.org> --- sound/soc/soc-dapm.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index ebd785f9aa46..e0ff40b10d85 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -802,7 +802,13 @@ static void dapm_set_mixer_path_status(struct snd_soc_dapm_path *p, int i, val = max - val; p->connect = !!val; } else { - p->connect = 0; + /* since a virtual mixer has no backing registers to + * decide which path to connect, it will try to match + * with initial state. This is to ensure + * that the default mixer choice will be + * correctly powered up during initialization. + */ + p->connect = invert; } } -- 2.21.0

5 years, 8 months

1
0
0 0

[PATCH 1/4] ASoC: fix regwmask

by Gyeongtaek Lee

If regwshift is 32 and the selected architecture compiles '<<' operator for signed int literal into rotating shift, '1<<regwshift' became 1 and it makes regwmask to 0x0. The literal is set to unsigned long to get intended regwmask. Signed-off-by: Gyeongtaek Lee <gt82.lee(a)samsung.com> Link: https://lore.kernel.org/r/001001d60665$db7af3e0$9270dba0$@samsung.com Signed-off-by: Mark Brown <broonie(a)kernel.org> --- sound/soc/soc-ops.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/soc-ops.c b/sound/soc/soc-ops.c index f4dc3d445aae..95fc24580f85 100644 --- a/sound/soc/soc-ops.c +++ b/sound/soc/soc-ops.c @@ -832,7 +832,7 @@ int snd_soc_get_xr_sx(struct snd_kcontrol *kcontrol, unsigned int regbase = mc->regbase; unsigned int regcount = mc->regcount; unsigned int regwshift = component->val_bytes * BITS_PER_BYTE; - unsigned int regwmask = (1<<regwshift)-1; + unsigned int regwmask = (1UL<<regwshift)-1; unsigned int invert = mc->invert; unsigned long mask = (1UL<<mc->nbits)-1; long min = mc->min; @@ -881,7 +881,7 @@ int snd_soc_put_xr_sx(struct snd_kcontrol *kcontrol, unsigned int regbase = mc->regbase; unsigned int regcount = mc->regcount; unsigned int regwshift = component->val_bytes * BITS_PER_BYTE; - unsigned int regwmask = (1<<regwshift)-1; + unsigned int regwmask = (1UL<<regwshift)-1; unsigned int invert = mc->invert; unsigned long mask = (1UL<<mc->nbits)-1; long max = mc->max; -- 2.21.0

5 years, 8 months

1
0
0 0

[PATCH] ext4: Do not zeroout extents beyond i_disksize

by Jan Kara

We do not want to create initialized extents beyond end of file because for e2fsck it is impossible to distinguish them from a case of corrupted file size / extent tree and so it complains like: Inode 12, i_size is 147456, should be 163840. Fix? no Code in ext4_ext_convert_to_initialized() and ext4_split_convert_extents() try to make sure it does not create initialized extents beyond inode size however they check against inode->i_size which is wrong. They should instead check against EXT4_I(inode)->i_disksize which is the current inode size on disk. That's what e2fsck is going to see in case of crash before all dirty data is written. This bug manifests as generic/456 test failure (with recent enough fstests where fsx got fixed to properly pass FALLOC_KEEP_SIZE_FL flags to the kernel) when run with dioread_lock mount option. CC: stable(a)vger.kernel.org Fixes: 21ca087a3891 ("ext4: Do not zero out uninitialized extents beyond i_size") Signed-off-by: Jan Kara <jack(a)suse.cz> --- fs/ext4/extents.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index 954013d6076b..c5e190fd4589 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -3532,8 +3532,8 @@ static int ext4_ext_convert_to_initialized(handle_t *handle, (unsigned long long)map->m_lblk, map_len); sbi = EXT4_SB(inode->i_sb); - eof_block = (inode->i_size + inode->i_sb->s_blocksize - 1) >> - inode->i_sb->s_blocksize_bits; + eof_block = (EXT4_I(inode)->i_disksize + inode->i_sb->s_blocksize - 1) + >> inode->i_sb->s_blocksize_bits; if (eof_block < map->m_lblk + map_len) eof_block = map->m_lblk + map_len; @@ -3785,8 +3785,8 @@ static int ext4_split_convert_extents(handle_t *handle, __func__, inode->i_ino, (unsigned long long)map->m_lblk, map->m_len); - eof_block = (inode->i_size + inode->i_sb->s_blocksize - 1) >> - inode->i_sb->s_blocksize_bits; + eof_block = (EXT4_I(inode)->i_disksize + inode->i_sb->s_blocksize - 1) + >> inode->i_sb->s_blocksize_bits; if (eof_block < map->m_lblk + map->m_len) eof_block = map->m_lblk + map->m_len; /* -- 2.16.4

5 years, 8 months

3
3
0 0

+ mm-hugetlb-fix-a-addressing-exception-caused-by-huge_pte_offset.patch added to -mm tree

by Andrew Morton

The patch titled Subject: mm/hugetlb: fix a addressing exception caused by huge_pte_offset has been added to the -mm tree. Its filename is mm-hugetlb-fix-a-addressing-exception-caused-by-huge_pte_offset.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-hugetlb-fix-a-addressing-except… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-hugetlb-fix-a-addressing-except… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Longpeng <longpeng2(a)huawei.com> Subject: mm/hugetlb: fix a addressing exception caused by huge_pte_offset Our machine encountered a panic(addressing exception) after run for a long time and the calltrace is: RIP: 0010:[<ffffffff9dff0587>] [<ffffffff9dff0587>] hugetlb_fault+0x307/0xbe0 RSP: 0018:ffff9567fc27f808 EFLAGS: 00010286 RAX: e800c03ff1258d48 RBX: ffffd3bb003b69c0 RCX: e800c03ff1258d48 RDX: 17ff3fc00eda72b7 RSI: 00003ffffffff000 RDI: e800c03ff1258d48 RBP: ffff9567fc27f8c8 R08: e800c03ff1258d48 R09: 0000000000000080 R10: ffffaba0704c22a8 R11: 0000000000000001 R12: ffff95c87b4b60d8 R13: 00005fff00000000 R14: 0000000000000000 R15: ffff9567face8074 FS: 00007fe2d9ffb700(0000) GS:ffff956900e40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffd3bb003b69c0 CR3: 000000be67374000 CR4: 00000000003627e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: [<ffffffff9df9b71b>] ? unlock_page+0x2b/0x30 [<ffffffff9dff04a2>] ? hugetlb_fault+0x222/0xbe0 [<ffffffff9dff1405>] follow_hugetlb_page+0x175/0x540 [<ffffffff9e15b825>] ? cpumask_next_and+0x35/0x50 [<ffffffff9dfc7230>] __get_user_pages+0x2a0/0x7e0 [<ffffffff9dfc648d>] __get_user_pages_unlocked+0x15d/0x210 [<ffffffffc068cfc5>] __gfn_to_pfn_memslot+0x3c5/0x460 [kvm] [<ffffffffc06b28be>] try_async_pf+0x6e/0x2a0 [kvm] [<ffffffffc06b4b41>] tdp_page_fault+0x151/0x2d0 [kvm] ... [<ffffffffc06a6f90>] kvm_arch_vcpu_ioctl_run+0x330/0x490 [kvm] [<ffffffffc068d919>] kvm_vcpu_ioctl+0x309/0x6d0 [kvm] [<ffffffff9deaa8c2>] ? dequeue_signal+0x32/0x180 [<ffffffff9deae34d>] ? do_sigtimedwait+0xcd/0x230 [<ffffffff9e03aed0>] do_vfs_ioctl+0x3f0/0x540 [<ffffffff9e03b0c1>] SyS_ioctl+0xa1/0xc0 [<ffffffff9e53879b>] system_call_fastpath+0x22/0x27 For 1G hugepages, huge_pte_offset() wants to return NULL or pudp, but it may return a wrong 'pmdp' if there is a race. Please look at the following code snippet: ... pud = pud_offset(p4d, addr); if (sz != PUD_SIZE && pud_none(*pud)) return NULL; /* hugepage or swap? */ if (pud_huge(*pud) || !pud_present(*pud)) return (pte_t *)pud; pmd = pmd_offset(pud, addr); if (sz != PMD_SIZE && pmd_none(*pmd)) return NULL; /* hugepage or swap? */ if (pmd_huge(*pmd) || !pmd_present(*pmd)) return (pte_t *)pmd; ... The following sequence would trigger this bug: 1. CPU0: sz = PUD_SIZE and *pud = 0 , continue 1. CPU0: "pud_huge(*pud)" is false 2. CPU1: calling hugetlb_no_page and set *pud to xxxx8e7(PRESENT) 3. CPU0: "!pud_present(*pud)" is false, continue 4. CPU0: pmd = pmd_offset(pud, addr) and maybe return a wrong pmdp However, we want CPU0 to return NULL or pudp in this case. We must make sure there is exactly one dereference of pud and pmd. Link: http://lkml.kernel.org/r/20200413010342.771-1-longpeng2@huawei.com Signed-off-by: Longpeng <longpeng2(a)huawei.com> Cc: Mike Kravetz <mike.kravetz(a)oracle.com> Cc: Jason Gunthorpe <jgg(a)ziepe.ca> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: Sean Christopherson <sean.j.christopherson(a)intel.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/hugetlb.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) --- a/mm/hugetlb.c~mm-hugetlb-fix-a-addressing-exception-caused-by-huge_pte_offset +++ a/mm/hugetlb.c @@ -5365,8 +5365,8 @@ pte_t *huge_pte_offset(struct mm_struct { pgd_t *pgd; p4d_t *p4d; - pud_t *pud; - pmd_t *pmd; + pud_t *pud, pud_entry; + pmd_t *pmd, pmd_entry; pgd = pgd_offset(mm, addr); if (!pgd_present(*pgd)) @@ -5376,17 +5376,19 @@ pte_t *huge_pte_offset(struct mm_struct return NULL; pud = pud_offset(p4d, addr); - if (sz != PUD_SIZE && pud_none(*pud)) + pud_entry = READ_ONCE(*pud); + if (sz != PUD_SIZE && pud_none(pud_entry)) return NULL; /* hugepage or swap? */ - if (pud_huge(*pud) || !pud_present(*pud)) + if (pud_huge(pud_entry) || !pud_present(pud_entry)) return (pte_t *)pud; pmd = pmd_offset(pud, addr); - if (sz != PMD_SIZE && pmd_none(*pmd)) + pmd_entry = READ_ONCE(*pmd); + if (sz != PMD_SIZE && pmd_none(pmd_entry)) return NULL; /* hugepage or swap? */ - if (pmd_huge(*pmd) || !pmd_present(*pmd)) + if (pmd_huge(pmd_entry) || !pmd_present(pmd_entry)) return (pte_t *)pmd; return NULL; _ Patches currently in -mm which might be from longpeng2(a)huawei.com are mm-hugetlb-fix-a-addressing-exception-caused-by-huge_pte_offset.patch

5 years, 8 months

1
0
0 0

stable/linux-5.6.y boot: 101 boots: 4 failed, 92 passed with 5 untried/unknown (v5.6.4)

by kernelci.org bot

stable/linux-5.6.y boot: 101 boots: 4 failed, 92 passed with 5 untried/unknown (v5.6.4) Full Boot Summary: https://kernelci.org/boot/all/job/stable/branch/linux-5.6.y/kernel/v5.6.4/ Full Build Summary: https://kernelci.org/build/stable/branch/linux-5.6.y/kernel/v5.6.4/ Tree: stable Branch: linux-5.6.y Git Describe: v5.6.4 Git Commit: 0a27a29496060843ae3a8fe78aaec0062cbd5dfa Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Tested: 64 unique boards, 16 SoC families, 17 builds out of 200 Boot Regressions Detected: arm: exynos_defconfig: gcc-8: exynos5422-odroidxu3: lab-collabora: new failure (last pass: v5.6.2) versatile_defconfig: gcc-8: versatile-pb: lab-collabora: new failure (last pass: v5.6.3) arm64: defconfig: gcc-8: meson-gxm-q200: lab-baylibre: new failure (last pass: v5.6.3) Boot Failures Detected: arm: multi_v7_defconfig: gcc-8: bcm2836-rpi-2-b: 1 failed lab exynos_defconfig: gcc-8: exynos5422-odroidxu3: 1 failed lab sama5_defconfig: gcc-8: at91-sama5d4_xplained: 1 failed lab arm64: defconfig: gcc-8: meson-gxm-q200: 1 failed lab --- For more info write to <info(a)kernelci.org>

5 years, 8 months

1
0
0 0

stable/linux-4.19.y boot: 92 boots: 2 failed, 84 passed with 6 untried/unknown (v4.19.114-56-g6dd0e32665e5)

by kernelci.org bot

stable/linux-4.19.y boot: 92 boots: 2 failed, 84 passed with 6 untried/unknown (v4.19.114-56-g6dd0e32665e5) Full Boot Summary: https://kernelci.org/boot/all/job/stable/branch/linux-4.19.y/kernel/v4.19.1… Full Build Summary: https://kernelci.org/build/stable/branch/linux-4.19.y/kernel/v4.19.114-56-g… Tree: stable Branch: linux-4.19.y Git Describe: v4.19.114-56-g6dd0e32665e5 Git Commit: 6dd0e32665e591e9debe3edaf73c2f8135bf047e Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Tested: 54 unique boards, 15 SoC families, 17 builds out of 206 Boot Regressions Detected: arm: multi_v7_defconfig: gcc-8: sun4i-a10-olinuxino-lime: lab-baylibre: new failure (last pass: v4.19.114) versatile_defconfig: gcc-8: versatile-pb: lab-collabora: new failure (last pass: v4.19.114) arm64: defconfig: gcc-8: meson-gxl-s805x-p241: lab-baylibre: new failure (last pass: v4.19.114) Boot Failures Detected: arm: sama5_defconfig: gcc-8: at91-sama5d4_xplained: 1 failed lab arm64: defconfig: gcc-8: meson-gxl-s805x-p241: 1 failed lab --- For more info write to <info(a)kernelci.org>

5 years, 8 months

1
0
0 0

[PATCH AUTOSEL 5.6 01/68] cpufreq: imx6q: Fixes unwanted cpu overclocking on i.MX6ULL

by Sasha Levin

From: Christoph Niedermaier <cniedermaier(a)dh-electronics.com> [ Upstream commit 36eb7dc1bd42fe5f850329c893768ff89b696fba ] imx6ul_opp_check_speed_grading is called for both i.MX6UL and i.MX6ULL. Since the i.MX6ULL was introduced to a separate ocotp compatible node later, it is possible that the i.MX6ULL has also dtbs with "fsl,imx6ull-ocotp". On a system without nvmem-cell speed grade a missing check on this node causes a driver fail without considering the cpu speed grade. This patch prevents unwanted cpu overclocking on i.MX6ULL with compatible node "fsl,imx6ull-ocotp" in old dtbs without nvmem-cell speed grade. Fixes: 2733fb0d0699 ("cpufreq: imx6q: read OCOTP through nvmem for imx6ul/imx6ull") Signed-off-by: Christoph Niedermaier <cniedermaier(a)dh-electronics.com> Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/cpufreq/imx6q-cpufreq.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c index 648a09a1778a3..1fcbbd53a48a2 100644 --- a/drivers/cpufreq/imx6q-cpufreq.c +++ b/drivers/cpufreq/imx6q-cpufreq.c @@ -280,6 +280,9 @@ static int imx6ul_opp_check_speed_grading(struct device *dev) void __iomem *base; np = of_find_compatible_node(NULL, NULL, "fsl,imx6ul-ocotp"); + if (!np) + np = of_find_compatible_node(NULL, NULL, + "fsl,imx6ull-ocotp"); if (!np) return -ENOENT; -- 2.20.1

5 years, 8 months

5
76
0 0

stable/linux-4.14.y boot: 80 boots: 3 failed, 72 passed with 5 untried/unknown (v4.14.176)

by kernelci.org bot

stable/linux-4.14.y boot: 80 boots: 3 failed, 72 passed with 5 untried/unknown (v4.14.176) Full Boot Summary: https://kernelci.org/boot/all/job/stable/branch/linux-4.14.y/kernel/v4.14.1… Full Build Summary: https://kernelci.org/build/stable/branch/linux-4.14.y/kernel/v4.14.176/ Tree: stable Branch: linux-4.14.y Git Describe: v4.14.176 Git Commit: c10b57a567e4333b9fdf60b5ec36de9859263ca2 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Tested: 46 unique boards, 14 SoC families, 16 builds out of 201 Boot Regressions Detected: arm: sama5_defconfig: gcc-8: at91-sama5d4_xplained: lab-baylibre: failing since 80 days (last pass: v4.14.166 - first fail: v4.14.167) versatile_defconfig: gcc-8: versatile-pb: lab-collabora: new failure (last pass: v4.14.175) vexpress_defconfig: gcc-8: vexpress-v2p-ca15-tc1: lab-collabora: failing since 23 days (last pass: v4.14.173 - first fail: v4.14.174) Boot Failures Detected: arm: sama5_defconfig: gcc-8: at91-sama5d4_xplained: 1 failed lab arm64: defconfig: gcc-8: meson-gxbb-p200: 1 failed lab meson-gxm-q200: 1 failed lab --- For more info write to <info(a)kernelci.org>

5 years, 8 months

1
0
0 0

stable/linux-5.4.y boot: 103 boots: 1 failed, 96 passed with 6 untried/unknown (v5.4.32)

by kernelci.org bot

stable/linux-5.4.y boot: 103 boots: 1 failed, 96 passed with 6 untried/unknown (v5.4.32) Full Boot Summary: https://kernelci.org/boot/all/job/stable/branch/linux-5.4.y/kernel/v5.4.32/ Full Build Summary: https://kernelci.org/build/stable/branch/linux-5.4.y/kernel/v5.4.32/ Tree: stable Branch: linux-5.4.y Git Describe: v5.4.32 Git Commit: bc844d58f697dff3ded4b410094ee89f5cedc04c Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Tested: 64 unique boards, 17 SoC families, 17 builds out of 200 Boot Regressions Detected: arm: versatile_defconfig: gcc-8: versatile-pb: lab-collabora: new failure (last pass: v5.4.31) Boot Failure Detected: arm: sama5_defconfig: gcc-8: at91-sama5d4_xplained: 1 failed lab --- For more info write to <info(a)kernelci.org>

5 years, 8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror