| Age | Commit message (Collapse) | Author |
|---|
|
All accesses to ipvlan->addrs are under rtnl.
Signed-off-by: Jiri Benc <jbenc@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Adding and removing to the 'ipvlans' list is already done using _rcu list
operations.
Signed-off-by: Jiri Benc <jbenc@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
When ipvlan interface with IP addresses attached is brought down and then
deleted, the assigned addresses are deleted twice from the address hash
list, first on the interface down and second on the link deletion.
Similarly, when an address is added while the interface is down, it is added
second time once the interface is brought up.
When the interface is down, the addresses should be kept off the hash list
for performance reasons. Ensure this is true, which also fixes the double add
problem. To fix the double free, check whether the address is hashed before
removing it.
Reported-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: Jiri Benc <jbenc@redhat.com>
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi into x86/urgent
Pull EFI fix from Matt Fleming:
- Fix integer overflow issue in the DMI SMBIOS 3.0 code when
calculating the number of DMI table entries. (Jean Delvare)
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata
Pull libata fixes from Tejun Heo:
"Nothing exciting. Two patches to update queued trim blacklist"
* 'for-4.0-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata:
libata: Blacklist queued TRIM on Samsung SSD 850 Pro
libata: Update Crucial/Micron blacklist
|
|
The vd->node is removed from the lists when the transfer started so the
vchan_get_all_descriptors() will not find it. This results memory leak.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
|
|
The vd->node is removed from the lists when the transfer started so the
vchan_get_all_descriptors() will not find it. This results memory leak.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
|
|
In omap_dma_start_desc the vdesc->node is removed from the virt-dma
framework managed lists (to be precise from the desc_issued list).
If a terminate_all comes before the transfer finishes the omap_desc will
not be freed up because it is not in any of the lists and we stopped the
DMA channel so the transfer will not going to complete.
There is no special sequence for leaking memory when using cyclic (audio)
transfer: with every start and stop of a cyclic transfer the driver leaks
struct omap_desc worth of memory.
Free up the allocated memory directly in omap_dma_terminate_all() since the
framework will not going to do that for us.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
CC: <stable@vger.kernel.org>
CC: <linux-omap@vger.kernel.org>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
|
|
If edma_terminate_all() was called while a transfer was running (i.e. after
edma_execute() but before edma_callback()) the echan->edesc was not freed.
This was due to the fact that a running transfer is on none of the
vchan lists: desc_submitted, desc_issued, desc_completed (edma_execute()
removes it from the desc_issued list), so the vchan_dma_desc_free_list()
called at the end of edma_terminate_all() didn't find it and didn't free it.
This bug was found on an AM1808 based hardware (very similar to da850evm,
however using the second MMC/SD controller), where intense operations on the SD
card wasted the device 128MB RAM within a couple of days.
Peter Ujfalusi:
The issue is even more severe since it affects cyclic (audio) transfers as
well. In this case starting/stopping audio will results memory leak.
Signed-off-by: Petr Kulhavy <petr@barix.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
CC: <stable@vger.kernel.org>
CC: <linux-omap@vger.kernel.org>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
|
|
Setup the capabilities of the device/driver, so that users of the DMAengine API
can query them.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull late GPIO fixes from Linus Walleij:
"Here are the (hopefully) last GPIO fixes for v4.0. Nothing
controversial whatsoever, just fixes:
- syscon GPIO fix for Keystone DSP GPIOs
- pin number translation fix for ACPI GPIO
- a smallish compiler warning fix on the mpc8xxx driver"
* tag 'gpio-v4.0-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
gpio: syscon: reduce message level when direction reg offset not in dt
gpiolib: translate pin number in GPIO ACPI callbacks
gpio: mpc8xxx: remove __initdata annotation for mpc8xxx_gpio_ids[]
|
|
Since
commit 17cabf571e50677d980e9ab2a43c5f11213003ae
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Jan 14 11:20:57 2015 +0000
drm/i915: Trim the command parser allocations
we may then try to allocate a zero-sized object and attempt to extract
its pages. Understandably this fails.
Note that the real offender seems to be
commit b9ffd80ed659c559152c042e74741f4f60cac691
Author: Brad Volkin <bradley.d.volkin@intel.com>
Date: Thu Dec 11 12:13:10 2014 -0800
drm/i915: Use batch length instead of object size in command parser
Testcase: igt/gem_exec_nop #ivb,byt,hsw
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[cherry picked from commit 743e78c1d726d875b98ff9689cc77c4d3d5d9ae2
from drm-intel-next because 4.0 seems to be affected by this too,
despite that the obvious culprit is definitely not in 4.0. Whatever,
if fixes a bug.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes
* fix a memory leak: we leaked memory each time the module
was loaded.
|
|
into drm-fixes
A few more fixes for 4.0 for radeon. Sorry for the delay, I was
a little under the weather this week and time got away from me.
* 'drm-fixes-4.0' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: programm the VCE fw BAR as well
drm/radeon: always dump the ring content if it's available
radeon: Do not directly dereference pointers to BIOS area.
drm/radeon/dpm: fix 120hz handling harder
|
|
The FEC modules used on i.MX28 and newer have a register to tune the MDIO
output hold time that should be at least 10 ns. Up to now this value was not
explicitly set and so resulted in less hold time if the fec clock was
faster than 100 MHz.
This was noticed on an i.MX28 machine that uses an input clock of ~150
Mhz which resulted in unreliable communication with a Marvell switch.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Fixes sparse warnings introduced in commit e85c9a7abfa407ed ("cxgb4/cxgb4vf: Add
code to calculate T5 BAR2 Offsets for SGE Queue Registers") and
df64e4d38c904dd3 ("cxgb4/cxgb4vf: Use new interfaces to calculate BAR2 SGE Queue
Register addresses") and few old ones
sparse warnings:
>> drivers/net/ethernet/chelsio/cxgb4vf/sge.c:1006:48: sparse: cast removes
>> address space of expression
>> drivers/net/ethernet/chelsio/cxgb4vf/sge.c:1006:48: sparse: incorrect type in
>> initializer (different address space)
>> drivers/net/ethernet/chelsio/cxgb4vf/sge.c:1020:40: sparse: incorrect type in
>> argument 1 (different base types)
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
|
|
If the ITS or the redistributors report their shareability as zero,
then it is important to make sure they will no generate any cacheable
traffic, as this is unlikely to produce the expected result.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1427465705-17126-5-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
|
The ITS driver sometime mixes up the use of GICR_PROPBASE bitfields
for the GICR_PENDBASE register, and GITS_BASER for GICR_CBASE.
This does not lead to any observable bug because similar bits are
at the same location, but this just make the code even harder to
understand...
This patch provides the required #defines and fixes the mixup.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1427465705-17126-4-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
|
When building ITS commands which have the device ID in it, we
should mask off the whole upper 32 bits of the first command word
before inserting the new value in there.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1427465705-17126-3-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
|
With a monolithic GICv3, redistributors are addressed using a linear
number, while a distributed implementation uses physical addresses.
When encoding a target address into a command, we strip the lower
16 bits, as redistributors are always 64kB aligned. This works
perfectly well with a distributed implementation, but has the
silly effect of always encoding target 0 in the monolithic case
(unless you have more than 64k CPUs, of course).
The obvious fix is to shift the linear target number by 16 when
computing the target address, so that we don't loose any precious
bit.
Reported-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1427465705-17126-2-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
|
Disable interrupts and quiesce rx before unregistering net device to avoid crash
while unloading driver when traffic is flowing through.
Based on original work by Shameem Khalid <shameem@chelsio.com>
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
QIDs (egress/ingress) from firmware in FW_*_CMD.alloc command
can be anywhere in the range from EQ(IQFLINT)_START to EQ(IQFLINT)_END.
For eg, in the first load eqid can be from 100 to 300.
In the next load it can be from 301 to 500 (assume eq_start is 100 and eq_end is
1000).
The driver was assuming them to always start from EQ(IQFLINT)_START till
MAX_EGRQ(INGQ). This was causing stack overflow and subsequent crash.
Fixed it by dynamically allocating memory (of qsize (x_END - x_START + 1)) for
these structures.
Based on original work by Santosh Rastapur <santosh@chelsio.com>
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
cdc_ncm disagrees with usbnet about how much framing overhead should
be counted in the tx_bytes statistics, and tries 'fix' this by
decrementing tx_bytes on the transmit path. But statistics must never
be decremented except due to roll-over; this will thoroughly confuse
user-space. Also, tx_bytes is only incremented by usbnet in the
completion path.
Fix this by requiring drivers that set FLAG_MULTI_FRAME to set a
tx_bytes delta along with the tx_packets count.
Fixes: beeecd42c3b4 ("net: cdc_ncm/cdc_mbim: adding NCM protocol statistics")
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
|
|
Currently the usbnet core does not update the tx_packets statistic for
drivers with FLAG_MULTI_PACKET and there is no hook in the TX
completion path where they could do this.
cdc_ncm and dependent drivers are bumping tx_packets stat on the
transmit path while asix and sr9800 aren't updating it at all.
Add a packet count in struct skb_data so these drivers can fill it
in, initialise it to 1 for other drivers, and add the packet count
to the tx_packets statistic on completion.
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Tested-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull timer fixes from Ingo Molnar:
"Two clocksource driver fixes, and an idle loop RCU warning fix"
* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
clocksource/drivers/sun5i: Fix cpufreq interaction with sched_clock()
clocksource/drivers: Fix various !CONFIG_HAS_IOMEM build errors
timers/tick/broadcast-hrtimer: Fix suspicious RCU usage in idle loop
|
|
This patch uses iio_trigger_get to increment the reference
count of trigger device, to avoid incorrect assignment.
Can result in a null pointer dereference during removal if the
trigger has been changed before removal.
This patch refers to a similar situation encountered through the
following discussion:
http://www.spinics.net/lists/linux-iio/msg13669.html
Signed-off-by: Darshana Padmadas <darshanapadmadas@gmail.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
Depending on conversion mode used, the ADC clock (ADCK) needs
to be below a maximum frequency. According to Vybrid's data
sheet this is 20MHz for the low power conversion mode.
The ADC clock is depending on input clock, which is the bus
clock by default. Vybrid SoC are typically clocked at at 400MHz
or 500MHz, which leads to 66MHz or 83MHz bus clock respectively.
Hence, a divider of 8 is required to stay below the specified
maximum clock of 20MHz.
Due to the different bus clock speeds, the resulting sampling
frequency is not static. Hence use the ADC clock and calculate
the actual available sampling frequency dynamically.
This fixes bogous values observed on some 500MHz clocked Vybrid
SoC. The resulting value usually showed Bit 9 being stuck at 1,
or 0, which lead to a value of +/-512.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Acked-by: Fugang Duan <B38611@freescale.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
Fixes:
drivers/built-in.o: In function `cc10001_adc_probe':
cc10001_adc.c:(.text+0x412e92): undefined reference to `devm_ioremap_resource'
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
The "sdc" node is missing the ranges property, it needs to be treated
as having an empty one otherwise translation fails for its children.
Fixes 746c9e9f92dd, "of/base: Fix PowerPC address parsing hack"
Tested-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Grant Likely <grant.likely@linaro.org>
Cc: Stable <stable@vger.kernel.org> # v3.18+
|
|
Blacklist queued TRIM on this drive for now.
Reported-by: Stefan Keller <linux-list@zahlenfresser.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
CC: stable@vger.kernel.org
Signed-off-by: Tejun Heo <tj@kernel.org>
|
|
Micron has released an updated firmware (MU02) for M510/M550/MX100
drives to fix the issues with queued TRIM. Queued TRIM remains broken on
M500 but is working fine on later drives such as M600 and MX200.
Tweak our blacklist to reflect the above.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=71371
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Cc: stable@vger.kernel.org
Signed-off-by: Tejun Heo <tj@kernel.org>
|
|
Otherwise the VCE firmware needs to be in the first 256MB of VRAM.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Dumping is still possible if a ring isn't ready, only when it
isn't allocated at all we need to abort here.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Use readb() and memcpy_fromio() accessors instead.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
|
|
Need to expand the check to handle short circuiting
if the selected state is the same as current state.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=87796
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
|
|
If the user supplies EDID through firmware or debugfs override, the
driver callbacks are bypassed and the connector ELD does not get
updated, and audio fails. Set ELD for firmware and debugfs EDIDs too.
There should be no harm in gratuitously doing this for non HDMI/DP
connectors, as it's still up to the driver to use the ELD, if any.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82349
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=80691
Reported-by: Emil <emilsvennesson@gmail.com>
Reported-by: Rob Engle <grenoble@gmail.com>
Tested-by: Jolan Luff <jolan@gormsby.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
dmi_num is a u16, dmi_len is a u32, so this construct:
dmi_num = dmi_len / 4;
would result in an integer overflow for a DMI table larger than
256 kB. I've never see such a large table so far, but SMBIOS 3.0
makes it possible so maybe we'll see such tables in the future.
So instead of faking a structure count when the entry point does
not provide it, adjust the loop condition in dmi_table() to properly
deal with the case where dmi_num is not set.
This bug was introduced with the initial SMBIOS 3.0 support in commit
fc43026278b2 ("dmi: add support for SMBIOS 3.0 64-bit entry point").
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: Matt Fleming <matt.fleming@intel.com>
Cc: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Cc: <stable@vger.kernel.org>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
Now GPIO syscon driver produces bunch of warnings during the
boot of Kesytone 2 SoCs:
gpio-syscon soc:keystone_dsp_gpio@02620240: can't read the dir register offset!
gpio-syscon soc:keystone_dsp_gpio@2620244: can't read the dir register offset!
This message unintentionally was added using dev_err(), but its
actual log level is debug, because third cell of "ti,syscon-dev" is
optional.
Hence change it to dev_dbg() as it should be.
This patch fixes commit:
5a3e3f8 ("gpio: syscon: retriave syscon node and regs offsets from dt")
Reported-by: Russell King <linux@arm.linux.org.uk>
Tested-by: Murali Karicheri <m-karicheri2@ti.com>
Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
Signed-off-by: Grygorii Strashko <grygorii.strashko@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
The IMG PDC watchdog driver heartbeat module parameter has no default so
it is initialised to zero. This results in the following warning during
probe:
imgpdc-wdt 2006000.wdt: Initial timeout out of range! setting max timeout
The module parameter description implies that the default value should
be PDC_WDT_DEF_TIMEOUT, which isn't yet used, so initialise it to that.
Also tweak the heartbeat module parameter description for consistency.
Fixes: 93937669e9b5 ("watchdog: ImgTec PDC Watchdog Timer Driver")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Ezequiel Garcia <ezequiel.garcia@imgtec.com>
Cc: Naidu Tellapati <Naidu.Tellapati@imgtec.com>
Cc: Jude Abraham <Jude.Abraham@imgtec.com>
Cc: linux-watchdog@vger.kernel.org
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
|
|
The IMG PDC watchdog probe function calls pdc_wdt_stop() prior to
watchdog_set_drvdata(), causing a NULL pointer dereference when
pdc_wdt_stop() retrieves the struct pdc_wdt_dev pointer using
watchdog_get_drvdata() and reads the register base address through it.
Fix by moving the watchdog_set_drvdata() call earlier, to where various
other pdc_wdt->wdt_dev fields are initialised.
Fixes: 93937669e9b5 ("watchdog: ImgTec PDC Watchdog Timer Driver")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Ezequiel Garcia <ezequiel.garcia@imgtec.com>
Cc: Naidu Tellapati <Naidu.Tellapati@imgtec.com>
Cc: Jude Abraham <Jude.Abraham@imgtec.com>
Cc: linux-watchdog@vger.kernel.org
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
|
|
"ret" should be signed for the error handling to work correctly. This
doesn't matter much in real life since mtk_wdt_set_timeout() always
succeeds.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
|
|
When the receiver was enabled during startup, a character could
have been in the FIFO when the UART get initially used. The
driver configures the (receive) watermark level, and flushes the
FIFO. However, the receive flag (RDRF) could still be set at that
stage (as mentioned in the register description of UARTx_RWFIFO).
This leads to an interrupt which won't be handled properly in
interrupt mode: The receive interrupt function lpuart_rxint checks
the FIFO count, which is 0 at that point (due to the flush
during initialization). The problem does not manifest when using
DMA to receive characters.
Fix this situation by explicitly read the status register, which
leads to clearing of the RDRF flag. Due to the flush just after
the status flag read, a explicit data read is not to required.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Specify transmit FIFO size which might be different depending on
LPUART instance. This makes sure uart_wait_until_sent in serial
core getting called, which in turn waits and checks if the FIFO
is really empty on shutdown by using the tx_empty callback.
Without the call of this callback, the last several characters
might not yet be transmitted when closing the serial port. This
can be reproduced by simply using echo and redirect the output to
a ttyLP device.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Exynos serial ports operate either in a DMA-based or interrupt-based
modes. In DMA-based mode, the UART generates a transfer data request
and a Transmission (Tx) interrupt in interrupt-based mode.
The Tx IRQ is only unmasked in interrupt-based mode and it was done
in s3c24xx_serial_start_tx(). Commit ba019a3e2ad5 ("serial: samsung:
remove redundant interrupt enabling") removed the IRQ enable on that
function since it is enabled when the mode is set in enable_tx_pio().
The problem is that enable_tx_pio() is only called if the port mode
has not been set before but the mode was not cleared on .shutdown().
So if the UART was shutdown and then started up again, the mode set
will remain and the Tx IRQ won't be unmasked.
This caused a hang on at least Exynos5250, Exynos5420 and Exynos5800
when the system is rebooted or powered off.
Fixes: ba019a3e2ad5 ("serial: samsung: remove redundant interrupt enabling")
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Pull drm refcounting fixes from Dave Airlie:
"Here is the complete set of i915 bug/warn/refcounting fixes"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/i915: Fixup legacy plane->crtc link for initial fb config
drm/i915: Fix atomic state when reusing the firmware fb
drm/i915: Keep ring->active_list and ring->requests_list consistent
drm/i915: Don't try to reference the fb in get_initial_plane_config()
drm: Fixup racy refcounting in plane_force_disable
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
Pull device mapper fix from Mike Snitzer:
"Fix DM core device cleanup regression -- due to a latent race that was
exposed by the bdi changes that were introduced during the 4.0 merge"
* tag 'dm-4.0-fix-2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
dm: fix add_disk() NULL pointer due to race with free_dev()
|
|
This is a very similar bug in the load detect code fixed in
commit 9128b040eb774e04bc23777b005ace2b66ab2a85
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Mar 3 17:31:21 2015 +0100
drm/i915: Fix modeset state confusion in the load detect code
But this time around it was the initial fb code that forgot to update
the plane->crtc pointer. Otherwise it's the exact same bug, with the
exact same restrains (any set_config call/ioctl that doesn't disable
the pipe papers over the bug for free, so fairly hard to hit in normal
testing). So if you want the full explanation just go read that one
over there - it's rather long ...
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Josh Boyer <jwboyer@fedoraproject.org>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Reported-and-tested-by: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[Jani: backported to drm-intel-fixes for v4.0-rc]
Reference: http://mid.gmane.org/CA+5PVA7ChbtJrknqws1qvZcbrg1CW2pQAFkSMURWWgyASRyGXg@mail.gmail.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Right now, we get a warning when taking over the firmware fb:
[drm:drm_atomic_plane_check] FB set but no CRTC
with the following backtrace:
[<ffffffffa010339d>] drm_atomic_check_only+0x35d/0x510 [drm]
[<ffffffffa0103567>] drm_atomic_commit+0x17/0x60 [drm]
[<ffffffffa00a6ccd>] drm_atomic_helper_plane_set_property+0x8d/0xd0 [drm_kms_helper]
[<ffffffffa00f1fed>] drm_mode_plane_set_obj_prop+0x2d/0x90 [drm]
[<ffffffffa00a8a1b>] restore_fbdev_mode+0x6b/0xf0 [drm_kms_helper]
[<ffffffffa00aa969>] drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
[<ffffffffa00aa9e2>] drm_fb_helper_set_par+0x22/0x50 [drm_kms_helper]
[<ffffffffa050a71a>] intel_fbdev_set_par+0x1a/0x60 [i915]
[<ffffffff813ad444>] fbcon_init+0x4f4/0x580
That's because we update the plane state with the fb from the firmware, but we
never associate the plane to that CRTC.
We don't quite have the full DRM take over from HW state just yet, so
fake enough of the plane atomic state to pass the checks.
v2: Fix the state on which we set the CRTC in the case we're sharing the
initial fb with another pipe. (Matt)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[Jani: backported to drm-intel-fixes for v4.0-rc]
Reference: http://mid.gmane.org/CA+5PVA7yXH=U757w8V=Zj2U1URG4nYNav20NpjtQ4svVueyPNw@mail.gmail.com
Reference: http://lkml.kernel.org/r/CA+55aFweWR=nDzc2Y=rCtL_H8JfdprQiCimN5dwc+TgyD4Bjsg@mail.gmail.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
The sun5i timer is used as the sched-clock on certain systems, and ever
since we started using cpufreq, the cpu clock (that is one of the
timer's clock indirect parent) now changes as well, along with the
actual sched_clock() rate.
This is not accurate and not desirable.
We can safely remove the sun5i sched-clock on those systems, since we
have other reliable sched_clock() sources in the system.
Tested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
[ Improved the changelog. ]
Cc: richard@nod.at
Link: http://lkml.kernel.org/r/1427362029-6511-4-git-send-email-daniel.lezcano@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
