- 10 May, 2019 13 commits
-
-
John Hsu authored
[ Upstream commit 844a4a36 ] The driver has two issues when machine add prefix name for codec. (1)The stream name of DAI can't find the AIF widgets. (2)The drivr can enable/disalbe the MICBIAS and SAR widgets. The patch will fix these issues caused by prefixed name added. Signed-off-by:
John Hsu <KCHSU0@nuvoton.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Rander Wang authored
[ Upstream commit c899df3e ] If playback and capture are enabled concurrently, when the capture stops the output becomes inaudile. The playback application will become stuck and underrun after a timeout. This is caused by mistaken use of the stream_id, which should only be set for playback and not for capture Tested on Apollolake and Kabylake with SST driver. Signed-off-by:
Rander Wang <rander.wang@linux.intel.com> Acked-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by:
-
Rander Wang authored
[ Upstream commit 570f18b6 ] On HDaudio platforms, if playback is started when capture is working, there is no audible output. This can be root-caused to the use of the rx|tx_mask to store an HDaudio stream tag. If capture is stared before playback, rx_mask would be non-zero on HDaudio platform, then the channel number of playback, which is in the same codec dai with the capture, would be changed by soc_pcm_codec_params_fixup based on the tx_mask at first, then overwritten by this function based on rx_mask at last. According to the author of tx|rx_mask, tx_mask is for playback and rx_mask is for capture. And stream direction is checked at all other references of tx|rx_mask in ASoC, so here should be an error. This patch checks stream direction for tx|rx_mask for fixup function. This issue would affect not only HDaudio+ASoC, but also I2S codecs if the channel number based on rx_mask is not equal to the one for tx_mask. It could be rarely reproduecd because most drivers in kernel set the same channel number to tx|rx_mask or rx_mask is zero. Tested on all platforms using stream_tag & HDaudio and intel I2S platforms. Signed-off-by:
-
Olivier Moysan authored
[ Upstream commit b8468192 ] Change capabilities exposed in SAI S/PDIF mode, to match actually supported formats. In S/PDIF mode only 32 bits stereo is supported. Signed-off-by:
Olivier Moysan <olivier.moysan@st.com> Signed-off-by:
-
Olivier Moysan authored
[ Upstream commit 5f8a1000 ] Allow indexation of sai iec958 controls according to device id. Signed-off-by:
-
Russell King authored
[ Upstream commit 2e95f984 ] When using the S/PDIF DAI, there is no requirement to call snd_soc_dai_set_fmt() as there is no DAI format definition that defines S/PDIF. In any case, S/PDIF does not have separate clocks, this is embedded into the data stream. Consequently, when attempting to use TDA998x in S/PDIF mode, the attempt to configure TDA998x via the hw_params callback fails as the hdmi_codec_daifmt is left initialised to zero. Since the S/PDIF DAI will only be used by S/PDIF, prepare the hdmi_codec_daifmt structure for this format. Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by:
Jyri Sarha <jsarha@ti.com> Signed-off-by:
-
Philipp Puschmann authored
[ Upstream commit 82ad7591 ] This patch fixes a bug that prevents freeing the reset gpio on unloading the module. aic3x_i2c_probe is called when loading the module and it calls list_add with a probably uninitialized list entry aic3x->list (next = prev = NULL)). So even if list_del is called it does nothing and in the end the gpio_reset is not freed. Then a repeated module probing fails silently because gpio_request fails. When moving INIT_LIST_HEAD to aic3x_i2c_probe we also have to move list_del to aic3x_i2c_remove because aic3x_remove may be called multiple times without aic3x_i2c_remove being called which leads to a NULL pointer dereference. Signed-off-by:
Philipp Puschmann <philipp.puschmann@emlix.com> Signed-off-by:
-
Suresh Udipi authored
commit af708900 upstream. It looks like v4.18-rc1 commit [0] which upstreams mld-1.8.0 commit [1] missed to fix the memory leak in mod_exit function. Do it now. [0] aba258b7 ("staging: most: cdev: fix chrdev_region leak") [1] https://github.com/microchip-ais/linux/commit/a2d8f7ae7ea381 ("staging: most: cdev: fix leak for chrdev_region") Signed-off-by:
Suresh Udipi <sudipi@jp.adit-jv.com> Signed-off-by:
Eugeniu Rosca <erosca@de.adit-jv.com> Acked-by:
Christian Gromm <christian.gromm@microchip.com> Fixes: aba258b7 ("staging: most: cdev: fix chrdev_region leak") Cc: stable <stable@vger.kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Johan Hovold authored
commit 47830c11 upstream. Since moving the message buffers off the stack, the dynamically allocated get-prop-descriptor request buffer is incorrectly sized due to using the pointer rather than request-struct size when creating the operation. Fortunately, the pointer size is always larger than this one-byte request, but this could still cause trouble on the remote end due to the unexpected message size. Fixes: 9d15134d ("greybus: power_supply: rework get descriptors") Cc: stable <stable@vger.kernel.org> # 4.9 Cc: Rui Miguel Silva <rui.silva@linaro.org> Signed-off-by:
Johan Hovold <johan@kernel.org> Reviewed-by:
Rui Miguel Silva <rmfrfs@gmail.com> Signed-off-by:
-
Andrey Ryabinin authored
commit f0996bc2 upstream. Building lib/ubsan.c with gcc-9 results in a ton of nasty warnings like this one: lib/ubsan.c warning: conflicting types for built-in function ‘__ubsan_handle_negate_overflow’; expected ‘void(void *, void *)’ [-Wbuiltin-declaration-mismatch] The kernel's declarations of __ubsan_handle_*() often uses 'unsigned long' types in parameters while GCC these parameters as 'void *' types, hence the mismatch. Fix this by using 'void *' to match GCC's declarations. Reported-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Andrey Ryabinin <aryabinin@virtuozzo.com> Fixes: c6d30853 ("UBSAN: run-time undefined behavior sanity checker") Cc: <stable@vger.kernel.org> Signed-off-by:
-
Dexuan Cui authored
commit a0033bd1 upstream. With CONFIG_DEBUG_PREEMPT=y, the put_cpu_ptr() triggers an underflow warning in preempt_count_sub(). Fixes: 37cdd991 ("vmbus: put related per-cpu variable together") Cc: stable@vger.kernel.org Cc: Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by:
Dexuan Cui <decui@microsoft.com> Reviewed-by:
Michael Kelley <mikelley@microsoft.com> Signed-off-by:
-
Jason Yan authored
commit b90cd6f2 upstream. When the lldd is processing the complete sas task in interrupt and set the task stat as SAS_TASK_STATE_DONE, the smp timeout timer is able to be triggered at the same time. And smp_task_timedout() will complete the task wheter the SAS_TASK_STATE_DONE is set or not. Then the sas task may freed before lldd end the interrupt process. Thus a use-after-free will happen. Fix this by calling the complete() only when SAS_TASK_STATE_DONE is not set. And remove the check of the return value of the del_timer(). Once the LLDD sets DONE, it must call task->done(), which will call smp_task_done()->complete() and the task will be completed and freed correctly. Reported-by:
chenxiang <chenxiang66@hisilicon.com> Signed-off-by:
Jason Yan <yanaijie@huawei.com> CC: John Garry <john.garry@huawei.com> CC: Johannes Thumshirn <jthumshirn@suse.de> CC: Ewan Milne <emilne@redhat.com> CC: Christoph Hellwig <hch@lst.de> CC: Tomas Henzl <thenzl@redhat.com> CC: Dan Williams <dan.j.williams@intel.com> CC: Hannes Reinecke <hare@suse.com> Reviewed-by:
Hannes Reinecke <hare@suse.com> Reviewed-by:
John Garry <john.garry@huawei.com> Reviewed-by:
Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Cc: Guenter Roeck <linux@roeck-us.net Signed-off-by:
-
YueHaibing authored
commit f87db4db upstream. gcc warn this: drivers/net/ethernet/stmicro/stmmac/norm_desc.c: In function ndesc_init_rx_desc: drivers/net/ethernet/stmicro/stmmac/norm_desc.c:138:6: warning: variable 'bfsize1' set but not used [-Wunused-but-set-variable] Like enh_desc_init_rx_desc, we should use bfsize1 in ndesc_init_rx_desc to calculate 'p->des1' Fixes: 583e6361 ("net: stmmac: use correct DMA buffer size in the RX descriptor") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Reviewed-by:
Aaro Koskinen <aaro.koskinen@nokia.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Cc: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Signed-off-by:
-
- 08 May, 2019 27 commits
-
-
Greg Kroah-Hartman authored
-
Arnd Bergmann authored
commit dce5b0bd upstream. The only references outside of the #ifdef have been removed, so now we get a warning in non-SMP configurations: mm/kmemleak.c:1404:13: error: unused function 'scan_large_block' [-Werror,-Wunused-function] Add a new #ifdef around it. Link: http://lkml.kernel.org/r/20190416123148.3502045-1-arnd@arndb.de Fixes: 298a32b1 ("kmemleak: powerpc: skip scanning holes in the .bss section") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Cc: Vincent Whitchurch <vincent.whitchurch@axis.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Charles Keepax authored
commit 43d147be upstream. Trigger stop can be called in situations where trigger start failed and as such it can't be assumed the buffer is already attached to the compressed stream or a NULL pointer may be dereferenced. Fixes: 639e5eb3 ("ASoC: wm_adsp: Correct handling of compressed streams that restart") Signed-off-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by:
-
Jacopo Mondi authored
commit 61da76be upstream. The following commits: commit f6dd927f ("[media] media: ov7670: calculate framerate properly for ov7675") commit 04ee6d92 ("[media] media: ov7670: add possibility to bypass pll for ov7675") introduced the ability to bypass PLL multiplier and use input clock (xvclk) as pixel clock output frequency for ov7675 sensor. PLL is bypassed using register DBLV[7:6], according to ov7670 and ov7675 sensor manuals. Macros used to set DBLV register seem wrong in the driver, as their values do not match what reported in the datasheet. Fix by changing DBLV_* macros to use bits [7:6] and set bits [3:0] to default 0x0a reserved value (according to datasheets). While at there, remove a write to DBLV register in "ov7675_set_framerate()" that over-writes the previous one to the same register that takes "info->pll_bypass" flag into account instead of setting PLL multiplier to 4x unconditionally. And, while at there, since "info->pll_bypass" is only used in set/get_framerate() functions used by ov7675 only, it is not necessary to check for the device id at probe time to make sure that when using ov7670 "info->pll_bypass" is set to false. Fixes: f6dd927f ("[media] media: ov7670: calculate framerate properly for ov7675") Signed-off-by:
Jacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Nicolas Le Bayon authored
commit c86da50c upstream. It conforms with Reference Manual I2C timing section. Fixes: aeb068c5 ("i2c: i2c-stm32f7: add driver") Signed-off-by:
Nicolas Le Bayon <nicolas.le.bayon@st.com> Signed-off-by:
Bich Hemon <bich.hemon@st.com> Reviewed-by:
Pierre-Yves MORDRET <pierre-yves.mordret@st.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Peter Zijlstra authored
commit 780e0106 upstream. Revert the following commit: 515ab7c4: ("x86/mm: Align TLB invalidation info") I found out (the hard way) that under some .config options (notably L1_CACHE_SHIFT=7) and compiler combinations this on-stack alignment leads to a 320 byte stack usage, which then triggers a KASAN stack warning elsewhere. Using 320 bytes of stack space for a 40 byte structure is ludicrous and clearly not right. Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by:
Nadav Amit <namit@vmware.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: 515ab7c4 ("x86/mm: Align TLB invalidation info") Link: http://lkml.kernel.org/r/20190416080335.GM7905@worktop.programming.kicks-ass.net [ Minor changelog edits. ] Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Qian Cai authored
commit 0d02113b upstream. The first kmemleak_scan() call after boot would trigger the crash below because this callpath: kernel_init free_initmem mem_encrypt_free_decrypted_mem free_init_pages unmaps memory inside the .bss when DEBUG_PAGEALLOC=y. kmemleak_init() will register the .data/.bss sections and then kmemleak_scan() will scan those addresses and dereference them looking for pointer references. If free_init_pages() frees and unmaps pages in those sections, kmemleak_scan() will crash if referencing one of those addresses: BUG: unable to handle kernel paging request at ffffffffbd402000 CPU: 12 PID: 325 Comm: kmemleak Not tainted 5.1.0-rc4+ #4 RIP: 0010:scan_block Call Trace: scan_gray_list kmemleak_scan kmemleak_scan_thread kthread ret_from_fork Since kmemleak_free_part() is tolerant to unknown objects (not tracked by kmemleak), it is fine to call it from free_init_pages() even if not all address ranges passed to this function are known to kmemleak. [ bp: Massage. ] Fixes: b3f0907c ("x86/mm: Add .bss..decrypted section to hold shared variables") Signed-off-by:
Qian Cai <cai@lca.pw> Signed-off-by:
Borislav Petkov <bp@suse.de> Reviewed-by:
-
Baoquan He authored
commit ec393710 upstream. kernel_randomize_memory() uses __PHYSICAL_MASK_SHIFT to calculate the maximum amount of system RAM supported. The size of the direct mapping section is obtained from the smaller one of the below two values: (actual system RAM size + padding size) vs (max system RAM size supported) This calculation is wrong since commit b83ce5ee ("x86/mm/64: Make __PHYSICAL_MASK_SHIFT always 52"). In it, __PHYSICAL_MASK_SHIFT was changed to be 52, regardless of whether the kernel is using 4-level or 5-level page tables. Thus, it will always use 4 PB as the maximum amount of system RAM, even in 4-level paging mode where it should actually be 64 TB. Thus, the size of the direct mapping section will always be the sum of the actual system RAM size plus the padding size. Even when the amount of system RAM is 64 TB, the following layout will still be used. Obviously KALSR will be weakened significantly. |____|_______actual RAM_______|_padding_|______the rest_______| 0 64TB ~120TB Instead, it should be like this: |____|_______actual RAM_______|_________the rest______________| 0 64TB ~120TB The size of padding region is controlled by CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING, which is 10 TB by default. The above issue only exists when CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING is set to a non-zero value, which is the case when CONFIG_MEMORY_HOTPLUG is enabled. Otherwise, using __PHYSICAL_MASK_SHIFT doesn't affect KASLR. Fix it by replacing __PHYSICAL_MASK_SHIFT with MAX_PHYSMEM_BITS. [ bp: Massage commit message. ] Fixes: b83ce5ee ("x86/mm/64: Make __PHYSICAL_MASK_SHIFT always 52") Signed-off-by:
Baoquan He <bhe@redhat.com> Signed-off-by:
Thomas Garnier <thgarnie@google.com> Acked-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Kees Cook <keescook@chromium.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: frank.ramsay@hpe.com Cc: herbert@gondor.apana.org.au Cc: kirill@shutemov.name Cc: mike.travis@hpe.com Cc: thgarnie@google.com Cc: x86-ml <x86@kernel.org> Cc: yamada.masahiro@socionext.com Link: https://lkml.kernel.org/r/20190417083536.GE7065@MiWiFi-R3L-srvSigned-off-by:
-
David Müller authored
commit 7c2e0713 upstream. Since commit 648e9218 ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL"), the pmc_plt_clocks of the Bay Trail SoC are unconditionally gated off. Unfortunately this will break systems where these clocks are used for external purposes beyond the kernel's knowledge. Fix it by implementing a system specific quirk to mark the necessary pmc_plt_clks as critical. Fixes: 648e9218 ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL") Signed-off-by:
David Müller <dave.mueller@gmx.ch> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
Stephen Boyd <sboyd@kernel.org> Signed-off-by:
-
Tony Luck authored
commit 41f035a8 upstream. In c7d606f5 ("x86/mce: Improve error message when kernel cannot recover") a case was added for a machine check caused by a DATA access to poison memory from the kernel. A case should have been added also for an uncorrectable error during an instruction fetch in the kernel. Add that extra case so the error message now reads: mce: [Hardware Error]: Machine check: Instruction fetch error in kernel Fixes: c7d606f5 ("x86/mce: Improve error message when kernel cannot recover") Signed-off-by:
Tony Luck <tony.luck@intel.com> Signed-off-by:
-
Aneesh Kumar K.V authored
commit 3b4d07d2 upstream. When doing top-down search the low_limit is not PAGE_SIZE but rather max(PAGE_SIZE, mmap_min_addr). This handle cases in which mmap_min_addr > PAGE_SIZE. Fixes: fba2369e ("mm: use vm_unmapped_area() on powerpc architecture") Reviewed-by:
Laurent Dufour <ldufour@linux.vnet.ibm.com> Signed-off-by:
Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Alexander Wetzel authored
commit 78ad2341 upstream. Restore SW_CRYPTO_CONTROL operation on AP_VLAN interfaces for unicast keys, the original override was intended to be done for group keys as those are treated specially by mac80211 and would always have been rejected. Now the situation is that AP_VLAN support must be enabled by the driver if it can support it (meaning it can support software crypto GTK TX). Thus, also simplify the code - if we get here with AP_VLAN and non- pairwise key, software crypto must be used (driver doesn't know about the interface) and can be used (driver must've advertised AP_VLAN if it also uses SW_CRYPTO_CONTROL). Fixes: db3bdcb9 ("mac80211: allow AP_VLAN operation on crypto controlled devices") Signed-off-by:
Alexander Wetzel <alexander@wetzel-home.de> [rewrite commit message] Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Ondrej Mosnacek authored
commit a83d6dda upstream. In the SECURITY_FS_USE_MNTPOINT case we never want to allow relabeling files/directories, so we should never set the SBLABEL_MNT flag. The 'special handling' in selinux_is_sblabel_mnt() is only intended for when the behavior is set to SECURITY_FS_USE_GENFS. While there, make the logic in selinux_is_sblabel_mnt() more explicit and add a BUILD_BUG_ON() to make sure that introducing a new SECURITY_FS_USE_* forces a review of the logic. Fixes: d5f3a5f6 ("selinux: add security in-core xattr support for pstore and debugfs") Signed-off-by:
Ondrej Mosnacek <omosnace@redhat.com> Reviewed-by:
Stephen Smalley <sds@tycho.nsa.gov> Signed-off-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
-
Stephen Smalley authored
commit 3a28cff3 upstream. commit 0dc1ba24 ("SELINUX: Make selinux cache VFS RCU walks safe") results in no audit messages at all if in permissive mode because the cache is updated during the rcu walk and thus no denial occurs on the subsequent ref walk. Fix this by not updating the cache when performing a non-blocking permission check. This only affects search and symlink read checks during rcu walk. Fixes: 0dc1ba24 ("SELINUX: Make selinux cache VFS RCU walks safe") Reported-by:
BMK <bmktuwien@gmail.com> Signed-off-by:
-
Anson Huang authored
commit a329bbe7 upstream. On i.MX8MQ platform, clock driver uses platform driver model and it is probed after GPIO driver, so when GPIO driver fails to get clock, it should check the error type to decide whether to return defer probe or just ignore the clock operation. Fixes: 2808801a ("gpio: mxc: add clock operation") Signed-off-by:
Anson Huang <Anson.Huang@nxp.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Dmitry Torokhov authored
commit 937c4e55 upstream. We need to turn regulators on and off when switching brightness, and that may block, therefore we have to set stmfts_brightness_set() as LED's brightness_set_blocking() method. Fixes: 78bcac7b ("Input: add support for the STMicroelectronics FingerTip touchscreen") Acked-by:
Andi Shyti <andi@etezian.org> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Anson Huang authored
commit bf2a7ca3 upstream. SNVS IRQ is requested before necessary driver data initialized, if there is a pending IRQ during driver probe phase, kernel NULL pointer panic will occur in IRQ handler. To avoid such scenario, just initialize necessary driver data before enabling IRQ. This patch is inspired by NXP's internal kernel tree. Fixes: d3dc6e23 ("input: keyboard: imx: add snvs power key driver") Signed-off-by:
-
Yuval Avnery authored
commit 535005ca upstream. The open-coded variant missed destroy of SELinux created QP, reuse already existing ib_detroy_qp() call and use this opportunity to clean ib_create_qp() from double prints and unclear exit paths. Reported-by:
Parav Pandit <parav@mellanox.com> Fixes: d291f1a6 ("IB/core: Enforce PKey security on QPs") Signed-off-by:
Yuval Avnery <yuvalav@mellanox.com> Reviewed-by:
Daniel Jurgens <danielj@mellanox.com> Signed-off-by:
Leon Romanovsky <leonro@mellanox.com> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
Daniel Jurgens authored
commit 6e88e672 upstream. If the MAD agents isn't allowed to manage the subnet, or fails to register for the LSM notifier, the security context is leaked. Free the context in these cases. Fixes: 47a2b338 ("IB/core: Enforce security on management datagrams") Signed-off-by:
-
Daniel Jurgens authored
commit d60667fc upstream. If the notifier runs after the security context is freed an access of freed memory can occur. Fixes: 47a2b338 ("IB/core: Enforce security on management datagrams") Signed-off-by:
-
Rajneesh Bhardwaj authored
commit e50af833 upstream. Only Coffeelake should use Cannonlake regmap other than Cannonlake platform. This allows Coffeelake special handling only when there is no matching PCI device and default reg map selected as per CPUID is for Sunrisepoint PCH. This change is needed to enable support for newer SoCs such as Icelake. Cc: "David E. Box" <david.e.box@intel.com> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Fixes: 661405bd ("platform/x86: intel_pmc_core: Special case for Coffeelake") Acked-by:
"David E. Box" <david.e.box@linux.intel.com> Signed-off-by:
Rajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Rajneesh Bhardwaj authored
commit d6827015 upstream. For Cannonlake and Icelake, the IP name for Res_6 should be SPF i.e. South Port F. No functional change is intended other than just renaming the IP appropriately. Cc: "David E. Box" <david.e.box@intel.com> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Fixes: 291101f6 ("platform/x86: intel_pmc_core: Add CannonLake PCH support") Signed-off-by:
-
Arnaud Pouliquen authored
commit 17d3069c upstream. This patch fixes the sai driver structure overwriting which results in a cpu dai name equal NULL. Fixes: 3e086edf ("ASoC: stm32: add SAI driver") Signed-off-by:
Arnaud Pouliquen <arnaud.pouliquen@st.com> Signed-off-by:
-
Charles Keepax authored
commit 639e5eb3 upstream. Previously support was added to allow streams to be stopped and started again without the DSP being power cycled and this was done by clearing the buffer state in trigger start. Another supported use-case is using the DSP for a trigger event then opening the compressed stream later to receive the audio, unfortunately clearing the buffer state in trigger start destroys the data received from such a trigger. Correct this issue by moving the call to wm_adsp_buffer_clear to be in trigger stop instead. Fixes: 61fc060c ("ASoC: wm_adsp: Support streams which can start/stop with DSP active") Signed-off-by:
-
Hans de Goede authored
commit aee48a9f upstream. Commit 37c7401e ("ASoC: Intel: bytcr_rt5651: Fix DMIC map headsetmic mapping"), changed the headsetmic mapping from IN3P to IN2P, this was based on the observation that all bytcr_rt5651 devices I have access to (7 devices) where all using IN3P for the headsetmic. This was an attempt to unifify / simplify the mapping, but it was wrong. None of those devices was actually using a digital internal mic. Now I've access to a Point of View TAB-P1006W-232 (v1.0) tabler, which does use a DMIC and it does have its headsetmic connected to IN2P, showing that the original mapping was correct, so this commit reverts the change changing the mapping back to IN2P. Fixes: 37c7401e ("ASoC: Intel: bytcr_rt5651: Fix DMIC map ... mapping") Acked-by:
-
Bart Van Assche authored
commit 40ca8757 upstream. Make sure that the next time a response is sent to the initiator that the credit it had allocated for the aborted request gets freed. Cc: Doug Ledford <dledford@redhat.com> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Nicholas Bellinger <nab@linux-iscsi.org> Cc: Mike Christie <mchristi@redhat.com> Cc: Hannes Reinecke <hare@suse.com> Cc: Christoph Hellwig <hch@lst.de> Fixes: 131e6abc ("target: Add TFO->abort_task for aborted task resources release") # v3.15 Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
-
Jeremy Fertic authored
commit 78accaea upstream. The lsb calculation is not masking the correct bits from the user input. Subtract 1 from (1 << offset) to correctly set up the mask to be applied to user input. The lsb register stores its value starting at the bit 7 position. adt7316_store_DAC() currently assumes the value is at the other end of the register. Shift the lsb value before storing it in a new variable lsb_reg, and write this variable to the lsb register. Fixes: 35f6b6b8 ("staging: iio: new ADT7316/7/8 and ADT7516/7/9 driver") Signed-off-by:
Jeremy Fertic <jeremyfertic@gmail.com> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
