| Age | Commit message (Collapse) | Author |
|---|
|
There is a possible race condition when we unregister the PCI Driver and then
flush/destroy the global "workq". This could lead to situations where there
are tasks on the Work Queue with references to now deleted adapter data
structures. Instead, have per-adapter Work Queues which were instantiated and
torn down in init_one() and remove_one(), respectively.
v2: Remove unnecessary call to flush_workqueue() before destroy_workqueue()
Signed-off-by: Anish Bhatt <anish@chelsio.com>
Signed-off-by: Casey Leedom <leedom@chelsio.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Currently the sh-intc driver is compiled on all SuperH and
non-multiplatform SH-Mobile platforms, while it's only used on a limited
number of platforms:
- SuperH: SH2(A), SH3(A), SH4(A)(L) (all but SH5)
- ARM: sh7372, sh73a0
Drop the "default y" on SH_INTC, make all CPU platforms that use it
select it, and protect all sub-options by "if SH_INTC" to fix this.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Magnus Damm <damm+renesas@opensource.se>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
|
|
Commit 91ebb929b6f8 ("bnx2x: Add support for Multi-Function UNDI") [which was
later supposedly fixed by de682941eef3 ("bnx2x: Fix UNDI driver unload")]
introduced a bug in which in some [yet-to-be-determined] scenarios the
alternative flushing mechanism which was to guarantee the Rx buffers are
empty before resetting them during device probe will fail.
If this happens, when device will be loaded once more a fatal attention will
occur; Since this most likely happens in boot from SAN scenarios, the machine
will fail to load.
Notice this may occur not only in the 'Multi-Function' scenario but in the
regular scenario as well, i.e., this introduced a regression in the driver's
ability to perform boot from SAN.
The patch reverts the mechanism and applies the old scheme to multi-function
devices as well as to single-function devices.
Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com>
Signed-off-by: Ariel Elior <Ariel.Elior@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Firmware binary file is in little endian. On big-endian architecture, while
writing this binary FW file to adapters memory, writel() swaps the data resulting into
corruption of FW image. So, swap the data before writing into adapters memory.
Signed-off-by: Shahed Shaikh <shahed.shaikh@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Firmware dump template header is read from adapter using
readl() which swaps the data. So, adjust structure
element on the boundary of 32bit dword.
Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
Signed-off-by: Shahed Shaikh <shahed.shaikh@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Application expects flash data in little endian, but driver reads/writes
flash data using readl()/writel() APIs which swaps data on big endian machine.
So, swap the data after reading from and before writing to flash memory.
Signed-off-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
Signed-off-by: Shahed Shaikh <shahed.shaikh@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Currently, macvlan code restricts multicast and unicast
filter setting only to passthru devices. As a result,
if a guest using macvtap wants to receive multicast
traffic, it has to set IFF_ALLMULTI or IFF_PROMISC.
This patch makes it possible to use the fdb interface
to add multicast addresses to the filter thus allowing
a guest to receive only targeted multicast traffic.
CC: John Fastabend <john.r.fastabend@intel.com>
CC: Michael S. Tsirkin <mst@redhat.com>
CC: Jason Wang <jasowang@redhat.com>
Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
Acked-by: John Fastabend <john.r.fastabend@intel.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://anongit.freedesktop.org/drm-intel
Display fixes from Ville and Imre, all cc: stable.
* tag 'drm-intel-fixes-2014-08-21' of git://anongit.freedesktop.org/drm-intel:
drm/i915: don't try to retrain a DP link on an inactive CRTC
drm/i915: make sure VDD is turned off during system suspend
drm/i915: cancel hotplug and dig_port work during suspend and unload
drm/i915: fix HPD IRQ reenable work cancelation
drm/i915: take display port power domain in DP HPD handler
drm/i915: Don't try to enable cursor from setplane when crtc is disabled
drm/i915: Skip load detect when intel_crtc->new_enable==true
drm/i915: Fix locking for intel_enable_pipe_a()
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata
Pull libata fixes from Tejun Heo:
"Nothing drastic but pushing out early due to build breakage in the new
tegra platform.
Additionally:
- M550 tagged trim blacklist pattern is widened so that it matches
the new 1TB model
- three controller specific fixes"
* 'for-3.17-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata:
libata: widen Crucial M550 blacklist matching
pata_scc: propagate return value of scc_wait_after_reset
ata: ahci_tegra: Change include to fix compilation
pata_samsung_cf: change ret type to signed
ahci_xgene: Removing NCQ support from the APM X-Gene SoC AHCI SATA Host Controller driver.
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid
Pull HID fixes from Jiri Kosina:
- fixes for a couple potential memory corruption problems (the HW would
have to be manufactured to be deliberately evil to trigger those)
found by Ben Hawkes
- fix for potential infinite loop when using sysfs interface of
logitech driver, from Simon Wood
- a couple more simple driver fixes
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid:
HID: fix a couple of off-by-ones
HID: logitech: perform bounds checking on device_id early enough
HID: logitech: fix bounds checking on LED report size
HID: logitech: Prevent possibility of infinite loop when using /sys interface
HID: rmi: print an error if F11 is not found instead of stopping the device
HID: hid-sensor-hub: use devm_ functions consistently
HID: huion: Use allocated buffer for DMA
HID: huion: Fail on parameter retrieval errors
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
Pull i2c fixes from Wolfram Sang:
"Here is the fixup for the 'lowlight' of my last pull request. I2C is
not selected anymore by I2C_ACPI. Instead, the code in question now
depends on I2C=y.
Also, Mika has agreed to support me and be the maintainer for I2C-ACPI
related patches. Finally, a new-ID-patch came along last week"
* 'i2c/for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
MAINTAINERS: add maintainer for ACPI parts of I2C
i2c: i801: Add PCI ID for Intel Braswell
i2c: rework kernel config I2C_ACPI
|
|
There are a few very theoretical off-by-one bugs in report descriptor size
checking when performing a pre-parsing fixup. Fix those.
Cc: stable@vger.kernel.org
Reported-by: Ben Hawkes <hawkes@google.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
device_index is a char type and the size of paired_dj_deivces is 7
elements, therefore proper bounds checking has to be applied to
device_index before it is used.
We are currently performing the bounds checking in
logi_dj_recv_add_djhid_device(), which is too late, as malicious device
could send REPORT_TYPE_NOTIF_DEVICE_UNPAIRED early enough and trigger the
problem in one of the report forwarding functions called from
logi_dj_raw_event().
Fix this by performing the check at the earliest possible ocasion in
logi_dj_raw_event().
Cc: stable@vger.kernel.org
Reported-by: Ben Hawkes <hawkes@google.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
The check on report size for REPORT_TYPE_LEDS in logi_dj_ll_raw_request()
is wrong; the current check doesn't make any sense -- the report allocated
by HID core in hid_hw_raw_request() can be much larger than
DJREPORT_SHORT_LENGTH, and currently logi_dj_ll_raw_request() doesn't
handle this properly at all.
Fix the check by actually trimming down the report size properly if it is
too large.
Cc: stable@vger.kernel.org
Reported-by: Ben Hawkes <hawkes@google.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
It appears that input sensing bit might be reset during
suspend/resume. Set input sensing again for all requested gpios
in resume
Tested-by: Jerome Blin <jerome.blin@intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
Currently after configuring a GPIO pin as an interrupt related pinmux
registers are changed, but there is no protection from calling
gpio_direction_*() in a badly written driver, which would cause the same
pinmux register to be reconfigured for regular input/output and this
disabling interrupt capability of the pin.
This patch addresses this issue by moving pinmux reconfiguration to
.irq_{request,release}_resources() callback of irq_chip and calling
gpio_lock_as_irq() helper to prevent reconfiguration of pin direction.
Setting up a GPIO interrupt on Samsung SoCs is a two-step operation -
in addition to trigger configuration in a dedicated register, the pinmux
must be also reconfigured to GPIO interrupt, which is a different function
than normal GPIO input, although I/O-wise they both behave in the same way
and gpio_get_value() can be used on a pin configured as IRQ as well.
Such design implies subtleties such as gpio_direction_input() not having
to fail if a pin is already configured as an interrupt nor change the
configuration to normal input. But the FLAG_USED_AS_IRQ set in gpiolib by
gpio_lock_as_irq() is only used to check that gpio_direction_output() is
not called, it's not used to prevent gpio_direction_input() to be called.
So this is not a complete solution for Samsung SoCs but it's definitely a
move in the right direction.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
[javier: use request resources instead of startup and expand commit message]
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
Once the CAN-bus is open and a packet is sent, the controller switches
into the PASSIVE state. Once the BUS is closed again it goes the back
err-warning. The TX error counter goes 0 -> 0x80 -> 0x7f.
This patch makes sure that the user learns about this state chang
(CAN_STATE_ERROR_WARNING => CAN_STATE_ERROR_PASSIVE)
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Matthias Klein <matthias.klein@optimeas.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
In case we don't have FLEXCAN_HAS_BROKEN_ERR_STATE and the user set
CAN_CTRLMODE_BERR_REPORTING once it can not be unset again until reboot.
So in case neither hardware nor user wants the error interrupt disable
the bit.
Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
devm_ioremap() returns NULL on error, not an ERR_PTR().
Fixes: 33cf75656923 ('can: c_can_platform: Fix raminit, use devm_ioremap() instead of devm_ioremap_resource()')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: linux-stable <stable@vger.kernel.org> # >= v3.11
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
When sja1000 is not compiled as module the SJA1000 chip is only
initialized during device registration on kernel boot. Should the chip
get a hardware reset there is no way to reinitialize it without re-
booting the Linux kernel.
This patch adds a check in sja1000_start if the chip is initialized, if
not we initialize it.
Signed-off-by: Mirza Krak <mirza.krak@hostmobility.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
Pull x86 platform driver revert from Matthew Garrett:
"This clearly shouldn't have been merged. No excuse on my part"
* 'for_linus' of git://cavan.codon.org.uk/platform-drivers-x86:
Revert "platform/x86/toshiba-apci.c possible bad if test?"
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"These are the two bug fixes I mentioned in the final merge window
pull. One is a reversed logic check in the device busy tests which
can cause a nasty hang and another crash seen in the new SCSI pool
support if the use count ever goes to zero"
[ The device busy test already got merged from a patch earlier, so is
now duplicated. ]
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
[SCSI] save command pool address of Scsi_Host
[SCSI] fix qemu boot hang problem
|
|
This reverts commit bdc3ae7221213963f438faeaa69c8b4a2195f491.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
|
|
The config symbol 'CONFIG_DEBUG_FS' should be protected by a 'ifdef' instead
of a plain 'if'.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
|
|
Signed-off-by: Hans Wennborg <hans@hanshq.net>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
|
|
Signed-off-by: Hans Wennborg <hans@hanshq.net>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
|
|
commit 257462dbf3ed ("pwm-backlight: switch to gpiod interface")
introduced a regression leading to acquiring a bogus GPIO-0 when
configured from DT without an 'enable-gpios' property.
The driver will happily accept the 0 initialized 'enable_gpio' member
of the struct platform_pwm_backlight_data as valid gpio number, and
request this GPIO as enable pin. In case of multiple driver instances,
the second will fail to register with the error message:
pwm-backlight backlight1.23: failed to request GPIO#0: -16
Fix this by setting enable_gpio in the pdata struct to -EINVAL.
Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
|
|
The latest kernel fails to boot qemu arm images when using scsi
for disk access. Boot gets stuck after the following messages.
brd: module loaded
sym53c8xx 0000:00:0c.0: enabling device (0100 -> 0103)
sym0: <895a> rev 0x0 at pci 0000:00:0c.0 irq 93
sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking
sym0: SCSI BUS has been reset.
scsi host0: sym-2.2.3
Bisect points to commit 71e75c97f97a ("scsi: convert device_busy to
atomic_t"). Code inspection shows the following suspicious change
in scsi_request_fn.
out_delay:
- if (sdev->device_busy == 0 && !scsi_device_blocked(sdev))
+ if (atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
blk_delay_queue(q, SCSI_QUEUE_DELAY);
}
'sdev->device_busy == 0' was replaced with 'atomic_read(&sdev->device_busy)',
meaning the logic was reversed. Changing this expression to
'!atomic_read(&sdev->device_busy)' fixes the problem.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Acked-by: Jens Axboe <axboe@fb.com>
Reviewed-by: Venkatesh Srinivas <venkateshs@google.com>
Reviewed-by: Webb Scales <webbnh@hp.com>
Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
This reverts commit 1490434f0da63afc6006411c8829c6a7935a4e7e.
Several people have reported regressions with this patch on kabini.
|
|
Need to initialize the mask to 0 on init, otherwise it
keeps increasing.
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=82581
v2: also fix cu count
v3: split count fix into separate patch
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Cc: stable@vger.kernel.org
|
|
This fixes the CU count reported to userspace for
OpenCL.
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=82581
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Cc: stable@vger.kernel.org
|
|
Now that the PFP and ME synchronization is fixed, we
can enable this again reliably.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
|
|
Fixes lockups due to CP read GPUVM faults when running piglit on Cape
Verde.
v2 (chk): apply the fix to R600+ as well, on CIK only the GFX CP has
a PFP, add more comments to R600 code, enable flushing again
v3: (agd5f): only apply to 7xx+. r6xx does not have the packet.
v4: (agd5f): split flush change into a separate patch, fix formatting
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
|
|
If the display hw was reset or a hard reset was used,
we need to re-init some of the common display hardware as well.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
|
|
pm_suspend is handled in the radeon_suspend callbacks.
pm_resume has special handling depending on whether
dpm or legacy pm is enabled. Change radeon_gpu_reset
to mirror the behavior in the suspend and resume
pathes.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
|
|
The SMBus host controller is the same as used in Baytrail so add the new
PCI ID to the driver's list of supported IDs.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
Commit da3c6647(I2C/ACPI: Clean up I2C ACPI code and Add CONFIG_I2C_ACPI
config) adds a new kernel config I2C_ACPI and make I2C core built in
when the config is selected. This is wrong because distributions
etc generally compile I2C as a module and the commit broken that.
This patch is to rename I2C_ACPI to ACPI_I2C_OPREGION. New config
only controls ACPI I2C operation region code and depends on I2C=y.
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
[wsa: removed unrelated change for Kconfig]
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
Pull md bugfixes from Neil Brown:
"Here are the bug-fixes I promised :-)
Funny how you start looking for one and other start appearing.
- raid6 data corruption during recovery
- raid6 livelock
- raid10 memory leaks"
* tag 'md/3.17-fixes' of git://neil.brown.name/md:
md/raid10: always initialise ->state on newly allocated r10_bio
md/raid10: avoid memory leak on error path during reshape.
md/raid10: Fix memory leak when raid10 reshape completes.
md/raid10: fix memory leak when reshaping a RAID10.
md/raid6: avoid data corruption during recovery of double-degraded RAID6
md/raid5: avoid livelock caused by non-aligned writes.
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci
Pull PCI changes from Bjorn Helgaas:
"Marvell MVEBU
- Remove ARCH_KIRKWOOD dependency (Andrew Lunn)
NVIDIA Tegra
- Add debugfs support (Thierry Reding)
Synopsys DesignWare
- Look for configuration space in 'reg', not 'ranges' (Kishon Vijay Abraham I)
- Program ATU with untranslated address (Kishon Vijay Abraham I)
- Add config access-related pcie_host_ops for v3.65 hardware (Murali Karicheri)
- Add MSI-related pcie_host_ops for v3.65 hardware (Murali Karicheri)
TI DRA7xx
- Add TI DR7xx PCIe driver (Kishon Vijay Abraham I)"
* tag 'pci-v3.17-changes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
PCI: designware: Add MSI-related pcie_host_ops for v3.65 hardware
PCI: designware: Add config access-related pcie_host_ops for v3.65 hardware
PCI: dra7xx: Add TI DRA7xx PCIe driver
PCI: designware: Program ATU with untranslated address
PCI: designware: Look for configuration space in 'reg', not 'ranges'
PCI: tegra: Add debugfs support
PCI: mvebu: Remove ARCH_KIRKWOOD dependency
|
|
Pull devicetree fixes from Grant Likely:
"Three more commits needed for v3.17: A bug fix for reserved regions
based at address zero, a clarification on how to interpret existence
of both interrupts and interrupts-extended properties, and a fix to
allow device tree testcases to run on any platform"
* tag 'devicetree-for-linus' of git://git.secretlab.ca/git/linux:
of/irq: Fix lookup to use 'interrupts-extended' property first
Enabling OF selftest to run without machine's devicetree
of: Allow mem_reserve of memory with a base address of zero
|
|
Most places which allocate an r10_bio zero the ->state, some don't.
As the r10_bio comes from a mempool, and the allocation function uses
kzalloc it is often zero anyway. But sometimes it isn't and it is
best to be safe.
I only noticed this because of the bug fixed by an earlier patch
where the r10_bios allocated for a reshape were left around to
be used by a subsequent resync. In that case the R10BIO_IsReshape
flag caused problems.
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
If raid10 reshape fails to find somewhere to read a block
from, it returns without freeing memory...
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
When a raid10 commences a resync/recovery/reshape it allocates
some buffer space.
When a resync/recovery completes the buffer space is freed. But not
when the reshape completes.
This can result in a small memory leak.
There is a subtle side-effect of this bug. When a RAID10 is reshaped
to a larger array (more devices), the reshape is immediately followed
by a "resync" of the new space. This "resync" will use the buffer
space which was allocated for "reshape". This can cause problems
including a "BUG" in the SCSI layer. So this is suitable for -stable.
Cc: stable@vger.kernel.org (v3.5+)
Fixes: 3ea7daa5d7fde47cd41f4d56c2deb949114da9d6
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
raid10 reshape clears unwanted bits from a bio->bi_flags using
a method which, while clumsy, worked until 3.10 when BIO_OWNS_VEC
was added.
Since then it clears that bit but shouldn't. This results in a
memory leak.
So change to used the approved method of clearing unwanted bits.
As this causes a memory leak which can consume all of memory
the fix is suitable for -stable.
Fixes: a38352e0ac02dbbd4fa464dc22d1352b5fbd06fd
Cc: stable@vger.kernel.org (v3.10+)
Reported-by: mdraid.pkoch@dfgh.net (Peter Koch)
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
Check for the ->map and not the ->unmap pointer.
Signed-off-by: Joerg Roedel <jroedel@suse.de>
|
|
Crucial M550 may cause data corruption on queued trims and is
blacklisted. The pattern used for it fails to match 1TB one as the
capacity section will be four chars instead of three. Widen the
pattern.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Charles Reiss <woggling@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=81071
Cc: stable@vger.kernel.org
|
|
It isn't necessary for command streams generated by the kernel (at least
not while we aren't storing ring or indirect buffers in VRAM).
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Instead of hard coding the value properly document
that this is an userspace interface.
No intended functional change.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
|
|
Atm we may retrain the DP link even if the CRTC is inactive through
HPD work->intel_dp_check_link_status(). This in turn can lock up the PHY
(at least on BYT), since the DP port is disabled.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81948
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org (3.16+)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Atm we may leave eDP VDD enabled during system suspend after the CRTCs
are disabled through an HPD->DPCD read event. So disable VDD during
suspend at a point when no HPDs can occur.
Note that runtime suspend doesn't have the same problem, since there the
RPM ref held by VDD provides already the needed serialization.
v2:
- add note to commit message about the runtime suspend path (Ville)
- use edp_panel_vdd_off_sync(), so we can keep the WARN in
edp_panel_vdd_off() (Ville)
v3:
- rebased on -fixes (for_each_intel_encoder()->list_for_each_entry())
(Imre)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v2)
Cc: stable@vger.kernel.org (3.16+)
[Jani: fix sparse warning reported by Fengguang Wu]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
