The MTIP32XX driver calls devm_request_irq() and therefore needs a
GENERIC_HARDIRQS dependency to prevent building it on s390.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
This reverts commit 93737456d6.
The cow-snapshots effort is no longer active, so remove these extra
fields to shrink down the handle structure.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
Track the delay between when we first request that the commit begin
and when it actually begins, so we can see how much of a gap exists.
In theory, this should just be the remaining scheduling quantuum of
the thread which requested the commit (assuming it was not a
synchronous operation which triggered the commit request) plus
scheduling overhead; however, it's possible that real time processes
might get in the way of letting the kjournald thread from executing.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Okay you don't really want to use udl devices as your console, but if
you are unlucky enough to do so, you run into a lot of schedule while atomic
due to printk being called from all sorts of funky places. So check if we
are in an atomic context, and queue the damage for later, the next printk
should cause it to appear. This isn't ideal, but it is simple, and seems to
work okay in my testing here.
(dirty area idea came from xenfb)
fixes a bunch of sleeping while atomic issues running fbcon on udl devices.
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
While looking at plymouth on udl I noticed that plymouth was trying
to use its fb plugin not its drm one, it was trying to drmOpen a driver called
usb not udl, noticed that we actually had out driver pointing at the wrong
device.
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
If grub2 loads efifb/vesafb, then when systemd starts it can set the console
font on that framebuffer device, however when we then load the native KMS
driver, the first thing it does is tear down the generic framebuffer driver.
The thing is the generic code is doing the right thing, it frees the font
because otherwise it would leak memory. However we can assume that if you
are removing the generic firmware driver (vesa/efi/offb), that a new driver
*should* be loading soon after, so we effectively leak the font.
However the old code left a dangling pointer in vc->vc_font.data and we
can now reuse that dangling pointer to load the font into the new
driver, now that we aren't freeing it.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=892340
Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
When we switch from 256->512 byte font rendering mode, it means the
current contents of the screen is being reinterpreted. The bit that holds
the high bit of the 9-bit font, may have been previously set, and thus
the new font misrenders.
The problem case we see is grub2 writes spaces with the bit set, so it
ends up with data like 0x820, which gets reinterpreted into 0x120 char
which the font translates into G with a circumflex. This flashes up on
screen at boot and is quite ugly.
A current side effect of this patch though is that any rendering on the
screen changes color to a slightly darker color, but at least the screen
no longer corrupts.
v2: as suggested by hpa, always clear the attribute space, whether we
are are going to or from 512 chars.
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Asymmetric keys were introduced in linux-3.7 to verify the signature on
signed kernel modules. The asymmetric keys infrastructure abstracts the
signature verification from the crypto details. This patch adds IMA/EVM
signature verification using asymmetric keys. Support for additional
signature verification methods can now be delegated to the asymmetric
key infrastructure.
Although the module signature header and the IMA/EVM signature header
could use the same format, to minimize the signature length and save
space in the extended attribute, this patch defines a new IMA/EVM
header format. The main difference is that the key identifier is a
sha1[12 - 19] hash of the key modulus and exponent, similar to the
current implementation. The only purpose of the key identifier is to
identify the corresponding key in the kernel keyring. ima-evm-utils
was updated to support the new signature format.
While asymmetric signature verification functionality supports many
different hash algorithms, the hash used in this patch is calculated
during the IMA collection phase, based on the configured algorithm.
The default algorithm is sha1, but for backwards compatibility md5
is supported. Due to this current limitation, signatures should be
generated using a sha1 hash algorithm.
Changes in this patch:
- Functionality has been moved to separate source file in order to get rid of
in source #ifdefs.
- keyid is derived according to the RFC 3280. It does not require to assign
IMA/EVM specific "description" when loading X509 certificate. Kernel
asymmetric key subsystem automatically generate the description. Also
loading a certificate does not require using of ima-evm-utils and can be
done using keyctl only.
- keyid size is reduced to 32 bits to save xattr space. Key search is done
using partial match functionality of asymmetric_key_match().
- Kconfig option title was changed
Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
Acked-by: David Howells <dhowells@redhat.com>
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
With the recent is-work-queued-here test simplification, the nested
if() in try_to_grab_pending() can be collapsed. Collapse it.
This patch is purely cosmetic.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
Currently, determining whether a work item is queued on a locked pool
involves somewhat convoluted memory barrier dancing. It goes like the
following.
* When a work item is queued on a pool, work->data is updated before
work->entry is linked to the pending list with a wmb() inbetween.
* When trying to determine whether a work item is currently queued on
a pool pointed to by work->data, it locks the pool and looks at
work->entry. If work->entry is linked, we then do rmb() and then
check whether work->data points to the current pool.
This works because, work->data can only point to a pool if it
currently is or were on the pool and,
* If it currently is on the pool, the tests would obviously succeed.
* It it left the pool, its work->entry was cleared under pool->lock,
so if we're seeing non-empty work->entry, it has to be from the work
item being linked on another pool. Because work->data is updated
before work->entry is linked with wmb() inbetween, work->data update
from another pool is guaranteed to be visible if we do rmb() after
seeing non-empty work->entry. So, we either see empty work->entry
or we see updated work->data pointin to another pool.
While this works, it's convoluted, to put it mildly. With recent
updates, it's now guaranteed that work->data points to cwq only while
the work item is queued and that updating work->data to point to cwq
or back to pool is done under pool->lock, so we can simply test
whether work->data points to cwq which is associated with the
currently locked pool instead of the convoluted memory barrier
dancing.
This patch replaces the memory barrier based "are you still here,
really?" test with much simpler "does work->data points to me?" test -
if work->data points to a cwq which is associated with the currently
locked pool, the work item is guaranteed to be queued on the pool as
work->data can start and stop pointing to such cwq only under
pool->lock and the start and stop coincide with queue and dequeue.
tj: Rewrote the comments and description.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
We plan to use work->data pointing to cwq as the synchronization
invariant when determining whether a given work item is on a locked
pool or not, which requires work->data pointing to cwq only while the
work item is queued on the associated pool.
With delayed_work updated not to overload work->data for target
workqueue recording, the only case where we still have off-queue
work->data pointing to cwq is try_to_grab_pending() which doesn't
update work->data after stealing a queued work item. There's no
reason for try_to_grab_pending() to not update work->data to point to
the pool instead of cwq, like the normal execution does.
This patch adds set_work_pool_and_keep_pending() which makes
work->data point to pool instead of cwq but keeps the pending bit
unlike set_work_pool_and_clear_pending() (surprise!).
After this patch, it's guaranteed that only queued work items point to
cwqs.
This patch doesn't introduce any visible behavior change.
tj: Renamed the new helper function to match
set_work_pool_and_clear_pending() and rewrote the description.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
To avoid executing the same work item from multiple CPUs concurrently,
a work_struct records the last pool it was on in its ->data so that,
on the next queueing, the pool can be queried to determine whether the
work item is still executing or not.
A delayed_work goes through timer before actually being queued on the
target workqueue and the timer needs to know the target workqueue and
CPU. This is currently achieved by modifying delayed_work->work.data
such that it points to the cwq which points to the target workqueue
and the last CPU the work item was on. __queue_delayed_work()
extracts the last CPU from delayed_work->work.data and then combines
it with the target workqueue to create new work.data.
The only thing this rather ugly hack achieves is encoding the target
workqueue into delayed_work->work.data without using a separate field,
which could be a trade off one can make; unfortunately, this entangles
work->data management between regular workqueue and delayed_work code
by setting cwq pointer before the work item is actually queued and
becomes a hindrance for further improvements of work->data handling.
This can be easily made sane by adding a target workqueue field to
delayed_work. While delayed_work is used widely in the kernel and
this does make it a bit larger (<5%), I think this is the right
trade-off especially given the prospect of much saner handling of
work->data which currently involves quite tricky memory barrier
dancing, and don't expect to see any measureable effect.
Add delayed_work->wq and drop the delayed_work->work.data overloading.
tj: Rewrote the description.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Currently, work_busy() first tests whether the work has a pool
associated with it and if not, considers it idle. This works fine
even for delayed_work.work queued on timer, as __queue_delayed_work()
sets cwq on delayed_work.work - a queued delayed_work always has its
cwq and thus pool associated with it.
However, we're about to update delayed_work queueing and this won't
hold. Update work_busy() such that it tests WORK_STRUCT_PENDING
before the associated pool. This doesn't make any noticeable behavior
difference now.
With work_pending() test moved, the function read a lot better with
"if (!pool)" test flipped to positive. Flip it.
While at it, lose the comment about now non-existent reentrant
workqueues.
tj: Reorganized the function and rewrote the description.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Now that workqueue has moved away from gcwqs, workqueue no longer has
the need to have a CPU identifier indicating "no cpu associated" - we
now use WORK_OFFQ_POOL_NONE instead - and most uses of WORK_CPU_NONE
are gone.
The only left usage is as the end marker for for_each_*wq*()
iterators, where the name WORK_CPU_NONE is confusing w/o actual
WORK_CPU_NONE usages. Similarly, WORK_CPU_LAST which equals
WORK_CPU_NONE no longer makes sense.
Replace both WORK_CPU_NONE and LAST with WORK_CPU_END. This patch
doesn't introduce any functional difference.
tj: s/WORK_CPU_LAST/WORK_CPU_END/ and rewrote the description.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Michał's previous patch missed this backlight check to fix up the
class_find_device() arguments.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use link_shadow_page to link the sp to the spte in __direct_map
Reviewed-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
It is only used in debug code, so drop it
Reviewed-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Currently, kvm zaps the large spte if write-protected is needed, the later
read can fault on that spte. Actually, we can make the large spte readonly
instead of making them not present, the page fault caused by read access can
be avoided
The idea is from Avi:
| As I mentioned before, write-protecting a large spte is a good idea,
| since it moves some work from protect-time to fault-time, so it reduces
| jitter. This removes the need for the return value.
Reviewed-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Fixed the checkpatch errors and warnings as below:
ERROR: spaces required around that '=' (ctx:VxW)
WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(... to printk(KERN_ERR ...
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
of_find_node_by_name() returns a node pointer with refcount incremented, use
of_node_put() on it when done.
of_find_node_by_name() will call of_node_put() against from parameter,
thus we also need to call of_node_get(from) before calling
of_find_node_by_name().
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
The correct dependency for the leds-pwm is PWM and not HAVE_PWM
since PWM drivers now have their own subsystem.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
When calculating hw_cr0 teh current code masks bits that should be always
on and re-adds them back immediately after. Cleanup the code by masking
only those bits that should be dropped from hw_cr0. This allow us to
get rid of some defines.
Signed-off-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Update changed platform data information.
Add leds-lp55xx.txt which includes the firmware interface description.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LP55XX common device attributes, 'led_current' and 'max_current' are created
while loading the driver.
Those are LED device attributes which are removed automatically on releasing
led class devices - led_classdev_unregister().
Therefore, this duplicate code should be removed.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Now LP5521 and LP5523 drivers are based on new lp55xx structure.
So the author and copyrights are updated.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
The LP55xx common driver provides a new header, leds-lp55xx.h.
This driver enables removing duplicate code for both drivers and
making coherent driver structure.
LP5521 and LP5523/55231 platform data were merged into one common file.
Therefore, the LP5521/5523 platform code need to be fixed.
This patch has been already acked.
For ux500: https://lkml.org/lkml/2012/10/11/417
Acked-by: Linus Walleij <linus.walleij@linaro.org>
For omap: https://lkml.org/lkml/2012/10/11/334
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Remove unused definitions and change hex values to capital letters
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Old data structures and I2C function are not used any more.
Each driver uses the lp55xx common data and functions.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Replace lp5521/5523_unregister_sysfs() with lp55xx_unregister_sysfs().
On unloading the driver, running engines should be stopped.
Use explicit driver function, lp5521/5523_stop_engine().
Unused functions are removed.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
lp55xx_unregister_sysfs() is used for removing lp55xx device attributes.
Chip specific and engine attributes are removed on unloading the driver.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LP5521 and LP5523 have a selftest function which is run via the sysfs.
Use lp55xx driver data and R/W functions rather than lp5521/5523 private data
and functions.
Additionally, if-statements are changed for code simplicity.
Unused functions, lp5521/5523_read() are removed.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
lp5521/5523_register_sysfs() are replaced with lp55xx common driver function,
lp55xx_register_sysfs().
Chip specific device attributes are configurable using 'dev_attr_group'.
Error condition name is changed:
use specific error condition, 'err_register_sysfs' rather than unclear name,
'fail2'.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
To support device specific attributes, new common driver function is added.
Eventually those are created on registering the sysfs with common dev attrs.
Furthermore, this patch makes adding device attributes simple in each driver.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LP55xx common driver provides generic firmware interface
for running a LED pattern.
LP5521 and LP5523 have many device attributes for running patterns.
This patch cleans up those complex code.
Removed device attributes:
engine1_mode
engine2_mode
engine3_mode
engine1_load
engine2_load
engine3_load
engine1_leds
engine2_leds
engine3_leds
All device attributes and functions are replaced with two callback functions,
'firmware_cb' and 'run_engine'.
New engine functions:
lp5523_load/stop/run_engine(), lp5523_update_program_memory() and
lp5523_wait_opmode_done()
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LP55xx common driver provides generic firmware interface
for running a LED pattern.
LP5521 and LP5523 have many device attributes for running patterns.
This patch cleans up those complex code.
Removed device attributes:
engine1_mode
engine2_mode
engine3_mode
engine1_load
engine2_load
engine3_load
led_pattern
All device attributes and functions are replaced with two callback functions,
'firmware_cb' and 'run_engine'.
New engine functions:
lp5521_load/stop/run_engine(), lp5521_update_program_memory() and
lp5521_wait_opmode_done()
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
This patch provides additional device attributes which enable
loading the firmware. ('select_engine' and 'run_engine')
To run a LED pattern, two parts of driver should be enabled.
Common features : lp55xx-common
===============================
Firmware interface for loading LED patterns
Chip specific features : leds-lp5521, leds-lp5523
=================================================
Register addresses for loading firmware data
Register addresses for running selected engine
Pattern programming sequence
============================
LP55xx chips have three program engines.
To load and run a LED pattern, the programming sequence is as follows.
(1) Select an engine number (1/2/3)
(2) Set engine mode to load
(3) Write pattern data into selected area
(4) Set engine mode to run
This sequence is almost same as the firmware interface.
(1) Select an engine number : 'select_engine' dev attribute
(2) Mode change to load : 'loading' of firmware class
(3) Write pattern data into selected area : 'data' of firmware class
(4) Mode change to run : 'run_engine' dev attribute
(1) and (4) are device specific features which provide callback functions
(2) and (3) are common features.
For example,
echo 1 or 2 or 3 > /sys/bus/i2c/devices/xxxx/select_engine
echo 1 > /sys/class/firmware/lp5521/loading
echo "4000600040FF6000" > /sys/class/firmware/lp5521/data
echo 0 > /sys/class/firmware/lp5521/loading
echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
As soon as 'loading' is set to 0, registered callback is called.
Inside the callback, the selected engine is loaded and memory is updated.
To run programmed pattern, 'run_engine' attribute should be enabled.
Device specific data structure
==============================
o Firmware callback
load selected engine and update program memory
o Run engine
change the engine mode
o 'engine_idx' and firmware data, 'fw'
Those are used in the driver internally with callback functions
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LP55xx family chips have internal program memory which run various patterns.
Using this memory, LEDs continue on blinking/dimming without continuous I2C
commands. That means the I2C HOST can be entered into sleep once the memory
is updated.
An application can get hex data from a file and write them into
the program memory through the I2C. This is general firwmare interface.
This patch is the initial step for adding the firmware interface.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Use lp55xx_unregister_leds() rather than duplicate code.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
To unregister led class devices and sysfs attributes,
LP5521 and LP5523 have each driver function.
This patch makes both drivers simple using common driver function,
lp55xx_unregister_leds().
And some unused variables are removed.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LED current is configurable via the sysfs.
Max current is a read-only attribute.
These attributes code can be shared in lp55xx common driver.
Device attributes: 'led_current' and 'max_current'
move to lp55xx common driver
Replaced functions:
show_max_current() => lp55xx_show_max_current()
show_current() => lp55xx_show_current()
store_current() => lp55xx_store_current()
LED setting function: set_led_current()
Current registers are device specific, so configurable function is added
in each driver.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
lp5521_set_brightness() and lp5523_set_brightness() are replaced with
common function, lp55xx_set_brightness().
This function is invoked when the brightness of each LED channel is updated.
LP5521 and LP5523 have different register address for the brightness control,
so this work is done by chip specific brightness_work_fn().
lp5521/5523_led_brightness_work():
use lp55xx_led and lp55xx_chip data structure.
use lp55xx write function.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
lp5521_init_led() and lp5523_init_led() are replaced with one common function,
lp55xx_init_led().
Max channels is configurable, so it's used in lp55xx_init_led().
'LP5523_LEDS' are changed to 'LP5523_MAX_LEDS'.
lp55xx_set_brightness, lp55xx_led_attributes: skeleton
Will be filled in next patches.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LED class devices are registered in lp5521_register_leds() and
lp5523_register_leds().
Two separate functions are merged into consolidated lp55xx function,
lp55xx_register_leds().
Error handling fix:
Unregistering LEDS are handled in lp55xx_register_leds() when LED registration
failure occurs. So each driver error handler is changed to 'err_register_leds'
Chip dependency: 'brightness_work_fn' and 'set_led_current'
To make the structure abstract, both functions are configured in each driver.
Those functions should be done by each driver because register control is
chip-dependant work.
lp55xx_init_led: skeleton
Will be filled in next patch
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Two separate de-init functions are merged into one common function.
And it is used in err_post_init of lp55xx_init_device().
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
lp5521/5523_init_device() are replaced with lp55xx common function,
lp55xx_init_device().
Error handler in init_device:
deinit function are matched with 'err_post_init' section in
lp55xx_init_device().
Remove LP5523 engine intialization code:
Engine functionality is not mandatory but optional.
Moreover engine initialization is done internally with device reset command.
Therefore, this code is unnecessary.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LP5521/5523 chip configuration is replaced with lp55xx common function,
lp55xx_post_init_device().
Name change:
lp5521/5523_configure() to lp5521/5523_post_init_device()
These are called in init function.
Register access function
Argument type is changed from 'i2c_client' to 'lp55xx_chip'.
Use exported R/W functions of lp55xx common driver.
Temporary variables in lp5521/5523_init_device()
These functions will be removed but temporary variables are needed for
blocking build warnings - incompatible pointer.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
