The OMAP UART provides support for HW assisted flow control. What is
missing is the support to throttle / unthrottle callbacks which are used
by the omap-serial driver at the moment.
This patch adds the callbacks. It should be safe to add them since they
are only invoked from the serial_core (uart_throttle()) if the feature
flags are set.
Reviewed-by: Tony Lindgren <tony@atomide.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pull scheduler fixes from Ingo Molnar:
"A CONFIG_STACK_GROWSUP=y fix, and a hotplug llc CPU mask fix"
* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched: Fix unreleased llc_shared_mask bit during CPU hotplug
sched: Fix end_of_stack() and location of stack canary for architectures using CONFIG_STACK_GROWSUP
This is detected with:
gcc-4.8.3-7.fc20.x86_64
sparse-0.5.0-3.fc20.x86_64
drivers/media/v4l2-core/v4l2-dv-timings.c:34:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:35:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:36:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:37:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:38:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:39:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:40:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:41:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:42:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:43:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:44:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:45:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:46:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:47:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:48:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:49:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:50:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:51:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:52:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:53:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:54:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:55:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:56:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:57:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:58:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:59:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:60:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:61:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:62:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:63:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:64:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:65:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:66:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:67:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:68:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:69:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:70:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:71:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:72:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:73:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:74:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:75:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:76:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:77:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:78:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:79:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:80:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:81:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:82:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:83:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:84:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:85:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:86:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:87:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:88:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:89:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:90:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:91:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:92:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:93:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:94:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:95:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:96:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:97:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:98:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:99:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c💯9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:101:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:102:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:103:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:104:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:105:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:106:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:107:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:108:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:109:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:110:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:111:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:112:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:113:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:114:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:115:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:116:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:117:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:118:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:119:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:120:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:121:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:122:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:123:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:124:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:125:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:126:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:127:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:128:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:129:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:130:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:131:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:132:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:133:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:134:9: error: unknown field name in initializer
drivers/media/v4l2-core/v4l2-dv-timings.c:135:9: error: too many errors
drivers/media/usb/hdpvr/hdpvr-video.c:42:9: error: unknown field name in initializer
drivers/media/usb/hdpvr/hdpvr-video.c:43:9: error: unknown field name in initializer
drivers/media/usb/hdpvr/hdpvr-video.c:44:9: error: unknown field name in initializer
drivers/media/usb/hdpvr/hdpvr-video.c:45:9: error: unknown field name in initializer
drivers/media/usb/hdpvr/hdpvr-video.c:46:9: error: unknown field name in initializer
drivers/media/usb/hdpvr/hdpvr-video.c:47:9: error: unknown field name in initializer
drivers/media/usb/hdpvr/hdpvr-video.c:48:9: error: unknown field name in initializer
drivers/media/usb/hdpvr/hdpvr-video.c:49:9: error: unknown field name in initializer
drivers/media/platform/s5p-tv/hdmi_drv.c:484:18: error: unknown field name in initializer
drivers/media/platform/s5p-tv/hdmi_drv.c:485:18: error: unknown field name in initializer
drivers/media/platform/s5p-tv/hdmi_drv.c:486:18: error: unknown field name in initializer
drivers/media/platform/s5p-tv/hdmi_drv.c:487:18: error: unknown field name in initializer
drivers/media/platform/s5p-tv/hdmi_drv.c:488:18: error: unknown field name in initializer
drivers/media/platform/s5p-tv/hdmi_drv.c:489:18: error: unknown field name in initializer
drivers/media/platform/s5p-tv/hdmi_drv.c:490:18: error: unknown field name in initializer
drivers/media/platform/s5p-tv/hdmi_drv.c:491:18: error: unknown field name in initializer
drivers/media/platform/s5p-tv/hdmi_drv.c:492:18: error: unknown field name in initializer
drivers/media/platform/s5p-tv/hdmi_drv.c:493:18: error: unknown field name in initializer
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
If an MFD device is backed by ACPI namespace, we should allow subdevice
drivers to access their corresponding ACPI companion devices through normal
means (e.g using ACPI_COMPANION()).
This patch adds such support to the MFD core. If the MFD parent device
does not specify any ACPI _HID/_CID for the child device, the child
device will share the parent ACPI companion device. Otherwise the child
device will be assigned with the corresponding ACPI companion, if found
in the namespace below the parent.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
The logic in AFE_Pen_Ctrl bitmask in the CTRL register is different for five
wire versus four or eight wire touschscreens. This patch should fix this for
five-wire touch screens. There should be no change needed here for four and
eight wire tousch screens.
Signed-off-by: Jeff Lance <j-lance1@ti.com>
[bigeasy: keep the change mfd only]
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Allow regmap to provide debugfs access to the register map by telling it
what registers are valid.
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
This adds driver to support HiSilicon Hi6421 PMIC. Hi6421 includes multi-
functions, such as regulators, codec, ADCs, Coulomb counter, etc.
This driver includes core APIs _only_.
Drivers for individul components, like voltage regulators, are
implemented in corresponding driver directories and files.
Registers in Hi6421 are memory mapped, so using regmap-mmio API.
Signed-off-by: Guodong Xu <guodong.xu@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
This patch adds the PCI id for Intel Quark ILB.
It will be used for GPIO and Multifunction device driver.
Signed-off-by: Josef Ahmad <josef.ahmad@intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
The RK808 chip is a power management IC for multimedia and handheld
devices. It contains the following components:
- Regulators
- RTC
- Clkout
The RK808 core driver is registered as a platform driver and provides
communication through I2C with the host device for the different
components.
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Zhang Qing <zhangqing@rock-chips.com>
Tested-by: Heiko <heiko@sntech.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Add device tree bindings documentation and a header file
for rockchip's RK808 pmic.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Zhang Qing <zhangqing@rock-chips.com>
Tested-by: Heiko <heiko@sntech.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Current code init regmap with &da9052_regmap_config for both da9052-spi and
da9052-i2c drivers. da9052-spi sets the read_flag_mask.
The same setting may be applied for da9052-i2c if da9052-spi driver is loaded
first because they actually use the same regmap_config setting.
Fix this issue by using a local variable for regmap_config in da9052-spi driver,
so the settings in spi driver won't impact the settings in i2c driver.
Also makes da9052_regmap_config const to avoid similar issue.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Some arizona devices have a second asynchronous sample rate, add the
registers necessary to support this.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Ricoh RN5T618 is a power management IC which integrates 3 step-down
DCDC converters, 7 low-dropout regulators, a Li-ion battery charger,
fuel gauge, ADC, GPIOs and a watchdog timer.
This commit adds a MFD core driver to support the I2C communication
with the device.
Signed-off-by: Beniamino Galvani <b.galvani@gmail.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
The include guard doesn't work as intended due to the transposition
typo DAVINCI -> DAVINIC.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
The header file include/linux/mfd/ti_ssp.h does not seem to be used
anywhere. It was orphaned by 3033ee62 "mfd: Remove obsolete ti-ssp
driver". Remove it.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
This patch improves support for the flash cell of
max77693 mfd by adding relevant of_compatible field
and a structure for caching related platform data.
Added are also FLASH registers related macro definitions.
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
According to the MAX77693 documentation the name of
the register is FLASH_STATUS.
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
During init the core checks if the wm5102 has finished starting by reading
register 0x19 and looking at the value. This read always fails since this
is not a readable register, mark it as being one. While we're at it provide
a constant for the register name (as supplied by Charles Keepax).
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Calling strncpy with a maximum size argument of 32 bytes on destination
array kim_gdata->dev_name of size 32 bytes might leave the destination
string unterminated.
Cc: gregkh@linuxfoundation.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Various drivers implement architecture and/or device specific means to
restart (reset) the system. Various mechanisms have been implemented to
support those schemes. The best known mechanism is arm_pm_restart, which
is a function pointer to be set either from platform specific code or from
drivers. Another mechanism is to use hardware watchdogs to issue a reset;
this mechanism is used if there is no other method available to reset a
board or system. Two examples are alim7101_wdt, which currently uses the
reboot notifier to trigger a reset, and moxart_wdt, which registers the
arm_pm_restart function.
The existing mechanisms have a number of drawbacks. Typically only one
scheme to restart the system is supported (at least if arm_pm_restart is
used). At least in theory there can be multiple means to restart the
system, some of which may be less desirable (for example one mechanism may
only reset the CPU, while another may reset the entire system). Using
arm_pm_restart can also be racy if the function pointer is set from a
driver, as the driver may be in the process of being unloaded when
arm_pm_restart is called. Using the reboot notifier is always racy, as it
is unknown if and when other functions using the reboot notifier have
completed execution by the time the watchdog fires.
Introduce a system restart handler call chain to solve the described
problems. This call chain is expected to be executed from the
architecture specific machine_restart() function. Drivers providing
system restart functionality (such as the watchdog drivers mentioned
above) are expected to register with this call chain. By using the
priority field in the notifier block, callers can control restart handler
execution sequence and thus ensure that the restart handler with the
optimal restart capabilities for a given system is called first.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Wim Van Sebroeck <wim@iguana.be>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Jonas Jensen <jonas.jensen@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
The send_check logic was only interesting in cases of TCP offload and
UDP UFO where the checksum needed to be initialized to the pseudo
header checksum. Now we've moved that logic into the related
gso_segment functions so gso_send_check is no longer needed.
Signed-off-by: Tom Herbert <therbert@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
If CONFIG_COMMON_CLK is selected then __clk_get and __clk_put are
defined in drivers/clk/clk.c and declared in include/linux/clkdev.h.
Sylwester's series[0] to properly support clk_{get,put} in the common
clock framework made changes to the asm-specific clkdev.h headers, but
not the asm-generic version. Tomeu's recent changes[1] to introduce a
provider/consumer split in the clock framework uncovered this problem,
causing the following build error on any architecture using the
asm-generic clkdev.h (e.g. x86 architecture and the ACPI LPSS driver):
In file included from drivers/acpi/acpi_lpss.c:15:0:
include/linux/clkdev.h:59:5: error: conflicting types for ‘__clk_get’
int __clk_get(struct clk_core *clk);
^
In file included from arch/x86/include/generated/asm/clkdev.h:1:0,
from include/linux/clkdev.h:15,
from drivers/acpi/acpi_lpss.c:15:
include/asm-generic/clkdev.h:20:19: note: previous definition of ‘__clk_get’ was here
static inline int __clk_get(struct clk *clk) { return 1; }
^
Fixed by only declarating __clk_get and __clk_put when
CONFIG_COMMON_CLK is set.
[0] http://lkml.kernel.org/r/<1386177127-2894-5-git-send-email-s.nawrocki@samsung.com>
[1] http://lkml.kernel.org/r/<1409758148-20104-1-git-send-email-tomeu.vizoso@collabora.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
- Revert of a recent hibernation core commit that introduced
a NULL pointer dereference during resume for at least one user
(Rafael J Wysocki).
- Fix for the ACPI LPSS (Low-Power Subsystem) driver to disable
asynchronous PM callback execution for LPSS devices during system
suspend/resume (introduced in 3.16) which turns out to break
ordering expectations on some systems. From Fu Zhonghui.
- cpufreq core fix related to the handling of sysfs nodes during
system suspend/resume that has been broken for intel_pstate
since 3.15 from Lan Tianyu.
- Restore the generation of "online" uevents for ACPI container
devices that was removed in 3.14, but some user space utilities
turn out to need them (Rafael J Wysocki).
- The cpufreq core fails to release a lock in an error code path
after changes made in 3.14. Fix from Prarit Bhargava.
- ACPICA and ACPI/GPIO fixes to make the handling of ACPI GPIO
operation regions (which means AML using GPIOs) work correctly
in all cases from Bob Moore and Srinivas Pandruvada.
- Fix for a wrong sign of the ACPI core's create_modalias() return
value in case of an error from Mika Westerberg.
- ACPI backlight blacklist entry for ThinkPad X201s from Aaron Lu.
/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABCAAGBQJUJJGgAAoJEILEb/54YlRxt3kP/19OjVjGK/lFKJk4LCmQ77k5
6DDF7/clNJmYBkKBXGdyqqRVdDUXjRuHS1Yd78zWMmwdLtdOcyI+wBjG1w0mMU7o
vAYvXkIks9fCeKBRHSlqdtQROFf3+bxothKD8JGTONA5z4Fih40fqsnuSW8G7uJs
iTEQQK7L2uPJ+w1OnltwN6eNgzN5KqfxgxI+L6DhEMRjWXRHuhfRZorVIjvz+ALV
Fjm8shhjnhQKzS2zuv5PZ5gGM7zZBH7hy7kd4aDYsbppOLAB2pMOwVs0sgC1Xcbv
teyWkyzmhix2Z1bX9wwia5FfMgbnY2leejJN7mukKzHz8CQ1vxS98Sji2uviIAej
Ctp6GKjuemGvjryjbkstD6r3KYS8CuWAL++YwlamqSa0eWBuM+aD9YqGj4i6ntbU
8BFT5KXauOIsA5U51zC8wNUDHoTgBcvoN99zNIM1jIF81M7wuQrXUzJLXBStuSlR
/bDpExwxHt7I6MeUfRTjg37ApVNRAiStw32+DfsKAj4HLsqTkGs1879Paxf30T0f
Z2SlYr5Jeusu5u9DNhk7MG21A+m46R0jjLd1OKBbf2mrtfQfdKCo6szGR7vjEMZC
aGIlwtIA4iS4MN3UAyqOW3SxIPT2SxqPXzG/z27hRN5MUsGNWiClzcUsaaHoHmpp
GlbY/BvDYfur4NBeCSli
=SzQq
-----END PGP SIGNATURE-----
Merge tag 'pm+acpi-3.17-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI and power management fixes from Rafael Wysocki:
"These are regression fixes (ACPI hotplug, cpufreq, hibernation, ACPI
LPSS driver), fixes for stuff that never worked correctly (ACPI GPIO
support in some cases and a wrong sign of an error code in the ACPI
core in one place), and one blacklist item for ACPI backlight
handling.
Specifics:
- Revert of a recent hibernation core commit that introduced a NULL
pointer dereference during resume for at least one user (Rafael J
Wysocki).
- Fix for the ACPI LPSS (Low-Power Subsystem) driver to disable
asynchronous PM callback execution for LPSS devices during system
suspend/resume (introduced in 3.16) which turns out to break
ordering expectations on some systems. From Fu Zhonghui.
- cpufreq core fix related to the handling of sysfs nodes during
system suspend/resume that has been broken for intel_pstate since
3.15 from Lan Tianyu.
- Restore the generation of "online" uevents for ACPI container
devices that was removed in 3.14, but some user space utilities
turn out to need them (Rafael J Wysocki).
- The cpufreq core fails to release a lock in an error code path
after changes made in 3.14. Fix from Prarit Bhargava.
- ACPICA and ACPI/GPIO fixes to make the handling of ACPI GPIO
operation regions (which means AML using GPIOs) work correctly in
all cases from Bob Moore and Srinivas Pandruvada.
- Fix for a wrong sign of the ACPI core's create_modalias() return
value in case of an error from Mika Westerberg.
- ACPI backlight blacklist entry for ThinkPad X201s from Aaron Lu"
* tag 'pm+acpi-3.17-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
Revert "PM / Hibernate: Iterate over set bits instead of PFNs in swsusp_free()"
gpio / ACPI: Use pin index and bit length
ACPICA: Update to GPIO region handler interface.
ACPI / platform / LPSS: disable async suspend/resume of LPSS devices
cpufreq: release policy->rwsem on error
cpufreq: fix cpufreq suspend/resume for intel_pstate
ACPI / scan: Correct error return value of create_modalias()
ACPI / video: disable native backlight for ThinkPad X201s
ACPI / hotplug: Generate online uevents for ACPI containers
- introduction of the new SAMA5D4 SoC and associated Evaluation Kit
- low level soc detection and early printk code
- taking advantage of this, documentation of all AT91 SoC DT strings
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAABAgAGBQJUIB6OAAoJEAf03oE53VmQL+IIALNg2XPS49u2Y6VMjL3srFLt
7CUdNoGB7GJKoGrIXPSyAhJLkRlWREgRsEk/RSYqfBpyBZV4PIx9R6dIz1L+VxGU
9neXLkZGrYNzN8qJPz82+ARuCXdCF13N8ClVfXkNDhwbDnlbZgTkh4hNV118mKLt
+PF0d3w354ujieUD7D0pOcdRlny487qMNjtc/0U4P+H2sp2EtL0PpFHicn79InPT
V36PpFtUMEgbw2wQPNtlFkjQWstyZ7WJJGUbIX/2P3PASCwKsgrbmkvDvmfp5tUT
FdclJwJnxgcpni2fDvbz8Vq04i3hixl2Olm8tAvIXOI/hdVcurvZSfweJ5BrfDk=
=fMfO
-----END PGP SIGNATURE-----
Merge tag 'at91-soc2' of git://github.com/at91linux/linux-at91 into next/soc
Pull "Second SoC batch for 3.18" from Nicolas Ferre:
- introduction of the new SAMA5D4 SoC and associated Evaluation Kit
- low level soc detection and early printk code
- taking advantage of this, documentation of all AT91 SoC DT strings
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
* tag 'at91-soc2' of git://github.com/at91linux/linux-at91:
ARM: at91: document Atmel SMART compatibles
ARM: at91: add sama5d4 support to sama5_defconfig
ARM: at91: dt: add device tree file for SAMA5D4ek board
ARM: at91: dt: add device tree file for SAMA5D4 SoC
ARM: at91: SAMA5D4 SoC detection code and low level routines
ARM: at91: introduce basic SAMA5D4 support
clk: at91: add a driver for the h32mx clock
- Remove unused pieces of the legacy DMA API as we're moving to
dmaengine API
- Search and replace to standardize on pr_warn instead of pr_warning
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJUGzmvAAoJEBvUPslcq6Vz53kQAOAS6Rxp03mmjflegqkVzech
JUPBfGQHVwcpbYQU53+ZCt2Bfg0iaD6xL2BtBfS8tsaePDwqT6kVFrDBqWuIiT6S
Taq2NUzqAhdgva74a6VAh0VSpPK4ui3cdXRoXvMfZRvOtR8bbfAprAWYyWipy2RM
4y07a9dcd1SalcWDJttfXxBV7ImqXPf1e6dRtxYRBBshoNJ46/nk8nS9HblaoJbJ
L3FdmOw7x5jG1nSO4dmhsGzg0PmfjKJwe+rGYPVLuEPil6Sc0VDJxGF8ZyAyK+/K
r8ZvIdbWLiJ6ga/ehMNaZaz6sOsSPRAWWSTOOGUlJvBUiOgHH8P+/Y/3fCkcjTlT
Rg15sij0aBVQJNGNEif9xd19f1tnlthSnjIt593YnqElCN50lnNDBt+bVICTlszd
sXbPZtO8vZ0PHEDshBpWvjyPKyN1CrRTVHtGJXZr/zNWoK2Y1NvsdOYR36AlQugW
WhA5hklyJnRpdbiU84fBon9pbowAOIMcLctBqpK5RyqyC+vVgopcaoMWl9F1XW/r
cAcGVm/zAWfWm01XeuJu1R6DOdLxUvi0Sn7UrXcsPwEYR2pp0NdQQUmNEX3Ko9cW
rIO7emEqQvUdY/K+wa5HzhVMHk5VuBIUb8nT30KjOCEGOB7QhEb/6ly6D0pxLFJ0
RtC70hvqxGWawiNpGadr
=ZNTi
-----END PGP SIGNATURE-----
Merge tag 'cleanup-for-v3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/cleanup
Pull "Clean-up for omaps for v3.18 merge window" from Tony Lindgren:
- Remove unused pieces of the legacy DMA API as we're moving to
dmaengine API
- Search and replace to standardize on pr_warn instead of pr_warning
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
* tag 'cleanup-for-v3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
arm: mach-omap2: Convert pr_warning to pr_warn
ARM: OMAP: Remove unused pieces of legacy DMA API
Pull i2c fixes from Wolfram Sang:
"This is probably not the kind of pull request you want to see that
late in the cycle. Yet, the ACPI refactorization was problematic
again and caused another two issues which need fixing. My holidays
with limited internet (plus travelling) and the developer's illness
didn't help either :(
The details:
- ACPI code was refactored out into a seperate file and as a
side-effect, the i2c-core module got renamed. Jean Delvare
rightfully complained about the rename being problematic for
distributions. So, Mika and I thought the least problematic way to
deal with it is to move all the code back into the main i2c core
source file. This is mainly a huge code move with some #ifdeffery
applied. No functional code changes. Our personal tests and the
testbots did not find problems. (I was thinking about reverting,
too, yet that would also have ~800 lines changed)
- The new ACPI code also had a NULL pointer exception, thanks to
Peter for finding and fixing it.
- Mikko fixed a locking problem by decoupling clock_prepare and
clock_enable.
- Addy learnt that the datasheet was wrong and reimplemented the
frequency setup according to the new algorithm.
- Fan fixed an off-by-one error when copying data
- Janusz fixed a copy'n'paste bug which gave a wrong error message
- Sergei made sure that "don't touch" bits are not accessed"
* 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
i2c: acpi: Fix NULL Pointer dereference
i2c: move acpi code back into the core
i2c: rk3x: fix divisor calculation for SCL frequency
i2c: mxs: fix error message in pio transfer
i2c: ismt: use correct length when copy buffer
i2c: rcar: fix RCAR_IRQ_ACK_{RECV|SEND}
i2c: tegra: Move clk_prepare/clk_set_rate to probe
move it to drivers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJUGze9AAoJEBvUPslcq6VzL4oP/3WxH63RYT2eAyYQ8EGEpPiu
puAfHh30Rrc+TH9ir51DbdXbcGnimOsJSHP89oEM309NKsMhezVx7htDAMKGguNt
wH9uU9LSJtoAHiO06wQOQJCho2UCYd6Fywveauhauxw7k9EQ6uHZlN3q/knLH6r2
2eV6E7aHeqwOWFlajOQywICeu7vlmYmEJCdrbcl+GAWzfzH+yiBHfJwzns1RIvmv
A4qBHvbejL2053Iz4BpO+6iGBLfvzCjoNZn37i/Etc32MTf4cVLRXeoqQBTfthxS
27R5CeT+EHTEU9q77uRF3R1t2PzoUZPx04zPEntYsiBLTRtlolbC6WrMAmPNKYS+
ePwkbVNvhapXzKD5SlcaC+8aY29rToF4l7pCh7ARWG2IYMlZNWRgkeQPWS76LF2O
53g/cy+FUaW2WSWjwL/ktnRdv50ShzUngcdaOrztK9mnF8MihlmbZwoTk5JLFQP6
Ick7vc2SVVMP55d7tMhPWH7o07Xc0KvUb3goSvsA4z7KMopaqFAw5s6nZx2QwA6o
LLJNbShIRPrsbi21dohkE/WUUAHFjFsWcckfzK9XKOMM9RRY6usAFVvp3XwM0326
xRcd8vvAb5DP2nbBYxSqLYygCQKG80KlpF9Uvuk3NCK5aPo3gEcJs8/qzv5ZwFjq
DIWYy/AVRYGQhY/8GJUP
=cYAz
-----END PGP SIGNATURE-----
Merge tag 'intc-part2-for-v3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/drivers
Merge "part 2 of omap intc changes" from Tony Lindgren:
Second part of omap intc interrupt controller changes to
move it to drivers.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
* tag 'intc-part2-for-v3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
irqchip: omap-intc: remove unnecessary comments
irqchip: omap-intc: correct maximum number or MIR registers
irqchip: omap-intc: enable TURBO idle mode
irqchip: omap-intc: enable IP protection
irqchip: omap-intc: remove unnecesary of_address_to_resource() call
irqchip: omap-intc: comment style cleanup
irqchip: omap-intc: minor improvement to omap_irq_pending()
arm: omap: irq: move irq.c to drivers/irqchip/
irqchip: add irq-omap-intc.h header
arm: omap2: n8x0: move i2c devices to DT
This patch add some clock binding id for different modules
that under development and going to send upstream.
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
The patch add the rest of the indices of the additional reset
registers from the updated TRM.
Signed-off-by: Mark yao <mark.yao@rock-chips.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
This patch supports to run one single flush machinery for
each blk-mq dispatch queue, so that:
- current init_request and exit_request callbacks can
cover flush request too, then the buggy copying way of
initializing flush request's pdu can be fixed
- flushing performance gets improved in case of multi hw-queue
In fio sync write test over virtio-blk(4 hw queues, ioengine=sync,
iodepth=64, numjobs=4, bs=4K), it is observed that througput gets
increased a lot over my test environment:
- throughput: +70% in case of virtio-blk over null_blk
- throughput: +30% in case of virtio-blk over SSD image
The multi virtqueue feature isn't merged to QEMU yet, and patches for
the feature can be found in below tree:
git://kernel.ubuntu.com/ming/qemu.git v2.1.0-mq.4
And simply passing 'num_queues=4 vectors=5' should be enough to
enable multi queue(quad queue) feature for QEMU virtio-blk.
Suggested-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
This patch introduces 'struct blk_flush_queue' and puts all
flush machinery related fields into this structure, so that
- flush implementation details aren't exposed to driver
- it is easy to convert to per dispatch-queue flush machinery
This patch is basically a mechanical replacement.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
- Add new driver for Rockchip IO voltage domains
- update MAINTAINERS to reflect maintenance of drivers/power/avs/*
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAABAgAGBQJUJEnpAAoJEFk3GJrT+8Zl0ZEP/A9WVCZ1B4dpA7mHkHR/1RwY
PdQpW1R9e4TJMsTk/x4AcWTRYmMQX5vhSedCI4v2tqC9SnGTEqMe9Zod43uQ2rdR
ld4D5dzPnyZvo8XHfNBD0wzCUpFBZVFA7xYI77OLkt6wW9Jf/87L75v1+07Q1PmV
LJyVkE8Ngwgw+bIZ8mDE4XtmChK2L4oTwosctsXi+MMyykcaEEgfhMQVFz7ove9r
FsumpeIT4N7MjTYNAH0QzrGqUwPSZAJP4JXsi6yLJEg1kxTwR7m50HNMbmQr6R8c
cf9rr0ee9FOo17hMmyOSJ3Joc+buVRUnFpP/aRMNeKBiYsd9tTQxUdDLTqQ/3Lv5
O+ebBvngPD9MG0UCd4OVgBPK+URfrt/C9vDgzAu/thKqc/A4aJa0n8h0tNJPiiWk
1Lr7W6IlpgUn2jiMo7qUe+BN6ErdWSRQfkRUi6yNxTgAPF3qoPwVUONZfVhiHCSG
+QLITDTKafCZ5sqcf2VCjhZbYZHIP4HGJYzqqfXhLBzUCJLWdci0ngdD4Uq86xXJ
1YPERYbpBDo9MSnOl2nm0QBnu9fZETqViRcVik7CT1tmAgC5C2Qj8vlFqxutJESS
aKz4gFF9Ge0Mth//DReBBpsVVFaOG2RbKKjDsUNQRcIi654cp2IfWdBzcL8th43e
AgR7YaKSqEBX+1p0fjp1
=owv3
-----END PGP SIGNATURE-----
Merge tag 'avs-for-3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux into pm-avs
Pull AVS changes for v3.18 from Kevin Hilman:
- Add new driver for Rockchip IO voltage domains
- update MAINTAINERS to reflect maintenance of drivers/power/avs/*
* tag 'avs-for-3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux:
MAINTAINERS: update entry for drivers/power/avs
PM / AVS: rockchip-io: add driver handling Rockchip io domains
There are no active clients of the legacy API and we now also have a
better way to handle genpd DT support. So let's remove the legacy API.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
While a PM domain can enable PM runtime management of its devices' module
clocks by setting
genpd->dev_ops.stop = pm_clk_suspend;
genpd->dev_ops.start = pm_clk_resume;
this also requires registering the clocks with the pm_clk subsystem.
In the legacy case, this is handled by the platform code, after
attaching the device to its PM domain.
When the devices are instantiated from DT, devices are attached to their
PM domains by generic code, leaving no method for the platform-specific
PM domain code to register their clocks.
Add two callbacks, allowing a PM domain to perform platform-specific
tasks when a device is attached to or detached from a PM domain.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
the primary change here gets its address information from DT rather than
iomap.h. This removes one more user of iomap.h, and will help allow the
code to move to a location that can be shared between arch/arm and
arch/arm64.
An unused header file was also removed.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJUGxmUAAoJEMzrak5tbycxh8gP/AraovjYUwxHfFDkRgRn/Ukb
t8PRy/mieHwypO86Rseu4x5P+OWO3MFMYLfqFpJZAYugwq7hgB6dCCcFuezqDP0k
HVBBQN1wu8XDpjJd260EQmzjx8mqW+omMmeWZcZSMChnqPsntVpCmbWf4dlGoAcY
qgGfiNVZ7QWsS7ROjGD9JI0SmkYdfoXWtPX6r0z93sn3SM4lrJeIs/RGYKfEaQb0
JXvJChj/K59Z8ejUjM5pI2CkC0Y23ftl5BH6sJk9yiFRA09UDahdUJiO1wcM0TgK
oukVFOapGyGscFrN/bZq79RPde1P0GnbllcT0aOV5PWr4R6HGEArxrsVm7UoC+L3
3J3OwpG5EokCOh7Agt81ExTP6uaohWZKC4WS8l247qbDXhdxIXscmTk9Y3Fey//x
UM044kprNgUaRiQ/fFFx8W+6V3dHthCD6TslNCN8E0s1yjqgw8lLyuW0YqaO+CJe
q3+d8Twf2d8GUwOPmh2hSYh1kGt47YNQvrQ+bkdb9FFOtkrrYZykPSDI71H/IpIR
wrmHiueQV1zu6f4KRCgYgg5SQj/SI9rncoI1innarw+JszSK5Pn8fKp+z9mTRDML
oaSCSKc9UNMVAMfex1p1GYgxuVbCQex6VHFTRXke99CJA7nedRzhB6v8wk7ICdXP
pb3AeTLB4R1rr7Ull1mt
=BeSe
-----END PGP SIGNATURE-----
Merge tag 'tegra-for-3.18-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra into next/soc
Pull "ARM: tegra: core SoC code changes for 3.18" from Stephen Warren:
the primary change here gets its address information from DT rather than
iomap.h. This removes one more user of iomap.h, and will help allow the
code to move to a location that can be shared between arch/arm and
arch/arm64.
An unused header file was also removed.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
* tag 'tegra-for-3.18-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra:
ARM: tegra: remove unused tegra_emc.h
ARM: tegra: Initialize flow controller from DT
of: Add NVIDIA Tegra flow controller bindings
In PCIe r1.0, sec 5.10.2, bit 0 of the Uncorrectable Error Status, Mask,
and Severity Registers was for "Training Error." In PCIe r1.1, sec 7.10.2,
bit 0 was redefined to be "Undefined."
Rename PCI_ERR_UNC_TRAIN to PCI_ERR_UNC_UND to reflect this change.
No functional change.
[bhelgaas: changelog]
Signed-off-by: Chen, Gong <gong.chen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Add all AER error bits defined in PCIe r3.0.
[bhelgaas: changelog]
Signed-off-by: Chen, Gong <gong.chen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Replace bare numbers like "BIT(0)" with the existing #defines, e.g.,
PCI_ERR_COR_RCVR, to improve maintainability. This way grep will find more
uses of the #defines.
No functional change.
[bhelgaas: changelog]
Signed-off-by: Chen, Gong <gong.chen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
With this patch, USB activity can be signaled by blinking a LED. There
are two triggers, one for activity on USB host and one for USB gadget.
Both triggers should work with all host/device controllers. Tested only
with musb.
Performace: I measured performance overheads on ARM Cortex-A8 (TI
AM335x) running on 600 MHz.
Duration of usb_led_activity():
- with no LED attached to the trigger: 2 ± 1 µs
- with one GPIO LED attached to the trigger: 2 ± 1 µs or 8 ± 2 µs (two peaks in histogram)
Duration of functions calling usb_led_activity() (with this patch
applied and no LED attached to the trigger):
- __usb_hcd_giveback_urb(): 10 - 25 µs
- usb_gadget_giveback_request(): 2 - 6 µs
Signed-off-by: Michal Sojka <sojka@merica.cz>
Acked-by: Felipe Balbi <balbi@ti.com>
Tested-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
All USB peripheral controller drivers call completion routines directly.
This patch adds usb_gadget_giveback_request() which will be used instead
of direct invocation in the next patch. The goal here is to have a place
where common functionality can be added.
Signed-off-by: Michal Sojka <sojka@merica.cz>
Acked-by: Felipe Balbi <balbi@ti.com>
Tested-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 5d98e61d33 ("I2C/ACPI: Add i2c ACPI operation region support")
renamed the i2c-core module. This may cause regressions for
distributions, so put the ACPI code back into the core.
Reported-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Tested-by: Lan Tianyu <tianyu.lan@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
This function will replace the current iommu_domain_has_cap
function and clean up the interface while at it.
Signed-off-by: Joerg Roedel <jroedel@suse.de>
These new-lines add empty lines to trace output
Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This will allow NFS to wait for PG_private to be cleared and,
particularly, to send a wake-up when it is.
Signed-off-by: NeilBrown <neilb@suse.de>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
In commit c1221321b7
sched: Allow wait_on_bit_action() functions to support a timeout
I suggested that a "wait_on_bit_timeout()" interface would not meet my
need. This isn't true - I was just over-engineering.
Including a 'private' field in wait_bit_key instead of a focused
"timeout" field was just premature generalization. If some other
use is ever found, it can be generalized or added later.
So this patch renames "private" to "timeout" with a meaning "stop
waiting when "jiffies" reaches or passes "timeout",
and adds two of the many possible wait..bit..timeout() interfaces:
wait_on_page_bit_killable_timeout(), which is the one I want to use,
and out_of_line_wait_on_bit_timeout() which is a reasonably general
example. Others can be added as needed.
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: NeilBrown <neilb@suse.de>
Acked-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
