summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2015-03-05Merge branch 'clockevents/4.0-rc2' of ↵Ingo Molnar
http://git.linaro.org/people/daniel.lezcano/linux into timers/urgent Pull clockevents fixes from Daniel Lezcano: " These two patches fix a potential crash at boot time. - Fix setup_irq / clockevents_config_and_register init ordering in order to prevent to have an interrupt to be fired before the handler is set for sun5i and efm32. (Yongbae Park)" Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-03-05dmaengine: mmp_pdma: fix warning about slave capsRobert Jarzmik
Fix the dmaengine complaint about missing slave caps : - declare the available bus widths - declare the available transfer types - declare the residue calculation type Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-03-05x86/intel/quark: Select COMMON_CLKAndy Shevchenko
The commit 8bbc2a135b63 ("x86/intel/quark: Add Intel Quark platform support") introduced a minimal support of Intel Quark SoC. That allows to use core parts of the SoC. However, the SPI, I2C, and GPIO drivers can't be selected by kernel configuration because they depend on COMMON_CLK. The patch adds a COMMON_CLK selection to the platfrom definition to allow user choose the drivers. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Ong, Boon Leong <boon.leong.ong@intel.com> Cc: Bryan O'Donoghue <pure.logic@nexus-software.ie> Cc: Darren Hart <dvhart@linux.intel.com> Fixes: 8bbc2a135b63 ("x86/intel/quark: Add Intel Quark platform support") Link: http://lkml.kernel.org/r/1425569044-2867-1-git-send-email-andriy.shevchenko@linux.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-03-05dmaengine: qcom_bam_dma: fix wrong register offsetsStanimir Varbanov
The commit fb93f520e (dmaengine: qcom_bam_dma: Generalize BAM register offset calculations) wrongly populated base offsets for event registers for bam v1.4. Signed-off-by: Stanimir Varbanov <svarbanov@mm-sol.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> Reviewed-by: Andy Gross <agross@codeaurora.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-03-05dmaengine: bam-dma: fix a warning about missing capabilitiesStanimir Varbanov
Avoid the warning below triggered during dmaengine async device registration. WARNING: CPU: 1 PID: 1 at linux/drivers/dma/dmaengine.c:863 dma_async_device_register+0x2a8/0x4b8() this driver doesn't support generic slave capabilities reporting To do that fill mandatory .directions bit mask, .src/dst_addr_widths and .residue_granularity dma_device fields with appropriate values. Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-03-05Merge tag 'usb-serial-4.0-rc3' of ↵Greg Kroah-Hartman
git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus Johan writes: USB-serial fixes for v4.0-rc3 Here are a few fixes for reported problems including a usb-debug device buffer overflow, potential use-after-free on failed probe, and a couple of issues with the USB console. Some new device IDs are also added. Signed-off-by: Johan Hovold <johan@kernel.org>
2015-03-05Merge tag 'nbd_fixes_20150305' of git://git.pengutronix.de/git/mpa/linux-nbd ↵Jens Axboe
into for-linus NBD fixes based on v4.0-rc1
2015-03-05clockevents: sun5i: Fix setup_irq init sequenceYongbae Park
The interrupt is enabled before the handler is set. Even this bug did not appear, it is potentially dangerous as it can lead to a NULL pointer dereference. Fix the error by enabling the interrupt after clockevents_config_and_register() is called. Cc: stable@vger.kernel.org Signed-off-by: Yongbae Park <yongbae2@gmail.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2015-03-05clocksource: efm32: Fix a NULL pointer dereferenceYongbae Park
The initialisation of the efm32 clocksource first sets up the irq and only after that initialises the data needed for irq handling. In case this initialisation is delayed the irq handler would dereference a NULL pointer. I'm not aware of anything that could delay the process in such a way, but it's better to be safe than sorry, so setup the irq only when the clock event device is ready. Cc: stable@vger.kernel.org Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Yongbae Park <yongbae2@gmail.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2015-03-05workqueue: fix hang involving racing cancel[_delayed]_work_sync()'s for ↵Tejun Heo
PREEMPT_NONE cancel[_delayed]_work_sync() are implemented using __cancel_work_timer() which grabs the PENDING bit using try_to_grab_pending() and then flushes the work item with PENDING set to prevent the on-going execution of the work item from requeueing itself. try_to_grab_pending() can always grab PENDING bit without blocking except when someone else is doing the above flushing during cancelation. In that case, try_to_grab_pending() returns -ENOENT. In this case, __cancel_work_timer() currently invokes flush_work(). The assumption is that the completion of the work item is what the other canceling task would be waiting for too and thus waiting for the same condition and retrying should allow forward progress without excessive busy looping Unfortunately, this doesn't work if preemption is disabled or the latter task has real time priority. Let's say task A just got woken up from flush_work() by the completion of the target work item. If, before task A starts executing, task B gets scheduled and invokes __cancel_work_timer() on the same work item, its try_to_grab_pending() will return -ENOENT as the work item is still being canceled by task A and flush_work() will also immediately return false as the work item is no longer executing. This puts task B in a busy loop possibly preventing task A from executing and clearing the canceling state on the work item leading to a hang. task A task B worker executing work __cancel_work_timer() try_to_grab_pending() set work CANCELING flush_work() block for work completion completion, wakes up A __cancel_work_timer() while (forever) { try_to_grab_pending() -ENOENT as work is being canceled flush_work() false as work is no longer executing } This patch removes the possible hang by updating __cancel_work_timer() to explicitly wait for clearing of CANCELING rather than invoking flush_work() after try_to_grab_pending() fails with -ENOENT. Link: http://lkml.kernel.org/g/20150206171156.GA8942@axis.com v3: bit_waitqueue() can't be used for work items defined in vmalloc area. Switched to custom wake function which matches the target work item and exclusive wait and wakeup. v2: v1 used wake_up() on bit_waitqueue() which leads to NULL deref if the target bit waitqueue has wait_bit_queue's on it. Use DEFINE_WAIT_BIT() and __wake_up_bit() instead. Reported by Tomeu Vizoso. Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: Rabin Vincent <rabin.vincent@axis.com> Cc: Tomeu Vizoso <tomeu.vizoso@gmail.com> Cc: stable@vger.kernel.org Tested-by: Jesper Nilsson <jesper.nilsson@axis.com> Tested-by: Rabin Vincent <rabin.vincent@axis.com>
2015-03-05ASoC: fsl_ssi: Don't try to round-up for PM divisor calculationNicolin Chen
According to i.MX6 Series Reference Manual, the formula to calculate the sys clock is sysclk rate = bclk rate * (div2 + 1) * (7 * psr + 1) * (pm + 1) * 2 Commit aafa85e71a75 ("ASoC: fsl_ssi: Add DAI master mode support for SSI on i.MX series") added the divisor calculation which relies on the clk_round_rate(). However, at that time, clk_round_rate() didn't provide closest clock rates for some cases because it might not use a correct rounding policy. So using the original formula (pm + 1) for PM divisor was not able to give us a desired clock rate. And then we used (pm + 2) to do the trick. However, the clk-divider driver has been refined a lot since commit b11d282dbea2 ("clk: divider: fix rate calculation for fractional rates") Now using (pm + 2) trick would result an incorrect clock rate. So this patch fixes the problem by removing the useless trick. Reported-by: Stephane Cerveau <scerveau@voxtok.com> Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-03-05iwlwifi: mvm: BT Coex - fix a NULL pointer exceptionEmmanuel Grumbach
The commit below introduced an unsafe dereference of mvmvif->phy_ctxt. It can be NULL even if we hold the mutex. We can be handling a BT Coex notification while the vif has already been unassigned. This can happen since the BT Coex notification is hanled asynchronuously: we can have started to handle the BT Coex notification trying to acquire the mutex while the unassign flow already got it. The BT Coex notification handling will wait for the mutext. I'll get it later, but then mvmvif->phy_ctxt will be NULL. Panic log: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<f985180d>] iwl_mvm_bt_notif_iterator+0x9d/0x340 [iwlmvm] *pdpt = 0000000000000000 *pde = f000eef300000007 Oops: 0000 [#1] SMP Workqueue: events iwl_mvm_async_handlers_wk [iwlmvm] task: ed719b20 ti: ec03e000 task.ti: ec03e000 EIP: 0060:[<f985180d>] EFLAGS: 00010202 CPU: 2 EIP is at iwl_mvm_bt_notif_iterator+0x9d/0x340 [iwlmvm] EAX: 00000000 EBX: f6d3cb70 ECX: f6d3cb70 EDX: 00000000 ESI: ec03fe40 EDI: efeb8810 EBP: ec03fdf0 ESP: ec03fdac DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 CR0: 80050033 CR2: 00000000 CR3: 01a1a000 CR4: 001407f0 Stack: f743ca80 f744a404 ec03fdcc c10e3952 00003aba f743ca80 00000246 f743ca80 00000246 00000000 00000001 00000000 ebd45ff6 ebd458a4 f6d3c500 ebd45578 ebd44b01 ec03fe18 f99e1bc2 00000002 ebd44bc0 f9851770 00000000 f6d3c500 Call Trace: [<c10e3952>] ? ring_buffer_unlock_commit+0xa2/0xd0 [<f99e1bc2>] __iterate_interfaces+0x82/0x110 [mac80211] [<f9851770>] ? iwl_mvm_bt_coex_reduced_txp+0x140/0x140 [iwlmvm] [<f99e1c6a>] ieee80211_iterate_active_interfaces_atomic+0x1a/0x20 [mac80211] [<f9851427>] iwl_mvm_bt_coex_notif_handle+0x77/0x280 [iwlmvm] [<f9852161>] iwl_mvm_rx_bt_coex_notif_old+0x211/0x220 [iwlmvm] [<f9850b8b>] iwl_mvm_rx_bt_coex_notif+0x19b/0x1b0 [iwlmvm] [<f983944f>] iwl_mvm_async_handlers_wk+0x7f/0xe0 [iwlmvm] CC: <stable@vger.kernel.org> [3.19+] Fixes: 123f515635b1 ("iwlwifi: mvm: BT Coex - add support for TTC / RRC") Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2015-03-05ALSA: line6: Clamp values correctlyTakashi Iwai
The usages of clamp() macro in sound/usb/line6/playback.c are just wrong, the low and high values are swapped. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-03-05ALSA: msnd: add some missing curly bracesDan Carpenter
There were some curly braces intended here. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-03-05ARM: at91/pm: MOR register KEY was missingPatrice Vilchez
Because writing the MOR register requires the PASSWD(0x37), if missed, the write operation will be aborted. Signed-off-by: Patrice Vilchez <patrice.vilchez@atmel.com> Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
2015-03-05ARM: at91/dt: sama5d4: fix lcdck clock definitionBoris BREZILLON
lcdck takes mck (not smd) as its parent. It is also assigned id 3 and not 4. Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com> [nicolas.ferre@atmel.com: squashed 2 related patches] Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
2015-03-05ARM: at91/dt: sama5d4: rename lcd_clk into lcdc_clkBoris BREZILLON
Rename lcd_clk into lcdc_clk to be consistent with sama5d3 clock definitions. Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
2015-03-05ARM: at91: debug: fix non MMU debugAlexandre Belloni
Linux may be used without MMU on atmel SoCs, fix debug in this configuration. Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
2015-03-05Revert "pinctrl: consumer: use correct retval for placeholder functions"Linus Walleij
This reverts commit 5a7d2efdd93f6c4bb6cd3d5df3d2f5611c9b87ac. As per discussion on the mailing list, this is not the right thing to do. NULL cookies are valid in the stubs. Reported-by: Wolfram Sang <wsa@the-dreams.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-03-05dmaengine: ioatdma: workaround for incorrect DMACAP registerDave Jiang
BDX-DE IOATDMA reports incorrect DMACAP register for PQ related ops. Ignoring those bits. Signed-off-by: Dave Jiang <dave.jiang@intel.com> Acked-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-03-05dmaengine: at_xdmac: fix for chan conf simplificationLudovic Desroches
When simplificating the channel configuration, the cyclic case has been forgotten. It leads to use bad configuration causing many bugs. Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-03-05dmaengine: dw: don't handle interrupt when dmaengine is not usedJie Yang
When dma controller is not used by any user and set off, we should disble interrupt handler, at least the interrupt reset part, for some subsystem, e.g. ADSP, may use the dma in its own logic, here reset the interrupt may make this subsystem work abnormally. Signed-off-by: Jie Yang <yang.jie@intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-03-05nbd: fix possible memory leakSudip Mukherjee
we have already allocated memory for nbd_dev, but we were not releasing that memory and just returning the error value. Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Acked-by: Paul Clements <Paul.Clements@SteelEye.com> Cc: <stable@vger.kernel.org> Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
2015-03-05thermal: Make sysfs attributes of cooling devices default attributesMatthias Kaehlcke
Default attributes are created when the device is registered. Attributes created after device registration can lead to race conditions, where user space (e.g. udev) sees the device but not the attributes. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2015-03-05Thermal/int340x: Fix memleak for aux tripSrinivas Pandruvada
When thermal zone device register fails or on module exit, the memory for aux_trip is not freed. This change fixes this issue. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2015-03-04seq_buf: Fix seq_buf_bprintf() truncationSteven Rostedt (Red Hat)
In seq_buf_bprintf(), bstr_printf() is used to copy the format into the buffer remaining in the seq_buf structure. The return of bstr_printf() is the amount of characters written to the buffer excluding the '\0', unless the line was truncated! If the line copied does not fit, it is truncated, and a '\0' is added to the end of the buffer. But in this case, '\0' is included in the length of the line written. To know if the buffer had overflowed, the return length will be the same or greater than the length of the buffer passed in. The check in seq_buf_bprintf() only checked if the length returned from bstr_printf() would fit in the buffer, as the seq_buf_bprintf() is only to be an all or nothing command. It either writes all the string into the seq_buf, or none of it. If the string is truncated, the pointers inside the seq_buf must be reset to what they were when the function was called. This is not the case. On overflow, it copies only part of the string. The fix is to change the overflow check to see if the length returned from bstr_printf() is less than the length remaining in the seq_buf buffer, and not if it is less than or equal to as it currently does. Then seq_buf_bprintf() will know if the write from bstr_printf() was truncated or not. Link: http://lkml.kernel.org/r/1425500481.2712.27.camel@perches.com Cc: stable@vger.kernel.org Reported-by: Joe Perches <joe@perches.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2015-03-04ARM: fix typos in smc91x platform dataArnd Bergmann
I recently did a rework of the smc91x driver and did some build-testing by compiling hundreds of randconfig kernels. Unfortunately, my script was wrong and did not actually test the configurations that mattered, so I introduced stupid typos in almost every file I touched. I fixed my script now, built all configurations that actually matter and fixed all the typos, this is the result. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: b70661c70830d ("net: smc91x: use run-time configuration on all ARM machines") Signed-off-by: David S. Miller <davem@davemloft.net>
2015-03-05virtio_console: avoid config access from irqMichael S. Tsirkin
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> Cc: stable@kernel.org
2015-03-05virtio_console: init work unconditionallyMichael S. Tsirkin
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> Cc: stable@kernel.org
2015-03-05fsl_ssi: fix of_property_read_u32_array return value checkMaciej S. Szmigiero
of_property_read_u32_array returns 0 on success, so the return value shouldn't be inverted twice, first on assignment then in condition expression. Signed-off-by: Maciej Szmigiero <mail@maciej.szmigiero.name> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-03-05ASoC: sn95031: Fix control-less DAPM routesLars-Peter Clausen
Routes without a control must use NULL for the control name. The sn95031 driver uses "NULL" instead in a few places. Previous to commit 5fe5b767dc6f ("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets") the DAPM core silently ignored non-NULL controls on non-mixer and non-mux routes. But starting with that commit it will complain and not add the route breaking the sn95031 driver in the process. This patch replaces the incorrect "NULL" control name with NULL to fix the issue. Fixes: 5fe5b767dc6f ("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets") Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
2015-03-05ASoC: da732x: Fix control-less DAPM routesLars-Peter Clausen
Routes without a control must use NULL for the control name. The da732x driver uses "NULL" instead in a few places. Previous to commit 5fe5b767dc6f ("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets") the DAPM core silently ignored non-NULL controls on non-mixer and non-mux routes. But starting with that commit it will complain and not add the route breaking the da732x driver in the process. This patch replaces the incorrect "NULL" control name with NULL to fix the issue. Fixes: 5fe5b767dc6f ("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets") Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
2015-03-05ASoC: ak4671: Fix control-less DAPM routesLars-Peter Clausen
Routes without a control must use NULL for the control name. The ak4671 driver uses "NULL" instead in a few places. Previous to commit 5fe5b767dc6f ("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets") the DAPM core silently ignored non-NULL controls on non-mixer and non-mux routes. But starting with that commit it will complain and not add the route breaking the ak4671 driver in the process. This patch replaces the incorrect "NULL" control name with NULL to fix the issue. Fixes: 5fe5b767dc6f ("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets") Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
2015-03-05x86/asm/entry/64: Remove a bogus 'ret_from_fork' optimizationAndy Lutomirski
'ret_from_fork' checks TIF_IA32 to determine whether 'pt_regs' and the related state make sense for 'ret_from_sys_call'. This is entirely the wrong check. TS_COMPAT would make a little more sense, but there's really no point in keeping this optimization at all. This fixes a return to the wrong user CS if we came from int 0x80 in a 64-bit task. Signed-off-by: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@alien8.de> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: <stable@vger.kernel.org> Link: http://lkml.kernel.org/r/4710be56d76ef994ddf59087aad98c000fbab9a4.1424989793.git.luto@amacapital.net [ Backported from tip:x86/asm. ] Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-03-05Merge branch 'msm-fixes-4.0' of git://people.freedesktop.org/~robclark/linux ↵Dave Airlie
into drm-fixes Fixup some fallout of the fallout of atomic dpms, few mdp5 cursor fixes, fix a leak in error path, and some fixes for kexec * 'msm-fixes-4.0' of git://people.freedesktop.org/~robclark/linux: drm/msm: kexec fixes drm/msm/mdp5: fix cursor blending drm/msm/mdp5: fix cursor ROI drm/msm/atomic: Don't leak atomic commit object when commit fails drm/msm/mdp5: Avoid flushing registers when CRTC is disabled drm/msm: update generated headers (add 6th lm.base entry) drm/msm/mdp5: fixup "drm/msm: fix fallout of atomic dpms changes"
2015-03-04drm/msm: kexec fixesRob Clark
In kexec environment, we are more likely to encounter irq's already enabled from previous environment. At which point we find that writes to disable/clear pending irq's are slightly less than useless without first enabling clocks. TODO: full blown state read-in so kexec'd kernel can inherit the mode already setup. Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-03-04drm/msm/mdp5: fix cursor blendingRob Clark
Seems like we just want BLEND_EN and not BLEND_TRANSP_EN (setting the latter results in black pixels in the cursor image treated as transparent). Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-03-04drm/msm/mdp5: fix cursor ROIRob Clark
If cursor is set near the edge of the screen, it is not valid to use the new cursor width/height as the ROI dimensions. Split out the ROI calc and use it both cursor_set and cursor_move. Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-03-04drm/msm/atomic: Don't leak atomic commit object when commit failsLaurent Pinchart
If the atomic commit fails due to completion wait interruption the atomic commit object is not freed and is thus leaked. Free it. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-03-04drm/msm/mdp5: Avoid flushing registers when CRTC is disabledStephane Viau
When a CRTC is disabled, no CTL is allocated to it (CRTC->ctl == NULL); in that case we should not try to FLUSH registers and do nothing instead. This can happen when we try to move a cursor but the CRTC's CTL (CONTROL) has not been allocated yet (inactive CRTC). It can also happens when we .atomic_check()/.atomic_flush() on a disabled CRTC. A CTL needs to be kept as long as the CRTC is alive. Releasing it after the last VBlank is safer than in .atomic_flush(). Signed-off-by: Stephane Viau <sviau@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-03-04drm/msm: update generated headers (add 6th lm.base entry)Stephane Viau
Some target have up to 6 layer mixers (LM). Let the header file access the last LM's base address. Signed-off-by: Stephane Viau <sviau@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-03-04drm/msm/mdp5: fixup "drm/msm: fix fallout of atomic dpms changes"Stephane Viau
Commit 0b776d457b94 ("drm/msm: fix fallout of atomic dpms changes") has a typo in both mdp5_encoder_helper_funcs and mdp5_crtc_helper_funcs definitions: .dpms entry should be replaced by .disable and .enable Also fixed a typo in mdp5_encoder_enable(). Note that these typos are only present for MDP5. MDP4 is fine. Signed-off-by: Stephane Viau <sviau@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-03-05Merge branch 'drm-fixes-4.0' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie
into drm-fixes Radeon fixes for 4.0: - Fix some fallout from the audio rework - Fix a possible oops in the CS ioctl - Fix interlaced modes on DCE8 - Do a posting read in irq_set callbacks to make sure interrupts are properly flushed through the pci bridge * 'drm-fixes-4.0' of git://people.freedesktop.org/~agd5f/linux: drm/radeon: fix interlaced modes on DCE8 drm/radeon: fix DRM_IOCTL_RADEON_CS oops drm/radeon: do a posting read in cik_set_irq drm/radeon: do a posting read in si_set_irq drm/radeon: do a posting read in evergreen_set_irq drm/radeon: do a posting read in r600_set_irq drm/radeon: do a posting read in rs600_set_irq drm/radeon: do a posting read in r100_set_irq radeon/audio: fix DP audio on DCE6 radeon/audio: fix whitespace drm/radeon: adjust audio callback order drm/radeon: properly set dto for dp on DCE4/5 drm/radeon/audio: update EDID derived fields in modeset drm/radeon: don't toggle audio state in modeset drm/radeon/audio: set mute around state setup drm/radeon: assign pin in detect drm/radeon: fix the audio dpms callbacks
2015-03-04Input: tc3589x-keypad - set IRQF_ONESHOT flag to ensure IRQ requestValentin Rothberg
Since commit 1c6c69525b40eb76de8adf039409722015927dc3 ("genirq: Reject bogus threaded irq requests") threaded IRQs without a primary handler need to be requested with IRQF_ONESHOT, otherwise the request will fail. Currently, plat->irqtype is only set to IRQF_TRIGGER_FALLING. This patch sets the ONESHOT flag directly in request_threaded_irq() to enforce the flag without being affected by future changes to plat->irqtype. Generated by: scripts/coccinelle/misc/irqf_oneshot.cocci Signed-off-by: Valentin Rothberg <Valentin.Rothberg@lip6.fr> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2015-03-04Input: ALPS - fix memory leak when detection failsDmitry Torokhov
This fixes memory leak introduced by commit a09221e83e13e09a33109b9b037484eade901cea Acked-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2015-03-05drm/ttm: device address space != CPU address spaceAlex Deucher
We need to store device offsets in 64 bit as the device address space may be larger than the CPU's. Fixes GPU init failures on radeons with 4GB or more of vram on 32 bit kernels. We put vram at the start of the GPU's address space so the gart aperture starts at 4 GB causing all GPU addresses in the gart aperture to get truncated. bug: https://bugs.freedesktop.org/show_bug.cgi?id=89072 [airlied: fix warning on nouveau build] Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: thellstrom@vmware.com Acked-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2015-03-05drm/mm: Support 4 GiB and larger rangesThierry Reding
The current implementation is limited by the number of addresses that fit into an unsigned long. This causes problems on 32-bit Tegra where unsigned long is 32-bit but drm_mm is used to manage an IOVA space of 4 GiB. Given the 32-bit limitation, the range is limited to 4 GiB - 1 (or 4 GiB - 4 KiB for page granularity). This commit changes the start and size of the range to be an unsigned 64-bit integer, thus allowing much larger ranges to be supported. [airlied: fix i915 warnings and coloring callback] Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com> fixupo
2015-03-04ARM: multi_v7_defconfig: increase the number of maximum number of CPUs to 16Tyler Baker
The HiSilicon HiP04 has 16 CPUs. I propose we increase the maximum number of CPUs to 16 to avoid the following warning identified during automated boot testing [1]. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at ../arch/arm/kernel/devtree.c:144 arm_dt_init_cpu_maps+0x118/0x1e8() DT /cpu 9 nodes greater than max cores 8, capping them Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 3.19.0-00528-gbdccc4edeb03 #1 Hardware name: Hisilicon HiP04 (Flattened Device Tree) [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0x78/0x94) [] (dump_stack) from [] (warn_slowpath_common+0x74/0xb0) [] (warn_slowpath_common) from [] (warn_slowpath_fmt+0x30/0x40) [] (warn_slowpath_fmt) from [] (arm_dt_init_cpu_maps+0x118/0x1e8) [] (arm_dt_init_cpu_maps) from [] (setup_arch+0x638/0x9a0) [] (setup_arch) from [] (start_kernel+0x8c/0x3b4) [] (start_kernel) from [<10208074>] (0x10208074) ---[ end trace cb88537fdc8fa200 ]--- [1] http://storage.kernelci.org/mainline/v3.19-528-gbdccc4edeb03/arm-multi_v7_defconfig/lab-tbaker/boot-hip04-d01.html Cc: Olof Johansson <olof@lixom.net> Cc: Kevin Hilman <khilman@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Tyler Baker <tyler.baker@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2015-03-04ARM: sunxi_defconfig: increase the number of maximum number of CPUs to 8Tyler Baker
The a80 optimus has 8 CPUs. I propose we increase the maximum number of CPUs to 8 to avoid the following warning identified during automated boot testing [1]. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at ../arch/arm/kernel/devtree.c:144 arm_dt_init_cpu_maps+0x110/0x1e0() DT /cpu 5 nodes greater than max cores 4, capping them CPU: 0 PID: 0 Comm: swapper Not tainted 3.19.0-00528-gbdccc4edeb03 #1 Hardware name: Allwinner sun9i Family [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0x74/0x90) [] (dump_stack) from [] (warn_slowpath_common+0x70/0xac) [] (warn_slowpath_common) from [] (warn_slowpath_fmt+0x30/0x40) [] (warn_slowpath_fmt) from [] (arm_dt_init_cpu_maps+0x110/0x1e0) [] (arm_dt_init_cpu_maps) from [] (setup_arch+0x634/0x8d4) [] (setup_arch) from [] (start_kernel+0x88/0x3ac) [] (start_kernel) from [<20008074>] (0x20008074) ---[ end trace cb88537fdc8fa200 ]--- [1] http://storage.kernelci.org/mainline/v3.19-528-gbdccc4edeb03/arm-sunxi_defconfig/lab-tbaker/boot-sun9i-a80-optimus.html Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: Olof Johansson <olof@lixom.net> Cc: Kevin Hilman <khilman@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Tyler Baker <tyler.baker@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2015-03-04locks: fix fasync_struct memory leak in lease upgrade/downgrade handlingJeff Layton
Commit 8634b51f6ca2 (locks: convert lease handling to file_lock_context) introduced a regression in the handling of lease upgrade/downgrades. In the event that we already have a lease on a file and are going to either upgrade or downgrade it, we skip doing any list insertion or deletion and simply re-call lm_setup on the existing lease. As of commit 8634b51f6ca2 however, we end up calling lm_setup on the lease that was passed in, instead of on the existing lease. This causes us to leak the fasync_struct that was allocated in the event that there was not already an existing one (as it always appeared that there wasn't one). Fixes: 8634b51f6ca2 (locks: convert lease handling to file_lock_context) Reported-and-Tested-by: Daniel Wagner <daniel.wagner@bmw-carit.de> Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>
generated by cgit (git 2.34.1) at 2025-09-13 16:11:28 +0000