Async hash API allows the use of HW acceleration for hash calculation.
It may give significant performance gain and/or reduce power consumption,
which might be very beneficial for battery powered devices.
This patch introduces hash calculation using ahash API. ahash performance
depends on the data size and the particular HW. Depending on the specific
system, shash performance may be better.
This patch defines 'ahash_minsize' module parameter, which is used to
define the minimal file size to use with ahash. If this minimum file size
is not set or the file is smaller than defined by the parameter, shash will
be used.
Changes in v3:
- kernel parameter replaced with module parameter
- pr_crit replaced with pr_crit_ratelimited
- more comment changes - Mimi
Changes in v2:
- ima_ahash_size became as ima_ahash
- ahash pre-allocation moved out from __init code to be able to use
ahash crypto modules. Ahash allocated once on the first use.
- hash calculation falls back to shash if ahash allocation/calculation fails
- complex initialization separated from variable declaration
- improved comments
Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com>
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Add the device tree binding documentation for the GK20A GPU used in
Tegra K1 SoCs.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
This patch adds the device tree to support Toradex Apalis T30, a
computer on module which can be used on different carrier boards.
The module consists of a Tegra 3 SoC, two PMICs, 1 or 2 GB of DDR3L
RAM, eMMC, an LM95245 temperature sensor chip, an i210 resp. i211
gigabit Ethernet controller, an STMPE811 ADC/touch controller as well
as two MCP2515 CAN controllers. Furthermore, there is an SGTL5000 audio
codec which is not yet supported. Anything that is not self contained
on the module is disabled by default.
The device tree for the Evaluation Board includes the modules device
tree and enables the supported peripherals of the carrier board (the
Evaluation Board supports almost all of them).
While at it also add the device tree binding documentation for Apalis
T30.
Signed-off-by: Marcel Ziswiler <marcel@ziswiler.com>
[swarren: fixed some node sort orders]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Docbook creation was broken. We need to move after
v3.16-rc1-3-ga981296f048b in order to get commit
a981296f04.
Linux 3.16-rc5
* tag 'v3.16-rc5': (985 commits)
Linux 3.16-rc5
clk: spear3xx: Set proper clock parent of uart1/2
clk: spear3xx: Use proper control register offset
parisc: drop unused defines and header includes
parisc: fix fanotify_mark() syscall on 32bit compat kernel
parisc: add serial ports of C8000/1GHz machine to hardware database
ext4: fix potential null pointer dereference in ext4_free_inode
ext4: fix a potential deadlock in __ext4_es_shrink()
Documenation/laptops: rename and update hpfall.c
DocBook: fix various typos
DocBook: fix mtdnand typos
scripts/kernel-doc: handle object-like macros
Documentation/Changes: clean up mcelog paragraph
ARM: at91: at91sam9x5: add clocks for usb device
phy: omap-usb2: Balance pm_runtime_enable() on probe failure and remove
phy: core: Fix error path in phy_create()
drivers: phy: phy-samsung-usb2.c: Add missing MODULE_DEVICE_TABLE
phy: omap-usb2: fix devm_ioremap_resource error detection code
phy: sun4i: depend on RESET_CONTROLLER
USB: serial: ftdi_sio: Add Infineon Triboard
...
Add efuse and apbmisc bindings for Tegra20, Tegra30, Tegra114 and
Tegra124.
Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Implement fuse driver for Tegra20, Tegra30, Tegra114 and Tegra124. This
replaces functionality previously provided in arch/arm/mach-tegra, which
is removed in this patch.
While at it, move the only user of the global tegra_revision variable
over to tegra_sku_info.revision and export tegra_fuse_readl() to allow
drivers to read calibration fuses.
Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The shared library feature in Makefile.host is no longer used.
Rip it off to keep the build infrastucture simple.
Update Documentation/kbuild/makefiles.txt too.
The section "4.3 Definition shared libraries" should be removed
and the following sections should be re-numbered.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Suggested-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>
OPPs can be populated statically, via DT, or added at run time with
dev_pm_opp_add().
While this driver handles the first case correctly, it would fail to populate
OPPs added at runtime. Because call to of_init_opp_table() would fail as there
are no OPPs in DT and probe will return early.
To fix this, remove error checking and call dev_pm_opp_init_cpufreq_table()
unconditionally.
Update bindings as well.
Suggested-by: Stephen Boyd <sboyd@codeaurora.org>
Tested-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The current "wait_on_bit" interface requires an 'action'
function to be provided which does the actual waiting.
There are over 20 such functions, many of them identical.
Most cases can be satisfied by one of just two functions, one
which uses io_schedule() and one which just uses schedule().
So:
Rename wait_on_bit and wait_on_bit_lock to
wait_on_bit_action and wait_on_bit_lock_action
to make it explicit that they need an action function.
Introduce new wait_on_bit{,_lock} and wait_on_bit{,_lock}_io
which are *not* given an action function but implicitly use
a standard one.
The decision to error-out if a signal is pending is now made
based on the 'mode' argument rather than being encoded in the action
function.
All instances of the old wait_on_bit and wait_on_bit_lock which
can use the new version have been changed accordingly and their
action functions have been discarded.
wait_on_bit{_lock} does not return any specific error code in the
event of a signal so the caller must check for non-zero and
interpolate their own error code as appropriate.
The wait_on_bit() call in __fscache_wait_on_invalidate() was
ambiguous as it specified TASK_UNINTERRUPTIBLE but used
fscache_wait_bit_interruptible as an action function.
David Howells confirms this should be uniformly
"uninterruptible"
The main remaining user of wait_on_bit{,_lock}_action is NFS
which needs to use a freezer-aware schedule() call.
A comment in fs/gfs2/glock.c notes that having multiple 'action'
functions is useful as they display differently in the 'wchan'
field of 'ps'. (and /proc/$PID/wchan).
As the new bit_wait{,_io} functions are tagged "__sched", they
will not show up at all, but something higher in the stack. So
the distinction will still be visible, only with different
function names (gds2_glock_wait versus gfs2_glock_dq_wait in the
gfs2/glock.c case).
Since first version of this patch (against 3.15) two new action
functions appeared, on in NFS and one in CIFS. CIFS also now
uses an action function that makes the same freezer aware
schedule call as NFS.
Signed-off-by: NeilBrown <neilb@suse.de>
Acked-by: David Howells <dhowells@redhat.com> (fscache, keys)
Acked-by: Steven Whitehouse <swhiteho@redhat.com> (gfs2)
Acked-by: Peter Zijlstra <peterz@infradead.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Steve French <sfrench@samba.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/20140707051603.28027.72349.stgit@notabene.brown
Signed-off-by: Ingo Molnar <mingo@kernel.org>
This commit extends the existing clk-cpu driver used on Marvell Armada
XP platforms to support the dynamic frequency scaling of the CPU
clock. Non-dynamic frequency change was already supported (and used
before secondary CPUs are started), but the dynamic frequency change
requires a completely different procedure.
In order to achieve this, the clk_cpu_set_rate() function is reworked
to handle two separate cases:
- The case where the clock is enabled, which is the new dynamic
frequency change code, implemented in clk_cpu_on_set_rate(). This
part will be used for cpufreq activities.
- The case where the clock is disabled, which is the existing
frequency change code, moved in clk_cpu_off_set_rate(). This part
is already used to set the clock frequency of the secondary CPUs
before starting them.
In order to implement the dynamic frequency change function, we need
to access the PMU DFS registers, which are outside the currently
mapped "Clock Complex" registers, so a new area of registers is now
mapped. This affects the Device Tree binding, but we are careful to do
it in a backward-compatible way (by allowing the second pair of
registers to be non-existent, and in this case, ensuring
clk_cpu_on_set_rate() returns an error).
Note that technically speaking, the clk_cpu_on_set_rate() does not do
the entire procedure needed to change the frequency dynamically, as it
involves touching a number of PMSU registers. This is done through a
clock notifier registered by the PMSU driver in followup commits.
Cc: <devicetree@vger.kernel.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1404920715-19834-4-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
The CA9 MPcore SoC Control block is a set of registers that allows to
configure certain internal aspects of the core blocks of the SoC
(Cortex-A9, L2 cache controller, etc.). In most cases, the default
values are fine so they aren't many reasons to touch those registers,
but there is one exception: to support cpuidle on Armada 38x, we need
to modify the value of the CA9 MPcore Reset Control register.
Therefore, this commit adds a new Device Tree binding for this
hardware block, and uses this new binding for the Armada 38x Device
Tree file.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: devicetree@vger.kernel.org
Link: https://lkml.kernel.org/r/1404913221-17343-11-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
We always use resched_task() with rq->curr argument.
It's not possible to reschedule any task but rq's current.
The patch introduces resched_curr(struct rq *) to
replace all of the repeating patterns. The main aim
is cleanup, but there is a little size profit too:
(before)
$ size kernel/sched/built-in.o
text data bss dec hex filename
155274 16445 7042 178761 2ba49 kernel/sched/built-in.o
$ size vmlinux
text data bss dec hex filename
7411490 1178376 991232 9581098 92322a vmlinux
(after)
$ size kernel/sched/built-in.o
text data bss dec hex filename
155130 16445 7042 178617 2b9b9 kernel/sched/built-in.o
$ size vmlinux
text data bss dec hex filename
7411362 1178376 991232 9580970 9231aa vmlinux
I was choosing between resched_curr() and resched_rq(),
and the first name looks better for me.
A little lie in Documentation/trace/ftrace.txt. I have not
actually collected the tracing again. With a hope the patch
won't make execution times much worse :)
Signed-off-by: Kirill Tkhai <tkhai@yandex.ru>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Link: http://lkml.kernel.org/r/20140628200219.1778.18735.stgit@localhost
Signed-off-by: Ingo Molnar <mingo@kernel.org>
The APQ8064 multimedia clock controller is fairly similar to the
8960 multimedia clock controller, except that gfx2d0/1 has been
removed and the gfx3d frequency is slightly faster when using the
newly introduced PLL15. We also add vcap clocks and a couple new
TV clocks.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Add a driver for the global clock controller found on IPQ8064 based
platforms. This should allow most non-multimedia device drivers to probe
and control their clocks.
This is currently missing clocks for USB HSIC and networking devices.
Signed-off-by: Kumar Gala <galak@codeaurora.org>
Signed-off-by: Andy Gross <agross@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Add support for the multimedia clock controller found on the APQ8084
based platforms. This will allow the multimedia device drivers to
control their clocks.
Signed-off-by: Georgi Djakov <gdjakov@mm-sol.com>
[sboyd: Rework parent mapping to avoid conflicts]
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
The SO_TIMESTAMPING API defines option SOF_TIMESTAMPING_SYS_HW.
This feature is deprecated. It should not be implemented by new
device drivers. Existing drivers do not implement it, either --
with one exception.
Driver developers are encouraged to expose the NIC hw clock as a
PTP HW clock source, instead, and synchronize system time to the
HW source.
The control flag cannot be removed due to being part of the ABI, nor
can the structure scm_timestamping that is returned. Due to the one
legacy driver, the internal datapath and structure are not removed.
This patch only clearly marks the interface as deprecated. Device
drivers should always return a syststamp value of zero.
Signed-off-by: Willem de Bruijn <willemb@google.com>
----
We can consider adding a WARN_ON_ONCE in__sock_recv_timestamp
if non-zero syststamp is encountered
Acked-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Based on a patch by David Herrmann.
The name_assign_type attribute gives hints where the interface name of a
given net-device comes from. These values are currently defined:
NET_NAME_ENUM:
The ifname is provided by the kernel with an enumerated
suffix, typically based on order of discovery. Names may
be reused and unpredictable.
NET_NAME_PREDICTABLE:
The ifname has been assigned by the kernel in a predictable way
that is guaranteed to avoid reuse and always be the same for a
given device. Examples include statically created devices like
the loopback device and names deduced from hardware properties
(including being given explicitly by the firmware). Names
depending on the order of discovery, or in any other way on the
existence of other devices, must not be marked as PREDICTABLE.
NET_NAME_USER:
The ifname was provided by user-space during net-device setup.
NET_NAME_RENAMED:
The net-device has been renamed from userspace. Once this type is set,
it cannot change again.
NET_NAME_UNKNOWN:
This is an internal placeholder to indicate that we yet haven't yet
categorized the name. It will not be exposed to userspace, rather
-EINVAL is returned.
The aim of these patches is to improve user-space renaming of interfaces. As
a general rule, userspace must rename interfaces to guarantee that names stay
the same every time a given piece of hardware appears (at boot, or when
attaching it). However, there are several situations where userspace should
not perform the renaming, and that depends on both the policy of the local
admin, but crucially also on the nature of the current interface name.
If an interface was created in repsonse to a userspace request, and userspace
already provided a name, we most probably want to leave that name alone. The
main instance of this is wifi-P2P devices created over nl80211, which currently
have a long-standing bug where they are getting renamed by udev. We label such
names NET_NAME_USER.
If an interface, unbeknown to us, has already been renamed from userspace, we
most probably want to leave also that alone. This will typically happen when
third-party plugins (for instance to udev, but the interface is generic so could
be from anywhere) renames the interface without informing udev about it. A
typical situation is when you switch root from an installer or an initrd to the
real system and the new instance of udev does not know what happened before
the switch. These types of problems have caused repeated issues in the past. To
solve this, once an interface has been renamed, its name is labelled
NET_NAME_RENAMED.
In many cases, the kernel is actually able to name interfaces in such a
way that there is no need for userspace to rename them. This is the case when
the enumeration order of devices, or in fact any other (non-parent) device on
the system, can not influence the name of the interface. Examples include
statically created devices, or any naming schemes based on hardware properties
of the interface. In this case the admin may prefer to use the kernel-provided
names, and to make that possible we label such names NET_NAME_PREDICTABLE.
We want the kernel to have tho possibilty of performing predictable interface
naming itself (and exposing to userspace that it has), as the information
necessary for a proper naming scheme for a certain class of devices may not
be exposed to userspace.
The case where renaming is almost certainly desired, is when the kernel has
given the interface a name using global device enumeration based on order of
discovery (ethX, wlanY, etc). These naming schemes are labelled NET_NAME_ENUM.
Lastly, a fallback is left as NET_NAME_UNKNOWN, to indicate that a driver has
not yet been ported. This is mostly useful as a transitionary measure, allowing
us to label the various naming schemes bit by bit.
v8: minor documentation fixes
v9: move comment to the right commit
Signed-off-by: Tom Gundersen <teg@jklm.no>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Kay Sievers <kay@vrfy.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
The DMA40 device tree documentation was vague on the second cell passed
in the configuration node for consumers, and did not specify what the
available signals were connected to. Extend the documentation with this
information for the DB8500 ASIC.
Reported-by: Pawel Kulakowski <pawel.kulakowski@tieto.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Until now, cftype arrays carried files for both the default and legacy
hierarchies and the files which needed to be used on only one of them
were flagged with either CFTYPE_ONLY_ON_DFL or CFTYPE_INSANE. This
gets confusing very quickly and we may end up exposing interface files
to the default hierarchy without thinking it through.
This patch makes cgroup core provide separate sets of interfaces for
cftype handling so that the cftypes for the default and legacy
hierarchies are clearly distinguished. The previous two patches
renamed the existing ones so that they clearly indicate that they're
for the legacy hierarchies. This patch adds the interface for the
default hierarchy and apply them selectively depending on the
hierarchy type.
* cftypes added through cgroup_subsys->dfl_cftypes and
cgroup_add_dfl_cftypes() only show up on the default hierarchy.
* cftypes added through cgroup_subsys->legacy_cftypes and
cgroup_add_legacy_cftypes() only show up on the legacy hierarchies.
* cgroup_subsys->dfl_cftypes and ->legacy_cftypes can point to the
same array for the cases where the interface files are identical on
both types of hierarchies.
* This makes all the existing subsystem interface files legacy-only by
default and all subsystems will have no interface file created when
enabled on the default hierarchy. Each subsystem should explicitly
review and compose the interface for the default hierarchy.
* A boot param "cgroup__DEVEL__legacy_files_on_dfl" is added which
makes subsystems which haven't decided the interface files for the
default hierarchy to present the legacy files on the default
hierarchy so that its behavior on the default hierarchy can be
tested. As the awkward name suggests, this is for development only.
* memcg's CFTYPE_INSANE on "use_hierarchy" is noop now as the whole
array isn't used on the default hierarchy. The flag is removed.
v2: Updated documentation for cgroup__DEVEL__legacy_files_on_dfl.
v3: Clear CFTYPE_ONLY_ON_DFL and CFTYPE_INSANE when cfts are removed
as suggested by Li.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Li Zefan <lizefan@huawei.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Aristeu Rozanski <aris@redhat.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
This patch add registers, bit fields and compatible strings for Exynos3250 TMU
(Thermal Management Unit). Exynos3250 uses the Cortex-A7 dual cores and has
a target speed of 1.0 GHz.
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
[Add MUX address setting bits by Jonghwa Lee]
Signed-off-by: Jonghwa Lee <jonghwa3.lee@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Amit Daniel Kachhap<amit.daniel@samsung.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
This panel is used by Atmel's SAMA5D3 Evaluation Kits (sama5d3xek) and
supported by the simple-panel driver.
Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This patch adds "allwinner,sun8i-a23-apb0-gates-clk", a A23 specific
compatible to the sun6i-a31-apb0-gates clock driver, along with the
gate bitmap.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Create a sysfs-fs-xfs ABI documentation file for newly added sysfs
attributes. This is created under the testing section.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
During the last few years, several inline wrappers for DMA operations have
been introduced:
- commit 16052827d9 ("dmaengine/dma_slave:
introduce inline wrappers"),
- commit a14acb4ac2 ("DMAEngine: add
dmaengine_prep_interleaved_dma wrapper for interleaved api"),
- commit 6e3ecaf0ad ("dmaengine: add
wrapper functions for device control functions").
Update the documentation to use the wrappers.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
By default when CONFIG_XEN and CONFIG_XEN_PVHVM kernels are
run, they will enable the PV extensions (drivers, interrupts, timers,
etc) - which is the best option for the majority of use cases.
However, in some cases (kexec not fully working, benchmarking)
we want to disable Xen PV extensions. As such introduce the
'xen_nopv' parameter that will do it.
This parameter is intended only for HVM guests as the Xen PV
guests MUST boot with PV extensions. However, even if you use
'xen_nopv' on Xen PV guests it will be ignored.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
---
[v2: s/off/xen_nopv/ per Boris Ostrovsky recommendation.]
[v3: Add Reviewed-by]
[v4: Clarify that this is only for HVM guests]
SPEAr SOCs have some miscellaneous registers which are used to configure
peripheral.
This patch adds dt node and binding information for this block.
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Cc: devicetree@vger.kernel.org
[viresh: fixed logs/cclist]
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
ARM based ST Microelectronics's SPEAr1310/40 platforms uses ST's phy (known as
'miphy') for PCIe and SATA. This patch adds drivers for these miphys.
This also adds proper bindings for miphys.
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Tested-by: Mohit Kumar <mohit.kumar@st.com>
Cc: Kishon Vijay Abraham I <kishon@ti.com>
[viresh: fixed logs/cclist/checkpatch warnings, broken into smaller patches]
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
ARM based ST Microelectronics's SPEAr1310 and SPEAr1340 SOCs have onchip
designware PCIe controller. To make that usable, this patch adds a wrapper
driver based on existing designware driver.
Adds bindings for this new driver and update MAINTAINERS as well.
Cc: linux-pci@vger.kernel.org
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Signed-off-by: Mohit Kumar <mohit.kumar@st.com>
[viresh: fixed logs/cclist/checkpatch warnings, broken into smaller patches]
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
This resolves a number of merge issues with changes in this tree and
Linus's tree at the same time.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jonathan writes:
3rd round of IIO new drivers, cleanups and functionality for the 3.17 cycle.
New drivers
* isl29125 digital color light sensor driver
* TAOS/AMS tcs3414 digital color sensor
Staging graduation
* ad7291 ADC driver.
New functionality
* st_sensors - device tree support and bindings
* mma8452 - device tree support
Cleanups
* Drop redundant variables in a number of drivers.
* Reorder a structure definition to ealy wiht a warning about static
not being at the beginning in the hid-sensors driver.
* Switch a few more drivers away from using explicit sampling_frequency
attribute to providing this through the core.
* Make hid_sensor_get_reporting_interval static as only used within a single
file.
* Drop a redundant check for negative values in an unsigned variable from
ad9832
* Drop some duplicate case labels in the event monitor example code.
* Use devm_ioremap_resource to simplify error handling.
* Use devm_kzalloc within the blackfin timer driver to simplify error
handling and removal.
* A number of cleanups of the ad7291 from Hartmut Knaack in response
to a patch moving it out of staging.
* Core support for the period info element about events. It has been
in the abi for a while, but not added until now to the newer handling
of information related to events.
* Add HAS_IOMEM dependency to mxs_lradc to avoid build issues when testing
enabled.
This add bindings documentation for the clock and reset unit found on
rk3188 and rk3066 SoCs from Rockchip.
Also deprecate the old gate clock binding, as these shouldn't be used
in the future.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Acked-By: Max Schwarz <max.schwarz@online.de>
Tested-By: Max Schwarz <max.schwarz@online.de>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
Pull ARM SoC fixes from Olof Johansson:
"This week's arm-soc fixes:
- Another set of OMAP fixes
* Clock fixes
* Restart handling
* PHY regulators
* SATA hwmod data for DRA7
+ Some trivial fixes and removal of a bit of dead code
- Exynos fixes
* A bunch of clock fixes
* Some SMP fixes
* Exynos multi-core timer: register as clocksource and fix ftrace.
+ a few other minor fixes
There's also a couple more patches, and at91 fix for USB caused by
common clock conversion, and more MAINTAINERS entries for shmobile.
We're definitely switching to only regression fixes from here on out,
we've been a little less strict than usual up until now"
* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (26 commits)
ARM: at91: at91sam9x5: add clocks for usb device
ARM: EXYNOS: Register cpuidle device only on exynos4210 and 5250
ARM: dts: Add clock property for mfc_pd in exynos5420
clk: exynos5420: Add IDs for clocks used in PD mfc
ARM: EXYNOS: Add support for clock handling in power domain
ARM: OMAP2+: Remove non working OMAP HDMI audio initialization
ARM: imx: fix shared gate clock
ARM: dts: Update the parent for Audss clocks in Exynos5420
ARM: EXYNOS: Update secondary boot addr for secure mode
ARM: dts: Fix TI CPSW Phy mode selection on IGEP COM AQUILA.
ARM: dts: am335x-evmsk: Enable the McASP FIFO for audio
ARM: dts: am335x-evm: Enable the McASP FIFO for audio
ARM: OMAP2+: Make GPMC skip disabled devices
ARM: OMAP2+: create dsp device only on OMAP3 SoCs
ARM: dts: dra7-evm: Make VDDA_1V8_PHY supply always on
ARM: DRA7/AM43XX: fix header definition for omap44xx_restart
ARM: OMAP2+: clock/dpll: fix _dpll_test_fint arithmetics overflow
ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss
ARM: DRA7: hwmod: Fixup SATA hwmod
ARM: OMAP3: PRM/CM: Add back macros used by TI DSP/Bridge driver
...
