| Age | Commit message (Collapse) | Author |
|---|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull scheduler fixes from Ingo Molnar:
"Misc fixes, most of them SCHED_DEADLINE fallout"
* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched/deadline: Prevent rt_time growth to infinity
sched/deadline: Switch CPU's presence test order
sched/deadline: Cleanup RT leftovers from {inc/dec}_dl_migration
sched: Fix double normalization of vruntime
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull liblockdep fixes from Ingo Molnar:
"A handful of build fixes for liblockdep"
* 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
tools/liblockdep: Use realpath for srctree and objtree
tools/liblockdep: Add a stub for new rcu_is_watching
tools/liblockdep: Mark runtests.sh as executable
tools/liblockdep: Add include directory to allow tests to compile
tools/liblockdep: Fix include of asm/hash.h
tools/liblockdep: Fix initialization code path
|
|
git://git.linaro.org/people/mike.turquette/linux
Pull clk framework fixes from Mike Turquette:
"Clock framework and driver fixes, all of which fix user-visible
regressions.
There is a single framework fix that prevents dereferencing a NULL
pointer when calling clk_get. The range of fixes for clock driver
regressions spans memory leak fixes, touching the wrong registers that
cause things to explode, misconfigured clock rates that result in
non-responsive devices and even some boot failures. The most benign
fix is DT binding doc typo. It is a stable ABI exposed from the
kernel that was introduced in -rc1, so best to fix it now"
* tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mike.turquette/linux: (25 commits)
clk:at91: Fix memory leak in of_at91_clk_master_setup()
clk: nomadik: fix multiplatform problem
clk: Correct handling of NULL clk in __clk_{get, put}
clk: shmobile: Fix typo in MSTP clock DT bindings
clk: shmobile: rcar-gen2: Fix qspi divisor
clk: shmobile: rcar-gen2: Fix clock parent for all non-PLL clocks
clk: tegra124: remove gr2d and gr3d clocks
clk: tegra: Fix vic03 mux index
clk: shmobile: rcar-gen2: Fix qspi divisor
clk: shmobile: rcar-gen2: Fix clock parent all non-PLL clocks
clk: tegra: use max divider if divider overflows
clk: tegra: cclk_lp has a pllx/2 divider
clk: tegra: fix sdmmc clks on Tegra1x4
clk: tegra: fix host1x clock on Tegra124
clk: tegra: PLLD2 fixes for hdmi
clk: tegra: Fix PLLD mnp table
clk: tegra: Fix PLLP rate table
clk: tegra: Correct clock number for UARTE
clk: tegra: Add missing Tegra20 fuse clks
ARM: keystone: dts: fix clkvcp3 control register address
...
|
|
The kfifo_put() API changed in 498d319bb512 (kfifo API type safety)
which now results in the wrong pointer being added to the kfifo ring,
which then causes an oops. Fix this.
Cc: <stable@vger.kernel.org> # 3.13
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Single-link DVI max dotclock is 165MHz. Filter out modes with higher
dotclock when the monitor doesn't support HDMI.
Modes higher than 165 MHz were allowed in
commit 7d148ef51a657fd04036c3ed7803da600dd0d451
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Mon Jul 22 18:02:39 2013 +0200
drm/i915: fix hdmi portclock limits
Also don't attempt to use 12bpc mode with DVI monitors.
Cc: Adam Nielsen <a.nielsen@shikadi.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75345
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=70331
Tested-by: Ralf Jung <post+kernel@ralfj.de>
Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
We need to read the correct register, not a register that doesn't exist
and will trigger "Unclaimed register" messages when we touch it.
Also rearrange the checks in an attempt to prevent this error from
happening again.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[Jani: dropped an extra empty line introduced.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
We reserve the space for the power context in stolen memory at a fixed
address from a delayed work. This races with the subsequent driver
init/resume code which could allocate something at that address, so the
reservation for the power context fails. Reserve the space up-front, so
this can't happen. This also adds a missing struct_mutex lock around the
stolen allocation, which wasn't taken in the delayed work path.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
[ 365.164040] BUG: sleeping function called from invalid context at kernel/rtmutex.c:674
[ 365.164041] in_atomic(): 1, irqs_disabled(): 1, pid: 26, name: migration/1
[ 365.164043] no locks held by migration/1/26.
[ 365.164044] irq event stamp: 6648
[ 365.164056] hardirqs last enabled at (6647): [<ffffffff8153d377>] restore_args+0x0/0x30
[ 365.164062] hardirqs last disabled at (6648): [<ffffffff810ed98d>] multi_cpu_stop+0x9d/0x120
[ 365.164070] softirqs last enabled at (0): [<ffffffff810543bc>] copy_process.part.28+0x6fc/0x1920
[ 365.164072] softirqs last disabled at (0): [< (null)>] (null)
[ 365.164076] CPU: 1 PID: 26 Comm: migration/1 Tainted: GF N 3.12.12-rt19-0.gcb6c4a2-rt #3
[ 365.164078] Hardware name: QCI QSSC-S4R/QSSC-S4R, BIOS QSSC-S4R.QCI.01.00.S013.032920111005 03/29/2011
[ 365.164091] 0000000000000001 ffff880a42ea7c30 ffffffff815367e6 ffffffff81a086c0
[ 365.164099] ffff880a42ea7c40 ffffffff8108919c ffff880a42ea7c60 ffffffff8153c24f
[ 365.164107] ffff880a42ea91f0 00000000ffffffe1 ffff880a42ea7c88 ffffffff81297ec0
[ 365.164108] Call Trace:
[ 365.164119] [<ffffffff810060b1>] try_stack_unwind+0x191/0x1a0
[ 365.164127] [<ffffffff81004872>] dump_trace+0x92/0x360
[ 365.164133] [<ffffffff81006108>] show_trace_log_lvl+0x48/0x60
[ 365.164138] [<ffffffff81004c18>] show_stack_log_lvl+0xd8/0x1d0
[ 365.164143] [<ffffffff81006160>] show_stack+0x20/0x50
[ 365.164153] [<ffffffff815367e6>] dump_stack+0x54/0x9a
[ 365.164163] [<ffffffff8108919c>] __might_sleep+0xfc/0x140
[ 365.164173] [<ffffffff8153c24f>] rt_spin_lock+0x1f/0x70
[ 365.164182] [<ffffffff81297ec0>] blk_mq_main_cpu_notify+0x20/0x70
[ 365.164191] [<ffffffff81540a1c>] notifier_call_chain+0x4c/0x70
[ 365.164201] [<ffffffff81083499>] __raw_notifier_call_chain+0x9/0x10
[ 365.164207] [<ffffffff810567be>] cpu_notify+0x1e/0x40
[ 365.164217] [<ffffffff81525da2>] take_cpu_down+0x22/0x40
[ 365.164223] [<ffffffff810ed9c6>] multi_cpu_stop+0xd6/0x120
[ 365.164229] [<ffffffff810edd97>] cpu_stopper_thread+0xd7/0x1e0
[ 365.164235] [<ffffffff810863a3>] smpboot_thread_fn+0x203/0x380
[ 365.164241] [<ffffffff8107cbf8>] kthread+0xc8/0xd0
[ 365.164250] [<ffffffff8154440c>] ret_from_fork+0x7c/0xb0
[ 365.164429] smpboot: CPU 1 is now offline
Signed-off-by: Mike Galbraith <bitbucket@online.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
|
|
This patch does a cleanup about the thermal zone govenor,
setting and make the following rule.
1. For thermal zone devices that are registered w/o tz->tzp,
they can use the default thermal governor only.
2. For thermal zone devices w/ governor name specified in
tz->tzp->governor_name, we will use the default govenor
if the governor specified is not available at the moment,
and update tz->governor when the matched governor is registered.
This also fixes a problem that OF registered thermal zones
are running with no governor.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Javi Merino <javi.merino@arm.com>
|
|
In initialization, if the cooling device is initialized at
max cooling state, and the thermal zone temperature is below
the first trip point, then the cooling state can't be updated
to the right state, untill the first trip point be triggered.
To fix this issue, allow first update of cooling device state
during registration, initialized "updated" device field as
"false" (instead of "true").
Signed-off-by: Wei Ni <wni@nvidia.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
Commit beeb5a1e (thermal: rcar-thermal: Enable driver compilation with COMPILE_TEST)
broke build on archs wihout io memory.
On archs like S390 or um this driver cannot build nor work.
Make it depend on HAS_IOMEM to bypass build failures.
drivers/thermal/rcar_thermal.c:404: undefined reference to `devm_ioremap_resource'
drivers/thermal/rcar_thermal.c:426: undefined reference to `devm_ioremap_resource'
Signed-off-by: Richard Weinberger <richard@nod.at>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
The thermal zone type should not include an instance number. Otherwise
each zone is considered a different type and the thermal-to-hwmon
bridge fails to group them all in a single hwmon device.
I also changed the type to "x86_pkg_temp", because "pkg" was too
generic, and other thermal drivers use an underscore, not a dash, as
a separator. Or maybe "cpu_pkg_temp" would be better?
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Eduardo Valentin <eduardo.valentin@ti.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
The temperature value reported by x86_pkg_temp_thermal is already
reported by the coretemp driver. So, do not expose this thermal zone
as a hwmon device, because it would be redundant.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Eduardo Valentin <eduardo.valentin@ti.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
arch/arm/xen/enlighten.c (and maybe others) use MMU-specific functions
like pte_mkspecial which are only available on MMU builds. So let XEN
depend on MMU.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
|
In commit e2d265d3b587 (canfd: add support for CAN FD in CAN_RAW sockets)
CAN FD frames with a payload length up to 8 byte are passed to legacy
sockets where the CAN FD support was not enabled by the application.
After some discussions with developers at a fair this well meant feature
leads to confusion as no clean switch for CAN / CAN FD is provided to the
application programmer. Additionally a compatibility like this for legacy
CAN_RAW sockets requires some compatibility handling for the sending, e.g.
make CAN2.0 frames a CAN FD frame with BRS at transmission time (?!?).
This will become a mess when people start to develop applications with
real CAN FD hardware. This patch reverts the bad compatibility code
together with the documentation describing the removed feature.
Acked-by: Stephane Grosjean <s.grosjean@peak-system.com>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
This patch moves the soft reset into a seperate function.
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
This patch adds the missing netif_napi_del() to the flexcan_remove() function.
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
In case of AP mode, the beacon interval is already reset to
zero inside cfg80211_stop_ap(), and in the other modes it
isn't relevant. Remove the assignment to remove a potential
race since the assignment isn't properly locked.
Reported-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
When calculating the current max bw required for
a channel context, we didn't consider the virtual
monitor interface, resulting in its channel context
being narrower than configured.
This broke monitor mode with iwlmvm, which uses the
minimal width.
Reported-by: Ido Yariv <idox.yariv@intel.com>
Signed-off-by: Eliad Peller <eliadx.peller@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
This patch factors out freeze and unfreeze of the CAN core into seperate
functions. Experiments have shown that the transition from and to freeze mode
may take several microseconds, especially the time entering the freeze mode
depends on the current bitrate.
This patch adds a while loop which polls the Freeze Mode ACK bit (FRZ_ACK) that
indicates a successfull mode change. If the function runs into a timeout a
error value is returned.
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
This patch moves the transceiver enable and disable into seperate functions,
where the NULL pointer check is hidden.
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
In flexcan_chip_enable() and flexcan_chip_disable() fixed delays are used.
Experiments have shown that the transition from and to low power mode may take
several microseconds.
This patch adds a while loop which polls the Low Power Mode ACK bit (LPM_ACK)
that indicates a successfull mode change. If the function runs into a timeout a
error value is returned.
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
If flexcan_chip_start() in flexcan_open() fails, the interrupt is not freed,
this patch adds the missing cleanup.
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
When shutting down the CAN interface (ifconfig canX down) during high CAN bus
loads, the CAN core might hang and freeze the whole CPU.
This patch fixes the shutdown sequence by first disabling the CAN core then
disabling all interrupts.
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
pci_get_class(class, from) drops the refcount for 'from', so the
extra pci_dev_put we do on it will result in a use after free bug
starting with the WARN below.
Regression introduced in
commit 6a9c4b35e6696a63805b6da5e4889c6986e9ee1b
Author: Rui Guo <firemeteor@users.sourceforge.net>
Date: Wed Jun 19 21:10:23 2013 +0800
drm/i915: Fix PCH detect with multiple ISA bridges in VM
[ 164.338460] WARNING: CPU: 1 PID: 2094 at include/linux/kref.h:47 klist_next+0xae/0x110()
[ 164.347731] CPU: 1 PID: 2094 Comm: modprobe Tainted: G O 3.13.0-imre+ #354
[ 164.356468] Hardware name: Intel Corp. VALLEYVIEW B0 PLATFORM/NOTEBOOK, BIOS BYTICRB1.X64.0062.R70.1310112051 10/11/2013
[ 164.368796] Call Trace:
[ 164.371609] [<ffffffff816a32a6>] dump_stack+0x4e/0x7a
[ 164.377447] [<ffffffff8104f75d>] warn_slowpath_common+0x7d/0xa0
[ 164.384238] [<ffffffff8104f83a>] warn_slowpath_null+0x1a/0x20
[ 164.390851] [<ffffffff8169aeae>] klist_next+0xae/0x110
[ 164.396777] [<ffffffff8130a110>] ? pci_do_find_bus+0x70/0x70
[ 164.403286] [<ffffffff813cb4a9>] bus_find_device+0x89/0xc0
[ 164.409719] [<ffffffff8130a373>] pci_get_dev_by_id+0x63/0xa0
[ 164.416238] [<ffffffff8130a4e4>] pci_get_class+0x44/0x50
[ 164.422433] [<ffffffffa034821f>] intel_dsm_detect+0x16f/0x1f0 [i915]
[ 164.429801] [<ffffffffa03482ae>] intel_register_dsm_handler+0xe/0x10 [i915]
[ 164.437831] [<ffffffffa02d30fe>] i915_driver_load+0xafe/0xf30 [i915]
[ 164.445126] [<ffffffff8158a150>] ? intel_alloc_coherent+0x110/0x110
[ 164.452340] [<ffffffffa0148c07>] drm_dev_register+0xc7/0x150 [drm]
[ 164.459462] [<ffffffffa014b23f>] drm_get_pci_dev+0x11f/0x1f0 [drm]
[ 164.466554] [<ffffffff816abb81>] ? _raw_spin_unlock_irqrestore+0x51/0x70
[ 164.474287] [<ffffffffa02cf7a6>] i915_pci_probe+0x56/0x60 [i915]
[ 164.481185] [<ffffffff8130a028>] pci_device_probe+0x78/0xf0
[ 164.487603] [<ffffffff813cd495>] driver_probe_device+0x155/0x350
[ 164.494505] [<ffffffff813cd74e>] __driver_attach+0x6e/0xa0
[ 164.500826] [<ffffffff813cd6e0>] ? __device_attach+0x50/0x50
[ 164.507333] [<ffffffff813cb2be>] bus_for_each_dev+0x6e/0xc0
[ 164.513752] [<ffffffff813ccefe>] driver_attach+0x1e/0x20
[ 164.519870] [<ffffffff813cc958>] bus_add_driver+0x138/0x260
[ 164.526289] [<ffffffffa0188000>] ? 0xffffffffa0187fff
[ 164.532116] [<ffffffff813cde78>] driver_register+0x98/0xe0
[ 164.538558] [<ffffffffa0188000>] ? 0xffffffffa0187fff
[ 164.544389] [<ffffffff813087b0>] __pci_register_driver+0x60/0x70
[ 164.551336] [<ffffffffa014b37d>] drm_pci_init+0x6d/0x120 [drm]
[ 164.558040] [<ffffffffa0188000>] ? 0xffffffffa0187fff
[ 164.563928] [<ffffffffa018806a>] i915_init+0x6a/0x6c [i915]
[ 164.570363] [<ffffffff810002da>] do_one_initcall+0xaa/0x160
[ 164.576783] [<ffffffff8103b140>] ? set_memory_nx+0x40/0x50
[ 164.583100] [<ffffffff810ce7f5>] load_module+0x1fb5/0x2550
[ 164.589410] [<ffffffff810caab0>] ? store_uevent+0x40/0x40
[ 164.595628] [<ffffffff810cee7d>] SyS_init_module+0xed/0x100
[ 164.602048] [<ffffffff816b3c52>] system_call_fastpath+0x16/0x1b
v2: simplify the loop further (Chris)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reported-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65652
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74161
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
There is a conflict seen when requesting the kernel to reserve
the physical space used for the stolen area. This is because
some BIOS are wrapping the stolen area in the root PCI bus, but have
an off-by-one error. As a workaround we retry the reservation with an
offset of 1 instead of 0.
v2: updated commit message & the comment in source file (Daniel)
Signed-off-by: Akash Goel <akash.goel@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
i915gm and i945gm also seem to use and need the legacy combination mode
bit in BLC_PWM_CTL.
v2: Also do this for i915gm (Ville).
Reported-and-tested-by: Luis Ortega <luiorpe1@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75001
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
This quirk is needed for the headset microphone to work.
Signed-off-by: Kailang Yang <kailang@realtek.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Signed-off-by: Marius Knaust <marius.knaust@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The ops to read and write registers should take pointers labeled as
__iomem. Thanks to the sparse bot for catching this.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Using readl, writel, etc. resulted in some architectures, such as
s390, expanding the member names into zpci_writel. Obviously not the
intended result.
Fixes s390 build breakage introduced by "4083081 - ALSA: hda - Allow
different ops to read/write registers"
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
It is only used in hda_controller.c now.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Use table based setup to register the DAPM widgets and routes. This on one hand
makes the code a bit shorter and cleaner and on the other hand the board level
DAPM elements get registered in the card's DAPM context rather than in the
CODEC's DAPM context.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
|
The new sequence ensure that dapm_pre_sequence_async work on
the card before all codecs and dapm_post_sequence_async work
on the card after all codecs.
So the machine driver could utilize the determinate sequence
to do the gloabl setup and teardown in the right place.
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
|
The widgets generated by the machine driver need to power off too.
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
|
The 'ath79_spi_setup_cs' function initializes the chip
select line of a given SPI device in order to make sure
that the device is inactive.
If the SPI_CS_HIGH bit is set for a given device, it
means that the CS line of that device is active HIGH
so it must be set to LOW initially. In case of GPIO
CS lines, the 'ath79_spi_setup_cs' function does the
opposite of that due to the wrong GPIO flags.
Fix the code to use the correct GPIO flags.
Reported-by: Ronald Wahl <ronald.wahl@raritan.com>
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
Cc: stable@vger.kernel.org
|
|
Cc: Eric Bénard <eric@eukrea.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: alsa-devel@alsa-project.org
Cc: devicetree@vger.kernel.org
Signed-off-by: Denis Carikli <denis@eukrea.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
|
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
The clean-up in commit 36281caa839f ended up removing a NULL pointer check
that is needed in order to prevent an Oops in
nfs_async_inode_return_delegation().
Reported-by: "Yan, Zheng" <zheng.z.yan@intel.com>
Link: http://lkml.kernel.org/r/5313E9F6.2020405@intel.com
Fixes: 36281caa839f (NFSv4: Further clean-ups of delegation stateid validation)
Cc: stable@vger.kernel.org # 3.4+
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
|
|
|
|
Use table based setup to register the DAPM widgets and routes. This on one hand
makes the code a bit cleaner and on the other hand the board level DAPM elements
get registered in the card's DAPM context rather than in the CODEC's DAPM
context.
Also drop the two snd_soc_dapm_enable_pin() since pins are enabled by default
and there is no matching snd_soc_dapm_disable_pin() in the driver.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
|
Use table based setup to register the DAPM widgets and routes. This on one hand
makes the code a bit cleaner and on the other hand the board level DAPM elements
get registered in the card's DAPM context rather than in the CODEC's DAPM
context.
Also remove the snd_soc_dapm_enable_pin() calls, since pins are enabled by
default and there are no matching snd_soc_dapm_disable_pin() calls.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
|
Use table based setup to register the DAPM widgets and routes. This on one hand
makes the code a bit cleaner and on the other hand the board level DAPM elements
get registered in the card's DAPM context rather than in the CODEC's DAPM
context.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
|
Use table based setup to register the DAPM widgets and routes. This on one hand
makes the code a bit cleaner and on the other hand the board level DAPM elements
get registered in the card's DAPM context rather than in the CODEC's DAPM
context.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
|
Use table based setup to register the DAPM widgets and routes. This on one hand
makes the code a bit cleaner and on the other hand the board level DAPM elements
get registered in the card's DAPM context rather than in the CODEC's DAPM
context.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
|
When calling {corgi,poodle,spitz}_ext_control() from the startup callback we
pass the CODEC's DAPM context instead of the card's DAPM context. This is not a
problem per se since all the DAPM functions in ext_control() fallback to widgets
from other DAPM contexts, but passing the card's context is more consistent.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
|
Use table based setup to register the controls and DAPM widgets and routes.
This on one hand makes the code a bit shorter and cleaner and on the other hand
the board level DAPM elements get registered in the card's DAPM context rather
than in the CODEC's DAPM context.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
|
With GTA01 support gone from the driver there is no need to keep a separate
initilization routine for the GTA02 specific bits.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
