| Age | Commit message (Collapse) | Author |
|---|
|
commit 6c51d46f135b00c00373fcd029786ccef2b02b5b upstream.
The kernel in_irq() function tests for hard-IRQ context only, so if a
system is run with the kernel 'threadirqs' option selected, the test in
intel_check_page_flip() generates lots of warnings, because then it gets
called in soft-IRQ context.
We can instead use in_interrupt() which allows for either type of
interrupt, while still detecting and complaining about misuse of the
page flip code if it is ever called from non-interrupt context.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89321
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Cc: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 215a8fe4198f607f34ecdbc9969dae783d8b5a61 upstream.
This patch fixes a NULL pointer dereference OOPs with pSCSI backends
within target_core_stat.c code. The bug is caused by a configfs attr
read if no pscsi_dev_virt->pdv_sd has been configured.
Reported-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit f068fbc82e7696d67b1bb8189306865bedf368b6 upstream.
This patch fixes a iser specific logout bug where early complete()
of conn->conn_logout_comp in iscsit_close_connection() was causing
isert_wait4logout() to complete too soon, triggering a use after
free NULL pointer dereference of iscsi_conn memory.
The complete() was originally added for traditional iscsi-target
when a ISCSI_LOGOUT_OP failed in iscsi_target_rx_opcode(), but given
iser-target does not wait in logout failure, this special case needs
to be avoided.
Reported-by: Sagi Grimberg <sagig@mellanox.com>
Cc: Sagi Grimberg <sagig@mellanox.com>
Cc: Slava Shwartsman <valyushash@gmail.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 5f7da044f8bc1cfb21c962edf34bd5699a76e7ae upstream.
This patch fixes a NULL pointer dereference triggered by a late
target_configure_device() -> alloc_workqueue() failure that results
in target_free_device() being called with DF_CONFIGURED already set,
which subsequently OOPses in destroy_workqueue() code.
Currently this only happens at modprobe target_core_mod time when
core_dev_setup_virtual_lun0() -> target_configure_device() fails,
and the explicit target_free_device() gets called.
To address this bug originally introduced by commit 0fd97ccf45, go
ahead and move DF_CONFIGURED to end of target_configure_device()
code to handle this special failure case.
Reported-by: Claudio Fleiner <cmf@daterainc.com>
Cc: Claudio Fleiner <cmf@daterainc.com>
Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 7544e597343e2166daba3f32e4708533aa53c233 upstream.
This patch fixes a se_cmd->cmd_kref leak buf when se_sess->sess_tearing_down
is true within target_get_sess_cmd() submission path code.
This se_cmd reference leak can occur during active session shutdown when
ack_kref=1 is passed by target_submit_cmd_[map_sgls,tmr]() callers.
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 0ff66cffde47de51c155ebdd2356403276c04cc4 upstream.
It was incorrectly detected as 2 GHz device.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 5724be8464dceac047c1eaddaa3651cea0ec16ca upstream.
On the Cortex-A9-based Armada SoCs, the MPIC is not the primary interrupt
controller. Yet, it still has to handle some per-cpu interrupt.
To do so, it is chained with the GIC using a per-cpu interrupt. However, the
current code only call irq_set_chained_handler, which is called and enable that
interrupt only on the boot CPU, which means that the parent per-CPU interrupt
is never unmasked on the secondary CPUs, preventing the per-CPU interrupt to
actually work as expected.
This was not seen until now since the only MPIC PPI users were the Marvell
timers that were not working, but not used either since the system use the ARM
TWD by default, and the ethernet controllers, that are faking there interrupts
as SPI, and don't really expect to have interrupts on the secondary cores
anyway.
Add a CPU notifier that will enable the PPI on the secondary cores when they
are brought up.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Link: https://lkml.kernel.org/r/1425378443-28822-1-git-send-email-maxime.ripard@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 4efe874aace57dba967624ce1c48322da2447b75 upstream.
When printing the driver_override parameter when it is 4095 and 4094 bytes
long, the printing code would access invalid memory because we need count+1
bytes for printing.
Fixes: 782a985d7af2 ("PCI: Introduce new device binding path using pci_dev.driver_override")
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Alex Williamson <alex.williamson@redhat.com>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
CC: Alexander Graf <agraf@suse.de>
CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 6302ce4d80aa82b3fdb5c5cd68e7268037091b47 upstream.
This crash was reported:
[ 366.947370] sd 3:0:1:0: [sdb] Spinning up disk....
[ 368.804046] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 368.804072] IP: [<ffffffff81358457>] __mutex_lock_common.isra.7+0x9c/0x15b
[ 368.804098] PGD 0
[ 368.804114] Oops: 0002 [#1] SMP
[ 368.804143] CPU 1
[ 368.804151] Modules linked in: sg netconsole s3g(PO) uinput joydev hid_multitouch usbhid hid snd_hda_codec_via cpufreq_userspace cpufreq_powersave cpufreq_stats uhci_hcd cpufreq_conservative snd_hda_intel snd_hda_codec snd_hwdep snd_pcm sdhci_pci snd_page_alloc sdhci snd_timer snd psmouse evdev serio_raw pcspkr soundcore xhci_hcd shpchp s3g_drm(O) mvsas mmc_core ahci libahci drm i2c_core acpi_cpufreq mperf video processor button thermal_sys dm_dmirror exfat_fs exfat_core dm_zcache dm_mod padlock_aes aes_generic padlock_sha iscsi_target_mod target_core_mod configfs sswipe libsas libata scsi_transport_sas picdev via_cputemp hwmon_vid fuse parport_pc ppdev lp parport autofs4 ext4 crc16 mbcache jbd2 sd_mod crc_t10dif usb_storage scsi_mod ehci_hcd usbcore usb_common
[ 368.804749]
[ 368.804764] Pid: 392, comm: kworker/u:3 Tainted: P W O 3.4.87-logicube-ng.22 #1 To be filled by O.E.M. To be filled by O.E.M./EPIA-M920
[ 368.804802] RIP: 0010:[<ffffffff81358457>] [<ffffffff81358457>] __mutex_lock_common.isra.7+0x9c/0x15b
[ 368.804827] RSP: 0018:ffff880117001cc0 EFLAGS: 00010246
[ 368.804842] RAX: 0000000000000000 RBX: ffff8801185030d0 RCX: ffff88008edcb420
[ 368.804857] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff8801185030d4
[ 368.804873] RBP: ffff8801181531c0 R08: 0000000000000020 R09: 00000000fffffffe
[ 368.804885] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801185030d4
[ 368.804899] R13: 0000000000000002 R14: ffff880117001fd8 R15: ffff8801185030d8
[ 368.804916] FS: 0000000000000000(0000) GS:ffff88011fc80000(0000) knlGS:0000000000000000
[ 368.804931] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 368.804946] CR2: 0000000000000000 CR3: 000000000160b000 CR4: 00000000000006e0
[ 368.804962] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 368.804978] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 368.804995] Process kworker/u:3 (pid: 392, threadinfo ffff880117000000, task ffff8801181531c0)
[ 368.805009] Stack:
[ 368.805017] ffff8801185030d8 0000000000000000 ffffffff8161ddf0 ffffffff81056f7c
[ 368.805062] 000000000000b503 ffff8801185030d0 ffff880118503000 0000000000000000
[ 368.805100] ffff8801185030d0 ffff8801188b8000 ffff88008edcb420 ffffffff813583ac
[ 368.805135] Call Trace:
[ 368.805153] [<ffffffff81056f7c>] ? up+0xb/0x33
[ 368.805168] [<ffffffff813583ac>] ? mutex_lock+0x16/0x25
[ 368.805194] [<ffffffffa018c414>] ? smp_execute_task+0x4e/0x222 [libsas]
[ 368.805217] [<ffffffffa018ce1c>] ? sas_find_bcast_dev+0x3c/0x15d [libsas]
[ 368.805240] [<ffffffffa018ce4f>] ? sas_find_bcast_dev+0x6f/0x15d [libsas]
[ 368.805264] [<ffffffffa018e989>] ? sas_ex_revalidate_domain+0x37/0x2ec [libsas]
[ 368.805280] [<ffffffff81355a2a>] ? printk+0x43/0x48
[ 368.805296] [<ffffffff81359a65>] ? _raw_spin_unlock_irqrestore+0xc/0xd
[ 368.805318] [<ffffffffa018b767>] ? sas_revalidate_domain+0x85/0xb6 [libsas]
[ 368.805336] [<ffffffff8104e5d9>] ? process_one_work+0x151/0x27c
[ 368.805351] [<ffffffff8104f6cd>] ? worker_thread+0xbb/0x152
[ 368.805366] [<ffffffff8104f612>] ? manage_workers.isra.29+0x163/0x163
[ 368.805382] [<ffffffff81052c4e>] ? kthread+0x79/0x81
[ 368.805399] [<ffffffff8135fea4>] ? kernel_thread_helper+0x4/0x10
[ 368.805416] [<ffffffff81052bd5>] ? kthread_flush_work_fn+0x9/0x9
[ 368.805431] [<ffffffff8135fea0>] ? gs_change+0x13/0x13
[ 368.805442] Code: 83 7d 30 63 7e 04 f3 90 eb ab 4c 8d 63 04 4c 8d 7b 08 4c 89 e7 e8 fa 15 00 00 48 8b 43 10 4c 89 3c 24 48 89 63 10 48 89 44 24 08 <48> 89 20 83 c8 ff 48 89 6c 24 10 87 03 ff c8 74 35 4d 89 ee 41
[ 368.805851] RIP [<ffffffff81358457>] __mutex_lock_common.isra.7+0x9c/0x15b
[ 368.805877] RSP <ffff880117001cc0>
[ 368.805886] CR2: 0000000000000000
[ 368.805899] ---[ end trace b720682065d8f4cc ]---
It's directly caused by 89d3cf6 [SCSI] libsas: add mutex for SMP task
execution, but shows a deeper cause: expander functions expect to be able to
cast to and treat domain devices as expanders. The correct fix is to only do
expander discover when we know we've got an expander device to avoid wrongly
casting a non-expander device.
Reported-by: Praveen Murali <pmurali@logicube.com>
Tested-by: Praveen Murali <pmurali@logicube.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit f01d35a15fa04162a58b95970fc01fa70ec9dacd upstream.
AIO_PREAD requests call ->aio_read() with iovec on caller's stack, so if
we are going to access it asynchronously, we'd better get ourselves
a copy - the one on kernel stack of aio_run_iocb() won't be there
anymore. function/f_fs.c take care of doing that, legacy/inode.c
doesn't...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 721a09e95c786346b4188863a1cfa3909c76f690 upstream.
Commit 106937e8ccdc ("of: fix handling of '/' in options for
of_find_node_by_path()") caused a regression in OF handling of
stdout-path. While it fixes some cases which have '/' after the ':', it
breaks cases where there is more than one '/' *before* the ':'.
For example, it breaks this boot string
stdout-path = "/rdb/serial@f040ab00:115200";
So rather than doing sequentialized checks (first for '/', then for ':';
or vice versa), to get the correct behavior we need to check for the
first occurrence of either one of them.
It so happens that the handy strcspn() helper can do just that.
Fixes: 106937e8ccdc ("of: fix handling of '/' in options for of_find_node_by_path()")
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 106937e8ccdcf0f4b95fbf0fe9abd42766cade33 upstream.
Ensure proper handling of paths with appended options (after ':'),
where those options may contain a '/'.
Fixes: 7914a7c5651a ("of: support passing console options with stdout-path")
Reported-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit af6fc858a35b90e89ea7a7ee58e66628c55c776b upstream.
Otherwise the guest can abuse that control to cause e.g. PCIe
Unsupported Request responses by disabling memory and/or I/O decoding
and subsequently causing (CPU side) accesses to the respective address
ranges, which (depending on system configuration) may be fatal to the
host.
Note that to alter any of the bits collected together as
PCI_COMMAND_GUEST permissive mode is now required to be enabled
globally or on the specific device.
This is CVE-2015-2150 / XSA-120.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 85e40b0539b24518c8bdf63e2605c8522377d00f upstream.
Using the pvops kernel a NULL pointer dereference was detected on a
large machine (144 processors) when booting as dom0 in
evtchn_fifo_unmask() during assignment of a pirq.
The event channel in question was the first to need a new entry in
event_array[] in events_fifo.c. Unfortunately xen_irq_info_pirq_setup()
is called with evtchn being 0 for a new pirq and the real event channel
number is assigned to the pirq only during __startup_pirq().
It is mandatory to call xen_evtchn_port_setup() after assigning the
event channel number to the pirq to make sure all memory needed for the
event channel is allocated.
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 8792f7772f4f40ffc68bad5f28311205584b734d upstream.
Commit df9e26d093d3 ("rtc: s3c: add support for RTC of Exynos3250 SoC")
added an "rtc_src" DT property to specify the clock used as a source to
the S3C real-time clock.
Not all SoCs needs this so commit eaf3a659086e ("drivers/rtc/rtc-s3c.c:
fix initialization failure without rtc source clock") changed to check
the struct s3c_rtc_data .needs_src_clk to conditionally grab the clock.
But that commit didn't update the data for each IP version so the RTC
broke on the boards that needs a source clock. This is the case of at
least Exynos5250 and Exynos5440 which uses the s3c6410 RTC IP block.
This commit fixes the S3C rtc on the Exynos5250 Snow and Exynos5420
Peach Pit and Pi Chromebooks.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Chanwoo Choi <cw00.choi@samsung.com>
Cc: Doug Anderson <dianders@chromium.org>
Cc: Olof Johansson <olof@lixom.net>
Cc: Kevin Hilman <khilman@linaro.org>
Cc: Tyler Baker <tyler.baker@linaro.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit ab3be73fa7b43f4c3648ce29b5fd649ea54d3adb upstream.
Bjørn reported that his machine hang during hibernation and eventually
bisected the problem to the following commit:
commit da2bc1b9db3351addd293e5b82757efe1f77ed1d
Author: Imre Deak <imre.deak@intel.com>
Date: Thu Oct 23 19:23:26 2014 +0300
drm/i915: add poweroff_late handler
The problem seems to be that after the kernel puts the device into D3
the BIOS still tries to access it, or otherwise assumes that it's in D0.
This is clearly bogus, since ACPI mandates that devices are put into D3
by the OSPM if they are not wake-up sources. In the future we want to
unify more of the driver's runtime and system suspend paths, for example
by skipping all the system suspend/hibernation hooks if the device is
runtime suspended already. Accordingly for all other platforms the goal
is still to properly power down the device during hibernation.
v2:
- Another GEN4 Lenovo laptop had the same issue, while platforms from
other vendors (including mobile and desktop, GEN4 and non-GEN4) seem
to work fine. Based on this apply the workaround on all GEN4 Lenovo
platforms.
- add code comment about failing platforms (Ville)
Reference: http://lists.freedesktop.org/archives/intel-gfx/2015-February/060633.html
Reported-and-bisected-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 888d0d421663313739a8bf93459c6ba61fd4b121 upstream.
This will be needed by later patches, so factor it out.
No functional change.
v2:
- s/dev_to_i915_priv/dev_to_i915/ (Jani)
- don't use the helper in i915_pm_suspend (Chris)
- simplify the helper (Chris)
v3:
- remove redundant upcasting in the helper (Daniel)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 9a6f5130143c17b91e0a3cbf5cc2d8c1e5a80a63 upstream.
The internal framebuffers we create to remap legacy cursor ioctls to
plane operations for the universal plane support shouldn't be linke to
the file like normal userspace framebuffers. This bug goes back to the
original universal cursor plane support introduced in
commit 161d0dc1dccb17ff7a38f462c7c0d4ef8bcc5662
Author: Matt Roper <matthew.d.roper@intel.com>
Date: Tue Jun 10 08:28:10 2014 -0700
drm: Support legacy cursor ioctls via universal planes when possible (v4)
The isn't too disastrous since fbs are small, we only create one when the
cursor bo gets changed and ultimately they'll be reaped when the window
server restarts.
Conceptually we'd want to just pass NULL for file_priv when creating it,
but the driver needs the file to lookup the underlying buffer object for
cursor id. Instead let's move the file_priv linking out of
add_framebuffer_internal() into the addfb ioctl implementation, which is
the only place it is needed. And also rename the function for a more
accurate since it only creates the fb, but doesn't add it anywhere.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> (fix & commit msg)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (provider of lipstick)
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 5151adb37a5918957f4c33a8d8e7629c0fb00563 upstream.
Experimental lockdep annotation added to the TTM lock has unveiled a
couple of lock dependency violations in the vmwgfx driver. In both
cases it turns out that the device_private::reservation_sem is not
needed so the offending code is moved out of that lock.
Acked-by: Sinclair Yeh <syeh@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 3458390b9f0ba784481d23134798faee27b5f16f upstream.
To take down the MOB and GMR memory types, the driver may have to issue
fence objects and thus make sure that the fence manager is taken down
after those memory types.
Reorder device init accordingly.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit a49445727014216703a3c28ccee4cef36d41571e upstream.
This reverts commit e4df3a0b6228
("i2c: core: Dispose OF IRQ mapping at client removal time")
Calling irq_dispose_mapping() will destroy the mapping and disassociate
the IRQ from the IRQ chip to which it belongs. Keeping it is OK, because
existent mappings are reused properly.
Also, this commit breaks drivers using devm* for IRQ management on
OF-based systems because devm* cleanup happens in device code, after
bus's remove() method returns.
Signed-off-by: Jakub Kicinski <kubakici@wp.pl>
Reported-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
[wsa: updated the commit message with findings fromt the other bug report]
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Fixes: e4df3a0b6228
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 29d62ec5f87fbeec8413e2215ddad12e7f972e4c upstream.
Normally _regulator_do_enable() isn't called on an already-enabled
rdev. That's because the main caller, _regulator_enable() always
calls _regulator_is_enabled() and only calls _regulator_do_enable() if
the rdev was not already enabled.
However, there is one caller of _regulator_do_enable() that doesn't
check: regulator_suspend_finish(). While we might want to make
regulator_suspend_finish() behave more like _regulator_enable(), it's
probably also a good idea to make _regulator_do_enable() robust if it
is called on an already enabled rdev.
At the moment, _regulator_do_enable() is _not_ robust for already
enabled rdevs if we're using an ena_pin. Each time
_regulator_do_enable() is called for an rdev using an ena_pin the
reference count of the ena_pin is incremented even if the rdev was
already enabled. This is not as intended because the ena_pin is for
something else: for keeping track of how many active rdevs there are
sharing the same ena_pin.
Here's how the reference counting works here:
* Each time _regulator_enable() is called we increment
rdev->use_count, so _regulator_enable() calls need to be balanced
with _regulator_disable() calls.
* There is no explicit reference counting in _regulator_do_enable()
which is normally just a warapper around rdev->desc->ops->enable()
with code for supporting delays. It's not expected that the
"ops->enable()" call do reference counting.
* Since regulator_ena_gpio_ctrl() does have reference counting
(handling the sharing of the pin amongst multiple rdevs), we
shouldn't call it if the current rdev is already enabled.
Note that as part of this we cleanup (remove) the initting of
ena_gpio_state in regulator_register(). In _regulator_do_enable(),
_regulator_do_disable() and _regulator_is_enabled() is is clear that
ena_gpio_state should be the state of whether this particular rdev has
requested the GPIO be enabled. regulator_register() was initting it
as the actual state of the pin.
Fixes: 967cfb18c0e3 ("regulator: core: manage enable GPIO list")
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 0548bf4f5ad6fc3bd93c4940fa48078b34609682 upstream.
The _regulator_do_enable() call ought to be a no-op when called on an
already-enabled regulator. However, as an optimization
_regulator_enable() doesn't call _regulator_do_enable() on an already
enabled regulator. That means we never test the case of calling
_regulator_do_enable() during normal usage and there may be hidden
bugs or warnings. We have seen warnings issued by the tps65090 driver
and bugs when using the GPIO enable pin.
Let's match the same optimization that _regulator_enable() in
regulator_suspend_finish(). That may speed up suspend/resume and also
avoids exposing hidden bugs.
[Use much clearer commit message from Doug Anderson]
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 28249b0c2fa361cdac450a6f40242ed45408a24f upstream.
The LDOs are documented in the rk808 datasheet to have a soft start
time of 400us. Add that to the driver. If this time takes longer on
a certain board the device tree should be able to override with
"regulator-enable-ramp-delay".
This fixes some dw_mmc probing problems (together with other patches
posted to the mmc maiing lists) on rk3288.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 61615cd27e2fdcf698261ba77c7d93f7a7739c65 upstream.
When do suspend/resume stress test, some log shows "rcv is not +last".
The issue is that enet suspend will disable phy clock, phy link down,
after resume back, enet MAC redo initial and ready to tx/rx packet,
but phy still is not ready which is doing auto-negotiation. When phy
link is not up, don't schdule napi soft irq.
[Peter]
It has fixed kernel panic after long time suspend/resume test
with nfs rootfs.
[ 8864.429458] fec 2188000.ethernet eth0: rcv is not +last
[ 8864.434799] fec 2188000.ethernet eth0: rcv is not +last
[ 8864.440088] fec 2188000.ethernet eth0: rcv is not +last
[ 8864.445424] fec 2188000.ethernet eth0: rcv is not +last
[ 8864.450782] fec 2188000.ethernet eth0: rcv is not +last
[ 8864.456111] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[ 8864.464225] pgd = 80004000
[ 8864.466997] [00000000] *pgd=00000000
[ 8864.470627] Internal error: Oops: 17 [#1] SMP ARM
[ 8864.475353] Modules linked in: evbug
[ 8864.479006] CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted 4.0.0-rc1-00044-g7a2a1d2 #234
[ 8864.486854] Hardware name: Freescale i.MX6 SoloX (Device Tree)
[ 8864.492709] task: be069380 ti: be07a000 task.ti: be07a000
[ 8864.498137] PC is at memcpy+0x80/0x330
[ 8864.501919] LR is at gro_pull_from_frag0+0x34/0xa8
[ 8864.506735] pc : [<802bb080>] lr : [<8057c204>] psr: 00000113
[ 8864.506735] sp : be07bbd4 ip : 00000010 fp : be07bc0c
[ 8864.518235] r10: 0000000e r9 : 00000000 r8 : 809c7754
[ 8864.523479] r7 : 809c7754 r6 : bb43c040 r5 : bd280cc0 r4 : 00000012
[ 8864.530025] r3 : 00000804 r2 : fffffff2 r1 : 00000000 r0 : bb43b83c
[ 8864.536575] Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
[ 8864.543904] Control: 10c5387d Table: bd14c04a DAC: 00000015
[ 8864.549669] Process ksoftirqd/0 (pid: 3, stack limit = 0xbe07a210)
[ 8864.555869] Stack: (0xbe07bbd4 to 0xbe07c000)
[ 8864.560250] bbc0: bd280cc0 bb43c040 809c7754
[ 8864.568455] bbe0: 809c7754 bb43b83c 00000012 8057c204 00000000 bd280cc0 bd8a0718 00000003
[ 8864.576658] bc00: be07bc5c be07bc10 8057ebf0 8057c1dc 00000000 00000000 8057ecc4 bef59760
[ 8864.584863] bc20: 00000002 bd8a0000 be07bc64 809c7754 00000000 bd8a0718 bd280cc0 bd8a0000
[ 8864.593066] bc40: 00000000 0000001c 00000000 bd8a0000 be07bc74 be07bc60 8057f148 8057eb90
[ 8864.601268] bc60: bf0810a0 00000000 be07bcf4 be07bc78 8044e7b4 8057f12c 00000000 8007df6c
[ 8864.609470] bc80: bd8a0718 00000040 00000000 bd280a80 00000002 00000019 bd8a0600 bd8a1214
[ 8864.617672] bca0: bd8a0690 bf0810a0 00000000 00000000 bd8a1000 00000000 00000027 bd280cc0
[ 8864.625874] bcc0: 80062708 800625cc 000943db bd8a0718 00000001 000d1166 00000040 be7c1ec0
[ 8864.634077] bce0: 0000012c be07bd00 be07bd3c be07bcf8 8057fc98 8044e3ac 809c2ec0 3ddff000
[ 8864.642280] bd00: be07bd00 be07bd00 be07bd08 be07bd08 00000000 00000020 809c608c 00000003
[ 8864.650481] bd20: 809c6080 40000001 809c6088 00200100 be07bd84 be07bd40 8002e690 8057fac8
[ 8864.658684] bd40: be07bd64 be07bd50 00000001 04208040 000d1165 0000000a be07bd84 809c0d7c
[ 8864.666885] bd60: 00000000 809c6af8 00000000 00000001 be008000 00000000 be07bd9c be07bd88
[ 8864.675087] bd80: 8002eb64 8002e564 00000125 809c0d7c be07bdc4 be07bda0 8006f100 8002eaac
[ 8864.683291] bda0: c080e10c be07bde8 809c6c6c c080e100 00000002 00000000 be07bde4 be07bdc8
[ 8864.691492] bdc0: 800087a0 8006f098 806f2934 20000013 ffffffff be07be1c be07be44 be07bde8
[ 8864.699695] bde0: 800133a4 80008784 00000001 00000001 00000000 00000000 be7c1680 00000000
[ 8864.707896] be00: be0cfe00 bd93eb40 00000002 00000000 00000000 be07be44 be07be00 be07be30
[ 8864.716098] be20: 8006278c 806f2934 20000013 ffffffff be069380 be7c1680 be07be7c be07be48
[ 8864.724300] be40: 80049cfc 806f2910 00000001 00000000 80049cb4 00000000 be07be7c be7c1680
[ 8864.732502] be60: be3289c0 be069380 bd23b600 be0cfe00 be07bebc be07be80 806ed614 80049c68
[ 8864.740706] be80: be07a000 0000020a 809c608c 00000003 00000001 8002e858 be07a000 be035740
[ 8864.748907] bea0: 00000000 00000001 809d4598 00000000 be07bed4 be07bec0 806edd0c 806ed440
[ 8864.757110] bec0: be07a000 be07a000 be07bee4 be07bed8 806edd68 806edcf0 be07bef4 be07bee8
[ 8864.765311] bee0: 8002e860 806edd34 be07bf24 be07bef8 800494b0 8002e828 be069380 00000000
[ 8864.773512] bf00: be035780 be035740 8004938c 00000000 00000000 00000000 be07bfac be07bf28
[ 8864.781715] bf20: 80045928 80049398 be07bf44 00000001 00000000 be035740 00000000 00030003
[ 8864.789917] bf40: dead4ead ffffffff ffffffff 80a2716c 80b59b00 00000000 8088c954 be07bf5c
[ 8864.798120] bf60: be07bf5c 00000000 00000000 dead4ead ffffffff ffffffff 80a2716c 00000000
[ 8864.806320] bf80: 00000000 8088c954 be07bf88 be07bf88 be035780 8004584c 00000000 00000000
[ 8864.814523] bfa0: 00000000 be07bfb0 8000ed10 80045858 00000000 00000000 00000000 00000000
[ 8864.822723] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 8864.830925] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 5ffbb5f7 f9fcf5e7
[ 8864.839115] Backtrace:
[ 8864.841631] [<8057c1d0>] (gro_pull_from_frag0) from [<8057ebf0>] (dev_gro_receive+0x6c/0x3f8)
[ 8864.850173] r6:00000003 r5:bd8a0718 r4:bd280cc0 r3:00000000
[ 8864.855958] [<8057eb84>] (dev_gro_receive) from [<8057f148>] (napi_gro_receive+0x28/0xac)
[ 8864.864152] r10:bd8a0000 r9:00000000 r8:0000001c r7:00000000 r6:bd8a0000 r5:bd280cc0
[ 8864.872115] r4:bd8a0718
[ 8864.874713] [<8057f120>] (napi_gro_receive) from [<8044e7b4>] (fec_enet_rx_napi+0x414/0xc74)
[ 8864.883167] r5:00000000 r4:bf0810a0
[ 8864.886823] [<8044e3a0>] (fec_enet_rx_napi) from [<8057fc98>] (net_rx_action+0x1dc/0x2ec)
[ 8864.895016] r10:be07bd00 r9:0000012c r8:be7c1ec0 r7:00000040 r6:000d1166 r5:00000001
[ 8864.902982] r4:bd8a0718
[ 8864.905570] [<8057fabc>] (net_rx_action) from [<8002e690>] (__do_softirq+0x138/0x2c4)
[ 8864.913417] r10:00200100 r9:809c6088 r8:40000001 r7:809c6080 r6:00000003 r5:809c608c
[ 8864.921382] r4:00000020
[ 8864.923966] [<8002e558>] (__do_softirq) from [<8002eb64>] (irq_exit+0xc4/0x138)
[ 8864.931289] r10:00000000 r9:be008000 r8:00000001 r7:00000000 r6:809c6af8 r5:00000000
[ 8864.939252] r4:809c0d7c
[ 8864.941841] [<8002eaa0>] (irq_exit) from [<8006f100>] (__handle_domain_irq+0x74/0xe8)
[ 8864.949688] r4:809c0d7c r3:00000125
[ 8864.953342] [<8006f08c>] (__handle_domain_irq) from [<800087a0>] (gic_handle_irq+0x28/0x68)
[ 8864.961707] r9:00000000 r8:00000002 r7:c080e100 r6:809c6c6c r5:be07bde8 r4:c080e10c
[ 8864.969597] [<80008778>] (gic_handle_irq) from [<800133a4>] (__irq_svc+0x44/0x5c)
[ 8864.977097] Exception stack(0xbe07bde8 to 0xbe07be30)
[ 8864.982173] bde0: 00000001 00000001 00000000 00000000 be7c1680 00000000
[ 8864.990377] be00: be0cfe00 bd93eb40 00000002 00000000 00000000 be07be44 be07be00 be07be30
[ 8864.998573] be20: 8006278c 806f2934 20000013 ffffffff
[ 8865.003638] r7:be07be1c r6:ffffffff r5:20000013 r4:806f2934
[ 8865.009447] [<806f2904>] (_raw_spin_unlock_irq) from [<80049cfc>] (finish_task_switch+0xa0/0x160)
[ 8865.018334] r4:be7c1680 r3:be069380
[ 8865.021993] [<80049c5c>] (finish_task_switch) from [<806ed614>] (__schedule+0x1e0/0x5dc)
[ 8865.030098] r8:be0cfe00 r7:bd23b600 r6:be069380 r5:be3289c0 r4:be7c1680
[ 8865.036942] [<806ed434>] (__schedule) from [<806edd0c>] (preempt_schedule_common+0x28/0x44)
[ 8865.045307] r9:00000000 r8:809d4598 r7:00000001 r6:00000000 r5:be035740 r4:be07a000
[ 8865.053197] [<806edce4>] (preempt_schedule_common) from [<806edd68>] (_cond_resched+0x40/0x48)
[ 8865.061822] r4:be07a000 r3:be07a000
[ 8865.065472] [<806edd28>] (_cond_resched) from [<8002e860>] (run_ksoftirqd+0x44/0x64)
[ 8865.073252] [<8002e81c>] (run_ksoftirqd) from [<800494b0>] (smpboot_thread_fn+0x124/0x190)
[ 8865.081550] [<8004938c>] (smpboot_thread_fn) from [<80045928>] (kthread+0xdc/0xf8)
[ 8865.089133] r10:00000000 r9:00000000 r8:00000000 r7:8004938c r6:be035740 r5:be035780
[ 8865.097097] r4:00000000 r3:be069380
[ 8865.100752] [<8004584c>] (kthread) from [<8000ed10>] (ret_from_fork+0x14/0x24)
[ 8865.107990] r7:00000000 r6:00000000 r5:8004584c r4:be035780
[ 8865.113767] Code: e320f000 e4913004 e4914004 e4915004 (e4916004)
[ 8865.120006] ---[ end trace b0a4c6bd499288ca ]---
[ 8865.124697] Kernel panic - not syncing: Fatal exception in interrupt
[ 8865.131084] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
Tested-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Fugang Duan <B38611@freescale.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit da293700568ed3d96fcf062ac15d7d7c41377f11 upstream.
EEH recovery for bnx2x based adapters is not reliable on all Power
systems using the default hot reset, which can result in an
unrecoverable EEH error. Forcing the use of fundamental reset
during EEH recovery fixes this.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 8dad0386b97c4bd6edd56752ca7f2e735fe5beb4 upstream.
The NDDB register holds the data that are needed by the read and write
commands.
However, during a read PIO access, the datasheet specifies that after each 32
bytes read in that register, when BCH is enabled, we have to make sure that the
RDDREQ bit is set in the NDSR register.
This fixes an issue that was seen on the Armada 385, and presumably other mvebu
SoCs, when a read on a newly erased page would end up in the driver reporting a
timeout from the NAND.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit cd6fa8d2ca53cac3226fdcffcf763be390abae32 upstream.
Commit fd316941c ("spi/pl022: disable port when unused") introduced a race,
which leads to possible driver lock up (easily reproducible on SMP).
The problem happens in giveback() function where the completion of the transfer
is signalled to SPI subsystem and then the HW SPI controller is disabled. Another
transfer might be setup in between, which brings driver in locked-up state.
Exact event sequence on SMP:
core0 core1
=> pump_transfers()
/* message->state == STATE_DONE */
=> giveback()
=> spi_finalize_current_message()
=> pl022_unprepare_transfer_hardware()
=> pl022_transfer_one_message
=> flush()
=> do_interrupt_dma_transfer()
=> set_up_next_transfer()
/* Enable SSP, turn on interrupts */
writew((readw(SSP_CR1(pl022->virtbase)) |
SSP_CR1_MASK_SSE), SSP_CR1(pl022->virtbase));
...
=> pl022_interrupt_handler()
=> readwriter()
/* disable the SPI/SSP operation */
=> writew((readw(SSP_CR1(pl022->virtbase)) &
(~SSP_CR1_MASK_SSE)), SSP_CR1(pl022->virtbase));
Lockup! SPI controller is disabled and the data will never be received. Whole
SPI subsystem is waiting for transfer ACK and blocked.
So, only signal transfer completion after disabling the controller.
Fixes: fd316941c (spi/pl022: disable port when unused)
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit c9dafb27c84412fe4b17c3b94cc4ffeef5df1833 upstream.
When DMA descriptor allocation fails we should not try to assign any fields in
the bad descriptor. The patch adds the necessary checks for that.
Fixes: 7063c0d942a1 (spi/dw_spi: add DMA support)
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 76e1d14b316d6f501ebc001e7a5d86b24ce5b615 upstream.
Additionally to the current DMA transfer the PDC allows to set up a next DMA
transfer. This is useful for larger SPI transfers.
The driver currently waits for ENDRX as end of the transfer. But ENDRX is set
when the current DMA transfer is done (RCR = 0), i.e. it doesn't include the
next DMA transfer.
Thus a subsequent SPI transfer could be started although there is currently a
transfer in progress. This can cause invalid accesses to the SPI slave devices
and to SPI transfer errors.
This issue has been observed on a hardware with a M25P128 SPI NOR flash.
So instead of ENDRX we should wait for RXBUFF. This flag is set if there is
no more DMA transfer in progress (RCR = RNCR = 0).
Signed-off-by: Torsten Fleischer <torfl6749@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit c4eadfafb91d5501095c55ffadaa1168743f39d3 upstream.
Add a return value check when reading data from the FIFO register.
Reviewed-by: Jason Gunthorpe <jason.gunthorpe@obsidianresearch.com>
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Reviewed-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 62dfd912ab3b5405b6fe72d0135c37e9648071f1 upstream.
Problem: When IMA and VTPM are both enabled in kernel config,
kernel hangs during bootup on LE OS.
Why?: IMA calls tpm_pcr_read() which results in tpm_ibmvtpm_send
and tpm_ibmtpm_recv getting called. A trace showed that
tpm_ibmtpm_recv was hanging.
Resolution: tpm_ibmtpm_recv was hanging because tpm_ibmvtpm_send
was sending CRQ message that probably did not make much sense
to phype because of Endianness. The fix below sends correctly
converted CRQ for LE. This was not caught before because it
seems IMA is not enabled by default in kernel config and
IMA exercises this particular code path in vtpm.
Tested with IMA and VTPM enabled in kernel config and VTPM
enabled on both a BE OS and a LE OS ppc64 lpar. This exercised
CRQ and TPM command code paths in vtpm.
Patch is against Peter's tpmdd tree on github which included
Vicky's previous vtpm le patches.
Signed-off-by: Joy Latten <jmlatten@linux.vnet.ibm.com>
Reviewed-by: Ashley Lai <ashley@ahsleylai.com>
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 2fec5104f9c61de4cf2205aa355101e19a81f490 upstream.
The Kvaser firmware can only read and write messages that are
not crossing the USB endpoint's wMaxPacketSize boundary. While
receiving commands from the CAN device, if the next command in
the same URB buffer crossed that max packet size boundary, the
firmware puts a zero-length placeholder command in its place
then moves the real command to the next boundary mark.
The driver did not recognize such behavior, leading to missing
a good number of rx events during a heavy rx load session.
Moreover, a tx URB context only gets freed upon receiving its
respective tx ACK event. Over time, the free tx URB contexts
pool gets depleted due to the missing ACK events. Consequently,
the netif transmission queue gets __permanently__ stopped; no
frames could be sent again except after restarting the CAN
newtwork interface.
Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 969439016d2cf61fef53a973d7e6d2061c3793b1 upstream.
When accessing CAN network interfaces with AF_PACKET sockets e.g. by dhclient
this can lead to a skb_under_panic due to missing skb initialisations.
Add the missing initialisations at the CAN skbuff creation times on driver
level (rx path) and in the network layer (tx path).
Reported-by: Austin Schuh <austin@peloton-tech.com>
Reported-by: Daniel Steer <daniel.steer@mclaren.com>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit f2e0ea861117bda073d1d7ffbd3120c07c0d5d34 upstream.
I'm still receiving reports to my email address, so let's point this
at the linux-serial mailing list instead.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit eeb8a7e8bb123e84daeef84f5a2eab99ad2839a2 upstream.
when multiport is off, virtio console invokes config access from irq
context, config access is blocking on s390.
Fix this up by scheduling work from config irq - similar to what we do
for multiport configs.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Amit Shah <amit.shah@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 4f6e24ed9de8634d6471ef86b382cba6d4e57ca8 upstream.
when multiport is off, we don't initialize config work,
but we then cancel uninitialized control_work on freeze.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Amit Shah <amit.shah@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 7fd6f640f2dd17dac6ddd6702c378cb0bb9cfa11 upstream.
Trying to write console output from within the serial console driver
while the port->lock is held causes recursive deadlock:
CPU 0
spin_lock_irqsave(&port->lock)
printk()
console_unlock()
call_console_drivers()
serial8250_console_write()
spin_lock_irqsave(&port->lock)
** DEADLOCK **
The 8250_dw i/o accessors try to write a console error message if the
LCR workaround was unsuccessful. When the port->lock is already held
(eg., when called from serial8250_set_termios()), this deadlocks.
Make the error message a FIXME until a general solution is devised.
Cc: Tim Kryger <tim.kryger@gmail.com>
Reported-by: Zhang Zhen <zhenzhang.zhang@huawei.com>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit a239118a24b3bf9089751068e431dfb63dc4168b upstream.
radeon_bo_create() calls radeon_ttm_placement_from_domain()
before ttm_bo_init() is called. radeon_ttm_placement_from_domain()
uses the ttm bo size to determine when to select top down
allocation but since the ttm bo is not initialized yet the
check is always false. It only took effect when buffers
were validated later. It also seemed to regress suspend
and resume on some systems possibly due to it not
taking effect in radeon_bo_create().
radeon_bo_create() and radeon_ttm_placement_from_domain()
need to be reworked substantially for this to be optimally
effective. Re-enable it at that point.
Noticed-by: Oded Gabbay <oded.gabbay@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit e405ca3a1bf166f741506c07c2a277b5d48af8f7 upstream.
The current CP firmware can handle Usermode Queues only on MEC1.
To reflect this firmware change, this commit reduces number of compute pipelines
to 4 - 1, from 8 - 1 (the first pipeline is allocated for kgd).
Signed-off-by: Ben Goz <ben.goz@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit b6610101718d4ab90d793c482625e98eb1262cad upstream.
A normal wait adds to the front of the tail. By doing something
similar to fence_default_wait the fence code can run without racing.
This is a complete fix for "panic on suspend from KDE with radeon",
and a partial fix for "Radeon: System pauses on TAHITI". On tahiti
si_irq_set needs to be fixed too, to completely flush the writes
before radeon_fence_activity is called in radeon_fence_enable_signaling.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90741
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90861
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@ubuntu.com>
Reported-by: Jon Arne Jørgensen <jonjon.arnearne@gmail.com>
Reported-and-tested-by: Gustaw Smolarczyk <wielkiegie@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit a17d4996e051e78d164989b894608cf37cd5110b upstream.
Just keep it working, seems to fix some PLL problems.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=73378
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 77ae5f4b48a0445426c9c1ef7c0f28b717e35d55 upstream.
Need to double the viewport height.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 54acf107e4e66d1f4a697e08a7f60dba9fcf07c3 upstream.
To make sure the writes go through the pci bridge.
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=90741
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 0586915ec10d0ae60de5cd3381ad25a704760402 upstream.
To make sure the writes go through the pci bridge.
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=90741
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit cffefd9bb31cd35ab745d3b49005d10616d25bdc upstream.
To make sure the writes go through the pci bridge.
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=90741
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 9d1393f23d5656cdd5f368efd60694d4aeed81d3 upstream.
To make sure the writes go through the pci bridge.
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=90741
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit f957063fee6392bb9365370db6db74dc0b2dce0a upstream.
To make sure the writes go through the pci bridge.
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=90741
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit c320bb5f6dc0cb88a811cbaf839303e0a3916a92 upstream.
To make sure the writes go through the pci bridge.
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=90741
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit a28b2a47edcd0cb7c051b445f71a426000394606 upstream.
Passing zeroed drm_radeon_cs struct to DRM_IOCTL_RADEON_CS produces the
following oops.
Fix by always calling INIT_LIST_HEAD() to avoid the crash in list_sort().
----------------------------------
#include <stdint.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <drm/radeon_drm.h>
static const struct drm_radeon_cs cs;
int main(int argc, char **argv)
{
return ioctl(open(argv[1], O_RDWR), DRM_IOCTL_RADEON_CS, &cs);
}
----------------------------------
[ttrantal@test2 ~]$ ./main /dev/dri/card0
[ 46.904650] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 46.905022] IP: [<ffffffff814d6df2>] list_sort+0x42/0x240
[ 46.905022] PGD 68f29067 PUD 688b5067 PMD 0
[ 46.905022] Oops: 0002 [#1] SMP
[ 46.905022] CPU: 0 PID: 2413 Comm: main Not tainted 4.0.0-rc1+ #58
[ 46.905022] Hardware name: Hewlett-Packard HP Compaq dc5750 Small Form Factor/0A64h, BIOS 786E3 v02.10 01/25/2007
[ 46.905022] task: ffff880058e2bcc0 ti: ffff880058e64000 task.ti: ffff880058e64000
[ 46.905022] RIP: 0010:[<ffffffff814d6df2>] [<ffffffff814d6df2>] list_sort+0x42/0x240
[ 46.905022] RSP: 0018:ffff880058e67998 EFLAGS: 00010246
[ 46.905022] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[ 46.905022] RDX: ffffffff81644410 RSI: ffff880058e67b40 RDI: ffff880058e67a58
[ 46.905022] RBP: ffff880058e67a88 R08: 0000000000000000 R09: 0000000000000000
[ 46.905022] R10: ffff880058e2bcc0 R11: ffffffff828e6ca0 R12: ffffffff81644410
[ 46.905022] R13: ffff8800694b8018 R14: 0000000000000000 R15: ffff880058e679b0
[ 46.905022] FS: 00007fdc65a65700(0000) GS:ffff88006d600000(0000) knlGS:0000000000000000
[ 46.905022] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 46.905022] CR2: 0000000000000000 CR3: 0000000058dd9000 CR4: 00000000000006f0
[ 46.905022] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 46.905022] DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400
[ 46.905022] Stack:
[ 46.905022] ffff880058e67b40 ffff880058e2bcc0 ffff880058e67a78 0000000000000000
[ 46.905022] 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 46.905022] 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 46.905022] Call Trace:
[ 46.905022] [<ffffffff81644a65>] radeon_cs_parser_fini+0x195/0x220
[ 46.905022] [<ffffffff81645069>] radeon_cs_ioctl+0xa9/0x960
[ 46.905022] [<ffffffff815e1f7c>] drm_ioctl+0x19c/0x640
[ 46.905022] [<ffffffff810f8fdd>] ? trace_hardirqs_on_caller+0xfd/0x1c0
[ 46.905022] [<ffffffff810f90ad>] ? trace_hardirqs_on+0xd/0x10
[ 46.905022] [<ffffffff8160c066>] radeon_drm_ioctl+0x46/0x80
[ 46.905022] [<ffffffff81211868>] do_vfs_ioctl+0x318/0x570
[ 46.905022] [<ffffffff81462ef6>] ? selinux_file_ioctl+0x56/0x110
[ 46.905022] [<ffffffff81211b41>] SyS_ioctl+0x81/0xa0
[ 46.905022] [<ffffffff81dc6312>] system_call_fastpath+0x12/0x17
[ 46.905022] Code: 48 89 b5 10 ff ff ff 0f 84 03 01 00 00 4c 8d bd 28 ff ff
ff 31 c0 48 89 fb b9 15 00 00 00 49 89 d4 4c 89 ff f3 48 ab 48 8b 46 08 <48> c7
00 00 00 00 00 48 8b 0e 48 85 c9 0f 84 7d 00 00 00 c7 85
[ 46.905022] RIP [<ffffffff814d6df2>] list_sort+0x42/0x240
[ 46.905022] RSP <ffff880058e67998>
[ 46.905022] CR2: 0000000000000000
[ 47.149253] ---[ end trace 09576b4e8b2c20b8 ]---
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Tommi Rantala <tt.rantala@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
