redrat3_send_cmd() can return an error or the read data. However,
it currently returns an u8, as reported by smatch:
drivers/media/rc/redrat3.c:416 redrat3_send_cmd() warn: signedness bug returning '(-12)'
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Since the first version of this driver, the remote controller
code is disabled, adding an early return inside vp702x_rc_query().
Let's disable the code with #if 0, to remove this warning:
drivers/media/usb/dvb-usb/vp702x.c:268 vp702x_rc_query() info: ignoring unreachable code.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The indentation on this driver were deadly broken. On lots
of places, it was using 4 spaces instead of tab to indent.
On other parts, it were using tabs.
Also, on several places, it were not even being properly aligned,
as reported by smatch:
drivers/media/dvb-frontends/dib0070.c:179 dib0070_set_bandwidth() warn: inconsistent indenting
drivers/media/dvb-frontends/dib0070.c:198 dib0070_captrim() warn: inconsistent indenting
drivers/media/dvb-frontends/dib0070.c:246 dib0070_set_ctrl_lo5() warn: inconsistent indenting
drivers/media/dvb-frontends/dib0070.c:260 dib0070_ctrl_agc_filter() warn: inconsistent indenting
drivers/media/dvb-frontends/dib0070.c:494 dib0070_tune_digital() warn: inconsistent indenting
drivers/media/dvb-frontends/dib0070.c:498 dib0070_tune_digital() warn: inconsistent indenting
drivers/media/dvb-frontends/dib0070.c:655 dib0070_reset() warn: inconsistent indenting
drivers/media/dvb-frontends/dib0070.c:711 dib0070_reset() warn: curly braces intended?
drivers/media/dvb-frontends/dib0070.c:713 dib0070_reset() warn: inconsistent indenting
My first idea were to leave it as-is or to just touch the above.
However, this won't be fixing anything. So, as painful as it
is, let's fix indentation globally on the driver, and then
address the inconsistencies.
Hopefully, this driver doesn't have much patches, so it likely
won't conflict to any other patch during this merge window.
Besides the big size of this patch, no functional changes
were done.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
ov7670_s_exp() checks read error for 2 registers: REG_COM1
and REG_COM8. But, although it uses the value latter, it
doesn't check errors on REG_AECHH read. Yet, as it is doing
a bitmask operation there, the read operation should succeed.
So, fix the code to also check if this succeeded.
This fixes this smatch report:
drivers/media/i2c/ov7670.c:1366 ov7670_s_exp() warn: inconsistent indenting
Compile-tested only.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Acked-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
drivers/media/dvb-frontends/stv0297.c:140 stv0297_get_symbolrate() warn: should 'stv0297_readreg(state, 86) << 8' be a 64 bit type?
drivers/media/dvb-frontends/stv0297.c:141 stv0297_get_symbolrate() warn: should 'stv0297_readreg(state, 87) << 16' be a 64 bit type?
drivers/media/dvb-frontends/stv0297.c:142 stv0297_get_symbolrate() warn: should 'stv0297_readreg(state, 88) << 24' be a 64 bit type?
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Using IDR_SRR in RXFIFO_ID to test for the presence of data is only
valid for standard frames. For extended frames the bit is always 1 and
IDR_RTR should be used instead. This patch switches the check to use
CAN_RTR_FLAG which is correctly set when reading the ID.
The patch also changes the DW1/DW2 to be read unconditionally, since
this is necessary to remove the frame from the RXFIFO.
Signed-off-by: Jeppe Ledet-Pedersen <jlp@gomspace.com>
Acked-by: Kedareswara rao Appana <appanad@xilinx.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Fujitsu Lifebook E752 laptop needs a similar quirk done for Lifebook
T731. Otherwise the headphone is always muted.
Reported-and-tested-by: Christian Weber <we_chris@hotmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Patches 7cba160ad "powernv/cpuidle: Redesign idle states management"
and 77b54e9f2 "powernv/powerpc: Add winkle support for offline cpus"
use non-volatile condition registers (cr2, cr3 and cr4) early in the system
reset interrupt handler (system_reset_pSeries()) before it has been determined
if state loss has occurred. If state loss has not occurred, control returns via
the power7_wakeup_noloss() path which does not restore those condition
registers, leaving them corrupted.
Fix this by restoring the condition registers in the power7_wakeup_noloss()
case.
This is apparent when running a KVM guest on hardware that does not
support winkle or sleep and the guest makes use of secondary threads. In
practice this means Power7 machines, though some early unreleased Power8
machines may also be susceptible.
The secondary CPUs are taken off line before the guest is started and
they call pnv_smp_cpu_kill_self(). This checks support for sleep
states (in this case there is no support) and power7_nap() is called.
When the CPU is woken, power7_nap() returns and because the CPU is
still off line, the main while loop executes again. The sleep states
support test is executed again, but because the tested values cannot
have changed, the compiler has optimized the test away and instead we
rely on the result of the first test, which has been left in cr3
and/or cr4. With the result overwritten, the wrong branch is taken and
power7_winkle() is called on a CPU that does not support it, leading
to it stalling.
Fixes: 7cba160ad7 ("powernv/cpuidle: Redesign idle states management")
Fixes: 77b54e9f21 ("powernv/powerpc: Add winkle support for offline cpus")
[mpe: Massage change log a bit more]
Signed-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Commit 1c509148b ("powerpc/eeh: Do probe on pci_dn") probes EEH
devices in early stage, which is reasonable to pSeries platform.
However, it's wrong for PowerNV platform because the PE# isn't
determined until the resources (IO and MMIO) are assigned to
PE in hotplug case. So we have to delay probing EEH devices
for PowerNV platform until the PE# is assigned.
Fixes: ff57b454dd ("powerpc/eeh: Do probe on pci_dn")
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
When asserting reset in pcibios_set_pcie_reset_state(), the PE
is enforced to (hardware) frozen state in order to drop unexpected
PCI transactions (except PCI config read/write) automatically by
hardware during reset, which would cause recursive EEH error.
However, the (software) frozen state EEH_PE_ISOLATED is missed.
When users get 0xFF from PCI config or MMIO read, EEH_PE_ISOLATED
is set in PE state retrival backend. Unfortunately, nobody (the
reset handler or the EEH recovery functinality in host) will clear
EEH_PE_ISOLATED when the PE has been passed through to guest.
The patch sets and clears EEH_PE_ISOLATED properly during reset
in function pcibios_set_pcie_reset_state() to fix the issue.
Fixes: 28158cd ("Enhance pcibios_set_pcie_reset_state()")
Reported-by: Carol L. Soto <clsoto@us.ibm.com>
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Tested-by: Carol L. Soto <clsoto@us.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
The incorrect ordering of operations during cpu dlpar add results in invalid
affinity for the cpu being added. The ibm,associativity property in the
device tree is populated with all zeroes for the added cpu which results in
invalid affinity mappings and all cpus appear to belong to node 0.
This occurs because rtas configure-connector is called prior to making the
rtas set-indicator calls. Phyp does not assign affinity information
for a cpu until the rtas set-indicator calls are made to set the isolation
and allocation state.
Correct the order of operations to make the rtas set-indicator
calls (done in dlpar_acquire_drc) before calling rtas configure-connector.
Fixes: 1a8061c46c ("powerpc/pseries: Add kernel based CPU DLPAR handling")
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
This patch enables intel_powerclamp driver to run on the
next-generation Intel(R) Xeon Phi Microarchitecture
code named "Knights Landing"
Signed-off-by: Dasaratharaman Chandramouli <dasaratharaman.chandramouli@intel.com>
Acked-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
drivers/thermal/intel_soc_dts_iosf.c:358:4-7: WARNING: end returns can be simpified
Simplify a trivial if-return sequence. Possibly combine with a
preceding function call.
Generated by: scripts/coccinelle/misc/simple_return.cocci
CC: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
In Intel Quark SoC X1000, there is one on-die digital temperature sensor(DTS).
The DTS offers both hot & critical trip points.
However, in current distribution of UEFI BIOS for Quark platform, only
critical trip point is configured to be 105 degree Celsius (based on Quark
SW ver1.0.1 and hot trip point is not used due to lack of IRQ.
There is no active cooling device for Quark SoC, so Quark SoC thermal
management logic expects Linux distro to orderly power-off when temperature
of the DTS exceeds the configured critical trip point.
Kernel param "polling_delay" in milliseconds is used to control the frequency
the DTS temperature is read by thermal framework. It defaults to 2-second.
To change it, use kernel boot param "intel_quark_dts_thermal.polling_delay=X".
User interacts with Quark SoC DTS thermal driver through sysfs via:
/sys/class/thermal/thermal_zone0/
For example:
- to read DTS temperature
$ cat temp
- to read critical trip point
$ cat trip_point_0_temp
- to read trip point type
$ cat trip_point_0_type
- to emulate temperature raise to test orderly shutdown by Linux distro
$ echo 105 > emul_temp
Tested-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Signed-off-by: Ong Boon Leong <boon.leong.ong@intel.com>
Reviewed-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Kweh, Hock Leong <hock.leong.kweh@intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Support two auxiliary DTS present on Braswell platform using side band
IOSF interface. This supports two read write trips, which can be used
to get notification on trip violation.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
There is no change in functionality but using the common IOSF core APIs.
This driver is now just responsible for enumeration and call relevant
API to create thermal zone and register critical trip.
Also cpuid 0x4c is now handled in the int340x processor thermal driver
with the same functionality.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
This is becoming a common feature for Intel SoCs to expose the additional
digital temperature sensors (DTSs) using side band interface (IOSF). This
change remove common IOSF DTS handler function from the existing driver
intel_soc_dts_thermal.c and creates a stand alone module, which can
be selected from the SoC specific drivers. In this way there is less
code duplication.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
In the test manager, there are a number of if-statements with expressions of
the form !x == y that incur warnings with gcc-5 of the following form:
../crypto/testmgr.c: In function '__test_aead':
../crypto/testmgr.c:523:12: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
if (!ret == template[i].fail) {
^
By converting the 'fail' member of struct aead_testvec and struct
cipher_testvec to a bool, we can get rid of the warnings.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
In testmgr, struct pcomp_testvec takes a non-const 'params' field, which is
pointed to a const deflate_comp_params or deflate_decomp_params object. With
gcc-5 this incurs the following warnings:
In file included from ../crypto/testmgr.c:44:0:
../crypto/testmgr.h:28736:13: warning: initialization discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
.params = &deflate_comp_params,
^
../crypto/testmgr.h:28748:13: warning: initialization discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
.params = &deflate_comp_params,
^
../crypto/testmgr.h:28776:13: warning: initialization discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
.params = &deflate_decomp_params,
^
../crypto/testmgr.h:28800:13: warning: initialization discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
.params = &deflate_decomp_params,
^
Fix this by making the parameters pointer const and constifying the things
that use it.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
My patch to add install support for the powerpc selftests had a typo,
leading to the three tests in the pmu directory itself not being
installed.
Fixes: 6faeeea44b ("selftests: Add install support for the powerpc tests")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Fixed the following kbuild warnings:
1. unused variable 'of_id'
2. buffer overflow 'ring_cfg' 5 <= 5
Signed-off-by: Iyappan Subramanian <isubramanian@apm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The gfx3d_clk_src parents configuration is incorrect. Fix it.
Fixes: 3966fab8b6 "clk: qcom: Add MSM8916 Global Clock Controller support"
Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
One of the video codec clock frequencies has incorrect divider
value. Fix it.
Fixes: 3966fab8b6 "clk: qcom: Add MSM8916 Global Clock Controller support"
Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
The adv7511 IRQ is low level triggered, not falling edge triggered. The
wrong sense configuration results in no interrupt being triggered at
all, breaking hotplug detection. Fix it.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Fixes: 83a0731b39 ("ARM: shmobile: koelsch: Add DU HDMI output support")
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
The debugfs clk directory no longer expresses a clk tree. Update
the comments around that apporiately. Also drop comments about
prepare locks needing to be held as we have the proper
annotations with lockdep_assert_held().
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Move the code around so that we don't need to declare function
prototypes at the start of the file. Simplify
clk_core_is_prepared() and clk_core_is_enabled() too to make the
diff easier to read.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
This condition can't ever be true because this function is static
and it's always called with a non-NULL pointer.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
We don't need to print error messages when allocations fail.
We'll get a nice backtrace in such situations anyway.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
These functions are only used in one place. Let's squash them
into their respective callers to save some lines.
Signed-off-by: Dong Aisheng <aisheng.dong@freescale.com>
[sboyd@codeaurora.org: Redo commit text, add NULL check in
clk_enable()]
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
While introducing struct clk_core we tried to minimize the diff
by changing the type of 'clk' variables from struct clk to struct
clk_core without changing the names of the variables. Now that
the split is complete, the code is slightly confusing when it
mixes variables called 'clk' and variables called 'core' that are
of the same type struct clk_core. Let's be consistent and use
'core' everywhere we have a struct clk_core pointer and 'clk'
when we have a struct clk pointer.
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
The sentence "These resources are used be used to pass ..." contains
a suspicious repetition, likely the author meant "These resources can
be used to pass ...".
Simplify the wording.
Signed-off-by: Antonio Ospite <ao2@ao2.it>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
- Fix for a regression in the cpuidle core introduced by one of
the recent commits in the clockevents_notify() removal series
that put a call to a function which had to be executed with
disabled interrupts into a code path running with enabled
interrupts (Rafael J Wysocki).
- Fix for a build problem in ACPICA (with GCC 4.5) introduced by one
of the recent ACPICA tools commits that added a duplicate typedef
to one of the ACPICA's header files by mistake (Olaf Hering).
- Fix for a regression in the ACPI SBS (Smart Battery Subsystem)
driver introduced during the 3.18 development cycle causing the
smart battery manager to be marked as not present when it should
be marked as present (Chris Bainbridge).
/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABCAAGBQJVQoeSAAoJEILEb/54YlRxuscP/3Vz98JY0P7sMLnxVU8RPBxW
cBN7G7F1gZup66/yV3MzvYHbgOFwNdQ2aMVxN+qV7rVMw27uwHljVr3svB+/GS15
TeyKxvFWZYwhPKdsNAoHdkGBsptAK4DdyA+N2wH3MZ4dd8HepxpBG6QvzaEt4s43
wFhhFrzEP3HDjrPoF/7TwKbsSrFuU5/U5PTd3dIuukj6JAl0PWnjczuVsg1PRyCW
9kvefs3U56s8GbWOhDC+QyQ3eYJ2y35j/XnCKFWwljcdnis6HpsKj+oxSG2o0K4o
9LLL3MgnTQuFbenuFIJUsMdFFdFrFkEeiV1EAdKCzQcXdlipxvi2cPttdNWVd6eZ
JobXyhq7iYUQK5E5Dp6TCokxhzOyjvTo7VmEkkkqLVmfeO0FnggUAduRMAIacYXS
ZML45m4UtvCJRoQXXxyzwYQXFeRD/nJQlOavC95jGGqtAij0Xk4xqTauQKIiqiaE
zobOJ5ZxJMP+njFfzyDxjm68LjobYm1fUJTpWzpUSExjEKImRcw/QMzw23MyHHUL
IJ7hP8FcELglkZWk/0ZwoNhbwM5Q2qGX5WMtqyunNFcf83aBsCr8bSjOrm4zmuL7
NWjjeXuYwzPuC7SnFqf2K/CCfdkrdnU1frKLTpOm8t8W0P4mr1ckYrPemNemr8sN
e5GozK5m13T2gTT4+q6M
=v78a
-----END PGP SIGNATURE-----
Merge tag 'pm+acpi-4.1-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management and ACPI fixes from Rafael Wysocki:
"Three regression fixes this time, one for a recent regression in the
cpuidle core affecting multiple systems, one for an inadvertently
added duplicate typedef in ACPICA that breaks compilation with GCC 4.5
and one for an ACPI Smart Battery Subsystem driver regression
introduced during the 3.18 cycle (stable-candidate).
Specifics:
- Fix for a regression in the cpuidle core introduced by one of the
recent commits in the clockevents_notify() removal series that put
a call to a function which had to be executed with disabled
interrupts into a code path running with enabled interrupts (Rafael
J Wysocki)
- Fix for a build problem in ACPICA (with GCC 4.5) introduced by one
of the recent ACPICA tools commits that added a duplicate typedef
to one of the ACPICA's header files by mistake (Olaf Hering)
- Fix for a regression in the ACPI SBS (Smart Battery Subsystem)
driver introduced during the 3.18 development cycle causing the
smart battery manager to be marked as not present when it should be
marked as present (Chris Bainbridge)"
* tag 'pm+acpi-4.1-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
cpuidle: Run tick_broadcast_exit() with disabled interrupts
ACPI / SBS: Enable battery manager when present
ACPICA: remove duplicate u8 typedef
Commit 7bc5a2bad0 'ACPI: Support _OSI("Darwin") correctly' caused
the MacBook firmware to expose the SBS, resulting in intermittent
hangs of several minutes on boot, and failure to detect or report
the battery. Fix this by adding a 5 us delay to the start of each
SMBUS transaction. This timing is the result of experimentation -
hangs were observed with 3 us but never with 5 us.
Fixes: 7bc5a2bad0 'ACPI: Support _OSI("Darwin") correctly'
Link: https://bugzilla.kernel.org/show_bug.cgi?id=94651
Signed-off-by: Chris Bainbridge <chris.bainbridge@gmail.com>
Cc: 3.18+ <stable@vger.kernel.org> # 3.18+
[ rjw: Subject and changelog ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Apparently I missed some compiler warnings on 32-bit platforms, where
phys_addr_t isn't the same size as void * and I casted it to make printk
work. Obviously I should have thought "I'm printing some random type,
instead of typecasting I should check Documentation/printk-formats.txt
and see how to do it." o/~ The More You Know ☆彡 o/~
This patch also fixes one other warning about an uninitialized variable
some compiler versions seem to see. You can't actually hit the code
path where it would be uninitialized, because there's a prior test that
would error out, but gcc hasn't figured that out. Anyway, it now has a
test and returns the error at both places.
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
The cmdline_size field in setup_header is listed as read-only, and is
never read by the kernel. Therefore, there is no need for it to be set
by a boot loader implementing the EFI handover protocol, so remove it
from the list of fields required to be set by a boot loader.
Signed-off-by: Alex Smith <alex@alex-smith.me.uk>
Cc: H. Peter Anvin <hpa@linux.intel.com>
Cc: x86@kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Add sysfs files for the EFI System Resource Table (ESRT) under
/sys/firmware/efi/esrt and for each EFI System Resource Entry under
entries/ as a subdir.
The EFI System Resource Table (ESRT) provides a read-only catalog of
system components for which the system accepts firmware upgrades via
UEFI's "Capsule Update" feature. This module allows userland utilities
to evaluate what firmware updates can be applied to this system, and
potentially arrange for those updates to occur.
The ESRT is described as part of the UEFI specification, in version 2.5
which should be available from http://uefi.org/specifications in early
2015. If you're a member of the UEFI Forum, information about its
addition to the standard is available as UEFI Mantis 1090.
For some hardware platforms, additional restrictions may be found at
http://msdn.microsoft.com/en-us/library/windows/hardware/jj128256.aspx ,
and additional documentation may be found at
http://download.microsoft.com/download/5/F/5/5F5D16CD-2530-4289-8019-94C6A20BED3C/windows-uefi-firmware-update-platform.docx
.
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
It's not very normal to return 1 on failure and 0 on success. There
isn't a reason for it here, the callers don't care so long as it's
non-zero on failure.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
