I2C IP block expect LE data, but CPU may operate in BE mode.
Need to use endian neutral functions to read/write h/w registers.
I.e instead of __raw_read[lw] and __raw_write[lw] functions code
need to use read[lw]_relaxed and write[lw]_relaxed functions.
If the first simply reads/writes register, the second will byteswap
it if host operates in BE mode.
Changes are trivial sed like replacement of __raw_xxx functions
with xxx_relaxed variant.
Signed-off-by: Taras Kondratiuk <taras.kondratiuk@linaro.org>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
The I2C controller node needs #address-cells and #size-cells properties,
but these are currently missing. Add them. This allows child nodes to be
parsed correctly.
Cc: stable@vger.kernel.org
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
Follow-up to commit 294d31e8227c ("sony-laptop: don't change keyboard
backlight settings"): avoid messing up the state on resume. Leave it to
what was before suspending as it's anyway likely that we still don't
know what value we should write to the EC registers. This fix is also
required in 3.12
Cc: stable@vger.kernel.org
Tested-by: Karol Babioch <karol@babioch.de>
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This reverts commit c284ee2cf12b55fa8496b2d098bf0938688f1c1c. Turns out
the locking was incorrect.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Cc: Chao Bi <chao.bi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Header file <acpi/acpi.h> contains environemnt settings and architecture
specific implementation that should be included before any other ACPICA
headers in order to keep a consistent build environment for ACPICA users.
The following internal ACPICA header files should be included from
<acpi/acpi.h> and should not be included by other kernel files:
<acpi/acpiosxf.h>
<acpi/acpixf.h>
Clean up incorrect inclusions of these files from non-ACPICA source
files.
[rjw: Subject and changelog]
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Without the interrupt you'll get problems if you enable
CONFIG_RTC_DRV_MAX77686. Setup the interrupt properly in the device
tree.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Tested-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Cc: stable@vger.kernel.org
This patch implements the power_down_finish() method for TC2, to
enable the kernel to confirm when CPUs are safely powered down.
The information required for determining when a CPU is parked
cannot be obtained from any single place, so a few sources of
information must be combined:
* mcpm_cpu_power_down() must be pending for the CPU, so that we
don't get confused by false STANDBYWFI positives arising from
CPUidle. This is detected by waiting for the tc2_pm use count
for the target CPU to reach 0.
* Either the SPC must report that the CPU has asserted
STANDBYWFI, or the TC2 tile's reset control logic must be
holding the CPU in reset.
Just checking for STANDBYWFI is not sufficient, because this
signal is not latched when the the cluster is clamped off and
powered down: the relevant status bits just drop to zero. This
means that STANDBYWFI status cannot be used for reliable
detection of the last CPU in a cluster reaching WFI.
This patch is required in order for kexec to work with MCPM on TC2.
MCPM code was changed in commit 0de0d6467525 ('ARM: 7848/1: mcpm:
Implement cpu_kill() to synchronise on powerdown'), and since then it
will hit a WARN_ON_ONCE() due to power_down_finish not being implemented
on the TC2 platform.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Acked-by: Pawel Moll <pawel.moll@arm.com>
Reviewed-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
idlestates in sysfs are counted from 0.
This fixes a wrong error message.
Current behavior on a machine with 4 sleep states is:
cpupower idle-set -e 4
Idlestate 4 enabled on CPU 0
-----Wrong---------------------
cpupower idle-set -e 5
Idlestate enabling not supported by kernel
-----Must and now will be -----
cpupower idle-set -e 5
Idlestate 6 not available on CPU 0
-------------------------------
cpupower idle-set -e 6
Idlestate 6 not available on CPU 0
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The cpupower idle-set subcommand was introduce recently.
This patch provides the missing manpage.
If cpupower is properly installed it will show up automatically
(similar to git), when invoking:
cpupower help idle-set
or
cpupower idle-set --help
Some parts have been taken over and adjusted from
git commit 62d6ae880e3e76098
documentation submitted by Carsten Emde.
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
In order to support increased build test coverage for drivers, implement
dummies for the powergate implementation. This will allow the drivers to
be built without requiring support for Tegra to be selected.
This patch solves the following build errors, which can be triggered in
v3.13-rc1 by selecting DRM_TEGRA without ARCH_TEGRA:
drivers/built-in.o: In function `gr3d_remove':
drivers/gpu/drm/tegra/gr3d.c:321: undefined reference to `tegra_powergate_power_off'
drivers/gpu/drm/tegra/gr3d.c:325: undefined reference to `tegra_powergate_power_off'
drivers/built-in.o: In function `gr3d_probe':
drivers/gpu/drm/tegra/gr3d.c:266: undefined reference to `tegra_powergate_sequence_power_up'
drivers/gpu/drm/tegra/gr3d.c:273: undefined reference to `tegra_powergate_sequence_power_up'
Signed-off-by: Thierry Reding <treding@nvidia.com>
[swarren, updated commit description]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
From Tony Lindgren:
Few more fixes for issues found booting older omaps using device tree.
Also few randconfig build fixes and removal of some dead code for omap4
as it no longer has legacy platform data based booting support.
* tag 'omap-for-v3.13/more-fixes-for-merge-window-take2' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: OMAP2+: Remove legacy omap4_twl6030_hsmmc_init
ARM: OMAP2+: Remove legacy mux code for display.c
ARM: OMAP2+: Fix undefined reference to set_cntfreq
gpio: twl4030: Fix passing of pdata in the device tree case
gpio: twl4030: Fix regression for twl gpio output
ARM: OMAP2+: More randconfig fixes for reconfigure_io_chain
ARM: dts: Fix omap2 specific dtsi files by adding the missing entries
ARM: OMAP2+: Fix GPMC and simplify bootloader timings for 8250 and smc91x
i2c: omap: Fix missing device tree flags for omap2
Some omap3 code is throwing a warning:
arch/arm/mach-omap2/pm34xx.c: In function 'omap3_save_secure_ram_context':
arch/arm/mach-omap2/pm34xx.c:123:32: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
In reality this code will never actually execute with LPAE=y, since
Cortex-A8 doesn't support it. So downcasting the __pa() is safe in
this case.
Signed-off-by: Olof Johansson <olof@lixom.net>
Acked-by: Tony Lindgren <tony@atomide.com>
When the system enters suspend, it disables all interrupts in
suspend_device_irqs(), including the interrupts marked EARLY_RESUME.
On the resume side things are different. The EARLY_RESUME interrupts
are reenabled in sys_core_ops->resume and the non EARLY_RESUME
interrupts are reenabled in the normal system resume path.
When suspend_noirq() failed or suspend is aborted for any other
reason, we might omit the resume side call to sys_core_ops->resume()
and therefor the interrupts marked EARLY_RESUME are not reenabled and
stay disabled forever.
To solve this, enable all irqs unconditionally in irq_resume()
regardless whether interrupts marked EARLY_RESUMEhave been already
enabled or not.
This might try to reenable already enabled interrupts in the non
failure case, but the only affected platform is XEN and it has been
confirmed that it does not cause any side effects.
[ tglx: Massaged changelog. ]
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Acked-by-and-tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Pavel Machek <pavel@ucw.cz>
Cc: <ian.campbell@citrix.com>
Cc: <rjw@rjwysocki.net>
Cc: <len.brown@intel.com>
Cc: <gregkh@linuxfoundation.org>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1385388587-16442-1-git-send-email-ldewangan@nvidia.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
If the next seqno returned by the firmware is 0, we return an error
(-16) in the iwl_mvm_get_last_nonqos_seq() function. This is because
we return an integer and don't use any casting when calculating the
last seqno from the one we received. Fix this by using a cast to u16
when doing the calculation, so we return 0xfff0, as we should.
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
In an open BSS, after suspend/resume, we don't set the last seqno
because the iwl_mvm_setup_connection_keep() returns too early. This
happens because the check to see if we have any keys was returning
immediately, without setting seqno and seqno_valid. Fix this.
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
If we call ieee80211_hw_restart, it means that the
firmware is in bad condition and will be reset soon.
Since the firmware will be reset, there is no good
reason to keep sending host commands.
Signed-off-by: Alexander Bondar <alexander.bondar@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
A new firmware is coming out soon with new APIs.
To make sure that this new firmware won't be loaded on old
driver that don't support it, it's API version has been
updated to 8. In order to be able to load it, bump the API
version to 8.
API version 7 is still supported and will be for another
year or so.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Time event notification can have a failure status even if
the time event was scheduled:
* in START notification, this can happen if the time event
was scheduled later than the requested apply time.
* in STOP notification, this can happen if the time event
is truncated.
Even if both happened, the offchannel packets sent during
the remain on channel are very likely to have been sent.
Hence, don't WARN when this happens, but rather print a
discrete line in the kernel log.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
This patch is very similar to a previous fix: 22cba0c0852f
When we disassociate, mac80211 removes the station and
then, it sets the bss it unsets the assoc bool in bss_info.
Since the firwmware wants it the opposite (first set the
MAC context as unassoc, and only then, remove the STA of
the API), we have a small period of time in which the STA
in firmware doesn't have a valid ieee80211_sta pointer.
During that time, iwl_mvm_vif->ap_sta_id, is still set
to the STA in firmware that represent the AP.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
This feature isn't supported by the firmware (yet).
Note that settingt he values to BT_CFG_CMD is harmless if
the validity bit is clear - so keep the configuration
values in BT_CFG_CMD, but clear the validity bit until thes
feature is enabled in the firmware.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
We changed the timeout for the interrupt coealescing for
calibration, but that wasn't effective since we changed
that value back before loading the firmware. Since
calibrations are notification from firmware and not Rx
packets, this doesn't change anyway - the firmware will
fire an interrupt straight away regardless of the interrupt
coalescing value.
Also, a HW issue has been discovered in 7000 devices series.
The work around is to disable the new interrupt coalescing
timeout feature - do this by setting bit 31 in
CSR_INT_COALESCING.
This has been fixed in 7265 which means that we can't rely
on the device family and must have a hint in the iwl_cfg
structure.
Cc: stable@vger.kernel.org [3.10+]
Fixes: 99cd47142399 ("iwlwifi: add 7000 series device configuration")
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
The station ID must be valid, if it's out of range then
the array access may crash. Validate the station ID to
the array length, and also validate the drain value even
if that doesn't matter all that much.
Cc: stable@vger.kernel.org
Fixes: 8ca151b568b6 ("iwlwifi: add the MVM driver")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
zsmalloc encodes a handle using the pfn and an object
index. On hardware platforms with physical memory starting
at 0x0 the pfn can be 0. This causes the encoded handle to be
0 and is incorrectly interpreted as an allocation failure.
This issue affects all current and future SoCs with physical
memory starting at 0x0. All MSM8974 SoCs which includes
Google Nexus 5 devices are affected.
To prevent this false error we ensure that the encoded handle
will not be 0 when allocation succeeds.
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It was introduced due to a patch hunk when porting
commit 20802057 (staging/lustre/ptlrpc: race in pinger).
Cc: Andreas Dilger <andreas.dilger@intel.com>
Signed-off-by: Peng Tao <bergwolf@gmail.com>
Cc: stable <stable@vger.kernel.org> # 3.12
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The usual mixed bag of fixes.
* 3 cases where kconfig dependencies were missing. We need to keep a closer
eye on this in new drivers.
* hid_sensors was abusing the iio_dev->trigger pointer. We had a round
of clearing this out some time ago but this driver clearly slipped through.
* A misuse of the IIO_ST macro, in mcp3422, which we should really make a
concertive effort to finish removing.
* Avoid a double free introduced by recent buffer reference counting in the
one driver that (quite reasonably!) does things differently (am335x)
* A missing mutex_unlock in kxsd9 that means that driver has been non
functional for some time and no one noticed (including me who for once
actually has one of the supported devices).
* An incorrect assumption about the parameters of sign_extend32 in mcp3422.
So nothing controversial. The only substantial patch is the hid_sensors
one and that is actually just adding a new pointer to the devices private
state then moving the code over to it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJSk7SvAAoJEFSFNJnE9BaIRNsQAJnM/WiH1ghfA5nuc0V7JrnB
2Z6Qtm3Stoq4Ul5LYiEMxumo6ckL17YFddxejUF9X4Eq5N8YyAxdPd8JdDJgS2OL
yCM2x6izd9drIGA3YUMMOvZ1BScSK1e5DmXJHp4nuF68uHtf2TM4TGF/2zuqt3TN
2bL7blNF3/5O/TiBRB4XjkH4Sy5c4G2kke+0SckRnWohTn8oE7tWihr84nYPciqt
mu11Nrv9S+sr/5GzRwN8d5SU33yU2/ML32QU/4oQzb/XxBW0W759NJflqY5sSZ89
JQnHcCKKZD7IWBFT0VAMiuEjBpSRGc4vxBbYjsVHtEHzW7v3L0fvob5YqfSrzMlD
rVUiTQJm7fC/4hn7iJUPrxkWsSGsjCvVrLZmZFOK3OYONUfd+Cqg0nliihRZo65s
054/yi4v8xd6OUzqSxtWKIK/ZQjDxa5W2BlRoryShCrUAo/e3Djy+jH32v4Mmgfe
D9aEwdUqa8kPlq6pyQC2QRgWWU1K5+RRrzW5nNNLlmjYtVlfF+8OgcQYGHW8iMur
8AaDXNZwQLEYA4409T/Ar9lNg4gDqc0YZsvNibu0q4Kxfp13dJOwra+xmF+ktECr
KcIFxu5v89SgpE1Rra74OXYFWQ1I4Qy+sJxhQKymthPzmw4nuUidK33mxjtcojwz
TvQJu8f3us8Ea5vQLZo0
=cIMc
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-3.13a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus
Jonathan writes:
First round of fixes for IIO in the 3.13 cycle.
The usual mixed bag of fixes.
* 3 cases where kconfig dependencies were missing. We need to keep a closer
eye on this in new drivers.
* hid_sensors was abusing the iio_dev->trigger pointer. We had a round
of clearing this out some time ago but this driver clearly slipped through.
* A misuse of the IIO_ST macro, in mcp3422, which we should really make a
concertive effort to finish removing.
* Avoid a double free introduced by recent buffer reference counting in the
one driver that (quite reasonably!) does things differently (am335x)
* A missing mutex_unlock in kxsd9 that means that driver has been non
functional for some time and no one noticed (including me who for once
actually has one of the supported devices).
* An incorrect assumption about the parameters of sign_extend32 in mcp3422.
So nothing controversial. The only substantial patch is the hid_sensors
one and that is actually just adding a new pointer to the devices private
state then moving the code over to it.
A bunch of fixes, a few driver specific ones and a framework fix for
voltage enumeration on fixed voltage regulators which had previously
worked but had been misplaced during some refactoring causing problems
for users that needed to know the voltage.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
iQIcBAABAgAGBQJSkgsOAAoJELSic+t+oim9soIQAIQL1Im2MKVa0M2Kj9npsf2G
QKgyobmpQRyjcVrEJp8waOG8WEdIY2s7iJOUNWWnBsyLJ88wMsRPYbloE87DO2nA
dBjYUI25YcTHOlqVYqCrhH5rJfS3m1PsbMJBgrW7vB0IvseobY63sk64hdfyO8Z+
zgroggEI6JXo6IYprtLYgIEOhDt3izZBvyFZyCdlpiGPPlMaD2UQFaJ/qwqQdwpY
FR5o4DbXmggILIhjl5TjH1u6UKinJDdS1n027626zsGSoVz3DJbgcwiDIUkbawfo
lucRQc4tESbr8D05TvTY1BuyKCU6Z1Ejf5DTPn7H5ESCfTer1TZ5BT5Vfgc5YDGq
my7vEZfpw2OndgunqG8bCG5MuWrA4mQ05sg7FFSbdWIbM3FfKB2bfPg3MHE4F3q6
pi7hFnnjdG0cVee+Dxn/vYn1KJ8JqaqutnFdVRmeB5PWqQUhafbIlNEpOoIaTtdq
8cMG9px9yKCC7NmI6pOEbQx9tjkJzvuLNOfuzYsehMKorFa0mqdyzBVYzhKFboCp
lSwA0B3slp1CcKda4WzCq3y7bSEf9+1xOW2kIfaGWfdJQTn4i7Pb0mp19f4++lDQ
GVtpmCP9fanpi+Xq6J5CnLCIZLZOLFz1PFQvjbD10vUbhW/9aJ7t4+dKdd3KwZxL
LvAzBohVYJc5VKoZYlRQ
=2BEl
-----END PGP SIGNATURE-----
Merge tag 'regulator-v3.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fixes from Mark Brown:
"A bunch of fixes, a few driver specific ones and a framework fix for
voltage enumeration on fixed voltage regulators which had previously
worked but had been misplaced during some refactoring causing problems
for users that needed to know the voltage"
* tag 'regulator-v3.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: arizona-micsupp: Correct wm5110 voltage selection
regulator: pfuze100: allow misprogrammed ID
regulator: fixed: fix regulator_list_voltage() for regression
regulator: gpio-regulator: Don't oops on missing regulator-type property
The number of bytes transmitted was not updated correctly, if several CAN
messages (with different length) were transmitted in one 'bunch'. Thus
programs like 'ifconfig' showed wrong transmit byte counts. Reason was, that
the message object whose DLC is to be read was not necessarily the active one
at the time when
priv->read_reg(priv, C_CAN_IFACE(MSGCTRL_REG, 0)) & IF_MCONT_DLC_MASK;
was executed.
Signed-off-by: Holger Bechtold <Holger.Bechtold@gmx.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
The c_can driver contians a callpath (c_can_poll -> c_can_state_change ->
c_can_get_berr_counter) which may call pm_runtime_get_sync() from the IRQ
handler, which is not allowed and results in "BUG: scheduling while atomic".
This problem is fixed by introducing __c_can_get_berr_counter, which will not
call pm_runtime_get_sync().
Reported-by: Andrew Glen <AGlen@bepmarine.com>
Tested-by: Andrew Glen <AGlen@bepmarine.com>
Signed-off-by: Andrew Glen <AGlen@bepmarine.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
For IBSS join if the requested SSID matches current SSID,
it returns without freeing the allocated beacon IE buffer.
Cc: <stable@vger.kernel.org> # 3.10+
Signed-off-by: Ujjal Roy <royujjal@gmail.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When building randconfigs with CONFIG_BCMA_DRIVER_GPIO=y, I get
drivers/built-in.o: In function `brcms_led_unregister':
(.text+0x351aca): undefined reference to `led_classdev_unregister'
drivers/built-in.o: In function `brcms_led_register':
(.text+0x351c65): undefined reference to `led_classdev_register'
during final linking stage because brcmsmac/led.c needs LEDS_CLASS for
registering/deregistering the led device. Select the required symbols.
Cc: Arend van Spriel <arend@broadcom.com>
Cc: "Rafał Miłecki" <zajec5@gmail.com>
Cc: <linux-wireless@vger.kernel.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch fixes the issue that the sja1000_interrupt() function may have
returned IRQ_NONE without processing the optional pre_irq() and post_irq()
function before. Further the irq processing counter 'n' is moved to the end of
the while statement to return correct IRQ_[NONE|HANDLED] values at error
conditions.
Reported-by: Wolfgang Grandegger <wg@grandegger.com>
Acked-by: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
drivers/staging/btmtk_usb/btmtk_usb.c: In function ‘btmtk_usb_probe’:
drivers/staging/btmtk_usb/btmtk_usb.c:1610: warning: assignment from incompatible pointer type
Add the new hdev parameter, cfr. commit
7bd8f09f69f8a190f9b8334a07bb0a9237612314 ("Bluetooth: Add hdev parameter to
hdev->send driver callback").
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This fixes up the remaining "dev is used before it is set" issues in the
go7007 driver that were originally caused by commit
b6ea5ef80aa7fd6f4b18ff2e4174930e8772e812 but not fixed up by reverting
it due to other patches later on adding these "fixes".
Cc: Hans Verkuil <hans.verkuil@cisco.com>
Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: Dulshani Gunawardhana <dulshani.gunawardhana89@gmail.com>
Cc: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b8d181e408af (staging: drm/imx: add drm plane support) added a file
to the make target for DRM_IMX_IPUV3 but didn't adjust the objs required
to actually build that as a module. Kbuild got confused and this lead to
link errors like:
ERROR: "ipu_plane_disable" [drivers/staging/imx-drm/ipuv3-crtc.ko] undefined!
ERROR: "ipu_plane_enable" [drivers/staging/imx-drm/ipuv3-crtc.ko] undefined!
Additionally, it added a call to imx_drm_crtc_id which also fails with a
link error as above. To fix this, we adjust the make target with the proper
objs, which will change the name of the resulting .ko. We also add an
EXPORT_SYMBOL_GPL for imx_drm_crtc_id.
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Fixes: b8d181e408af '(staging: drm/imx: add drm plane support)'
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit b6ea5ef80aa7fd6f4b18ff2e4174930e8772e812.
Turns out to have lots of run-time issues in that the structure is not
initialized before it is used in the debugging messages.
Reported-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: Dulshani Gunawardhana <dulshani.gunawardhana89@gmail.com>
Cc: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
With multiple, concurrent readers (each waiting to acquire the
atomic_read_lock mutex), a departing reader may mistakenly reset
minimum_to_wake after a new reader has already set a new value.
Protect the minimum_to_wake reset with the atomic_read_lock critical
section.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
As suggested by Minchan Kim and Jerome Marchand "The code in reset_store
get the block device (bdget_disk()) but it does not put it (bdput()) when
it's done using it. The usage count is therefore incremented but never
decremented."
This patch also puts bdput() for all error cases.
Acked-by: Minchan Kim <minchan@kernel.org>
Acked-by: Jerome Marchand <jmarchan@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We assume nvec->rx can be NULL earlier so I have added a check here as
well.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We fixed this to use free_netdev() instead of kfree() but unfortunately
free_netdev() doesn't accept NULL pointers. Smatch complains about
this, it's not something I discovered through testing.
Fixes: 3030d40b5036 ('staging: vt6655: use free_netdev instead of kfree')
Fixes: 0a438d5b381e ('staging: vt6656: use free_netdev instead of kfree')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
I broke `s626_set_dac()` by changing the type of the `dacdata` parameter
from `short` to `unsigned short`. It's actually designed to take a
signed value in the range -0x1fff to +0x2000 although values above
0x1fff get clamped to 0x1fff. (We could change the `maxdata` value to
0x1ffe to avoid the clamping, but `maxdata` values are usually a power
of 2 minus 1.) The bug results in all negative values passed to the
function being changed to +0x1fff by the clamp. Change the parameter
type to `int16_t` to fix the problem.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
