2
0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-29 15:43:59 +08:00
Commit Graph

33 Commits

Author SHA1 Message Date
Kees Cook
a86854d0c5 treewide: devm_kzalloc() -> devm_kcalloc()
The devm_kzalloc() function has a 2-factor argument form, devm_kcalloc().
This patch replaces cases of:

        devm_kzalloc(handle, a * b, gfp)

with:
        devm_kcalloc(handle, a * b, gfp)

as well as handling cases of:

        devm_kzalloc(handle, a * b * c, gfp)

with:

        devm_kzalloc(handle, array3_size(a, b, c), gfp)

as it's slightly less ugly than:

        devm_kcalloc(handle, array_size(a, b), c, gfp)

This does, however, attempt to ignore constant size factors like:

        devm_kzalloc(handle, 4 * 1024, gfp)

though any constants defined via macros get caught up in the conversion.

Any factors with a sizeof() of "unsigned char", "char", and "u8" were
dropped, since they're redundant.

Some manual whitespace fixes were needed in this patch, as Coccinelle
really liked to write "=devm_kcalloc..." instead of "= devm_kcalloc...".

The Coccinelle script used for this was:

// Fix redundant parens around sizeof().
@@
expression HANDLE;
type TYPE;
expression THING, E;
@@

(
  devm_kzalloc(HANDLE,
-	(sizeof(TYPE)) * E
+	sizeof(TYPE) * E
  , ...)
|
  devm_kzalloc(HANDLE,
-	(sizeof(THING)) * E
+	sizeof(THING) * E
  , ...)
)

// Drop single-byte sizes and redundant parens.
@@
expression HANDLE;
expression COUNT;
typedef u8;
typedef __u8;
@@

(
  devm_kzalloc(HANDLE,
-	sizeof(u8) * (COUNT)
+	COUNT
  , ...)
|
  devm_kzalloc(HANDLE,
-	sizeof(__u8) * (COUNT)
+	COUNT
  , ...)
|
  devm_kzalloc(HANDLE,
-	sizeof(char) * (COUNT)
+	COUNT
  , ...)
|
  devm_kzalloc(HANDLE,
-	sizeof(unsigned char) * (COUNT)
+	COUNT
  , ...)
|
  devm_kzalloc(HANDLE,
-	sizeof(u8) * COUNT
+	COUNT
  , ...)
|
  devm_kzalloc(HANDLE,
-	sizeof(__u8) * COUNT
+	COUNT
  , ...)
|
  devm_kzalloc(HANDLE,
-	sizeof(char) * COUNT
+	COUNT
  , ...)
|
  devm_kzalloc(HANDLE,
-	sizeof(unsigned char) * COUNT
+	COUNT
  , ...)
)

// 2-factor product with sizeof(type/expression) and identifier or constant.
@@
expression HANDLE;
type TYPE;
expression THING;
identifier COUNT_ID;
constant COUNT_CONST;
@@

(
- devm_kzalloc
+ devm_kcalloc
  (HANDLE,
-	sizeof(TYPE) * (COUNT_ID)
+	COUNT_ID, sizeof(TYPE)
  , ...)
|
- devm_kzalloc
+ devm_kcalloc
  (HANDLE,
-	sizeof(TYPE) * COUNT_ID
+	COUNT_ID, sizeof(TYPE)
  , ...)
|
- devm_kzalloc
+ devm_kcalloc
  (HANDLE,
-	sizeof(TYPE) * (COUNT_CONST)
+	COUNT_CONST, sizeof(TYPE)
  , ...)
|
- devm_kzalloc
+ devm_kcalloc
  (HANDLE,
-	sizeof(TYPE) * COUNT_CONST
+	COUNT_CONST, sizeof(TYPE)
  , ...)
|
- devm_kzalloc
+ devm_kcalloc
  (HANDLE,
-	sizeof(THING) * (COUNT_ID)
+	COUNT_ID, sizeof(THING)
  , ...)
|
- devm_kzalloc
+ devm_kcalloc
  (HANDLE,
-	sizeof(THING) * COUNT_ID
+	COUNT_ID, sizeof(THING)
  , ...)
|
- devm_kzalloc
+ devm_kcalloc
  (HANDLE,
-	sizeof(THING) * (COUNT_CONST)
+	COUNT_CONST, sizeof(THING)
  , ...)
|
- devm_kzalloc
+ devm_kcalloc
  (HANDLE,
-	sizeof(THING) * COUNT_CONST
+	COUNT_CONST, sizeof(THING)
  , ...)
)

// 2-factor product, only identifiers.
@@
expression HANDLE;
identifier SIZE, COUNT;
@@

- devm_kzalloc
+ devm_kcalloc
  (HANDLE,
-	SIZE * COUNT
+	COUNT, SIZE
  , ...)

// 3-factor product with 1 sizeof(type) or sizeof(expression), with
// redundant parens removed.
@@
expression HANDLE;
expression THING;
identifier STRIDE, COUNT;
type TYPE;
@@

(
  devm_kzalloc(HANDLE,
-	sizeof(TYPE) * (COUNT) * (STRIDE)
+	array3_size(COUNT, STRIDE, sizeof(TYPE))
  , ...)
|
  devm_kzalloc(HANDLE,
-	sizeof(TYPE) * (COUNT) * STRIDE
+	array3_size(COUNT, STRIDE, sizeof(TYPE))
  , ...)
|
  devm_kzalloc(HANDLE,
-	sizeof(TYPE) * COUNT * (STRIDE)
+	array3_size(COUNT, STRIDE, sizeof(TYPE))
  , ...)
|
  devm_kzalloc(HANDLE,
-	sizeof(TYPE) * COUNT * STRIDE
+	array3_size(COUNT, STRIDE, sizeof(TYPE))
  , ...)
|
  devm_kzalloc(HANDLE,
-	sizeof(THING) * (COUNT) * (STRIDE)
+	array3_size(COUNT, STRIDE, sizeof(THING))
  , ...)
|
  devm_kzalloc(HANDLE,
-	sizeof(THING) * (COUNT) * STRIDE
+	array3_size(COUNT, STRIDE, sizeof(THING))
  , ...)
|
  devm_kzalloc(HANDLE,
-	sizeof(THING) * COUNT * (STRIDE)
+	array3_size(COUNT, STRIDE, sizeof(THING))
  , ...)
|
  devm_kzalloc(HANDLE,
-	sizeof(THING) * COUNT * STRIDE
+	array3_size(COUNT, STRIDE, sizeof(THING))
  , ...)
)

// 3-factor product with 2 sizeof(variable), with redundant parens removed.
@@
expression HANDLE;
expression THING1, THING2;
identifier COUNT;
type TYPE1, TYPE2;
@@

(
  devm_kzalloc(HANDLE,
-	sizeof(TYPE1) * sizeof(TYPE2) * COUNT
+	array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2))
  , ...)
|
  devm_kzalloc(HANDLE,
-	sizeof(TYPE1) * sizeof(THING2) * (COUNT)
+	array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2))
  , ...)
|
  devm_kzalloc(HANDLE,
-	sizeof(THING1) * sizeof(THING2) * COUNT
+	array3_size(COUNT, sizeof(THING1), sizeof(THING2))
  , ...)
|
  devm_kzalloc(HANDLE,
-	sizeof(THING1) * sizeof(THING2) * (COUNT)
+	array3_size(COUNT, sizeof(THING1), sizeof(THING2))
  , ...)
|
  devm_kzalloc(HANDLE,
-	sizeof(TYPE1) * sizeof(THING2) * COUNT
+	array3_size(COUNT, sizeof(TYPE1), sizeof(THING2))
  , ...)
|
  devm_kzalloc(HANDLE,
-	sizeof(TYPE1) * sizeof(THING2) * (COUNT)
+	array3_size(COUNT, sizeof(TYPE1), sizeof(THING2))
  , ...)
)

// 3-factor product, only identifiers, with redundant parens removed.
@@
expression HANDLE;
identifier STRIDE, SIZE, COUNT;
@@

(
  devm_kzalloc(HANDLE,
-	(COUNT) * STRIDE * SIZE
+	array3_size(COUNT, STRIDE, SIZE)
  , ...)
|
  devm_kzalloc(HANDLE,
-	COUNT * (STRIDE) * SIZE
+	array3_size(COUNT, STRIDE, SIZE)
  , ...)
|
  devm_kzalloc(HANDLE,
-	COUNT * STRIDE * (SIZE)
+	array3_size(COUNT, STRIDE, SIZE)
  , ...)
|
  devm_kzalloc(HANDLE,
-	(COUNT) * (STRIDE) * SIZE
+	array3_size(COUNT, STRIDE, SIZE)
  , ...)
|
  devm_kzalloc(HANDLE,
-	COUNT * (STRIDE) * (SIZE)
+	array3_size(COUNT, STRIDE, SIZE)
  , ...)
|
  devm_kzalloc(HANDLE,
-	(COUNT) * STRIDE * (SIZE)
+	array3_size(COUNT, STRIDE, SIZE)
  , ...)
|
  devm_kzalloc(HANDLE,
-	(COUNT) * (STRIDE) * (SIZE)
+	array3_size(COUNT, STRIDE, SIZE)
  , ...)
|
  devm_kzalloc(HANDLE,
-	COUNT * STRIDE * SIZE
+	array3_size(COUNT, STRIDE, SIZE)
  , ...)
)

// Any remaining multi-factor products, first at least 3-factor products,
// when they're not all constants...
@@
expression HANDLE;
expression E1, E2, E3;
constant C1, C2, C3;
@@

(
  devm_kzalloc(HANDLE, C1 * C2 * C3, ...)
|
  devm_kzalloc(HANDLE,
-	(E1) * E2 * E3
+	array3_size(E1, E2, E3)
  , ...)
|
  devm_kzalloc(HANDLE,
-	(E1) * (E2) * E3
+	array3_size(E1, E2, E3)
  , ...)
|
  devm_kzalloc(HANDLE,
-	(E1) * (E2) * (E3)
+	array3_size(E1, E2, E3)
  , ...)
|
  devm_kzalloc(HANDLE,
-	E1 * E2 * E3
+	array3_size(E1, E2, E3)
  , ...)
)

// And then all remaining 2 factors products when they're not all constants,
// keeping sizeof() as the second factor argument.
@@
expression HANDLE;
expression THING, E1, E2;
type TYPE;
constant C1, C2, C3;
@@

(
  devm_kzalloc(HANDLE, sizeof(THING) * C2, ...)
|
  devm_kzalloc(HANDLE, sizeof(TYPE) * C2, ...)
|
  devm_kzalloc(HANDLE, C1 * C2 * C3, ...)
|
  devm_kzalloc(HANDLE, C1 * C2, ...)
|
- devm_kzalloc
+ devm_kcalloc
  (HANDLE,
-	sizeof(TYPE) * (E2)
+	E2, sizeof(TYPE)
  , ...)
|
- devm_kzalloc
+ devm_kcalloc
  (HANDLE,
-	sizeof(TYPE) * E2
+	E2, sizeof(TYPE)
  , ...)
|
- devm_kzalloc
+ devm_kcalloc
  (HANDLE,
-	sizeof(THING) * (E2)
+	E2, sizeof(THING)
  , ...)
|
- devm_kzalloc
+ devm_kcalloc
  (HANDLE,
-	sizeof(THING) * E2
+	E2, sizeof(THING)
  , ...)
|
- devm_kzalloc
+ devm_kcalloc
  (HANDLE,
-	(E1) * E2
+	E1, E2
  , ...)
|
- devm_kzalloc
+ devm_kcalloc
  (HANDLE,
-	(E1) * (E2)
+	E1, E2
  , ...)
|
- devm_kzalloc
+ devm_kcalloc
  (HANDLE,
-	E1 * E2
+	E1, E2
  , ...)
)

Signed-off-by: Kees Cook <keescook@chromium.org>
2018-06-12 16:19:22 -07:00
Andrew Lunn
95b2af637e leds: lp55xx: Remove work queue
Now the core implements the work queue, remove it from the drivers,
and switch to using brightness_set_blocking op.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Cc: Milo Kim <milo.kim@ti.com>
2016-01-04 09:57:33 +01:00
Milo Kim
ed13335204 leds:lp55xx: use the private data instead of updating I2C device platform data
Currently, lp55xx_of_populate_pdata() allocates lp55xx_platform_data if
it's null. And it parses the DT and copies values into the
'client->dev.platform_data'. This may have architectural issue.
Platform data is configurable through the DT or I2C board info inside the
platform area. However, lp55xx common driver changes this configuration
when it is loaded. So 'client->dev.platform_data' is not null anymore.
Eventually, the driver initialization is not identical when it's unloaded
and loaded again.
The lp55xx common driver should use the private data, 'lp55xx_chip->pdata'
instead of changing the original platform data.

So, lp55xx_of_populate_pdata() is modified as follows.
* Do not update 'dev->platform_data'. Return the pointer of new allocated
   lp55xx_platform_data. Then the driver points it to private data,
   'lp55xx_chip->pdata'.
* Each lp55xx driver checks the pointer and handles an error case.

Then, original platform data configuration will be kept regardless of
loading or unloading the driver.
The driver allocates the memory and copies them from the DT if it's NULL.
After the driver is loaded again, 'client->dev.platform_data' is same as
initial load, so the driver is initialized identically.

Cc: Toshi Kikuchi <toshik@chromium.org>
Cc: linux-leds@vger.kernel.org
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2015-08-28 14:06:28 +02:00
Milo Kim
b67893206f leds:lp55xx: fix firmware loading error
LP55xx driver uses not firmware file but raw data to load program through
the firmware interface.(Documents/leds/leds-lp55xx.txt)

  For example, here is how to run blinking green channel pattern.
  (The second engine is seleted and MUX is mapped to 'RGB' mode)
  echo 2 > /sys/bus/i2c/devices/xxxx/select_engine
  echo "RGB" > /sys/bus/i2c/devices/xxxx/engine_mux
  echo 1 > /sys/class/firmware/lp5562/loading
  echo "4000600040FF6000" > /sys/class/firmware/lp5562/data
  echo 0 > /sys/class/firmware/lp5562/loading
  echo 1 > /sys/bus/i2c/devices/xxxx/run_engine

However, '/sys/class/firmware/<device name>' is not created after the
firmware loader user helper was introduced.
This feature is used in the case below.

  As soon as the firmware download is requested by the driver, firmware
  class subsystem tries to find the binary file.
  If it gets failed, then it just falls back to user helper to load
  raw data manually. Here, you can see the device file under
  /sys/class/firmware/.

To make it happen, LP55xx driver requires two configurations.

  1. Enable CONFIG_FW_LOADER_USER_HELPER_FALLBACK in Kconfig
  2. Set option, 'FW_OPT_USERHELPER' on requesting the firmware data.
     It means the second option should be 'false' in
     request_firmware_nowait().
     This option enables to load firmware data manually by calling
     fw_load_from_user_helper().

Cc: linux-leds@vger.kernel.org
Signed-off-by: Milo Kim <milo.kim@ti.com>
Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
2015-06-29 10:10:57 -07:00
Johan Hovold
44a1255b03 leds: lp55xx-common: fix attribute-creation race
Use the attribute groups of the led-class to create the LED attributes
during probe in order to avoid racing with userspace.

Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
2014-06-27 13:44:05 -07:00
Johan Hovold
660216bf82 leds: lp55xx-common: fix sysfs entry leak
Make sure the sysfs group is removed when the LEDs are unregistered.

Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
2014-06-27 13:44:04 -07:00
Milo Kim
93ad8a1d59 leds: lp5523: Support LED MUX configuration on running a pattern
There are two ways to run a pattern in LP5523.
One is using legacy sysfs files such as 'enginex_mode','enginex_load' and
'enginex_leds'. ('x' is from 1 to 3).
Among them, 'enginex_leds' are used for selecting specific LED channel MUX.
(MUX means which LEDs are used for running a pattern from LED 1 to 9.)

The other way is using the firmware interface.
In this mode, the default LED MUX strings are used.
In other words, LED MUX is not configurable on the fly.

This patch enables dynamic LED MUX configuration when the firmware is loaded.
By accessing the sysfs file 'enginex_leds', the LED channels can be configured.
To synchronize the operation mode, each engine mode should be set to 'LOAD'.

The documentation is updated as well.

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>
2014-01-27 17:28:48 -08:00
Sebastian Reichel
30dae2f986 leds: lp55xx: handle enable pin in driver
This patch moves the handling of the chip's enable pin from the board
code into the driver. It also updates all board-code files using the
driver to incorporate this change.

This is needed for device tree support of the enable pin.

Signed-off-by: Sebastian Reichel <sre@debian.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-10-25 10:13:25 -07:00
Linus Walleij
f65f0a1a98 leds: lp55xx: enable setting default trigger
This enables setting a default trigger on an LP55xx channel,
either from platform data or device tree. This mechanism is
identical to the mechanism for GPIO LEDs and references the
common LEDs device tree bindings.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Milo Kim <milo.kim@ti.com>
Acked-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-10-22 10:57:34 -07:00
Kim, Milo
33b3a561f4 leds: support new LP8501 device - another LP55xx common
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>
2013-08-26 17:22:10 -07:00
Kim, Milo
2dac912809 leds: lp55xx: support dynamic channel settings in the device tree structure
Currently, the LP55xx DT structure supports max 3 channels.
However, LP5523 has max 9 channels and LP5562 has 4 channels.
To enhance this constraint, the DT structure has been changed.

 (a) Use the child node for various channel settings instead of fixed array
 (b) Remove 'num_channel' property.
     This value can be retrieved by counting the children node.
 (c) 'chan-name' property supported
 (d) Documentation updates for LP5521 and LP5523

(cooloney@gmail.com: fix a coding style issue in leds-lp55xx.txt)

Cc: Gabriel Fernandez <gabriel.fernandez@stericsson.com>
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-06-20 16:21:32 -07:00
Linus Walleij
7542a04b15 leds: lp55xx: add support for Device Tree bindings
This patch allows the lp5521 driver to be successfully probed and
initialised when Device Tree support is enabled.

Based on a patch by Gabriel Fernandez, rewritten in accordance
with review feedback.

Cc: Gabriel Fernandez <gabriel.fernandez@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-06-20 16:21:31 -07:00
Kim, Milo
53b4192266 leds: lp55xx: use common clock framework when external clock is used
Program execution is timed with 32768Hz clock in the LP55xx family devices.
To run LED functionalities, LP55xx devices provide two options.
One is using internal clock. The other is using external clock.
This patch enables external clock detection automatically.
If external clock is not detected, then the internal clock will be used in the
LP55xx driver.

Valid clock rate is 32768Hz in LP55xx devices.

This new API is used in each LP55xx driver like LP5521 and LP5562.

Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-04-01 11:04:53 -07:00
Kim, Milo
24d3212847 leds: lp55xx: fix the sysfs read operation
According to a sysfs documentation(Documentation/filesystem/sysfs.txt),
scnprintf() should be used in a read operation method.
It guarantees safe buffer size(PAGE_SIZE) which is allocated by the sysfs.

Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-04-01 11:04:50 -07:00
Kim, Milo
ff45262a85 leds: add new LP5562 LED driver
LP5562 can drive up to 4 channels, RGB and White.
LEDs can be controlled directly via the led class control interface.

 LP55xx common driver
  LP5562 is one of LP55xx family device, so LP55xx common code are used.
  On the other hand, chip specific configuration is defined in the structure
  'lp55xx_device_config'

 LED pattern data
  LP5562 has also internal program memory which is used for running various LED
  patterns. LP5562 driver supports the firmware interface and the predefined
  pattern data as well.

 LP5562 device attributes: 'led_pattern' and 'engine_mux'
  A 'led_pattern' is an index code which runs the predefined pattern data.
  And 'engine_mux' is updated with the firmware interface is activated.
  Detailed description has been updated in the documentation files,
  'leds-lp55xx.txt' and 'leds-lp5562.txt'.

 Changes on the header file
  LP5562 configurable definitions are added.
  Pattern RGB data is fixed as constant value.
  (No side effect on other devices, LP5521 or LP5523.)

(cooloney@gmail.com: remove redundant mutex_unlock(). Reported by Dan
Carpenter <dan.carpenter@oracle.com>)

Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-04-01 11:04:48 -07:00
Milo(Woogyom) Kim
109b833071 leds-lp55xx: fix problem on removing LED attributes
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>
2013-02-06 15:59:30 -08:00
Milo(Woogyom) Kim
ba6fa84651 leds-lp55xx: add new function for removing device attribtues
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>
2013-02-06 15:59:29 -08:00
Milo(Woogyom) Kim
240085e255 leds-lp55xx: support device specific attributes
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>
2013-02-06 15:59:29 -08:00
Milo(Woogyom) Kim
10c06d178d leds-lp55xx: support firmware interface
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>
2013-02-06 15:59:28 -08:00
Milo(Woogyom) Kim
b3b6f8119d leds-lp55xx: add new lp55xx_register_sysfs() for the firmware interface
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>
2013-02-06 15:59:28 -08:00
Milo(Woogyom) Kim
d9067d2846 leds-lp55xx: fix error condition in lp55xx_register_leds()
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>
2013-02-06 15:59:28 -08:00
Milo(Woogyom) Kim
c3a68ebfcd leds-lp55xx: use lp55xx_unregister_leds()
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>
2013-02-06 15:59:28 -08:00
Milo(Woogyom) Kim
a96bfa135d leds-lp55xx: provide common LED current setting
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>
2013-02-06 15:59:28 -08:00
Milo(Woogyom) Kim
a6e4679a09 leds-lp55xx: use lp55xx_set_brightness()
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>
2013-02-06 15:59:28 -08:00
Milo(Woogyom) Kim
0e2023463a leds-lp55xx: use lp55xx_init_led() common function
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>
2013-02-06 15:59:28 -08:00
Milo(Woogyom) Kim
9e9b3db1b2 leds-lp55xx: use lp55xx common led registration function
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>
2013-02-06 15:59:28 -08:00
Milo(Woogyom) Kim
6ce6176263 leds-lp55xx: use lp55xx common deinit function
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>
2013-02-06 15:59:27 -08:00
Milo(Woogyom) Kim
22ebeb488b leds-lp55xx: clean up init function
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>
2013-02-06 15:59:27 -08:00
Milo(Woogyom) Kim
ffbdccdbba leds-lp55xx: use lp55xx common init function - post int
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>
2013-02-06 15:59:27 -08:00
Milo(Woogyom) Kim
e3a700d8aa leds-lp55xx: use lp55xx common init function - detect
LP5521/5523 chip detection functions are replaced with lp55xx common function,
 lp55xx_detect_device().
 Chip dependent address and values are configurable in each driver.
 In init function, chip detection is executed.

Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-02-06 15:59:27 -08:00
Milo(Woogyom) Kim
48068d5de1 leds-lp55xx: use lp55xx common init function - reset
LP5521/5523 reset device functions are moved to lp55xx common driver.
 Value of register address and value are chip dependent.
 Those are configured in each driver.
 In init function, reset command is executed.

Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-02-06 15:59:27 -08:00
Milo(Woogyom) Kim
a85908dd77 leds-lp55xx: use lp55xx common init function - platform data
LP5521/5523 platform data functions are moved to lp55xx common driver.
 New init function, lp55xx_init_device() is created.

Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-02-06 15:59:27 -08:00
Milo(Woogyom) Kim
c93d08fa75 leds-lp55xx: add new common driver for lp5521/5523
This patch supports basic common driver code for LP5521, LP5523/55231 devices.

 ( Driver Structure Data )

 lp55xx_led and lp55xx_chip
 In lp55xx common driver, two different data structure is used.
 o lp55xx_led
   control multi output LED channels such as led current, channel index.
 o lp55xx_chip
   general chip control such like the I2C and platform data.

 For example, LP5521 has maximum 3 LED channels.
 LP5523/55231 has 9 output channels.

 lp55xx_chip for LP5521 ... lp55xx_led #1
                            lp55xx_led #2
                            lp55xx_led #3

 lp55xx_chip for LP5523 ... lp55xx_led #1
                            lp55xx_led #2
                            .
                            .
                            lp55xx_led #9

 ( Platform Data )

 LP5521 and LP5523/55231 have own specific platform data.
 However, this data can be handled with just one platform data structure.
 The lp55xx platform data is declared in the header.
 This structure is derived from leds-lp5521.h and leds-lp5523.h

Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-02-06 15:59:26 -08:00