| Age | Commit message (Collapse) | Author |
|---|
|
People have been dropping things in here without updating the index, do
it for them.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
|
The VSX alignment handler needs to write out the existing VSX
state to memory before operating on it (flush_vsx_to_thread()).
If we take a VSX alignment exception in the kernel bad things
will happen. It looks like we could write the kernel state out
to the user process, or we could handle the kernel exception
using data from the user process (depending if MSR_VSX is set
or not).
Worse still, if the code to read or write the VSX state causes an
alignment exception, we will recurse forever. I ended up with
hundreds of megabytes of kernel stack to look through as a result.
Floating point and SPE code have similar issues but already include
a user check. Add the same check to emulate_vsx().
With this patch any unaligned VSX loads and stores in the kernel
will show up as a clear oops rather than silent corruption of
kernel or userspace VSX state, or worse, corruption of a potentially
unlimited amount of kernel memory.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
|
As a part of pseries_idle backend driver cleanup to make
the code common to both pseries and powernv platforms, it
is necessary to move the backend-driver code to drivers/cpuidle.
As a pre-requisite for that, it is essential to move plpar_wrapper.h
to include/asm.
Signed-off-by: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
|
As a part of pseries_idle cleanup to make the backend driver
code common to both pseries and powernv.
Remove non-essential smt_snooze_delay declaration in pseries.h
header file and pseries.h file inclusion in
pseries/processor_idle.c
Signed-off-by: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
|
The stmw instruction was incorrectly decoded as an update form instruction
and thus the RA register was being clobbered.
Also, the utility routine to write memory to unaligned addresses breaks the
operation into smaller aligned accesses but was incorrectly incrementing
the address by only one; it needs to increment the address by the size of
the smaller aligned chunk.
Signed-off-by: Tom Musta <tmusta@us.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
|
Memory I/O resources need to be marked as busy or else we cannot remove
them when doing memory hot remove.
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
|
Latest FSL updates from Scott:
<<
Highlights include changes in compiler flag settings
on e500 family cores, booke64 hibernation support, support for two new
boards, and an erratum workaround.
>>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB bugfix from Greg KH:
"Here is a single bugfix that resolves the "can not build the OHCI
driver with CONFIG_PM disabled" problem that lots of people have been
reporting with 3.11-rc7. Sorry about that one, it missed my build
tests, and it seems, a number of others as well.
Thank goodness for Guenter :)"
* tag 'usb-3.11-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
USB: OHCI: fix build error related to ohci_suspend/resume
|
|
Pull jfs fix from Dave Kleikamp:
"One JFS patch to fix an incompatibility with NFSv4 resulting in the
nfs client reporting a readdir loop"
* tag 'jfs-3.11-rc8' of git://github.com/kleikamp/linux-shaggy:
jfs: fix readdir cookie incompatibility with NFSv4
|
|
Rely on the fact that another flavor of the filesystem is already
mounted and do not rely on state in the user namespace.
Verify that the mounted filesystem is not covered in any significant
way. I would love to verify that the previously mounted filesystem
has no mounts on top but there are at least the directories
/proc/sys/fs/binfmt_misc and /sys/fs/cgroup/ that exist explicitly
for other filesystems to mount on top of.
Refactor the test into a function named fs_fully_visible and call that
function from the mount routines of proc and sysfs. This makes this
test local to the filesystems involved and the results current of when
the mounts take place, removing a weird threading of the user
namespace, the mount namespace and the filesystems themselves.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
|
|
GEM does already a good job in tracking access to gem buffers via handles
and drm_vma access management. However, TTM drivers currently do not
verify this during mmap().
TTM provides the verify_access() callback to test this. So fix all drivers
to actually call into gem+vma to verify access instead of always returning
0.
All drivers assume that user-space can only get access to TTM buffers via
GEM handles. So whenever the verify_access() callback is called from
ttm_bo_mmap(), the buffer must have a valid embedded gem object. This is
true for all TTM+GEM drivers. But that's why this patch doesn't touch pure
TTM drivers (ie, vmwgfx).
v2: Switch to drm_vma_node_verify_access() to correctly return -EACCES if
access was denied.
Cc: Dave Airlie <airlied@redhat.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
We implement automatic vma mmap() access management for all drivers using
gem_mmap. We use the vma manager to add each open-file that creates a
gem-handle to the vma-node of the underlying gem object. Once the handle
is destroyed, we drop the open-file again.
This allows us to use drm_vma_node_is_allowed() on _any_ gem object to see
whether an open-file is granted access. In drm_gem_mmap() we use this to
verify that unprivileged users cannot guess gem offsets and map arbitrary
buffers.
Note that this manages access for _all_ gem users (also TTM+GEM), but the
actual access checks are only done for drm_gem_mmap(). TTM drivers use the
TTM mmap helpers, which need to do that separately.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
The VMA offset manager uses a device-global address-space. Hence, any
user can currently map any offset-node they want. They only need to guess
the right offset. If we wanted per open-file offset spaces, we'd either
need VM_NONLINEAR mappings or multiple "struct address_space" trees. As
both doesn't really scale, we implement access management in the VMA
manager itself.
We use an rb-tree to store open-files for each VMA node. On each mmap
call, GEM, TTM or the drivers must check whether the current user is
allowed to map this file.
We add a separate lock for each node as there is no generic lock available
for the caller to protect the node easily.
As we currently don't know whether an object may be used for mmap(), we
have to do access management for all objects. If it turns out to slow down
handle creation/deletion significantly, we can optimize it in several
ways:
- Most times only a single filp is added per bo so we could use a static
"struct file *main_filp" which is checked/added/removed first before we
fall back to the rbtree+drm_vma_offset_file.
This could be even done lockless with rcu.
- Let user-space pass a hint whether mmap() should be supported on the
bo and avoid access-management if not.
- .. there are probably more ideas once we have benchmarks ..
v2: add drm_vma_node_verify_access() helper
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Don't copy bind mounts of /proc/<pid>/ns/mnt between namespaces.
These files hold references to a mount namespace and copying them
between namespaces could result in a reference counting loop.
The current mnt_ns_loop test prevents loops on the assumption that
mounts don't cross between namespaces. Unfortunately unsharing a
mount namespace and shared substrees can both cause mounts to
propogate between mount namespaces.
Add two flags CL_COPY_UNBINDABLE and CL_COPY_MNT_NS_FILE are added to
control this behavior, and CL_COPY_ALL is redefined as both of them.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
|
|
This patch modifies PLL6552 and PLL6553 clock drivers to use recently
added common Samsung PLL registration method.
Signed-off-by: Tomasz Figa <tomasz.figa@gmail.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
|
|
notification callback
fb_notifier_callback is called on any event fired by
fb_notifier_call_chain. Events may, or may not contain some data
(fb_event.data). In case of FB_EVENT_BLANK fb_event.data contains a
pointer to an integer holdingthe blank state. The Problem is, that in
ledtrig-backlight.c - fb_notifier_callback the pointer to blank state
is dereferenced BEFORE the event-type is checked.
Obviously this leads to problems with other events than FB_EVENT_BLANK,
where fb_event.data is undefined or NULL. It seems, that this problem
existed ever since the driver was added.
Like in drivers/video/backlight/backlight.c line 43 I would suggest to
return immediately on events other than FB_EVENT_BLANK.
Signed-off-by: Manfred Schlaegl <manfred.schlaegl@gmx.at>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
It seems GCC generates a better code in that way, so I changed that statement.
Btw, they have the same semantic, so I'm sending this patch due to performance issues.
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Signed-off-by: Raphael S.Carvalho <raphael.scarv@gmail.com>
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
|
|
into pm-cpufreq
Pull cpufreq fixes for v3.12 from Viresh Kumar.
* 'cpufreq-fixes' of git://git.linaro.org/people/vireshk/linux:
cpufreq: imx6q: Fix clock enable balance
cpufreq: tegra: fix the wrong clock name
|
|
A malformed device tree could lead into a segmentation fault if the reg
value of a led is bigger than the number of leds.
A valid device tree could have only information about the last led of the
chip. Fix the device tree parsing to handle those cases.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
The driver now supports the chips pca9633 and pca9634, therefore we
rename the files to more generic and meaningul names
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
To update an LED a register has to be read, updated and writen. If
another LED whas been updated at the same time, this could lead into
wrong updates.
This patch adds a common mutex to all the leds of the same chip to
protect the ledout register.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
If there is more than one pca963x chips on the system and there are
some LEDs without platform_data names, the driver wont be able to
provide unique naming to them.
This will cause led_class_dev_register to fail, unregistering all the
LEDs of the chip.
This patch adds the i2c address to the name of the unnamed LEDs, making
them unique.
[ 555.346827] ------------[ cut here ]------------
[ 555.346844] WARNING: at /build/linux-voe0Su/linux-3.9.8/fs/sysfs/dir.c:536 sysfs_add_one+0x8b/0x9d()
[ 555.346847] Hardware name: QT5022
[ 555.346850] sysfs: cannot create duplicate filename '/class/leds/pca9633:6'
[ 555.346853] Modules linked in: qt5038_platform(O+) leds_pca9633(O) hid_generic ledtrig_default_on rfcomm bnep bluetooth binfmt_misc nfsd auth_rpcgss nfs_acl nfs lockd dns_resolver fscache sunrpc nls_utf8 nls_cp437 vfat fat loop fuse joydev hid_multitouch usbhid hid acpi_cpufreq mperf kvm_amd kvm evdev pn533 nfc arc4 microcode pcspkr efivars k10temp ath9k ath9k_common ath9k_hw ath fglrx(PO) mac80211 cfg80211 video rfkill processor thermal_sys sp5100_tco button i2c_piix4 ext4 crc16 jbd2 mbcache sg sd_mod crc_t10dif ahci libahci igb i2c_algo_bit i2c_core dca ptp pps_core ehci_pci ohci_hcd ehci_hcd libata usbcore usb_common scsi_mod [last unloaded: leds_pca963x]
[ 555.346940] Pid: 4766, comm: insmod Tainted: P W O 3.9-1-amd64 #1 Debian 3.9.8-1
[ 555.346943] Call Trace:
[ 555.346956] [<ffffffff8103d153>] ? warn_slowpath_common+0x76/0x8c
[ 555.346962] [<ffffffff8103d202>] ? warn_slowpath_fmt+0x47/0x49
[ 555.346968] [<ffffffff8116005d>] ? sysfs_pathname+0x3b/0x41
[ 555.346973] [<ffffffff81160767>] ? sysfs_add_one+0x8b/0x9d
[ 555.346978] [<ffffffff811610a4>] ? sysfs_do_create_link_sd+0xe8/0x174
[ 555.346985] [<ffffffff81279250>] ? device_add+0x243/0x5ab
[ 555.346991] [<ffffffff81060a16>] ? complete_all+0x31/0x40
[ 555.346998] [<ffffffff8104991a>] ? init_timer_key+0xc/0x56
[ 555.347004] [<ffffffff8127964c>] ? device_create_vargs+0x82/0xb6
[ 555.347009] [<ffffffff812796af>] ? device_create+0x2f/0x31
[ 555.347014] [<ffffffff81060add>] ? should_resched+0x5/0x23
[ 555.347021] [<ffffffff812a3a92>] ? led_classdev_register+0x24/0x103
[ 555.347028] [<ffffffffa09d01c0>] ? pca9633_probe+0x173/0x239 [leds_pca9633]
[ 555.347035] [<ffffffff8127b504>] ? __driver_attach+0x73/0x73
[ 555.347049] [<ffffffffa009dfc9>] ? i2c_device_probe+0x63/0x88 [i2c_core]
[ 555.347057] [<ffffffff8127b373>] ? driver_probe_device+0x92/0x1b0
[ 555.347064] [<ffffffff81279c5c>] ? bus_for_each_drv+0x43/0x7d
[ 555.347070] [<ffffffff8127b2af>] ? device_attach+0x68/0x83
[ 555.347078] [<ffffffff8127a990>] ? bus_probe_device+0x25/0x8d
[ 555.347083] [<ffffffff812793f7>] ? device_add+0x3ea/0x5ab
[ 555.347088] [<ffffffff81060a16>] ? complete_all+0x31/0x40
[ 555.347094] [<ffffffff8104991a>] ? init_timer_key+0xc/0x56
[ 555.347104] [<ffffffffa009d3a1>] ? i2c_new_device+0x10d/0x179 [i2c_core]
[ 555.347112] [<ffffffffa008f036>] ? qt5038_init+0x36/0x1000 [qt5038_platform]
[ 555.347119] [<ffffffffa008f000>] ? 0xffffffffa008efff
[ 555.347125] [<ffffffff8100209e>] ? do_one_initcall+0x74/0x128
[ 555.347131] [<ffffffffa008f000>] ? 0xffffffffa008efff
[ 555.347137] [<ffffffff810836f5>] ? load_module+0x1af7/0x1dfc
[ 555.347144] [<ffffffff810801c5>] ? free_notes_attrs+0x3c/0x3c
[ 555.347150] [<ffffffff81083a98>] ? sys_init_module+0x9e/0xab
[ 555.347157] [<ffffffff8138be29>] ? system_call_fastpath+0x16/0x1b
[ 555.347161] ---[ end trace ad00b85794e0de4d ]---
[ 555.347448] leds-pca9633: probe of 0-006b failed with error -17
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
Add support for PCA9634 chip, which belongs to the same family as the
9633 but with support for 8 outputs instead of 4.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
Now, all legacy application interfaces are restored.
Each driver documentation is updated.
Cc: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
This patch reduces the number of programming commands.
(Count of sending commands)
Old code: 32 + program size (32 counts for clearing program memory)
New code: 32
Pattern buffer is initialized to 0 in this function.
Just update new program data and remaining buffers are filled with 0.
So it's needless to clear whole area.
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
git commit db6eaf8388a413a5ee1b4547ce78506b9c6456b0
(leds-lp5523: use generic firmware interface) causes an application conflict.
This interface should be maintained for compatibility.
Restored device attributes are 'engineN_mode', 'engineN_load' and
'engineN_leds'. (N = 1, 2 or 3)
A 'selftest' attribute macro is replaced with LP55xx common macro.
Those are accessed when a LED pattern is run by an application.
Use a mutex in lp5523_update_program_memory()
: This function is called when an user-application writes a 'engineN_load' file
or pattern data is loaded from generic firmware interface.
So, writing program memory should be protected.
If an error occurs on accessing this area, just it returns as -EINVAL quickly.
This error code is exact same as old driver function, lp5523_do_store_load()
because it should be kept for an user-application compatibility.
Even the driver is changed, we can use the application without re-compiling
sources.
Reported-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
LED MUX start and stop address should be updated in the program memory
on LP5523 initialization.
LED pattern doesn't work without additional MUX address configuration.
This handling is done by new function, lp5523_init_program_engine().
Eventually, it's called during device initialization, lp5523_post_init_device().
This is a conflict after git commit 632418bf65503405df3f9a6a1616f5a95f91db85
(leds-lp5523: clean up lp5523_configure()).
So it should be fixed.
Cc: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
lp5523_load_engine()
It is called whenever the operation mode is changed to 'load'.
It is used for simple operation mode change.
It will be used when engine mode and LED selection is updated in later patch.
lp5523_load_engine_and_select_page()
Change the operation mode to 'load' and select program page number.
This is used for programming a LED pattern at a time.
So load_engine() is replaced with new API, load_engine_and_select_page()
in lp5523_firmware_loaded().
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
This patch reduces the number of programming commands.
(Count of sending commands)
Old code: 32 + program size (32 counts for clearing program memory)
New code: 32
Pattern buffer is initialized to 0 in this function.
Just update new program data and remaining buffers are filled with 0.
So it's needless to clear whole area.
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
git commit 9ce7cb170f97f83a78dc948bf7d25690f15e1328
may cause an application confict, engineN_mode and engineN_load.
This interface should be maintained for compatibility.
Restored device attributes are 'engineN_mode' and 'engineN_load'.
A 'selftest' attribute macro is replaced with LP55xx common macro.
Use a mutex in lp5521_update_program_memory()
: This function is called when an user-application writes a 'engineN_load' file
or pattern data is loaded from generic firmware interface.
So, writing program memory should be protected.
If an error occurs on accessing this area, just it returns as -EINVAL quickly.
This error code is exact same as old driver function, lp5521_do_store_load()
because it should be kept for an user-application compatibility.
Even the driver is changed, we can use the application without re-compiling
sources.
'led_pattern' attribute is not included
: engineN_mode and _load were created for custom user-application.
'led_pattern' is an exception. I added this attribute not for custom application
but for simple test. Now it is used only in LP5562 driver, not LP5521.
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
This patch provides common macros for LP5521 and LP5523 device attributes and
functions.
(Device attributes)
LP5521: 'mode', 'load' and 'selftest'
LP5523: 'mode', 'load', 'leds' and 'selftest'
(Permissions)
mode: R/W
load: Write-only
leds: R/W
selftest: Read-only
Couple of lines are duplicate, so use these macros for adding device attributes
in LP5521 and LP5523 drivers.
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
LP55xx family devices have internal three program engines which are used for
loading LED patterns. To maintain legacy device attributes, specific data
structure is used, 'mode' and 'led_mux'. The mode is used for showing/storing
current engine mode such like disabled, load and run. Then led_mux is used for
showing/storing current output LED selection.
This is only for LP5523/55231.
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
__initdata should be placed between the variable name and equal
sign for the variable to be placed in the intended section.
Fix the example.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
__initdata should be placed between the variable name and equal
sign for the variable to be placed in the intended section.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Cc: Dave Hansen <dave@sr71.net>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
__initdata should be placed between the variable name and equal
sign for the variable to be placed in the intended section.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Cc: Márton Németh <nm127@freemail.hu>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
With the DT conversion, the board Kconfig symbols MACH_ are going to be
removed. In order to prepare this removal, this patch replaces alls the
machines dependencies for leds-netxbig by ARCH_KIRKWOOD.
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
With the DT conversion, the board Kconfig symbols MACH_ are going to be
removed. In order to prepare this removal, this patch replaces alls the
machines dependencies for leds-ns2 by ARCH_KIRKWOOD.
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
Fix a warning from "sparse":
drivers/leds/leds-lp3944.c:292:23: warning: mixing different enum types
drivers/leds/leds-lp3944.c:292:23: int enum led_brightness versus
drivers/leds/leds-lp3944.c:292:23: int enum lp3944_status
Keeping track of LP3944_LED_STATUS_OFF and LP3944_LED_STATUS_ON only in
lp3944_led_set_brightness() is OK, as the handling of DIM (blinking)
mode[s] is in lp3944_led_set_blink().
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
Reviewed-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
nasgpio_led_get_attr() is used only in this file.
Fix the following sparse warning:
drivers/leds/leds-ss4200.c:200:5: warning: symbol 'nasgpio_led_get_attr' was not declared. Should it be static?
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
Use the wrapper function for retrieving the platform data instead of
accessing dev->platform_data directly.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
Add hardware blinking support to the pca9633 driver.
NOTE: Hardware blinking violates the leds infrastructure
driver interface since the hardware only supports
blinking all LEDs with the same delay_on/delay_off
rates. That is, only the LEDs that are set to blink
will actually blink but all LEDs that are set to blink
will blink in identical fashion. The delay_on/delay_off
values of the last LED that is set to blink will be used
for all of the blinking LEDs. If the hardware doesn't
support the requested blinking pattern, a default of
500ms on and off will be used.
Hardware blinking is disabled by default but can be enabled
by setting the 'blink_type' member in the platform_data
struct to 'PCA9633_HW_BLINK' or by adding the 'nxp,hw-blink'
property to the DTS.
(fengguang.wu@intel.com: Removes unneeded semicolon.)
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
LP8501 can drive up to 9 channels like LP5523.
LEDs can be controlled directly via the I2C and programmable engines are
supported.
LP55xx common driver
LP8501 is one of LP55xx family device, so LP55xx common code are used.
Chip specific data is defined in the structure, 'lp55xx_device_config'.
Differences between LP8501 and LP5523
Different register layout for LED output control and others.
LP8501 specific feature for separate output power selection.
LP8501 doesn't support external clock detection.
Different programming engine data.
LP8501 specific feature - output power selection
Output channels are selected by power selection - Vout or Vdd.
Separate power for VDD1-6 and VDD7-9 are available.
It is configurable in the platform data.
To support this feature, LP55xx DT structure and header are changed.
Device tree binding is updated as well.
LED pattern data
Example pattern data is updated in the driver documentation.
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
Similar to tca6507, we can just parse the standard LED
properties for pca9633.
Tested on a pca9632, which is compatible with pca9633.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
* pm-cpufreq: (60 commits)
cpufreq: pmac32-cpufreq: remove device tree parsing for cpu nodes
cpufreq: pmac64-cpufreq: remove device tree parsing for cpu nodes
cpufreq: maple-cpufreq: remove device tree parsing for cpu nodes
cpufreq: arm_big_little: remove device tree parsing for cpu nodes
cpufreq: kirkwood-cpufreq: remove device tree parsing for cpu nodes
cpufreq: spear-cpufreq: remove device tree parsing for cpu nodes
cpufreq: highbank-cpufreq: remove device tree parsing for cpu nodes
cpufreq: cpufreq-cpu0: remove device tree parsing for cpu nodes
cpufreq: imx6q-cpufreq: remove device tree parsing for cpu nodes
drivers/bus: arm-cci: avoid parsing DT for cpu device nodes
ARM: mvebu: remove device tree parsing for cpu nodes
ARM: topology: remove hwid/MPIDR dependency from cpu_capacity
of/device: add helper to get cpu device node from logical cpu index
driver/core: cpu: initialize of_node in cpu's device struture
ARM: DT/kernel: define ARM specific arch_match_cpu_phys_id
of: move of_get_cpu_node implementation to DT core library
powerpc: refactor of_get_cpu_node to support other architectures
openrisc: remove undefined of_get_cpu_node declaration
microblaze: remove undefined of_get_cpu_node declaration
cpufreq: fix bad unlock balance on !CONFIG_SMP
...
|
|
* pm-cpuidle: (25 commits)
cpuidle: Change struct menu_device field types
cpuidle: Add a comment warning about possible overflow
cpuidle: Fix variable domains in get_typical_interval()
cpuidle: Fix menu_device->intervals type
cpuidle: CodingStyle: Break up multiple assignments on single line
cpuidle: Check called function parameter in get_typical_interval()
cpuidle: Rearrange code and comments in get_typical_interval()
cpuidle: Ignore interval prediction result when timer is shorter
cpuidle-kirkwood.c: simplify use of devm_ioremap_resource()
cpuidle: kirkwood: Make kirkwood_cpuidle_remove function static
cpuidle: calxeda: Add missing __iomem annotation
SH: cpuidle: Add missing parameter for cpuidle_register()
ARM: ux500: cpuidle: Move ux500 cpuidle driver to drivers/cpuidle
ARM: ux500: cpuidle: Remove pointless include
ARM: ux500: cpuidle: Instantiate the driver from platform device
ARM: davinci: cpuidle: Fix target residency
cpuidle: Add Kconfig.arm and move calxeda, kirkwood and zynq
cpuidle: Check if device is already registered
cpuidle: Introduce __cpuidle_device_init()
cpuidle: Introduce __cpuidle_unregister_device()
...
|
|
* pm-opp:
PM / OPP: Export opp_add()
|
|
* pm-sleep:
PM / Sleep: new trace event to print device suspend and resume times
PM / Sleep: increase ftrace coverage in suspend/resume
|
|
* pnp:
PNP: convert PNP driver bus legacy pm_ops to dev_pm_ops
|
|
* acpi-video:
ACPI: blacklist win8 OSI for buggy laptops
ACPI: blacklist win8 OSI for ASUS Zenbook Prime UX31A
ACPI / video: drop unused fields from struct acpi_video_brightness_flags
ACPI / video: remove unnecessary type casting
ACPI / video: trivial style cleanups
ACPI / video: trivial costmetic cleanups
Conflicts:
drivers/acpi/video.c
|
