TI LP8788 PMU supports regulators, battery charger, RTC, ADC, backlight
dri= ver and current sinks. This patch enables LP8788 backlight module.
(Brightness mode)
The brightness is controlled by PWM input or I2C register.
All modes are supported in the driver.
(Platform data)
Configurable data can be defined in the platform side.
name : backlight driver name. (default: "lcd-backlight")
initial_brightness : initial value of backlight brightness
bl_mode : brightness control by PWM or lp8788 register
dim_mode : dimming mode selection
full_scale : full scale current setting
rise_time : brightness ramp up step time
fall_time : brightness ramp down step time
pwm_pol : PWM polarity setting when bl_mode is PWM based
period_ns : platform specific PWM period value. unit is nano.
The default values are set in case no platform data is defined.
[akpm@linux-foundation.org: checkpatch fixes]
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: Thierry Reding <thierry.reding@avionic-design.de>
Cc: "devendra.aaru" <devendra.aaru@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This patch makes power_on() call optional. The voltage source can be
provided to some boards using ams369fg06 panel, thus in this case, power
on/off sequence is not necessary.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This patch addresses a v3.5+ regression in iscsi-target where TX thread
process context -> handle_response_queue() execution is allowed to run
unbounded while servicing constant outgoing flow of ISTATE_SEND_DATAIN
response state.
This ends up preventing memory release of StatSN acknowledged commands
in a timely manner when under heavy large block streaming DATAIN
workloads.
The regression bug was initially introduced with:
commit 6f3c0e69a9
Author: Andy Grover <agrover@redhat.com>
Date: Tue Apr 3 15:51:09 2012 -0700
target/iscsi: Refactor target_tx_thread immediate+response queue loops
Go ahead and follow original iscsi_target_tx_thread() logic and check
to break for immediate queue processing after each DataIN Sequence and/or
Response PDU has been sent.
Reported-by: Benjamin ESTRABAUD <be@mpstor.com>
Cc: Andy Grover <agrover@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
If something has failed while the array was read-auto,
then when we switch to 'active' we need to update the metadata.
This will happen anyway but it is good to expedite it, and
also to ensure any failed device has been released by the
underlying device before we try to action the ioctl which
caused us to switch to 'active' mode.
Reported-by: Joe Lawrence <Joe.Lawrence@stratus.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Pull x86/EFI changes from Peter Anvin:
- Improve the initrd handling in the EFI boot stub by allowing forward
slashes in the pathname - from Chun-Yi Lee.
- Cleanup code duplication in the EFI mixed kernel/firmware code - from
Satoru Takeuchi.
- efivarfs bug fixes for more strict filename validation, with lots of
input from Al Viro.
* 'x86-efi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86, efi: remove duplicate code in setup_arch() by using, efi_is_native()
efivarfs: guid part of filenames are case-insensitive
efivarfs: Validate filenames much more aggressively
efivarfs: Use sizeof() instead of magic number
x86, efi: Allow slash in file path of initrd
Pull more x86 fixes from Peter Anvin:
"Additional x86 fixes. Three of these patches are pure documentation,
two are pretty trivial; the remaining one fixes boot problems on some
non-BIOS machines."
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86: Make sure we can boot in the case the BDA contains pure garbage
x86, efi: Mark disable_runtime as __initdata
x86, doc: Fix incorrect comment about 64-bit code segment descriptors
doc, kernel-parameters: Document 'console=hvc<n>'
doc, xen: Mention 'earlyprintk=xen' in the documentation.
ACPI: Overriding ACPI tables via initrd only works with an initrd and on X86
This doesn't seem to actually help and we have an alternate
multi-threading approach waiting in the wings, so just get
rid of this config option and associated code.
As a bonus, we remove one use of CONFIG_EXPERIMENTAL
Cc: Dan Williams <djbw@fb.com>
Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: NeilBrown <neilb@suse.de>
If CONFIG_MAC80211_MESH is not set, cfg80211 will now allow advertising
interface combinations with NL80211_IFTYPE_MESH_POINT present.
Add appropriate ifdefs to avoid running into errors.
Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
On many different chips, important aspects of the MAC state are not
fully cleared by a warm reset. This can show up as tx/rx hangs, those
annoying "DMA failed to stop in 10 ms..." messages or other quirks.
On AR933x, the chip can occasionally get stuck in a way that only a
driver unload/reload or a reboot would bring it back to life.
With this patch, a full reset is issued when bringing the chip out of
FULL-SLEEP state (after idle), or if either Rx or Tx was not shut down
properly. This makes the DMA related error messages disappear completely
in my tests on AR933x, and the chip does not get stuck anymore.
Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The ath9k commit 2ef167557c
(ath9k: fix signal strength reporting issues) fixed an issue where the
reported per-frame signal strength reported to mac80211 was being
overwritten with an internal average. The same issue is also present
in ath9k_htc.
In addition to preventing the driver from overwriting the value, this
commit also ensures that the internal average (which is used for ANI)
only tracks beacons of the AP that we're connected to.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@vger.kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
RSSI is being stored internally as s8 in several places. The indication
of an unset RSSI value, ATH_RSSI_DUMMY_MARKER, was supposed to have been
set to 127, but ended up being set to 0x127 because of a code cleanup
mistake. This could lead to invalid signal strength values in a few
places.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@vger.kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Use the infrastructure for delivering VMBUS interrupts using a
special vector. With this patch, we can now properly handle
the VMBUS interrupts that can be delivered on any CPU. Also,
turn on interrupt load balancing as well.
This patch requires the infrastructure that was implemented in the patch:
X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This USB ethernet adapter was purchased in anodyne packaging
from the computer store adjacent to linux.conf.au 2013 in
Canberra (Australia). A web search shows other recent
purchasers in Lancaster (UK) and Seattle (USA). Just like an
emergent virus, our age of e-commerce and airmail allows
underdocumented hardware to spread around the world instantly
using the vector of ridiculously low prices.
Paige Thompson, infected via eBay, discovered that the HG20F9
is a copy of the Asix 88772B; many viruses copy the RNA of
other viruses. See Paige's work at
<https://github.com/paigeadele/HG20F9>.
This patch uses her discovery to update the restructured Asix
driver in the current kernel.
Just as some viruses inhabit seemingly-healthy cells, the
HG20F9 uses the Vendor ID 0x066b assigned to Linksys Inc.
For the present there is no clash of Product ID 0x20f9.
Signed-off-by: Glen Turner <gdt@gdt.id.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Tag all Huawei NCM devices as WWAN modems, as we don't know of any which
are not. This is necessary for userspace clients to know that the device
requires further setup on e.g. an AT-capable serial ports before
connectivity is available.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
While PROC_CN_MCAST_LISTEN/IGNORE is entirely advisory, it was possible
for an unprivileged user to turn off notifications for all listeners by
sending PROC_CN_MCAST_IGNORE. Instead, require the same privileges as
required for a multicast bind.
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Evgeniy Polyakov <zbr@ioremap.net>
Cc: Matt Helsley <matthltc@us.ibm.com>
Cc: stable@vger.kernel.org
Acked-by: Evgeniy Polyakov <zbr@ioremap.net>
Acked-by: Matt Helsley <matthltc@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When taking an address of an extern array, gcc quite naturally should be
able to say "an address of an object can never be NULL" and just
optimize away the test entirely.
However, the new alternate sysrq reset code (commit 154b7a489a:
"Input: sysrq - allow specifying alternate reset sequence") did exactly
that, and declared platform_sysrq_reset_seq[] as a weak array, and
expecting that testing the address of the array would show whether it
actually got linked against something or not.
And that doesn't work with all gcc versions. Clearly it works with
*some* versions of gcc, and maybe it's even supposed to work, but it
really is a very fragile concept.
So instead of testing the address of the weak variable, just create a
weak instance of that array that is empty. If some platform then has a
real platform_sysrq_reset_seq[] that overrides our weak one, the linker
will switch to that one, and it all works without any run-time
conditionals at all.
Reported-by: Dave Airlie <airlied@gmail.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Selecting BACKLIGHT_CLASS_DEVICE doesn't guarantee that any of its
dependencies are enabled, and these are complicated. Depending isn't ideal
for configuration UI purposes, but is probably more appropriate here.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
I've got a report of build failure on ideapad-laptop, which shows
drivers/built-in.o: In function `ideapad_acpi_notify':
ideapad-laptop.c:(.text+0x63876a): undefined reference to `backlight_force_update'
drivers/built-in.o: In function `ideapad_acpi_remove':
ideapad-laptop.c:(.devexit.text+0x64a7): undefined reference to `backlight_device_unregister'
drivers/built-in.o: In function `ideapad_acpi_add':
ideapad-laptop.c:(.devinit.text+0x45e28): undefined reference to `backlight_device_register'
To select backlight subsystem can prevent this error from happening.
Also update comment for this driver.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Ike Panhc <ike.pan@canonical.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Add the two other i2c buses (vga and panel) from i915.
Chromebook Pixel has input and light sensor devices on these busses.
Signed-off-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
The Chromebook Pixel uses an isl29023 ambient light sensor on the PANEL
GMBus.
Signed-off-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Instantiate the atmel mxt1664s touchscreen on this system.
The touchscreen may appear at two possible addresses:
0x4a in operational mode.
0x26 in bootloader mode.
Signed-off-by: Yufeng Shen <miletus@chromium.org>
Signed-off-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
This will allow support for devices that may appear at more than
one i2c address at boot time. The specific example is the atmel_mxt touch
devices, which may appear at a different address if it comes up
in bootloader mode.
Signed-off-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Instantiate the atmel mxt224s trackpad on this system.
The trackpad may appear at two possible addresses:
0x4b in operational mode.
0x25 in bootloader mode.
Signed-off-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
The driver will not quite work if someone unbinds the platform device
from the platform driver via sysfs (moreover it will bomb is the driver
built into the kernel as hp_wmi_bios_remove is marked as __exit and will
not be present in the kernel).
To fix it let's use platform_driver_probe() instead of
platform_driver_register(), which disables binding/unbinding via sysfs.
This also allows us to mark hp_wmi_bios_setup as __init and discard it
once module is initialized.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
We need to decrement "i" first because the current "i" was not allocated
succesfully. Also we should go free the way down to zero to avoid a
leak.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Several models of HP laptops using the same DSDT have hotkey buttons
that do not work until the EC is configured to enable them.
Signed-off-by: Kyle Evans <kvans32@gmail.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Fix the following build warning
CC [M] drivers/platform/x86/asus-wmi.o
drivers/platform/x86/asus-wmi.c:1356:13: warning: ‘do_nothing’ defined but not used [-Wunused-function]
Signed-off-by: Shuah Khan <shuah.khan@hp.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Fengguang Wu run kernel build test to platform-drivers-x86/linux-next git tree
on x86_64 architecture and found a warning that was introduced by
727651bf738b6b917335025d09323d0962eda114 commit:
drivers/platform/x86/acer-wmi.c: In function âWMID_set_capabilitiesâ:
drivers/platform/x86/acer-wmi.c:1211: warning: âdevicesâ may be used
uninitialized in this function
This patch fixes the above warning message.
Cc: Carlos Corbacho <carlos@strangeworlds.co.uk>
Cc: Matthew Garrett <mjg@redhat.com>
Cc: Dmitry Torokhov <dtor@mail.ru>
Cc: Corentin Chary <corentincj@iksaif.net>
Cc: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Lee, Chun-Yi <jlee@suse.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Add support for the HP Pavilion 14 Chromebook's trackpad, which is a reuse
of the Samsung Series 5 550 trackpad.
Signed-off-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
The Samsung Series 5 Chromebook is equipped with a Taos tsl2583
light sensor. Instatiate it here.
Signed-off-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Two legacy Chromebooks, the Cr-48, and the Acer AC700,
are equipped with a Taos tsl2563 light sensor.
This will instantiate the sensor on those laptops.
Signed-off-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Add support for the Acer C7's trackpad, which is a reuse
of the Samsung Series 5 550 trackpad.
Signed-off-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
The Cypress trackpad on smbus is used on other systems
as well. Lets make the name more generic.
Signed-off-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Z series and other recent models have 0x14? for lid and keyboard
backlight.
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
