- 10 Dec, 2017 30 commits
-
-
Edward A. James authored
[ Upstream commit 6dcf2fb5 ] The pmbus core may call read/write word data functions with a page value of -1, intending to perform the operation without setting the page. However, the read/write word data functions accept only unsigned 8-bit page numbers, and therefore cannot check for negative page number to avoid setting the page. This results in setting the page number to 0xFF. This may result in errors or undefined behavior of some devices (specifically the ir35221, which allows the page to be set to 0xFF, but some subsequent operations to read registers may fail). Switch the pmbus_set_page page parameter to an integer and perform the check for negative page there. Make read/write functions consistent in accepting an integer page number parameter. Signed-off-by:
Edward A. James <eajames@us.ibm.com> Fixes: cbcdec62 ("hwmon: (pmbus): Access word data for STATUS_WORD") Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Sasha Levin <alexander.levin@verizon.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Subhash Jadavani authored
[ Upstream commit c7ccee22 ] SDCC controller reset (SW_RST) during probe may trigger power irq if previous status of PWRCTL was either BUS_ON or IO_HIGH_V. So before we enable the power irq interrupt in GIC (by registering the interrupt handler), we need to ensure that any pending power irq interrupt status is acknowledged otherwise power irq interrupt handler would be fired prematurely. Signed-off-by:
Subhash Jadavani <subhashj@codeaurora.org> Signed-off-by:
Vijay Viswanath <vviswana@codeaurora.org> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Fabrizio Castro authored
[ Upstream commit a3d95d1d ] mmc_regulator_get_supply returns -EPROBE_DEFER if either vmmc or vqmmc regulators had their probing deferred. vqmmc regulator is needed by UHS to work properly, therefore this patch checks the value returned by mmc_regulator_get_supply to make sure we have a reference to both vmmc and vqmmc (if found in the DT). Signed-off-by:
Fabrizio Castro <fabrizio.castro@bp.renesas.com> Reviewed-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by:
-
Johan Hovold authored
[ Upstream commit 4d5e0689 ] Take an extra reference to the controller before deregistering it to prevent use-after-free in the interrupt handler in case an interrupt fires before the line is disabled. Fixes: b1353d1c ("spi: Add Analog Devices AXI SPI Engine controller support") Acked-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Hiromitsu Yamasaki authored
[ Upstream commit 36735783 ] DMA supports 32-bit words only, even if BITLEN1 of SITMDR2 register is 16bit. Fixes: b0d0ce8b ("spi: sh-msiof: Add DMA support") Signed-off-by:
Hiromitsu Yamasaki <hiromitsu.yamasaki.ym@renesas.com> Signed-off-by:
Simon Horman <horms+renesas@verge.net.au> Acked-by:
Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
Dirk Behme <dirk.behme@de.bosch.com> Signed-off-by:
-
Colin Ian King authored
[ Upstream commit 123c0aab ] There is a check on pmlmepriv before dereferencing it when vfree'ing pmlmepriv->free_bss_buf however the previous call to rtw_free_mlme_priv_ie_data deferences pmlmepriv causing a null pointer deference if it is null. Avoid this by also calling rtw_free_mlme_priv_ie_data if the pointer is non-null. Detected by CoverityScan, CID#1230262 ("Dereference before null check") Fixes: 7b464c9f ("staging: r8188eu: Add files for new driver - part 4") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Stanislaw Gruszka authored
[ Upstream commit c40a45a4 ] Patch fixes splat: r8822be 0000:04:00.0: DMA-API: device driver frees DMA memory with different size [device address=0x0000000078477000] [map size=4096 bytes] [unmap size=424 bytes] <snip> Call Trace: debug_dma_unmap_page+0xa5/0xb0 ? unmap_single+0x2f/0x40 _rtl8822be_send_bcn_or_cmd_packet+0x2c5/0x300 [r8822be] ? _rtl8822be_send_bcn_or_cmd_packet+0x2c5/0x300 [r8822be] rtl8822b_halmac_cb_write_data_rsvd_page+0x51/0xc0 [r8822be] _halmac_write_data_rsvd_page+0x22/0x30 [r8822be] halmac_download_rsvd_page_88xx+0xee/0x1f0 [r8822be] halmac_dlfw_to_mem_88xx+0x80/0x120 [r8822be] halmac_download_firmware_88xx.part.47+0x477/0x600 [r8822be] halmac_download_firmware_88xx+0x32/0x40 [r8822be] rtl_halmac_dlfw+0x70/0x120 [r8822be] rtl_halmac_init_hal+0x5f/0x1b0 [r8822be] rtl8822be_hw_init+0x8a2/0x1040 [r8822be] Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Acked-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Lukas Wunner authored
[ Upstream commit 3236a965 ] This driver's ->rs485_config callback checks if SER_RS485_RTS_ON_SEND and SER_RS485_RTS_AFTER_SEND have the same value. If they do, it means the user has passed in invalid data with the TIOCSRS485 ioctl() since RTS must have a different polarity when sending and when not sending. In this case, rs485 mode is not enabled (the RS485_URA bit is not set in the RS485 Enable Register) and this is supposed to be signaled back to the user by clearing the SER_RS485_ENABLED bit in struct serial_rs485 ... except a missing tilde character is preventing that from happening. Fixes: 28e3fb6c ("serial: Add support for Fintek F81216A LPC to 4 UART") Cc: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Cc: "Ji-Ze Hong (Peter Hong)" <hpeter@gmail.com> Signed-off-by:
Lukas Wunner <lukas@wunner.de> Signed-off-by:
-
Greg Ungerer authored
[ Upstream commit f55ab8f2 ] The m68k pg_data_table is a fix size array defined in arch/m68k/mm/init.c. Index numbers within it are defined based on memory size. But for Coldfire these don't take into account a non-zero physical RAM base address, and this causes us to access past the end of this array at system start time. Change the node shift calculation so that we keep the index inside its range. Reported-by:
Angelo Dureghello <angelo@sysam.it> Tested-by:
Greg Ungerer <gerg@linux-m68k.org> Signed-off-by:
-
Bryan O'Donoghue authored
[ Upstream commit 44b02da3 ] Commit 12927835 ("greybus: loopback: Add asynchronous bi-directional support") does what it says on the tin - namely, adds support for asynchronous bi-directional loopback operations. What it neglects to do though is increment the per-connection gb->iteration_count on an asynchronous operation error. This patch fixes that omission. Fixes: 12927835 ("greybus: loopback: Add asynchronous bi-directional support") Signed-off-by:
Bryan O'Donoghue <pure.logic@nexus-software.ie> Reported-by:
Mitch Tasman <tasman@leaflabs.com> Reviewed-by:
-
Andy Lutomirski authored
[ Upstream commit d60ad744 ] Bits 19:16 of LAR's result are undefined, and some upcoming improvements to the test case seem to trigger this. Mask off those bits to avoid spurious failures. commit 5b781c7e ("x86/tls: Forcibly set the accessed bit in TLS segments") adds a valid case in which LAR's output doesn't quite agree with set_thread_area()'s input. This isn't triggered in the test as is, but it will be if we start calling set_thread_area() with the accessed bit clear. Work around this discrepency. I've added a Fixes tag so that -stable can pick this up if neccesary. Signed-off-by:
Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bpetkov@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: 5b781c7e ("x86/tls: Forcibly set the accessed bit in TLS segments") Link: http://lkml.kernel.org/r/b82f3f89c034b53580970ac865139fd8863f44e2.1509794321.git.luto@kernel.orgSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Andy Lutomirski authored
[ Upstream commit fec8f5ae ] We weren't testing the .limit and .limit_in_pages fields very well. Add more tests. This addition seems to trigger the "bits 16:19 are undefined" issue that was fixed in an earlier patch. I think that, at least on my CPU, the high nibble of the limit ends in LAR bits 16:19. Signed-off-by:
-
Christian Borntraeger authored
[ Upstream commit 48070c73 ] As of today QEMU does not provide the AIS facility to its guest. This prevents Linux guests from using PCI devices as the ais facility is checked during init. As this is just a performance optimization, we can move the ais check into the code where we need it (calling the SIC instruction). This is used at initialization and on interrupt. Both places do not require any serialization, so we can simply skip the instruction. Since we will now get all interrupts, we can also avoid the 2nd scan. As we can have multiple interrupts in parallel we might trigger spurious irqs more often for the non-AIS case but the core code can handle that. Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by:
Pierre Morel <pmorel@linux.vnet.ibm.com> Reviewed-by:
Halil Pasic <pasic@linux.vnet.ibm.com> Acked-by:
Sebastian Ott <sebott@linux.vnet.ibm.com> Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
-
Ulf Hansson authored
[ Upstream commit 5241ab40 ] During system-wide PM, genpd relies on its PM callbacks to be invoked for all its attached devices, as to deal with powering off/on the PM domain. In other words, genpd is not compatible with the direct_complete path, if executed by the PM core for any of its attached devices. However, when genpd's ->prepare() callback invokes pm_generic_prepare(), it does not take into account that it may return 1. Instead it treats that as an error internally and expects the PM core to abort the prepare phase and roll back. This leads to genpd not properly powering on/off the PM domain, because its internal counters gets wrongly balanced. To fix the behaviour, allow drivers to return 1 from their ->prepare() callbacks, but let's return 0 from genpd's ->prepare() callback in such case, as that prevents the PM core from running the direct_complete path for the device. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Jason J. Herne authored
[ Upstream commit 408358b5 ] Because we do not make use of the cda (channel data address) for test, no-op ccws no address translation takes place. This means cda could contain a guest address which we do not want to attempt to free. Let's check the command type and skip cda free when it is not needed. For a TIC ccw, ccw->cda points to either a ccw in an existing chain or it points to a whole new allocated chain. In either case the data will be freed when the owning chain is freed. Signed-off-by:
Jason J. Herne <jjherne@linux.vnet.ibm.com> Reviewed-by:
Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Reviewed-by:
Cornelia Huck <cohuck@redhat.com> Signed-off-by:
-
Boshi Wang authored
[ Upstream commit ebe7c0a7 ] The hash_setup function always sets the hash_setup_done flag, even when the hash algorithm is invalid. This prevents the default hash algorithm defined as CONFIG_IMA_DEFAULT_HASH from being used. This patch sets hash_setup_done flag only for valid hash algorithms. Fixes: e7a2ad7e "ima: enable support for larger default filedata hash algorithms" Signed-off-by:
Boshi Wang <wangboshi@huawei.com> Signed-off-by:
Mimi Zohar <zohar@linux.vnet.ibm.com> Signed-off-by:
-
Matt Redfearn authored
commit c8ec2041 upstream. Add a custom serial.h header for MIPS, allowing platforms to override the asm-generic version if required. The generic platform uses this header to set BASE_BAUD to 0. The generic platform supports multiple boards, which may have different UART clocks. Also one of the boards supported is the Boston FPGA board, where the UART clock depends on the loaded FPGA bitfile. As such there is no way that the generic kernel can set a compile time default BASE_BAUD. Commit 31cb9a85 ("earlycon: initialise baud field of earlycon device structure") changed the behavior of of_setup_earlycon such that any baud rate set in the device tree is now set in the earlycon structure. The UART driver will then calculate a divisor based on BASE_BAUD and set it. With MIPS generic kernels this resulted in garbage output due to the incorrect uart clock rate being used to calculate a divisor. This commit, combined with "serial: 8250_early: Only set divisor if valid clk & baud" prevents the earlycon code setting a bad divisor and restores earlycon output. Fixes: 31cb9a85 ("earlycon: initialise baud field of earlycon device structure") Signed-off-by:
Matt Redfearn <matt.redfearn@mips.com> Signed-off-by:
-
Matt Redfearn authored
commit 0ff3ab70 upstream. If either uartclk or baud are 0, avoid calculating and setting a divisor based on them since the output will almost certainly be garbage. This also allows platforms such as the MIPS generic kernel, which has no way to know a valid BASE_BASE for the board it is actually booted on at compile time, to set BASE_BAUD to 0 and avoid early_8250 setting a bad divisor. This fixes a regression caused by commit 31cb9a85 ("earlycon: initialise baud field of earlycon device structure"), which changed the behavior of of_setup_earlycon such that it sets a baud rate in the earlycon structure where previously it was left as 0. All boards supported by the MIPS generic kernel started outputting garbage from the boot console due to an incorrect divisor being set. Fixes: 31cb9a85 ("earlycon: initialise baud field of earlycon device structure") Signed-off-by:
-
Lu Baolu authored
commit 762ff467 upstream. USB vendor id and product id for Linux USB Debug Target is added. Signed-off-by:
Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by:
-
Sebastian Sjoholm authored
commit c654b21e upstream. Quectel BG96 is an Qualcomm MDM9206 based IoT modem, supporting both CAT-M and NB-IoT. Tested hardware is BG96 mounted on Quectel development board (EVB). The USB id is added to option.c to allow DIAG,GPS,AT and modem communication with the BG96. Signed-off-by:
Sebastian Sjoholm <ssjoholm@mac.com> Signed-off-by:
-
Martijn Coenen authored
commit fb2c4452 upstream. If a call to put_user() fails, we failed to properly free a transaction and send a failed reply (if necessary). Signed-off-by:
Martijn Coenen <maco@android.com> Signed-off-by:
-
Matt Wilson authored
commit 3bfd1300 upstream. This device will be used in future Amazon EC2 instances as the primary serial port (i.e., data sent to this port will be available via the GetConsoleOuput [1] EC2 API). [1] http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_GetConsoleOutput.htmlSigned-off-by:
Matt Wilson <msw@amazon.com> Signed-off-by:
-
Kai-Heng Feng authored
commit e43a12f1 upstream. KY-688 USB 3.1 Type-C Hub internally uses a Genesys Logic hub to connect to Realtek r8153. Similar to commit ("7496cfe5 usb: quirks: Add no-lpm quirk for Moshi USB to Ethernet Adapter"), no-lpm can make r8153 ethernet work. Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by:
-
Hans de Goede authored
commit 7fee72d5 upstream. We've been adding this as a quirk on a per device basis hoping that newer disk enclosures would do better, but that has not happened, so simply apply this quirk to all Seagate devices. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Yuyang Du authored
commit 770b2ede upstream. The previous USB3 SuperSpeed enabling patches mistakenly enabled URB scatter-gather chaining, which is actually not supported by the VHCI HCD. This patch fixes that. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=197867 Fixes: 03cd00d5 ("usbip: vhci-hcd: Set the vhci structure up to work") Reported-by:
Juan Zea <juan.zea@qindel.com> Signed-off-by:
Yuyang Du <yuyang.du@intel.com> Acked-by:
Shuah Khan <shuahkh@osg.samsung.com> Signed-off-by:
-
Shuah Khan authored
commit 1ac7c8a7 upstream. usbip attach fails to find a free port when the device on the first port is a USB_SPEED_SUPER device and non-super speed device is being attached. It keeps checking the first port and returns without a match getting stuck in a loop. Fix it check to find the first port with matching speed. Reported-by:
-
Heiko Carstens authored
commit 8d9047f8 upstream. Free data structures required for runtime instrumentation from arch_release_task_struct(). This allows to simplify the code a bit, and also makes the semantics a bit easier: arch_release_task_struct() is never called from the task that is being removed. In addition this allows to get rid of exit_thread() in a later patch. Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Ben Hutchings <ben.hutchings@codethink.co.uk> Signed-off-by:
-
Michel Dänzer authored
commit fa7c7939 upstream. This matches the corresponding UAPI fields. Treating the ring index as signed could result in accessing random unrelated memory if the MSB was set. Fixes: effd924d ("drm/amdgpu: untie user ring ids from kernel ring ids v6") Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
-
Stefan Agner authored
commit 9fd99f4f upstream. The resume helpers wait for a vblank to occurre hence IRQ need to be enabled. This avoids a warning as follows during resume: WARNING: CPU: 0 PID: 314 at drivers/gpu/drm/drm_atomic_helper.c:1249 drm_atomic_helper_wait_for_vblanks.part.1+0x284/0x288 [CRTC:28:crtc-0] vblank wait timed out Signed-off-by:
Stefan Agner <stefan@agner.ch> Signed-off-by:
-
Stefan Agner authored
commit 9306e996 upstream. With commit 0a70c998 ("drm/fsl-dcu: enable pixel clock when enabling CRTC") the pixel clock is controlled by the CRTC code. Disabling the pixel clock in suspend leads to a warning due to the second clk_disable_unprepare call: WARNING: CPU: 0 PID: 359 at drivers/clk/clk.c:594 clk_core_disable+0x8c/0x90 Remove clk_disable_unprepare call for pixel clock to avoid unbalanced clock disable on suspend. Fixes: 0a70c998 ("drm/fsl-dcu: enable pixel clock when enabling CRTC") Signed-off-by:
-
- 05 Dec, 2017 10 commits
-
-
Greg Kroah-Hartman authored
-
Greg Kroah-Hartman authored
This reverts commit f9a64e23 which is commit 0d794d0d upstream. Andy writes: I think the thing to do is to revert the patch from -stable. The bug it fixes is very minor, and the regression is that it made a pre-existing bug in some nearly-undebuggable core resume code much easier to hit. I don't feel comfortable with a backport of the latter fix until it has a good long soak in Linus' tree. Reported-by:
-
Ville Syrjälä authored
commit 56350fb8 upstream. The hardware always writes one or two bytes in the index portion of an indexed transfer. Make sure the message we send as the index doesn't have a zero length. Cc: Daniel Kurtz <djkurtz@chromium.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sean Paul <seanpaul@chromium.org> Fixes: 56f9eac0 ("drm/i915/intel_i2c: use INDEX cycles for i2c read transactions") Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171123194157.25367-3-ville.syrjala@linux.intel.comReviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> (cherry picked from commit bb9e0d4b) Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
commit ae5c631e upstream. We can only specify the one slave address to indexed reads/writes. Make sure the messages we check are destined to the same slave address before deciding to do an indexed transfer. Cc: Daniel Kurtz <djkurtz@chromium.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sean Paul <seanpaul@chromium.org> Fixes: 56f9eac0 ("drm/i915/intel_i2c: use INDEX cycles for i2c read transactions") Signed-off-by:
-
Xiong Zhang authored
commit b721b65a upstream. For ADDR_4K_MASK, bit[45..12] should be 1, all other bits should be 0. The current definition wrongly set bit[46] as 1 also. This path fixes this. v2: Add commit message, fixes and cc stable.(Zhenyu) Fixes: 2707e444("drm/i915/gvt: vGPU graphics memory virtualization") Signed-off-by:
Xiong Zhang <xiong.y.zhang@intel.com> Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
-
Chris Wilson authored
commit a45b30a6 upstream. As both the hotplug event and fbdev configuration run asynchronously, it is possible for them to run concurrently. If configuration fails, we were freeing the fbdev causing a use-after-free in the hotplug event. <7>[ 3069.935211] [drm:intel_fb_initial_config [i915]] Not using firmware configuration <7>[ 3069.935225] [drm:drm_setup_crtcs] looking for cmdline mode on connector 77 <7>[ 3069.935229] [drm:drm_setup_crtcs] looking for preferred mode on connector 77 0 <7>[ 3069.935233] [drm:drm_setup_crtcs] found mode 3200x1800 <7>[ 3069.935236] [drm:drm_setup_crtcs] picking CRTCs for 8192x8192 config <7>[ 3069.935253] [drm:drm_setup_crtcs] desired mode 3200x1800 set on crtc 43 (0,0) <7>[ 3069.935323] [drm:intelfb_create [i915]] no BIOS fb, allocating a new one <4>[ 3069.967737] general protection fault: 0000 [#1] PREEMPT SMP <0>[ 3069.977453] --------------------------------- <4>[ 3069.977457] Modules linked in: i915(+) vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm r8169 mei_me mii prime_numbers mei i2c_hid pinctrl_geminilake pinctrl_intel [last unloaded: i915] <4>[ 3069.977492] CPU: 1 PID: 15414 Comm: kworker/1:0 Tainted: G U 4.14.0-CI-CI_DRM_3388+ #1 <4>[ 3069.977497] Hardware name: Intel Corp. Geminilake/GLK RVP1 DDR4 (05), BIOS GELKRVPA.X64.0062.B30.1708222146 08/22/2017 <4>[ 3069.977508] Workqueue: events output_poll_execute <4>[ 3069.977512] task: ffff880177734e40 task.stack: ffffc90001fe4000 <4>[ 3069.977519] RIP: 0010:__lock_acquire+0x109/0x1b60 <4>[ 3069.977523] RSP: 0018:ffffc90001fe7bb0 EFLAGS: 00010002 <4>[ 3069.977526] RAX: 6b6b6b6b6b6b6b6b RBX: 0000000000000282 RCX: 0000000000000000 <4>[ 3069.977530] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880170d4efd0 <4>[ 3069.977534] RBP: ffffc90001fe7c70 R08: 0000000000000001 R09: 0000000000000000 <4>[ 3069.977538] R10: 0000000000000000 R11: ffffffff81899609 R12: ffff880170d4efd0 <4>[ 3069.977542] R13: ffff880177734e40 R14: 0000000000000001 R15: 0000000000000000 <4>[ 3069.977547] FS: 0000000000000000(0000) GS:ffff88017fc80000(0000) knlGS:0000000000000000 <4>[ 3069.977551] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 3069.977555] CR2: 00007f7e8b7bcf04 CR3: 0000000003e0f000 CR4: 00000000003406e0 <4>[ 3069.977559] Call Trace: <4>[ 3069.977565] ? mark_held_locks+0x64/0x90 <4>[ 3069.977571] ? _raw_spin_unlock_irq+0x24/0x50 <4>[ 3069.977575] ? _raw_spin_unlock_irq+0x24/0x50 <4>[ 3069.977579] ? trace_hardirqs_on_caller+0xde/0x1c0 <4>[ 3069.977583] ? _raw_spin_unlock_irq+0x2f/0x50 <4>[ 3069.977588] ? finish_task_switch+0xa5/0x210 <4>[ 3069.977592] ? lock_acquire+0xaf/0x200 <4>[ 3069.977596] lock_acquire+0xaf/0x200 <4>[ 3069.977600] ? __mutex_lock+0x5e9/0x9b0 <4>[ 3069.977604] _raw_spin_lock+0x2a/0x40 <4>[ 3069.977608] ? __mutex_lock+0x5e9/0x9b0 <4>[ 3069.977612] __mutex_lock+0x5e9/0x9b0 <4>[ 3069.977616] ? drm_fb_helper_hotplug_event.part.19+0x16/0xa0 <4>[ 3069.977621] ? drm_fb_helper_hotplug_event.part.19+0x16/0xa0 <4>[ 3069.977625] drm_fb_helper_hotplug_event.part.19+0x16/0xa0 <4>[ 3069.977630] output_poll_execute+0x8d/0x180 <4>[ 3069.977635] process_one_work+0x22e/0x660 <4>[ 3069.977640] worker_thread+0x48/0x3a0 <4>[ 3069.977644] ? _raw_spin_unlock_irqrestore+0x4c/0x60 <4>[ 3069.977649] kthread+0x102/0x140 <4>[ 3069.977653] ? process_one_work+0x660/0x660 <4>[ 3069.977657] ? kthread_create_on_node+0x40/0x40 <4>[ 3069.977662] ret_from_fork+0x27/0x40 <4>[ 3069.977666] Code: 8d 62 f8 c3 49 81 3c 24 e0 fa 3c 82 41 be 00 00 00 00 45 0f 45 f0 83 fe 01 77 86 89 f0 49 8b 44 c4 08 48 85 c0 0f 84 76 ff ff ff <f0> ff 80 38 01 00 00 8b 1d 62 f9 e8 01 45 8b 85 b8 08 00 00 85 <1>[ 3069.977707] RIP: __lock_acquire+0x109/0x1b60 RSP: ffffc90001fe7bb0 <4>[ 3069.977712] ---[ end trace 4ad012eb3af62df7 ]--- In order to keep the dev_priv->ifbdev alive after failure, we have to avoid the free and leave it empty until we unload the module (which is less than ideal, but a necessary evil for simplicity). Then we can use intel_fbdev_sync() to serialise the hotplug event with the configuration. The serialisation between the two was removed in commit 934458c2 ("Revert "drm/i915: Fix races on fbdev""), but the use after free is much older, commit 366e39b4 ("drm/i915: Tear down fbdev if initialization fails") Fixes: 366e39b4 ("drm/i915: Tear down fbdev if initialization fails") Fixes: 934458c2 ("Revert "drm/i915: Fix races on fbdev"") Signed-off-by:
-
Hans de Goede authored
commit 294cf1af upstream. intel_uncore_suspend() unregisters the uncore code's PMIC bus access notifier and gets called on both normal and runtime suspend. intel_uncore_resume_early() re-registers the notifier, but only on normal resume. Add a new intel_uncore_runtime_resume() function which only re-registers the notifier and call that on runtime resume. Reported-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Hans de Goede authored
commit f4359ced upstream. assert_rpm_wakelock_held is triggered from i915_pmic_bus_access_notifier even though it gets unregistered on (runtime) suspend, this is caused by a race happening under the following circumstances: intel_runtime_pm_put does: atomic_dec(&dev_priv->pm.wakeref_count); pm_runtime_mark_last_busy(kdev); pm_runtime_put_autosuspend(kdev); And pm_runtime_put_autosuspend calls intel_runtime_suspend from a workqueue, so there is ample of time between the atomic_dec() and intel_runtime_suspend() unregistering the notifier. If the notifier gets called in this windowd assert_rpm_wakelock_held falsely triggers (at this point we're not runtime-suspended yet). This commit adds disable_rpm_wakeref_asserts and enable_rpm_wakeref_asserts calls around the intel_uncore_forcewake_get(FORCEWAKE_ALL) call in i915_pmic_bus_access_notifier fixing the false-positive WARN_ON. Changes in v2: -Reword comment explaining why disabling the wakeref asserts is ok and necessary Reported-by:
FKr <bugs-freedesktop@ubermail.me> Reviewed-by:
-
NeilBrown authored
commit 230b55fa upstream. Having both a bitmap and a journal is pointless. Attempting to do so can corrupt the bitmap if the journal replay happens before the bitmap is initialized. Rather than try to avoid this corruption, simply refuse to allow arrays with both a bitmap and a journal. So: - if raid5_run sees both are present, fail. - if adding a bitmap finds a journal is present, fail - if adding a journal finds a bitmap is present, fail. Signed-off-by:
NeilBrown <neilb@suse.com> Tested-by:
Joshua Kinard <kumba@gentoo.org> Acked-by:
Shaohua Li <shli@fb.com> Signed-off-by:
-
Sasha Neftin authored
commit c0f4b163 upstream. This is a follow on to commit b10effb9 ("fix buffer overrun while the I219 is processing DMA transactions") to address David Laights concerns about the use of "magic" numbers. So define masks as well as add additional code comments to give a better understanding of what needs to be done to avoid a buffer overrun. Signed-off-by:
Sasha Neftin <sasha.neftin@intel.com> Reviewed-by:
Alexander H Duyck <alexander.h.duyck@intel.com> Reviewed-by:
Dima Ruinskiy <dima.ruinskiy@intel.com> Reviewed-by:
Raanan Avargil <raanan.avargil@intel.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
