iio: adc: ti_am335x_adc: avoid double free of buffer.

The driver is missing the iio_buffer_attach() call. As such it will attempt
to free the buffer twice on removal.

Introduced in commit 9e69c9 ("iio: Add reference counting for buffers").

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
regulator: gpio-regulator: Don't oops on missing regulator-type property

Catch missing regulator-type property in DT and return an error
gracefully instead of deferencing a NULL pointer and crashing.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
ARC: [TB10x] Updates for GPIO and pinctrl

Device tree and Kconfig updates for GPIO and pinctrl drivers.

Signed-off-by: Christian Ruppert <christian.ruppert@abilis.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Documentation/pwm: Update supported SoC name for pwm-samsung

Updated supported SoC name for pwm-samsung.

Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Reviewed-by: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
ARM: i.MX6q: fix the wrong parent of can_root clock

instead of pll3_usb_otg the parent of can_root clock
should be pll3_60m.

Signed-off-by: Jiada Wang <jiada_wang@mentor.com>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
ARM: imx: remove imx_src_prepare_restart() call

There is ~10% possibility that the following emergency restart command
fails to reboot imx6q.

$ echo b > /proc/sysrq-trigger

The IMX restart routine mxc_restart() assumes that it will always run on
primary core, and will call imx_src_prepare_restart() to disable
secondary cores in order to get them come to online in the following
boot.  However, the assumption is only true for normal kernel_restart()
case where migrate_to_reboot_cpu() will be called to migrate to primary
core, but not necessarily true for emergency_restart() case.  So when
emergency_restart() calls into mxc_restart() on any secondary core,
system will hang immediately once imx_src_prepare_restart() is called
to disabled secondary cores.  Since emergency_restart() is defined as a
function that is safe to call in interrupt context, we cannot just call
migrate_to_reboot_cpu() to fix the issue.

Fortunately, we just found that the issue can be fixed at imx6q platform
level.  We used to call imx_src_prepare_restart() to disable all
secondary cores before resetting hardware.  Otherwise, the secondary
will fail come to online in the reboot.  However, we recently found that
after commit 6050d18 (ARM: imx: reset core along with enable/disable
operation) comes to play, we do not need to reset the secondary cores
any more.  That said, mxc_restart() now can run on any core to reboot
the system, as long as we remove the imx_src_prepare_restart() call from
mxc_restart().

So let's simply remove imx_src_prepare_restart() call to fix the above
emergency restart failure.

Reported-by: Jiada Wang <jiada_wang@mentor.com>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
ARM: imx: improve mxc_restart() on the SRC bit writes

The current comment in the code does not make it clear why the double writes
on SRC bit is needed.  Let's quote the errata to get it clear.  Also, to
ensure there are at least 2 writes happen in the same one 32kHz period,
we actually need 3 writes.  Let's add the third one.

Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
ARM: imx: v7_cpu_resume() is needed by imx6sl build

Building a kernel with the following options,

  CONFIG_SMP=n
  CONFIG_PM=y
  CONFIG_SOC_IMX6SL=y
  CONFIG_SOC_IMX6Q=n

we will see the build error below.

  arch/arm/mach-imx/built-in.o: In function `imx6q_pm_enter':
  platform-spi_imx.c:(.text+0x2648): undefined reference to `v7_cpu_resume'
  make[1]: *** [vmlinux] Error 1

This is because that v7_cpu_resume() implemented in headsmp.S is also
needed by imx6sl build.  Let's build headsmp.S for CONFIG_SOC_IMX6SL as
well.

Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
ARM: imx6q: add missing sentinel to divider table

The clk_enet_ref_table[] is missing a final empty entry as end of list
marker. Also make the existing markers more obvious.

Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
ARM: imx: add sleep for pllv3 relock

The pllv3 relock time varies in the range of 50us ~ 500us, depending on
the specific PLL type, e.g. 50us for ARM PLL and 450us for Audio/Video
PLL.  Let's add a usleep_range() call instead of doing busy wait during
relock.

Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
ARM: imx: pllv3 needs relock in .set_rate() call

The pllv3 nees relock not only when powering up but also when rate
changes.  The patch creates a helper function clk_pllv3_wait_lock() and
moves the relock code from clk_pllv3_prepare() into there, so that
both .prepare() and .set_rate() hooks of pllv3 can call into the helper
for relocking.

Since relock is only needed when PLL is powered up while clk_set_rate()
could be called before clk is prepared, we need to add a check in
clk_pllv3_wait_lock() to skip the relock if PLL is not powered.

Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
ARM: imx: set up pllv3 POWER and BYPASS sequentially

Currently, POWER and BYPASS bits are set up in a single write to pllv3
register.  This causes problem occasionally from the IPU/HDMI testing.
Let's follow FSL BSP code to set up POWER bit, relock, and then BYPASS
sequentially.

Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
ARM: dts: i.MX51: Fix OTG PHY clock

Proper clock ID for USB OTG PHY is "usb_phy_gate".
The patch changes this mismatch.

Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
ALSA: hda - Control SPDIF out pin on MacBookPro 11,2

The SPDIF output MBP11,2 requires the pin control to be set/cleared
for turning on/off the optical SPDIF.  The red light turns off only
when the corresponding pin control is cleared (or powered to D3).

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64401
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA: sparc: fix missing unlock on error in snd_cs4231_playback_prepare()

Add the missing unlock before return from function
snd_cs4231_playback_prepare() in the error handling
case.

Fixes: 5a19b178d7b4 ('ALSA: sparc/cs4231: Use WARN_ON() instead of BUG_ON()')
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA: hda - hdmi: Use TFx channel positions instead of FxH

Channel map positions FLH, FCH, FRH duplicate positions TFL, TFC, TFR.
Both are the speakers above the front speakers (CEA uses "high" and USB
audio uses "top" nomenclature).

Since the USB audio code has used the TFx positions since v3.8
(04324ccc75f96, "ALSA: usb-audio: add channel map support") but the HDMI
code only just started using FxH in a5b7d510b2220cccb ("ALSA: hda -
hdmi: Fix channel maps with less common speakers") which is not yet in
any released kernel, standardize on TFx instead.

Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA: usb: Fix wrong mapping of RLC and RRC channels

According to USB Audio spec v2 bits 25 and 26 of bmChannelConfig are
"Back Left of Center - BLC" and "Back Right of Center - BRC",
respectively.

They are currently assigned to ALSA channels BLC/BRC. However, the ALSA
BLC/BRC are actually the rather nonsensical "bottom left center" and
"bottom right center", so the channels will be assigned wrongly. The
comments in the USB code are also similarly wrong, so this is not
readily apparent without looking at the actual specification.

Fix the channel mapping by mapping bits 25 and 26 to RLC (Rear Left
Center) and RRC (Rear Right Center), respectively, instead.

Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA: hda - hdmi: Add error-checking to some codec reads

Add error checks to HBR status reads (both generic and ATI/AMD) and
ATI/AMD codec reads for ELD generation.

Unchecked errors in these just caused more errors later on (invalid
codec writes for the HBR ones and ELD parsing errors for the ATI/AMD ELD
ones), but it is better to catch them earlier.

Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA: hda - hdmi: Skip out-of-range latency values in AMD ELD generator

The ATI/AMD video/audio latencies are specified in apparent HDMI VSDB
format. In this format values above 251 are not valid (or stream
component is not supported - 255), but no checking is performed since
this was not mentioned in the AMD HDA verbs specification.

Check that the latencies are valid before using them, and add a comment
describing the formats.

Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA: hda - hdmi: Fix wrong baseline length in ATI/AMD generated ELD

According to the HDA specification the baseline ELD length is counted in
DW of 4 bytes instead of in bytes.

Fix the code accordingly.

Baseline length is not used by the kernel so only the ELD exported to
userspace was affected. No issues have been reported.

v2: Fixed so that eld_size is adjusted upwards accordingly as well.

Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Signed-off-by: Takashi Iwai <tiwai@suse.de>