- 10 Nov, 2019 36 commits
-
-
Josef Bacik authored
[ Upstream commit 7ce23e8e ] We hit the following warning in production print_req_error: I/O error, dev nbd0, sector 7213934408 flags 80700 ------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 25 PID: 32407 at lib/refcount.c:190 refcount_sub_and_test_checked+0x53/0x60 Workqueue: knbd-recv recv_work [nbd] RIP: 0010:refcount_sub_and_test_checked+0x53/0x60 Call Trace: blk_mq_free_request+0xb7/0xf0 blk_mq_complete_request+0x62/0xf0 recv_work+0x29/0xa1 [nbd] process_one_work+0x1f5/0x3f0 worker_thread+0x2d/0x3d0 ? rescuer_thread+0x340/0x340 kthread+0x111/0x130 ? kthread_create_on_node+0x60/0x60 ret_from_fork+0x1f/0x30 ---[ end trace b079c3c67f98bb7c ]--- This was preceded by us timing out everything and shutting down the sockets for the device. The problem is we had a request in the queue at the same time, so we completed the request twice. This can actually happen in a lot of cases, we fail to get a ref on our config, we only have one connection and just error out the command, etc. Fix this by checking cmd->status in nbd_read_stat. We only change this under the cmd->lock, so we are safe to check this here and see if we've already error'ed this command out, which would indicate that we've completed it as well. Reviewed-by:
Mike Christie <mchristi@redhat.com> Signed-off-by:
Josef Bacik <josef@toxicpanda.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Josef Bacik authored
[ Upstream commit de6346ec ] We already do this for the most part, except in timeout and clear_req. For the timeout case we take the lock after we grab a ref on the config, but that isn't really necessary because we're safe to touch the cmd at this point, so just move the order around. For the clear_req cause this is initiated by the user, so again is safe. Reviewed-by:
-
Dave Wysochanski authored
[ Upstream commit d46b0da7 ] There's a deadlock that is possible and can easily be seen with a test where multiple readers open/read/close of the same file and a disruption occurs causing reconnect. The deadlock is due a reader thread inside cifs_strict_readv calling down_read and obtaining lock_sem, and then after reconnect inside cifs_reopen_file calling down_read a second time. If in between the two down_read calls, a down_write comes from another process, deadlock occurs. CPU0 CPU1 ---- ---- cifs_strict_readv() down_read(&cifsi->lock_sem); _cifsFileInfo_put OR cifs_new_fileinfo down_write(&cifsi->lock_sem); cifs_reopen_file() down_read(&cifsi->lock_sem); Fix the above by changing all down_write(lock_sem) calls to down_write_trylock(lock_sem)/msleep() loop, which in turn makes the second down_read call benign since it will never block behind the writer while holding lock_sem. Signed-off-by:
Dave Wysochanski <dwysocha@redhat.com> Suggested-by:
Ronnie Sahlberg <lsahlber@redhat.com> Reviewed--by:
Pavel Shilovsky <pshilov@microsoft.com> Signed-off-by:
-
Alain Volmat authored
[ Upstream commit 348e46fb ] Remove the following warning: drivers/i2c/busses/i2c-stm32f7.c:315: warning: cannot understand function prototype: 'struct stm32f7_i2c_spec i2c_specs[] = Replace a comment starting with /** by simply /* to avoid having it interpreted as a kernel-doc comment. Fixes: aeb068c5 ("i2c: i2c-stm32f7: add driver") Signed-off-by:
Alain Volmat <alain.volmat@st.com> Reviewed-by:
Pierre-Yves MORDRET <pierre-yves.mordret@st.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Fabrice Gasnier authored
[ Upstream commit 6d6b0d0d ] When in slave mode, an arbitration loss (ARLO) may be detected before the slave had a chance to detect the stop condition (STOPF in ISR). This is seen when two master + slave adapters switch their roles. It provokes the i2c bus to be stuck, busy as SCL line is stretched. - the I2C_SLAVE_STOP event is never generated due to STOPF flag is set but don't generate an irq (race with ARLO irq, STOPIE is masked). STOPF flag remains set until next master xfer (e.g. when STOPIE irq get unmasked). In this case, completion is generated too early: immediately upon new transfer request (then it doesn't send all data). - Some data get stuck in TXDR register. As a consequence, the controller stretches the SCL line: the bus gets busy until a future master transfer triggers the bus busy / recovery mechanism (this can take time... and may never happen at all) So choice is to let the STOPF being detected by the slave isr handler, to properly handle this stop condition. E.g. don't mask IRQs in error handler, when the slave is running. Fixes: 60d609f3 ("i2c: i2c-stm32f7: Add slave support") Signed-off-by:
Fabrice Gasnier <fabrice.gasnier@st.com> Reviewed-by:
-
Fabrice Gasnier authored
[ Upstream commit 02e64276 ] The slave-interface documentation [1] states "the bus driver should transmit the first byte" upon I2C_SLAVE_READ_REQUESTED slave event: - 'val': backend returns first byte to be sent The driver currently ignores the 1st byte to send on this event. [1] https://www.kernel.org/doc/Documentation/i2c/slave-interface Fixes: 60d609f3 ("i2c: i2c-stm32f7: Add slave support") Signed-off-by:
-
Zenghui Yu authored
[ Upstream commit 84243125 ] On a system without Single VMOVP support (say GITS_TYPER.VMOVP == 0), we will map vPEs only on ITSs that will actually control interrupts for the given VM. And when moving a vPE, the VMOVP command will be issued only for those ITSs. But when issuing VMOVPs we seemed fail to present the exact ITSList to ITSs who are actually included in the synchronization operation. The its_list_map we're currently using includes all ITSs in the system, even though some of them don't have the corresponding vPE mapping at all. Introduce get_its_list() to get the per-VM its_list_map, to indicate which ITSs have vPE mappings for the given VM, and use this map as the expected ITSList when building VMOVP. This is hopefully a performance gain not to do some synchronization with those unsuspecting ITSs. And initialize the whole command descriptor to zero at beginning, since the seq_num and its_list should be RES0 when GITS_TYPER.VMOVP == 1. Signed-off-by:
Zenghui Yu <yuzenghui@huawei.com> Signed-off-by:
Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/1571802386-2680-1-git-send-email-yuzenghui@huawei.comSigned-off-by:
-
Jonas Gorski authored
[ Upstream commit e4f5cb1a ] The vectors span more than one byte, so mark them as arrays. Fixes the following build error when building when using GCC 8.3: In file included from ./include/linux/string.h:19, from ./include/linux/bitmap.h:9, from ./include/linux/cpumask.h:12, from ./arch/mips/include/asm/processor.h:15, from ./arch/mips/include/asm/thread_info.h:16, from ./include/linux/thread_info.h:38, from ./include/asm-generic/preempt.h:5, from ./arch/mips/include/generated/asm/preempt.h:1, from ./include/linux/preempt.h:81, from ./include/linux/spinlock.h:51, from ./include/linux/mmzone.h:8, from ./include/linux/bootmem.h:8, from arch/mips/bcm63xx/prom.c:10: arch/mips/bcm63xx/prom.c: In function 'prom_init': ./arch/mips/include/asm/string.h:162:11: error: '__builtin_memcpy' forming offset [2, 32] is out of the bounds [0, 1] of object 'bmips_smp_movevec' with type 'char' [-Werror=array-bounds] __ret = __builtin_memcpy((dst), (src), __len); \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/mips/bcm63xx/prom.c:97:3: note: in expansion of macro 'memcpy' memcpy((void *)0xa0000200, &bmips_smp_movevec, 0x20); ^~~~~~ In file included from arch/mips/bcm63xx/prom.c:14: ./arch/mips/include/asm/bmips.h:80:13: note: 'bmips_smp_movevec' declared here extern char bmips_smp_movevec; Fixes: 18a1eef9 ("MIPS: BMIPS: Introduce bmips.h") Signed-off-by:
Jonas Gorski <jonas.gorski@gmail.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Paul Burton <paulburton@kernel.org> Cc: linux-mips@vger.kernel.org Cc: Ralf Baechle <ralf@linux-mips.org> Cc: James Hogan <jhogan@kernel.org> Signed-off-by:
-
Navid Emamdoost authored
[ Upstream commit e13de8fe ] In unittest_data_add, a copy buffer is created via kmemdup. This buffer is leaked if of_fdt_unflatten_tree fails. The release for the unittest_data buffer is added. Fixes: b951f9dc ("Enabling OF selftest to run without machine's devicetree") Signed-off-by:
Navid Emamdoost <navid.emamdoost@gmail.com> Reviewed-by:
Frank Rowand <frowand.list@gmail.com> Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
afzal mohammed authored
[ Upstream commit 2ecb2879 ] r0-r3 & r12 registers are saved & restored, before & after svc respectively. Intention was to preserve those registers across thread to handler mode switch. On v7-M, hardware saves the register context upon exception in AAPCS complaint way. Restoring r0-r3 & r12 is done from stack location where hardware saves it, not from the location on stack where these registers were saved. To clarify, on stm32f429 discovery board: 1. before svc, sp - 0x90009ff8 2. r0-r3,r12 saved to 0x90009ff8 - 0x9000a00b 3. upon svc, h/w decrements sp by 32 & pushes registers onto stack 4. after svc, sp - 0x90009fd8 5. r0-r3,r12 restored from 0x90009fd8 - 0x90009feb Above means r0-r3,r12 is not restored from the location where they are saved, but since hardware pushes the registers onto stack, the registers are restored correctly. Note that during register saving to stack (step 2), it goes past 0x9000a000. And it seems, based on objdump, there are global symbols residing there, and it perhaps can cause issues on a non-XIP Kernel (on XIP, data section is setup later). Based on the analysis above, manually saving registers onto stack is at best no-op and at worst can cause data section corruption. Hence remove storing of registers onto stack before svc. Fixes: b70cd406 ("ARM: 8671/1: V7M: Preserve registers across switch from Thread to Handler mode") Signed-off-by:
afzal mohammed <afzal.mohd.ma@gmail.com> Acked-by:
Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Zhengjun Xing authored
[ Upstream commit 9fa8c9c6 ] In the format of synthetic events, the "gfp_t" is shown as "signed:1", but in fact the "gfp_t" is "unsigned", should be shown as "signed:0". The issue can be reproduced by the following commands: echo 'memlatency u64 lat; unsigned int order; gfp_t gfp_flags; int migratetype' > /sys/kernel/debug/tracing/synthetic_events cat /sys/kernel/debug/tracing/events/synthetic/memlatency/format name: memlatency ID: 2233 format: field:unsigned short common_type; offset:0; size:2; signed:0; field:unsigned char common_flags; offset:2; size:1; signed:0; field:unsigned char common_preempt_count; offset:3; size:1; signed:0; field:int common_pid; offset:4; size:4; signed:1; field:u64 lat; offset:8; size:8; signed:0; field:unsigned int order; offset:16; size:4; signed:0; field:gfp_t gfp_flags; offset:24; size:4; signed:1; field:int migratetype; offset:32; size:4; signed:1; print fmt: "lat=%llu, order=%u, gfp_flags=%x, migratetype=%d", REC->lat, REC->order, REC->gfp_flags, REC->migratetype Link: http://lkml.kernel.org/r/20191018012034.6404-1-zhengjun.xing@linux.intel.comReviewed-by:
Tom Zanussi <tom.zanussi@linux.intel.com> Signed-off-by:
Zhengjun Xing <zhengjun.xing@linux.intel.com> Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
-
Bodo Stroesser authored
[ Upstream commit 27e84243 ] passthrough_parse_cdb() - used by TCMU and PSCSI - attepts to reset the LUN field of SCSI-2 CDBs (bits 5,6,7 of byte 1). The current code is wrong as for newer commands not having the LUN field it overwrites relevant command bits (e.g. for SECURITY PROTOCOL IN / OUT). We think this code was unnecessary from the beginning or at least it is no longer useful. So we remove it entirely. Link: https://lore.kernel.org/r/12498eab-76fd-eaad-1316-c2827badb76a@ts.fujitsu.comSigned-off-by:
Bodo Stroesser <bstroesser@ts.fujitsu.com> Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Reviewed-by:
Hannes Reinecke <hare@suse.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Christian König authored
[ Upstream commit 3122051e ] When we allocate new page tables under memory pressure we should not evict old ones. Signed-off-by:
Christian König <christian.koenig@amd.com> Acked-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Peter Ujfalusi authored
[ Upstream commit 564b6bb9 ] dm365 have only single McBSP, so the device name is without .0 Fixes: 0c750e1f ("ARM: davinci: dm365: Add dma_slave_map to edma") Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by:
Sekhar Nori <nsekhar@ti.com> Signed-off-by:
-
Yunfeng Ye authored
[ Upstream commit 1abecfca ] The memory @orig_flags is allocated by strdup(), it is freed on the normal path, but leak to free on the error path. Fix this by adding free(orig_flags) on the error path. Fixes: 0e111156 ("perf kmem: Print gfp flags in human readable string") Signed-off-by:
Yunfeng Ye <yeyunfeng@huawei.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Feilong Lin <linfeilong@huawei.com> Cc: Hu Shiyuan <hushiyuan@huawei.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lore.kernel.org/lkml/f9e9f458-96f3-4a97-a1d5-9feec2420e07@huawei.comSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Colin Ian King authored
[ Upstream commit f50b6805 ] The current checking for failure on the number of ports fails when -ENODEV is returned from the call to get_num_ports. Fix this by making num_ports and loop counter i signed rather than unsigned ints. Also add check for num_ports being less than zero to check for -ve error returns. Addresses-Coverity: ("Unsigned compared against 0") Fixes: e2fea54e ("8250-men-mcb: add support for 16z025 and 16z057") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Reviewed-by:
Michael Moese <mmoese@suse.de> Link: https://lore.kernel.org/r/20191013220016.9369-1-colin.king@canonical.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Yunfeng Ye authored
[ Upstream commit ae199c58 ] There is a memory leak problem in the failure paths of build_cl_output(), so fix it. Signed-off-by:
Jiri Olsa <jolsa@kernel.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Feilong Lin <linfeilong@huawei.com> Cc: Hu Shiyuan <hushiyuan@huawei.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lore.kernel.org/lkml/4d3c0178-5482-c313-98e1-f82090d2d456@huawei.comSigned-off-by:
-
Anson Huang authored
[ Upstream commit 252b9e21 ] i.MX7S/D's GPT ipg clock should be from GPT clock root and controlled by CCM's GPT CCGR, using correct clock source for GPT ipg clock instead of IMX7D_CLK_DUMMY. Fixes: 3ef79ca6 ("ARM: dts: imx7d: use imx7s.dtsi as base device tree") Signed-off-by:
Anson Huang <Anson.Huang@nxp.com> Signed-off-by:
Shawn Guo <shawnguo@kernel.org> Signed-off-by:
-
Thomas Bogendoerfer authored
[ Upstream commit 8cbf0c17 ] When building a kernel with SCSI_SNI_53C710 enabled, Kconfig warns: WARNING: unmet direct dependencies detected for 53C700_LE_ON_BE Depends on [n]: SCSI_LOWLEVEL [=y] && SCSI [=y] && SCSI_LASI700 [=n] Selected by [y]: - SCSI_SNI_53C710 [=y] && SCSI_LOWLEVEL [=y] && SNI_RM [=y] && SCSI [=y] Add the missing depends SCSI_SNI_53C710 to 53C700_LE_ON_BE to fix it. Link: https://lore.kernel.org/r/20191009151128.32411-1-tbogendoerfer@suse.deSigned-off-by:
Thomas Bogendoerfer <tbogendoerfer@suse.de> Signed-off-by:
-
Thomas Bogendoerfer authored
[ Upstream commit 0ee62114 ] Drop out memory dev_printk() with wrong device pointer argument. [mkp: typo] Link: https://lore.kernel.org/r/20191009151118.32350-1-tbogendoerfer@suse.deSigned-off-by:
-
Hannes Reinecke authored
[ Upstream commit b6ce6fb1 ] Some arrays are not capable of returning RTPG data during state transitioning, but rather return an 'LUN not accessible, asymmetric access state transition' sense code. In these cases we can set the state to 'transitioning' directly and don't need to evaluate the RTPG data (which we won't have anyway). Link: https://lore.kernel.org/r/20191007135701.32389-1-hare@suse.deReviewed-by:
Laurence Oberman <loberman@redhat.com> Reviewed-by:
Ewan D. Milne <emilne@redhat.com> Reviewed-by:
-
Allen Pais authored
[ Upstream commit 35a79a63 ] alloc_workqueue is not checked for errors and as a result a potential NULL dereference could occur. Link: https://lore.kernel.org/r/1568824618-4366-1-git-send-email-allen.pais@oracle.comSigned-off-by:
Allen Pais <allen.pais@oracle.com> Reviewed-by:
Martin Wilck <mwilck@suse.com> Acked-by:
Himanshu Madhani <hmadhani@marvell.com> Signed-off-by:
-
Russell King authored
[ Upstream commit 67e15fa5 ] When the system has high memory pressure, the page containing the instruction may be paged out. Using probe_kernel_address() means that if the page is swapped out, the resulting page fault will not be handled because page faults are disabled by this function. Use get_user() to read the instruction instead. Reported-by:
Jing Xiangfeng <jingxiangfeng@huawei.com> Fixes: b255188f ("ARM: fix scheduling while atomic warning in alignment handling code") Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit 39b65fbb ] The pinctrl->functions[] array has pinctrl->num_functions elements and the pinctrl->groups[] array is the same way. These are set in ns2_pinmux_probe(). So the > comparisons should be >= so that we don't read one element beyond the end of the array. Fixes: b5aa1006 ("pinctrl: ns2: add pinmux driver support for Broadcom NS2 SoC") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20190926081426.GB2332@mwandaAcked-by:
Scott Branden <scott.branden@broadcom.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Adam Ford authored
[ Upstream commit 6b512b0e ] The TWL4030 used on the Logit PD Torpedo SOM does not have the keypad pins routed. This patch disables the twl_keypad driver to remove some splat during boot: twl4030_keypad 48070000.i2c:twl@48:keypad: missing or malformed property linux,keymap: -22 twl4030_keypad 48070000.i2c:twl@48:keypad: Failed to build keymap twl4030_keypad: probe of 48070000.i2c:twl@48:keypad failed with error -22 Signed-off-by:
Adam Ford <aford173@gmail.com> [tony@atomide.com: removed error time stamps] Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Robin Murphy authored
[ Upstream commit b1e620e7 ] If rockchip_pcm_platform_register() fails, e.g. upon deferring to wait for an absent DMA channel, we return without disabling RPM, which makes subsequent re-probe attempts scream with errors about the unbalanced enable. Don't do that. Fixes: ebb75c0b ("ASoC: rockchip: i2s: Adjust devm usage") Signed-off-by:
Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/bcb12a849a05437fb18372bc7536c649b94bdf07.1570029862.git.robin.murphy@arm.comSigned-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Stuart Henderson authored
[ Upstream commit 3ae7359c ] User space always expects to be able to read ALSA controls, so ensure no kcontrols are generated without an appropriate READ flag. In the case of a read of such a control zeros will be returned. Signed-off-by:
Stuart Henderson <stuarth@opensource.cirrus.com> Signed-off-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20191002084240.21589-1-ckeepax@opensource.cirrus.comSigned-off-by:
-
Yizhuo authored
[ Upstream commit 1252b283 ] In function pfuze100_regulator_probe(), variable "val" could be initialized if regmap_read() fails. However, "val" is used to decide the control flow later in the if statement, which is potentially unsafe. Signed-off-by:
Yizhuo <yzhai003@ucr.edu> Link: https://lore.kernel.org/r/20190929170957.14775-1-yzhai003@ucr.eduSigned-off-by:
-
Jaska Uimonen authored
[ Upstream commit a315e76f ] Implement NULL handler in set_jack function to disable irq's. Signed-off-by:
Jaska Uimonen <jaska.uimonen@intel.com> Signed-off-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20190927201408.925-4-pierre-louis.bossart@linux.intel.comSigned-off-by:
-
Axel Lin authored
[ Upstream commit f64db548 ] ti_abb_wait_txdone() may return -ETIMEDOUT when ti_abb_check_txdone() returns true in the latest iteration of the while loop because the timeout value is abb->settling_time + 1. Similarly, ti_abb_clear_all_txdone() may return -ETIMEDOUT when ti_abb_check_txdone() returns false in the latest iteration of the while loop. Fix it. Signed-off-by:
Axel Lin <axel.lin@ingics.com> Acked-by:
Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20190929095848.21960-1-axel.lin@ingics.comSigned-off-by:
-
Rayagonda Kokatanur authored
[ Upstream commit 965f6603 ] There are total of 151 non-secure gpio (0-150) and four pins of pinmux (91, 92, 93 and 94) are not mapped to any gpio pin, hence update same in DT. Fixes: 8aa428cc ("arm64: dts: Add pinctrl DT nodes for Stingray SOC") Signed-off-by:
Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> Reviewed-by:
Ray Jui <ray.jui@broadcom.com> Signed-off-by:
-
Jernej Skrabec authored
[ Upstream commit ccdf3aaa ] It turns out that sopine-baseboard needs same fix as pine64-plus for ethernet PHY. Here too Realtek ethernet PHY chip needs additional power on delay to properly initialize. Datasheet mentions that chip needs 30 ms to be properly powered on and that it needs some more time to be initialized. Fix that by adding 100ms ramp delay to regulator responsible for powering PHY. Note that issue was found out and fix tested on pine64-lts, but it's basically the same as sopine-baseboard, only layout and connectors differ. Fixes: bdfe4ceb ("arm64: allwinner: a64: add Ethernet PHY regulator for several boards") Signed-off-by:
Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by:
Maxime Ripard <mripard@kernel.org> Signed-off-by:
-
Jernej Skrabec authored
[ Upstream commit 25113667 ] Depending on kernel and bootloader configuration, it's possible that Realtek ethernet PHY isn't powered on properly. According to the datasheet, it needs 30ms to power up and then some more time before it can be used. Fix that by adding 100ms ramp delay to regulator responsible for powering PHY. Fixes: 94dcfdc7 ("arm64: allwinner: pine64-plus: Enable dwmac-sun8i") Suggested-by:
Ondrej Jirman <megous@megous.com> Signed-off-by:
-
Sylwester Nawrocki authored
[ Upstream commit ca234719 ] In case of WM1811 device there are currently being registered controls referring to registers not existing on that device. It has been noticed when getting values of "AIF1ADC2 Volume", "AIF1DAC2 Volume" controls was failing during ALSA state restoring at boot time: "amixer: Mixer hw:0 load error: Device or resource busy" Reading some registers through I2C was failing with EBUSY error and indeed these registers were not available according to the datasheet. To fix this controls not available on WM1811 are moved to a separate array and registered only for WM8994 and WM8958. There are some further differences between WM8994 and WM1811, e.g. registers 603h, 604h, 605h, which are not covered in this patch. Acked-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Link: https://lore.kernel.org/r/20190920130218.32690-2-s.nawrocki@samsung.comSigned-off-by:
-
Marco Felsch authored
[ Upstream commit 131cb121 ] Currently the regulator-suspend-min/max-microvolt must be within the root regulator node but the dt-bindings specifies it as subnode properties for the regulator-state-[mem/disk/standby] node. The only DT using this bindings currently is the at91-sama5d2_xplained.dts and this DT uses it correctly. I don't know if it isn't tested but it can't work without this fix. Fixes: f7efad10 ("regulator: add PM suspend and resume hooks") Signed-off-by:
Marco Felsch <m.felsch@pengutronix.de> Link: https://lore.kernel.org/r/20190917154021.14693-3-m.felsch@pengutronix.deSigned-off-by:
-
Seth Forshee authored
[ Upstream commit 29be86d7 ] The gcc -fcf-protection=branch option is not compatible with -mindirect-branch=thunk-extern. The latter is used when CONFIG_RETPOLINE is selected, and this will fail to build with a gcc which has -fcf-protection=branch enabled by default. Adding -fcf-protection=none when building with retpoline enabled prevents such build failures. Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
-
- 06 Nov, 2019 4 commits
-
-
Greg Kroah-Hartman authored
-
Takashi Iwai authored
[ Upstream commit 1a7f60b9 ] This reverts commit caa8422d. It turned out that this commit caused a regression at shutdown / reboot, as the synchronize_irq() calls seems blocking the whole shutdown. Also another part of the change about shuffling the call order looks suspicious; the azx_stop_chip() call disables the CORB / RIRB while the others may still need the CORB/RIRB update. Since the original commit itself was a cargo-fix, let's revert the whole patch. Fixes: caa8422d ("ALSA: hda: Flush interrupts on disabling") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205333 BugLinK: https://bugs.freedesktop.org/show_bug.cgi?id=111174Signed-off-by:
Takashi Iwai <tiwai@suse.de> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: https://lore.kernel.org/r/20191028081056.22010-1-tiwai@suse.deSigned-off-by:
-
Nicholas Piggin authored
[ Upstream commit 7d647505 ] Commit e78a7614 ("idle: Prevent late-arriving interrupts from disrupting offline") changes arch_cpu_idle_dead to be called with interrupts disabled, which triggers the WARN in pnv_smp_cpu_kill_self. Fix this by fixing up irq_happened after hard disabling, rather than requiring there are no pending interrupts, similarly to what was done done until commit 2525db04 ("powerpc/powernv: Simplify lazy IRQ handling in CPU offline"). Fixes: e78a7614 ("idle: Prevent late-arriving interrupts from disrupting offline") Reported-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
Nicholas Piggin <npiggin@gmail.com> [mpe: Add unexpected_mask rather than checking for known bad values, change the WARN_ON() to a WARN_ON_ONCE()] Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20191022115814.22456-1-npiggin@gmail.comSigned-off-by:
-
Justin Song authored
[ Upstream commit e2995b95 ] This patch adds native DSD support for Gustard U16/X26 USB Interface. Tested using VID and fp->dsd_raw method. Signed-off-by:
Justin Song <flyingecar@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/CA+9XP1ipsFn+r3bCBKRinQv-JrJ+EHOGBdZWZoMwxFv0R8Y1MQ@mail.gmail.comSigned-off-by:
-
