Pull libata fixes from Tejun Heo:
"There's one interseting commit - "libata, freezer: avoid block device
removal while system is frozen". It's an ugly hack working around a
deadlock condition between driver core resume and block layer device
removal paths through freezer which was made more reproducible by
writeback being converted to workqueue some releases ago. The bug has
nothing to do with libata but it's just an workaround which is easy to
backport. After discussion, Rafael and I seem to agree that we don't
really need kernel freezables - both kthread and workqueue. There are
few specific workqueues which constitute PM operations and require
freezing, which will be converted to use workqueue_set_max_active()
instead. All other kernel freezer uses are planned to be removed,
followed by the removal of kthread and workqueue freezer support,
hopefully.
Others are device-specific fixes. The most notable is the addition of
NO_NCQ_TRIM which is used to disable queued TRIM commands to Micro
M500 SSDs which otherwise suffers data corruption"
* 'for-3.13-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata:
libata, freezer: avoid block device removal while system is frozen
libata: implement ATA_HORKAGE_NO_NCQ_TRIM and apply it to Micro M500 SSDs
libata: disable a disk via libata.force params
ahci: bail out on ICH6 before using AHCI BAR
ahci: imx: Explicitly clear IMX6Q_GPR13_SATA_MPLL_CLK_EN
libata: add ATA_HORKAGE_BROKEN_FPDMA_AA quirk for Seagate Momentus SpinPoint M8
The fields are not used anymore by board files, remove them.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
The field isn't set by any board, remote it.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
This patch introduces device tree support to the isp1704 charger driver.
Adding support involved moving the handling of the enable GPIO from board
code into the driver.
Signed-off-by: Sebastian Reichel <sre@debian.org>
Signed-off-by: Anton Vorontsov <anton@enomsg.org>
Add method to get power supply by device tree phandle.
Signed-off-by: Sebastian Reichel <sre@debian.org>
Reviewed-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Anton Vorontsov <anton@enomsg.org>
Computing the baud rate register value requires knowledge of the
hardware sampling rate. This information is currently encoded in a baud
rate calculation algorithm ID passed through platform data. However, it
can be derived from the port type directly in most cases.
Compute the sampling rate internally in the driver if the baud rate
calculation algorithm ID isn't specified, and allow platforms to
override the sampling rate through platform data in special cases (this
is only required for SCIFA ports on sh7723 and sh7724, the reason needs
to be investigated).
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
The driver requests at initialization time GPIOs passed through platform
data. No platform makes use of this feature, remove it.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
None of the fields is ever set by board code, and both of them are set
in the driver at probe time. Move them out of struct plat_sci_port to
struct sci_port.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Memory and IRQ resources are currently passed to the driver through
platform data. Support passing them through the standard platform
resources mechanism instead. This deprecates platform data resources.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Rewrite the baud rate register value calculations in easier to read
forms. The computed value isn't modified.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
This patch removing set_mode_hook function from board data and replacing
it with new string variable of notifier power supply device. After this
change it is possible to add DT support because driver does not need
specific board function anymore. Only static data and name of power supply
device is required.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Reviewed-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Anton Vorontsov <anton@enomsg.org>
Charger-manager can parse charger_desc data from devicetree which is used
to register charger manager.
Signed-off-by: Jonghwa Lee <jonghwa3.lee@samsung.com>
Signed-off-by: Myungjoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Anton Vorontsov <anton@enomsg.org>
Charger-manager driver used to check battery temperature through the
callback function passed by platform data. Unfortunatley, without that
pre-defined callback function, charger-manager can't get battery's
temperature at all. Also passing callback function through platform data
ruins DT support for charger-manager.
This patch mondifies charger-manager driver to get temperature of battery
without pre-defined callback function. Now, charger-manager can use either
of battery thermometer in fuel-gauge and ouside of battery. It uses
thermal framework interface for outer thermometer if thermal fw is
enabled. Otherwise, it tries to use fuel-gauge's through the power supply
interface.
Signed-off-by: Jonghwa Lee <jonghwa3.lee@samsung.com>
Signed-off-by: Myungjoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Anton Vorontsov <anton@enomsg.org>
This adds a pair of APIs that allows the generic PHY subsystem to
provide information on the PHY bus width. The PHY provider driver may
use phy_set_bus_width() to set the bus width that the PHY supports.
The controller driver may then use phy_get_bus_width() to fetch the
PHY bus width in order to properly configure the controller.
Signed-off-by: Matt Porter <mporter@linaro.org>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
iQEcBAABAgAGBQJSt1TYAAoJEHm+PkMAQRiGvWgH/iWg8TmEWz4KUKuHthuUi0uh
9+2YDN+4k577Xa0obaG24giQeqkCdxMr3oJrS3FO9jeAmaNRHEGhxUPneisb7RtN
9jIVsz5bPa9/DcK9nqtaUQdvA0O5AWTE6AAPmwleTVy+8CygBo987T2uGELnQCSR
FrKCrMePc7Pj0uthMVXrpJ17Ffm/j7jkfRtPhrxHJyngh3jEux+tPbpynH/aKuO2
47unsSQimoFk7n2SPFvNu3E/vZE2xVbu5SH9MCl5yyiCifFjpi3B71LV/FW51lvm
cK8Jzn2BmYDygRFjnZfq4zJHqYJCBHzpjCLWmR37Dm/JS91aGq3+Cg0stDP8UTs=
=+Hcn
-----END PGP SIGNATURE-----
Merge tag 'v3.13-rc5' into next
Linux 3.13-rc5
* tag 'v3.13-rc5': (231 commits)
Linux 3.13-rc5
aio: clean up and fix aio_setup_ring page mapping
aio/migratepages: make aio migrate pages sane
aio: fix kioctx leak introduced by "aio: Fix a trinity splat"
Don't set the INITRD_COMPRESS environment variable automatically
mm: fix build of split ptlock code
pstore: Don't allow high traffic options on fragile devices
mm: do not allocate page->ptl dynamically, if spinlock_t fits to long
mm: page_alloc: revert NUMA aspect of fair allocation policy
Revert "mm: page_alloc: exclude unreclaimable allocations from zone fairness policy"
mm: Fix NULL pointer dereference in madvise(MADV_WILLNEED) support
qla2xxx: Fix scsi_host leak on qlt_lport_register callback failure
target: Remove extra percpu_ref_init
arm64: ptrace: avoid using HW_BREAKPOINT_EMPTY for disabled events
ARC: Allow conditional multiple inclusion of uapi/asm/unistd.h
target/file: Update hw_max_sectors based on current block_size
iser-target: Move INIT_WORK setup into isert_create_device_ib_res
iscsi-target: Fix incorrect np->np_thread NULL assignment
mm/hugetlb: check for pte NULL pointer in __page_check_address()
fix build with make 3.80
...
Conflicts:
drivers/usb/phy/Kconfig
This patch adds support for accuracy retrieval on fixed clocks.
It also adds a new dt property called 'clock-accuracy' to define the clock
accuracy.
This can be usefull for oscillator (RC, crystal, ...) definitions which are
always given an accuracy characteristic.
Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
The clock accuracy is expressed in ppb (parts per billion) and represents
the possible clock drift.
Say you have a clock (e.g. an oscillator) which provides a fixed clock of
20MHz with an accuracy of +- 20Hz. This accuracy expressed in ppb is
20Hz/20MHz = 1000 ppb (or 1 ppm).
Clock users may need the clock accuracy information in order to choose
the best clock (the one with the best accuracy) across several available
clocks.
This patch adds clk accuracy retrieval support for common clk framework by
means of a new function called clk_get_accuracy.
This function returns the given clock accuracy expressed in ppb.
In order to get the clock accuracy, this implementation adds one callback
called recalc_accuracy to the clk_ops structure.
This callback is given the parent clock accuracy (if the clock is not a
root clock) and should recalculate the given clock accuracy.
This callback is optional and may be implemented if the clock is not
a perfect clock (accuracy != 0 ppb).
Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
Add new inode flags F2FS_INLINE_DATA and FI_INLINE_DATA to indicate
whether the inode has inline data.
Inline data makes use of inode block's data indices region to save small
file. Currently there are 923 data indices in an inode block. Since
inline xattr has made use of the last 50 indices to save its data, there
are 873 indices left which can be used for inline data. When
FI_INLINE_DATA is set, the layout of inode block's indices region is
like below:
+-----------------+
| | Reserved. reserve_new_block() will make use of
| i_addr[0] | i_addr[0] when we need to reserve a new data block
| | to convert inline data into regular one's.
|-----------------|
| | Used by inline data. A file whose size is less than
| i_addr[1~872] | 3488 bytes(~3.4k) and doesn't reserve extra
| | blocks by fallocate() can be saved here.
|-----------------|
| |
| i_addr[873~922] | Reserved for inline xattr
| |
+-----------------+
Signed-off-by: Haicheng Li <haicheng.li@linux.intel.com>
Signed-off-by: Huajun Li <huajun.li@intel.com>
Signed-off-by: Weihong Xu <weihong.xu@intel.com>
Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com>
This series of changes brings DRM panel support as well as initial code
to register DSI hosts and peripherals and bind them to DSI drivers. The
panel and DSI code are both used by the simple panel driver.
The Tegra-specific changes build on top of this work to add support for
various panels found on Tegra boards. New drivers enable the DSI host
found on Tegra114 and a special hardware block that calibrates the pads
used for DSI and CSI. The host1x and the display controller drivers gain
basic Tegra124 support. To round of the new features, the DRM driver now
sports a very simple PRIME implementation.
In addition there are various improvements such as the host1x API being
exported so that client drivers (like the Tegra DRM driver) can be built
as modules. HDMI now does better power management and legacy FBDEV can
now be disabled via Kconfig (though it's still enabled by default). A
few sparse warnings have been squashed and various parts of the code
have become more robust.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJStLL5AAoJEN0jrNd/PrOhtD0QAJwhRTuEh8xCJ7pu1eK3TMh2
BYCD5UOiqnPAcDjJlTsiX0NaNQQ15+9uIjSIbbk36tfZ5cWbiP5yURYyMZp1HjvP
woGqsdI4eHVXswXNPMMIeTRrQKNMoQV82uvFAnE3QsfFwdkB+9p5tSUxnqXSuJ5U
ZKv1AL4FC0FdAnvugEz1lBzxqthoLm0mQ9xwkoYN2hT9ak1bnZUljfGYp2G/0xqM
RqhKgboZapL4Aul8lLIqqTCgo9XS3xN8Zo8F3WwyuOYJTgGZ6EK25H2bMvPBx0NO
fBNeacVd2jaCrELL6ZdsodKuu+TbHM82Sc6mZTA3YxN/E4tFUTfT++LQF7w505mA
PGHiZylwfDUPhGRRA8tYEz+OVQvT1FMhKEswlhDki0RJF5OHReQdrmBl0HfiUfmn
cQC9/WzGIqIP68tuuxOf8tdKHbAP1sOf7WgjFrBVX86hktN2Aq2f4dYtB7tf1c5O
1wTY+NPho8avscCycWdcqAtrgz2/KHBo4KvO7f9dqiTFa+A6KXdqe1dZaFrsPBjL
N4SizpY9VW7zJnmW9dIhb7qopVNw4g9OzCfH9dmpqrCnHpNFfmXYqDuppcSz7X5h
fWpXtA6iAEVIa5CE44liZWv/5SU8Mowrb8YbBgC/EoMWphDfnzporvcHe94GLNiy
O1iUYmI3mv48JKs30bYD
=lQsh
-----END PGP SIGNATURE-----
Merge tag 'drm/for-3.14-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-next
drm/tegra: Changes for v3.14-rc1
This series of changes brings DRM panel support as well as initial code
to register DSI hosts and peripherals and bind them to DSI drivers. The
panel and DSI code are both used by the simple panel driver.
The Tegra-specific changes build on top of this work to add support for
various panels found on Tegra boards. New drivers enable the DSI host
found on Tegra114 and a special hardware block that calibrates the pads
used for DSI and CSI. The host1x and the display controller drivers gain
basic Tegra124 support. To round of the new features, the DRM driver now
sports a very simple PRIME implementation.
In addition there are various improvements such as the host1x API being
exported so that client drivers (like the Tegra DRM driver) can be built
as modules. HDMI now does better power management and legacy FBDEV can
now be disabled via Kconfig (though it's still enabled by default). A
few sparse warnings have been squashed and various parts of the code
have become more robust.
* tag 'drm/for-3.14-rc1' of git://anongit.freedesktop.org/tegra/linux: (121 commits)
drm/tegra: fix compile w/ CONFIG_DYNAMIC_DEBUG
drm/tegra: Add PRIME support
drm/tegra: Relocate some output-specific code
drm/tegra: Add Tegra124 DC support
drm/tegra: Fix small leak on error in tegra_fb_alloc()
drm/tegra: Make legacy fbdev support optional
drm/tegra: Sort reverse-dependencies alphabetically
drm/tegra: Fix return value check
drm/tegra: Add DSI support
drm/tegra: Disable outputs for power-saving
drm/tegra: Track HDMI enable state
drm/tegra: Fix HDMI audio frequency typo
drm/tegra: Do not export tegra_bo_ops
drm/tegra: Remove spurious blank line
drm/tegra: Increase compile test coverage
drm/tegra: Allow the driver to be built as a module
gpu: host1x: Add Tegra124 support
gpu: host1x: clk_round_rate() can return a zero upon error
gpu: host1x: Fix build warnings
gpu: host1x: Increase compile test coverage
...
Add a generic event_command.set_trigger_filter() op implementation and
have the current set of trigger commands use it - this essentially
gives them all support for filters.
Syntactically, filters are supported by adding 'if <filter>' just
after the command, in which case only events matching the filter will
invoke the trigger. For example, to add a filter to an
enable/disable_event command:
echo 'enable_event:system:event if common_pid == 999' > \
.../othersys/otherevent/trigger
The above command will only enable the system:event event if the
common_pid field in the othersys:otherevent event is 999.
As another example, to add a filter to a stacktrace command:
echo 'stacktrace if common_pid == 999' > \
.../somesys/someevent/trigger
The above command will only trigger a stacktrace if the common_pid
field in the event is 999.
The filter syntax is the same as that described in the 'Event
filtering' section of Documentation/trace/events.txt.
Because triggers can now use filters, the trigger-invoking logic needs
to be moved in those cases - e.g. for ftrace_raw_event_calls, if a
trigger has a filter associated with it, the trigger invocation now
needs to happen after the { assign; } part of the call, in order for
the trigger condition to be tested.
There's still a SOFT_DISABLED-only check at the top of e.g. the
ftrace_raw_events function, so when an event is soft disabled but not
because of the presence of a trigger, the original SOFT_DISABLED
behavior remains unchanged.
There's also a bit of trickiness in that some triggers need to avoid
being invoked while an event is currently in the process of being
logged, since the trigger may itself log data into the trace buffer.
Thus we make sure the current event is committed before invoking those
triggers. To do that, we split the trigger invocation in two - the
first part (event_triggers_call()) checks the filter using the current
trace record; if a command has the post_trigger flag set, it sets a
bit for itself in the return value, otherwise it directly invoks the
trigger. Once all commands have been either invoked or set their
return flag, event_triggers_call() returns. The current record is
then either committed or discarded; if any commands have deferred
their triggers, those commands are finally invoked following the close
of the current event by event_triggers_post_call().
To simplify the above and make it more efficient, the TRIGGER_COND bit
is introduced, which is set only if a soft-disabled trigger needs to
use the log record for filter testing or needs to wait until the
current log record is closed.
The syscall event invocation code is also changed in analogous ways.
Because event triggers need to be able to create and free filters,
this also adds a couple external wrappers for the existing
create_filter and free_filter functions, which are too generic to be
made extern functions themselves.
Link: http://lkml.kernel.org/r/7164930759d8719ef460357f143d995406e4eead.1382622043.git.tom.zanussi@linux.intel.com
Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Add 'enable_event' and 'disable_event' event_command commands.
enable_event and disable_event event triggers are added by the user
via these commands in a similar way and using practically the same
syntax as the analagous 'enable_event' and 'disable_event' ftrace
function commands, but instead of writing to the set_ftrace_filter
file, the enable_event and disable_event triggers are written to the
per-event 'trigger' files:
echo 'enable_event:system:event' > .../othersys/otherevent/trigger
echo 'disable_event:system:event' > .../othersys/otherevent/trigger
The above commands will enable or disable the 'system:event' trace
events whenever the othersys:otherevent events are hit.
This also adds a 'count' version that limits the number of times the
command will be invoked:
echo 'enable_event:system:event:N' > .../othersys/otherevent/trigger
echo 'disable_event:system:event:N' > .../othersys/otherevent/trigger
Where N is the number of times the command will be invoked.
The above commands will will enable or disable the 'system:event'
trace events whenever the othersys:otherevent events are hit, but only
N times.
This also makes the find_event_file() helper function extern, since
it's useful to use from other places, such as the event triggers code,
so make it accessible.
Link: http://lkml.kernel.org/r/f825f3048c3f6b026ee37ae5825f9fc373451828.1382622043.git.tom.zanussi@linux.intel.com
Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Add 'stacktrace' event_command. stacktrace event triggers are added
by the user via this command in a similar way and using practically
the same syntax as the analogous 'stacktrace' ftrace function command,
but instead of writing to the set_ftrace_filter file, the stacktrace
event trigger is written to the per-event 'trigger' files:
echo 'stacktrace' > .../tracing/events/somesys/someevent/trigger
The above command will turn on stacktraces for someevent i.e. whenever
someevent is hit, a stacktrace will be logged.
This also adds a 'count' version that limits the number of times the
command will be invoked:
echo 'stacktrace:N' > .../tracing/events/somesys/someevent/trigger
Where N is the number of times the command will be invoked.
The above command will log N stacktraces for someevent i.e. whenever
someevent is hit N times, a stacktrace will be logged.
Link: http://lkml.kernel.org/r/0c30c008a0828c660aa0e1bbd3255cf179ed5c30.1382622043.git.tom.zanussi@linux.intel.com
Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Add 'snapshot' event_command. snapshot event triggers are added by
the user via this command in a similar way and using practically the
same syntax as the analogous 'snapshot' ftrace function command, but
instead of writing to the set_ftrace_filter file, the snapshot event
trigger is written to the per-event 'trigger' files:
echo 'snapshot' > .../somesys/someevent/trigger
The above command will turn on snapshots for someevent i.e. whenever
someevent is hit, a snapshot will be done.
This also adds a 'count' version that limits the number of times the
command will be invoked:
echo 'snapshot:N' > .../somesys/someevent/trigger
Where N is the number of times the command will be invoked.
The above command will snapshot N times for someevent i.e. whenever
someevent is hit N times, a snapshot will be done.
Also adds a new tracing_alloc_snapshot() function - the existing
tracing_snapshot_alloc() function is a special version of
tracing_snapshot() that also does the snapshot allocation - the
snapshot triggers would like to be able to do just the allocation but
not take a snapshot; the existing tracing_snapshot_alloc() in turn now
also calls tracing_alloc_snapshot() underneath to do that allocation.
Link: http://lkml.kernel.org/r/c9524dd07ce01f9dcbd59011290e0a8d5b47d7ad.1382622043.git.tom.zanussi@linux.intel.com
Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
[ fix up from kbuild test robot <fengguang.wu@intel.com report ]
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
The pm_generic_runtime_suspend|resume functions were implemented within
CONFIG_PM_RUNTIME.
As we also may use runtime PM callbacks during system suspend, to put
devices into low power state, we need to move the implementation of
pm_generic_runtime_suspend|resume to CONFIG_PM.
This change gives a power domain provision to invoke a platform
driver's runtime PM callback from a power domain's system PM callback.
This were earlier prevented by the platform bus, since it uses the
pm_generic_runtime_suspend|resume functions as runtime PM callbacks.
Cc: Kevin Hilman <khilman@linaro.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
By having the runtime PM callbacks implemented for CONFIG_PM, these
becomes available in all combinations of CONFIG_PM_SLEEP and
CONFIG_PM_RUNTIME.
The benefit using this, is that we don't need to implement the wrapper
functions which handles runtime PM resourses, typically called from
both runtime PM and system PM callbacks. Instead the runtime PM
callbacks can be invoked directly from system PM callbacks, which is
useful for some drivers, subsystems and power domains.
Use the new macro SET_PM_RUNTIME_PM_OPS in cases were the above makes
sense. Make sure the callbacks are encapsulated within CONFIG_PM
instead of CONFIG_PM_RUNTIME.
Do note that the old macro SET_RUNTIME_PM_OPS, which is being quite
widely used right now, requires the callbacks to be defined for
CONFIG_PM_RUNTIME. In many cases it will certainly be convenient to
convert to the new macro above, but that will have to be distinguished
in case by case.
Cc: Kevin Hilman <khilman@linaro.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
We use the same approach as for the existing SET_SYSTEM_SLEEP_PM_OPS,
but for the late and early callbacks instead.
The new SET_LATE_SYSTEM_SLEEP_PM_OPS, defined for CONFIG_PM_SLEEP, will
point ->suspend_late, ->freeze_late and ->poweroff_late to the same
function. Vice verse happens for ->resume_early, ->thaw_early and
->restore_early.
Cc: Kevin Hilman <khilman@linaro.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The arbitrary restriction on page counts offered by the core
migrate_page_move_mapping() code results in rather suspicious looking
fiddling with page reference counts in the aio_migratepage() operation.
To fix this, make migrate_page_move_mapping() take an extra_count parameter
that allows aio to tell the code about its own reference count on the page
being migrated.
While cleaning up aio_migratepage(), make it validate that the old page
being passed in is actually what aio_migratepage() expects to prevent
misbehaviour in the case of races.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Define CPU interface offsets for the GICC_ABPR, GICC_APR, and GICC_IIDR
registers. Define distributor registers for the GICD_SPENDSGIR and the
GICD_CPENDSGIR. KVM/ARM needs to know about these definitions to fully
support save/restore of the VGIC.
Also define some masks and shifts for the various GICH_VMCR fields.
Cc: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Support creating the ARM VGIC device through the KVM_CREATE_DEVICE
ioctl, which can then later be leveraged to use the
KVM_{GET/SET}_DEVICE_ATTR, which is useful both for setting addresses in
a more generic API than the ARM-specific one and is useful for
save/restore of VGIC state.
Adds KVM_CAP_DEVICE_CTRL to ARM capabilities.
Note that we change the check for creating a VGIC from bailing out if
any VCPUs were created, to bailing out if any VCPUs were ever run. This
is an important distinction that shouldn't break anything, but allows
creating the VGIC after the VCPUs have been created.
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
We store BAR information as a struct resource, which contains the CPU
address, not the bus address. Drivers often need the bus address, and
there's currently no convenient way to get it, so they often read the
BAR directly, or use the resource address (which doesn't work if there's
any translation between CPU and bus addresses).
Add pci_bus_address() to make this convenient.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
These interfaces:
pcibios_resource_to_bus(struct pci_dev *dev, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_dev *dev, *resource, *bus_region)
took a pci_dev, but they really depend only on the pci_bus. And we want to
use them in resource allocation paths where we have the bus but not a
device, so this patch converts them to take the pci_bus instead of the
pci_dev:
pcibios_resource_to_bus(struct pci_bus *bus, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_bus *bus, *resource, *bus_region)
In fact, with standard PCI-PCI bridges, they only depend on the host
bridge, because that's the only place address translation occurs, but
we aren't going that far yet.
[bhelgaas: changelog]
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
kexec kernel will need exactly same mapping for EFI runtime memory
ranges. Thus here export the runtime ranges mapping to sysfs,
kexec-tools will assemble them and pass to 2nd kernel via setup_data.
Introducing a new directory /sys/firmware/efi/runtime-map just like
/sys/firmware/memmap. Containing below attribute in each file of that
directory:
attribute num_pages phys_addr type virt_addr
Signed-off-by: Dave Young <dyoung@redhat.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Export fw_vendor, runtime and config table physical addresses to
/sys/firmware/efi/{fw_vendor,runtime,config_table} because kexec kernels
need them.
From EFI spec these 3 variables will be updated to virtual address after
entering virtual mode. But kernel startup code will need the physical
address.
Signed-off-by: Dave Young <dyoung@redhat.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
tps65910 has a backup battery charger with a configurable voltage. This
patch adds a regulator for the backup battery.
Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
Add 'traceon' and 'traceoff' event_command commands. traceon and
traceoff event triggers are added by the user via these commands in a
similar way and using practically the same syntax as the analagous
'traceon' and 'traceoff' ftrace function commands, but instead of
writing to the set_ftrace_filter file, the traceon and traceoff
triggers are written to the per-event 'trigger' files:
echo 'traceon' > .../tracing/events/somesys/someevent/trigger
echo 'traceoff' > .../tracing/events/somesys/someevent/trigger
The above command will turn tracing on or off whenever someevent is
hit.
This also adds a 'count' version that limits the number of times the
command will be invoked:
echo 'traceon:N' > .../tracing/events/somesys/someevent/trigger
echo 'traceoff:N' > .../tracing/events/somesys/someevent/trigger
Where N is the number of times the command will be invoked.
The above commands will will turn tracing on or off whenever someevent
is hit, but only N times.
Some common register/unregister_trigger() implementations of the
event_command reg()/unreg() callbacks are also provided, which add and
remove trigger instances to the per-event list of triggers, and
arm/disarm them as appropriate. event_trigger_callback() is a
general-purpose event_command func() implementation that orchestrates
command parsing and registration for most normal commands.
Most event commands will use these, but some will override and
possibly reuse them.
The event_trigger_init(), event_trigger_free(), and
event_trigger_print() functions are meant to be common implementations
of the event_trigger_ops init(), free(), and print() ops,
respectively.
Most trigger_ops implementations will use these, but some will
override and possibly reuse them.
Link: http://lkml.kernel.org/r/00a52816703b98d2072947478dd6e2d70cde5197.1382622043.git.tom.zanussi@linux.intel.com
Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Add a 'trigger' file for each trace event, enabling 'trace event
triggers' to be set for trace events.
'trace event triggers' are patterned after the existing 'ftrace
function triggers' implementation except that triggers are written to
per-event 'trigger' files instead of to a single file such as the
'set_ftrace_filter' used for ftrace function triggers.
The implementation is meant to be entirely separate from ftrace
function triggers, in order to keep the respective implementations
relatively simple and to allow them to diverge.
The event trigger functionality is built on top of SOFT_DISABLE
functionality. It adds a TRIGGER_MODE bit to the ftrace_event_file
flags which is checked when any trace event fires. Triggers set for a
particular event need to be checked regardless of whether that event
is actually enabled or not - getting an event to fire even if it's not
enabled is what's already implemented by SOFT_DISABLE mode, so trigger
mode directly reuses that. Event trigger essentially inherit the soft
disable logic in __ftrace_event_enable_disable() while adding a bit of
logic and trigger reference counting via tm_ref on top of that in a
new trace_event_trigger_enable_disable() function. Because the base
__ftrace_event_enable_disable() code now needs to be invoked from
outside trace_events.c, a wrapper is also added for those usages.
The triggers for an event are actually invoked via a new function,
event_triggers_call(), and code is also added to invoke them for
ftrace_raw_event calls as well as syscall events.
The main part of the patch creates a new trace_events_trigger.c file
to contain the trace event triggers implementation.
The standard open, read, and release file operations are implemented
here.
The open() implementation sets up for the various open modes of the
'trigger' file. It creates and attaches the trigger iterator and sets
up the command parser. If opened for reading set up the trigger
seq_ops.
The read() implementation parses the event trigger written to the
'trigger' file, looks up the trigger command, and passes it along to
that event_command's func() implementation for command-specific
processing.
The release() implementation does whatever cleanup is needed to
release the 'trigger' file, like releasing the parser and trigger
iterator, etc.
A couple of functions for event command registration and
unregistration are added, along with a list to add them to and a mutex
to protect them, as well as an (initially empty) registration function
to add the set of commands that will be added by future commits, and
call to it from the trace event initialization code.
also added are a couple trigger-specific data structures needed for
these implementations such as a trigger iterator and a struct for
trigger-specific data.
A couple structs consisting mostly of function meant to be implemented
in command-specific ways, event_command and event_trigger_ops, are
used by the generic event trigger command implementations. They're
being put into trace.h alongside the other trace_event data structures
and functions, in the expectation that they'll be needed in several
trace_event-related files such as trace_events_trigger.c and
trace_events.c.
The event_command.func() function is meant to be called by the trigger
parsing code in order to add a trigger instance to the corresponding
event. It essentially coordinates adding a live trigger instance to
the event, and arming the triggering the event.
Every event_command func() implementation essentially does the
same thing for any command:
- choose ops - use the value of param to choose either a number or
count version of event_trigger_ops specific to the command
- do the register or unregister of those ops
- associate a filter, if specified, with the triggering event
The reg() and unreg() ops allow command-specific implementations for
event_trigger_op registration and unregistration, and the
get_trigger_ops() op allows command-specific event_trigger_ops
selection to be parameterized. When a trigger instance is added, the
reg() op essentially adds that trigger to the triggering event and
arms it, while unreg() does the opposite. The set_filter() function
is used to associate a filter with the trigger - if the command
doesn't specify a set_filter() implementation, the command will ignore
filters.
Each command has an associated trigger_type, which serves double duty,
both as a unique identifier for the command as well as a value that
can be used for setting a trigger mode bit during trigger invocation.
The signature of func() adds a pointer to the event_command struct,
used to invoke those functions, along with a command_data param that
can be passed to the reg/unreg functions. This allows func()
implementations to use command-specific blobs and supports code
re-use.
The event_trigger_ops.func() command corrsponds to the trigger 'probe'
function that gets called when the triggering event is actually
invoked. The other functions are used to list the trigger when
needed, along with a couple mundane book-keeping functions.
This also moves event_file_data() into trace.h so it can be used
outside of trace_events.c.
Link: http://lkml.kernel.org/r/316d95061accdee070aac8e5750afba0192fa5b9.1382622043.git.tom.zanussi@linux.intel.com
Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
Idea-by: Steve Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Some pstore backing devices use on board flash as persistent
storage. These have limited numbers of write cycles so it
is a poor idea to use them from high frequency operations.
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In struct page we have enough space to fit long-size page->ptl there,
but we use dynamically-allocated page->ptl if size(spinlock_t) is larger
than sizeof(int).
It hurts 64-bit architectures with CONFIG_GENERIC_LOCKBREAK, where
sizeof(spinlock_t) == 8, but it easily fits into struct page.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Add prototype declaration of function memory_block_size_bytes() to
the header file include/linux/memory.h.
This eliminates the following warning in memory.c:
drivers/base/memory.c:87:1: warning: no previous prototype for ‘memory_block_size_bytes’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* pci/msi:
PCI/MSI: Make pci_enable_msi/msix() 'nvec' argument type as int
PCI/MSI: Return -ENOSYS for unimplemented interfaces, not -1
PCI/MSI: Return msix_capability_init() failure if populate_msi_sysfs() fails
s390/PCI: Remove superfluous check of MSI type
s390/PCI: Fix single MSI only check
PCI/MSI: Export MSI mode using attributes, not kobjects
This isolates the custom S3C64xx GPIO definition table to
<linux/platform_data/gpio-samsung-s3x64xx.h> as this is
used in a few different places in the kernel, removing the
need to depend on the implicit inclusion of <mach/gpio.h>
from <linux/gpio.h> and thus getting rid of a few nasty
cross-dependencies.
Also delete the CONFIG_SAMSUNG_GPIO_EXTRA stuff. Instead
roof the number of GPIOs for this platform:
First sum up all the GPIO banks from A to Q: 187 GPIOs.
Add the 16 "board GPIOs" and the roof for SAMSUNG_GPIO_EXTRA,
128, so in total maximum 187+16+128 = 331 GPIOs, so let's
take the same roof as for S3C24XX: 512. This way we can do
away with the GPIO calculation macros for GPIO_BOARD_START,
BOARD_NR_GPIOS and the definition of ARCH_NR_GPIOS.
Cc: Mark Brown <broonie@kernel.org>
[on Mini6410 board]
Tested-by: Tomasz Figa <t.figa@samsung.com>
[for changes in mach-s3c64xx]
Acked-by: Tomasz Figa <t.figa@samsung.com>
Tested-by: Mark Brown <broonie@linaro.org>
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This isolates the custom S3C24xx GPIO definition table to
<linux/platform_data/gpio-samsung-s3x24xx.h> as this is
used in a few different places in the kernel, removing the
need to depend on the implicit inclusion of <mach/gpio.h>
from <linux/gpio.h> and thus getting rid of a few nasty
cross-dependencies.
We also delete the nifty CONFIG_S3C24XX_GPIO_EXTRA stuff.
The biggest this can ever be for the S3C24XX is
CONFIG_S3C24XX_GPIO_EXTRA = 128, and then for CPU_S3C2443 or
CPU_S3C2416 32*12 GPIOs are added, so 32*12+128 = 512
is the absolute roof value on this platform. So we set
the size of ARCH_NR_GPIO to this and the GPIOs array will
fit any S3C24XX platform, as per pattern from other archs.
ChangeLog v2->v3:
- Move the movement of the S3C64XX gpio.h file out of
this patch and into the follow-up patch where it belongs.
ChangeLog v1->v2:
- Added an #ifdef ARCH_S3C24XX around the header inclusion
in drivers/gpio/gpio-samsung.c as we would otherwise
have colliding definitions when compiling S3C64XX.
- Rename inclusion guard in the header file.
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: linux-samsung-soc@vger.kernel.org
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Make pci_enable_msi_block(), pci_enable_msi_block_auto() and
pci_enable_msix() consistent with regard to the type of 'nvec' argument.
Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Tejun Heo <tj@kernel.org>
