- 06 Feb, 2013 13 commits
-
-
Milo(Woogyom) Kim authored
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>
-
Milo(Woogyom) Kim authored
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>
-
Milo(Woogyom) Kim authored
This patch is a preceding step for making common lp55xx init function. Return code: Do not use 'OR' arithmetic for the result. If some error occurs, just return it. Remove engine verification code: To check whether internal engine works or not, many lines of code are executed. However, this job is unnecessary during the chip initialization because the engine usage is not mandatory but optional function. LED engines are enabled when specific LED pattern is loaded. Therefore, this verification code is removed. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
-
Milo(Woogyom) Kim authored
This patch is a preceding step for making common lp55xx init function. LP5521_REG_R_CURRENT register code moved: Chip specific code moved from lp5521_init_device() to lp5521_configure(). Remove engine init function: LP5521 has internal program engines which are used for running LED patterns. (blinking, ramp up/down and other emotional visual effects) Engine initialization is done by reset command in lp5521_init_device(). Remove this duplicate code. Return code: Do not use 'OR' arithmetic for the result. If some error occus, just return it. Enable latency: Use explicit named function, lp5521_wait_enable_done(). According to the datasheet, 500us is guaranteed time. Thus wait time is changed from 1000us to 500us. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
-
Milo(Woogyom) Kim authored
LP5521 and LP5523 data structures have common features. Use common lp55xx data structures rather than chip specific data. Legacy code in probe is replaced with this new data structures. lp55xx_chip : Common data between lp5521_chip and lp5523_chip lp55xx_led : Common LED structure between lp5521_led and lp5523_led lp55xx_platform_data : Common platform data between lp5521_platform_data and lp5523_platform_data Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
-
Milo(Woogyom) Kim authored
Change the name of chip data structure and platform data. This patch is a preceding step for cleaning up lp5521/5523 probe and remove. These data will be replaced with new lp55xx common data structures in next patch. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
-
Milo(Woogyom) Kim authored
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>
-
Milo(Woogyom) Kim authored
Chip specific function is configured when the device is initialized. So _configure() is moved to each device init function. If chip configuration gets failed, the device is de-initialized in each _init_device(), not probe(). For compile error fix, function type declarations are added. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
-
Milo(Woogyom) Kim authored
Use explicit each driver function rather than raw command. These function will be merged into the lp55xx common driver. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
-
Milo(Woogyom) Kim authored
To make LED unregistration code simple, new function, _unregister_leds() is added in each driver. This patch is a preceding step for lp55xx common driver architecture. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
-
Milo(Woogyom) Kim authored
To make LED initialization code simple, new function, _register_leds() is added at each driver. This patch is a preceding step for lp55xx common driver architecture. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
-
Milo(Woogyom) Kim authored
Device de-initialization code is moved to _deinit_device() at each driver. This patch is a preceding step for lp55xx common driver architecture. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
-
Milo(Woogyom) Kim authored
To make _probe() simple, device initialization code is moved to _init_device() at each driver. This patch is a preceding step for lp55xx common driver architecture. leds-lp5521: When 'lp5521_init_device()' gets failed, error handling should be 'fail1' rather than 'fail2'. fail1: releasing platform resource and return code fail2: releasing allocated LED devices with handling 'fail1' The 'lp5521_init_device()' is called before creating LED devices. Thus, 'goto fail1' is proper error handler of this function. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
-
- 02 Feb, 2013 18 commits
-
-
Jingoo Han authored
Fixed the checkpatch warning as below: WARNING: static const char * array should probably be static const char * const Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
-
Jingoo Han authored
This macro is used to create a struct pci_device_id array. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
-
Jingoo Han authored
Fixed the checkpatch warning as below: WARNING: suspect code indent for conditional statements (8, 8) Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
-
Jingoo Han authored
Fixed the checkpatch warning as below: WARNING: Avoid CamelCase: <devAttr> Rename devAttr to attr. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
-
Jingoo Han authored
Fixed the checkpatch warning as below: WARNING: Avoid CamelCase: <devAttr> Rename devAttr to attr. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
-
Axel Lin authored
I spent a few minutes to understand why the code catching the mismatch case by checking if k is 0 or not. And the code using "k - 1" as array index is unusual. This patch checks acceptable rate from the lowest rate, and then we don't need to subtract k by 1. This change improves the readability. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
-
Axel Lin authored
Add lm3530_led_enable() and lm3530_led_disable() helper functions. This ensures setting drvdata->enable to correct status if regulator_disable fails. Signed-off-by: Axel Lin <axel.lin@ingics.com> Acked-by: Shreshtha Kumar SAHU <shreshthakumar.sahu@stericsson.com> Acked-by: Milo Kim <milo.kim@ti.com> Tested-by: Milo Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
-
Kim, Milo authored
The lp8788-keyled is a platform driver of lp8788-mfd. The platform device is allocated when mfd_add_devices() is called in lp8788-mfd. On the other hand, 'lp->dev' is the i2c client device. Therefore, this 'platform_device' is a proper parent device in case of resource managed mem alloc, registering led device and device kernel messages. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
-
Peter Ujfalusi authored
The DT binding for the pwm-leds devices are similar to the gpio-leds type. LEDs are represented as sub-nodes of the pwm-leds device. The code for handling the DT boot is based on the code found in the leds-gpio driver and adapted to use PWMs instead of GPIOs. To avoid having custom cleanup code in case of DT boot the newly created devm_of_pwm_get() API is used to get the correct PWM instance. For usage see: Documentation/devicetree/bindings/leds/leds-pwm.txt Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Bryan Wu <cooloney@gmail.com>
-
Peter Ujfalusi authored
The code looks more nicer if we use: while (i--) instead: if (i > 0) for (i = i - 1; i >= 0; i--) Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
-
Peter Ujfalusi authored
When booted with DT users can use devm version of of_pwm_get() to benefit from automatic resource release. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Thierry Reding <thierry.reding@avionic-design.de> Signed-off-by: Bryan Wu <cooloney@gmail.com>
-
Peter Ujfalusi authored
Allow client driver to use of_pwm_get() to get the PWM they need. This is needed for drivers which handle more than one PWM separately, like leds-pwm driver, which have: pwmleds { compatible = "pwm-leds"; kpad { label = "omap4::keypad"; pwms = <&twl_pwm 0 7812500>; max-brightness = <127>; }; charging { label = "omap4:green:chrg"; pwms = <&twl_pwmled 0 7812500>; max-brightness = <255>; }; }; in the dts files. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Thierry Reding <thierry.reding@avionic-design.de> Signed-off-by: Bryan Wu <cooloney@gmail.com>
-
Peter Ujfalusi authored
To synchronize the header file definition and the actual code. In the code the consumer parameter is named as con_id, change the header file and replace consumer -> con_id in the parameter list. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Ackedy-by: Thierry Reding <thierry.reding@avionic-design.de> Signed-off-by: Bryan Wu <cooloney@gmail.com>
-
Peter Ujfalusi authored
In order to be able to add device tree support for leds-pwm driver we need to rearrange the data structures used by the drivers. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
-
Peter Ujfalusi authored
Update the driver to use the new API for requesting pwm so we can take advantage of the pwm_lookup table to find the correct pwm to be used for the LED functionality. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
-
Axel Lin authored
Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
-
Marek Belisko authored
Signed-off-by: Marek Belisko <marek.belisko@open-nandra.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
-
Marek Belisko authored
Support added only for leds (not for gpio's). (cooloney@gmail.com: fix 2 building errors) Signed-off-by: Marek Belisko <marek.belisko@open-nandra.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
-
- 01 Feb, 2013 2 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dmLinus Torvalds authored
Pull more device-mapper fixes from Alasdair G Kergon: "A fix for stacked dm thin devices and a fix for the new dm WRITE SAME support." * tag 'dm-3.8-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dm: dm: fix write same requests counting dm thin: fix queue limits stacking
-
- 31 Jan, 2013 7 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hidLinus Torvalds authored
PullHID fixes from Jiri Kosina: - fix i2c-hid and hidraw interaction, by Benjamin Tissoires - a quirk to make a particular device (Formosa IR receiver) work properly, by Nicholas Santos * 'for-3.8/upstream-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid: HID: i2c-hid: fix i2c_hid_output_raw_report HID: usbhid: quirk for Formosa IR receiver HID: remove x bit from sensor doc
-
git://git.linux-nfs.org/projects/trondmy/linux-nfsLinus Torvalds authored
Pull NFS client bugfixes from Trond Myklebust: - Error reporting in nfs_xdev_mount incorrectly maps all errors to ENOMEM - Fix an NFSv4 refcounting issue - Fix a mount failure when the server reboots during NFSv4 trunking discovery - NFSv4.1 mounts may need to run the lease recovery thread. - Don't silently fail setattr() requests on mountpoints - Fix a SUNRPC socket/transport livelock and priority queue issue - We must handle NFS4ERR_DELAY when resetting the NFSv4.1 session. * tag 'nfs-for-3.8-4' of git://git.linux-nfs.org/projects/trondmy/linux-nfs: NFSv4.1: Handle NFS4ERR_DELAY when resetting the NFSv4.1 session SUNRPC: When changing the queue priority, ensure that we change the owner NFS: Don't silently fail setattr() requests on mountpoints NFSv4.1: Ensure that nfs41_walk_client_list() does start lease recovery NFSv4: Fix NFSv4 trunking discovery NFSv4: Fix NFSv4 reference counting for trunked sessions NFS: Fix error reporting in nfs_xdev_mount
-
git://git.linux-mips.org/pub/scm/ralf/upstream-linusLinus Torvalds authored
Pull MIPS updates from Ralf Baechle: "A number of fixes all across the MIPS tree. No area is particularly standing out and things have cooled down quite nicely for a release." * 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus: MIPS: Function tracer: Fix broken function tracing mips: Move __virt_addr_valid() to a place for MIPS 64 MIPS: Netlogic: Fix UP compilation on XLR MIPS: AR71xx: Fix AR71XX_PCI_MEM_SIZE MIPS: AR724x: Fix AR724X_PCI_MEM_SIZE MIPS: Lantiq: Fix cp0_perfcount_irq mapping MIPS: DSP: Fix DSP mask for registers. MIPS: Fix build failure by adding definition of pfn_pmd(). MIPS: Octeon: Fix warning. MIPS: delay.c: Check BITS_PER_LONG instead of __SIZEOF_LONG__ MIPS: PNX833x: Fix comment. MIPS: Add struct p_format to union mips_instruction. MIPS: Export <asm/break.h>. MIPS: BCM47xx: Enable SSB prerequisite SSB_DRIVER_PCICORE. MIPS: BCM47xx: Select GPIOLIB for BCMA on bcm47xx platform MIPS: vpe.c: Fix null pointer dereference in print arguments.
-
Benjamin Tissoires authored
i2c_hid_output_raw_report is used by hidraw to forward set_report requests. The current implementation of i2c_hid_set_report needs to take the report_id as an argument. The report_id is stored in the first byte of the buffer in argument of i2c_hid_output_raw_report. Not removing the report_id from the given buffer adds this byte 2 times in the command, leading to a non working command. Reported-by: Andrew Duggan <aduggan@synaptics.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
-
Al Cooper authored
Function tracing is currently broken for all 32 bit MIPS platforms. When tracing is enabled, the kernel immediately hangs on boot. This is a result of commit b732d439 that changes the kernel/trace/Kconfig file so that is no longer forces FRAME_POINTER when FUNCTION_TRACING is enabled. MIPS frame pointers are generally considered to be useless because they cannot be used to unwind the stack. Unfortunately the MIPS function tracing code has bugs that are masked by the use of frame pointers. This commit fixes the bugs so that MIPS frame pointers don't need to be enabled. The bugs are a result of the odd calling sequence used to call the trace routine. This calling sequence is inserted into every traceable function when the tracing CONFIG option is enabled. This sequence is generated for 32bit MIPS platforms by the compiler via the "-pg" flag. Part of the sequence is "addiu sp,sp,-8" in the delay slot after every call to the trace routine "_mcount" (some legacy thing where 2 arguments used to be pushed on the stack). The _mcount routine is expected to adjust the sp by +8 before returning. So when not disabled, the original jalr and addiu will be there, so _mcount has to adjust sp. The problem is that when tracing is disabled for a function, the "jalr _mcount" instruction is replaced with a nop, but the "addiu sp,sp,-8" is still executed and the stack pointer is left trashed. When frame pointers are enabled the problem is masked because any access to the stack is done through the frame pointer and the stack pointer is restored from the frame pointer when the function returns. This patch writes two nops starting at the address of the "jalr _mcount" instruction whenever tracing is disabled. This means that the "addiu sp,sp.-8" will be converted to a nop along with the "jalr". When disabled, there will be two nops. This is SMP safe because the first time this happens is during ftrace_init() which is before any other processor has been started. Subsequent calls to enable/disable tracing when other CPUs ARE running will still be safe because the enable will only change the first nop to a "jalr" and the disable, while writing 2 nops, will only be changing the "jalr". This patch also stops using stop_machine() to call the tracer enable/disable routines and calls them directly because the routines are SMP safe. When the kernel first boots we have to be able to handle the gcc generated jalr, addui sequence until ftrace_init gets a chance to run and change the sequence. At this point mcount just adjusts the stack and returns. When ftrace_init runs, we convert the jalr/addui to nops. Then whenever tracing is enabled we convert the first nop to a "jalr mcount+8". The mcount+8 entry point skips the stack adjust. [ralf@linux-mips.org: Folded in Steven Rostedt's build fix.] Signed-off-by: Al Cooper <alcooperx@gmail.com> Cc: rostedt@goodmis.org Cc: ddaney.cavm@gmail.com Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/4806/ Patchwork: https://patchwork.linux-mips.org/patch/4841/Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
-
Alasdair G Kergon authored
When processing write same requests, fix dm to send the configured number of WRITE SAME requests to the target rather than the number of discards, which is not always the same. Device-mapper WRITE SAME support was introduced by commit 23508a96 ("dm: add WRITE SAME support"). Signed-off-by: Alasdair G Kergon <agk@redhat.com> Acked-by: Mike Snitzer <snitzer@redhat.com>
-
Steven Rostedt authored
Commit d3ce8843 "MIPS: Fix modpost error in modules attepting to use virt_addr_valid()" moved __virt_addr_valid() from a macro in a header file to a function in ioremap.c. But ioremap.c is only compiled for MIPS 32, and not for MIPS 64. When compiling for my yeeloong2, which supposedly supports hibernation, which compiles kernel/power/snapshot.c which calls virt_addr_valid(), I got this error: LD init/built-in.o kernel/built-in.o: In function `memory_bm_free': snapshot.c:(.text+0x4c9c4): undefined reference to `__virt_addr_valid' snapshot.c:(.text+0x4ca58): undefined reference to `__virt_addr_valid' kernel/built-in.o: In function `snapshot_write_next': (.text+0x4e44c): undefined reference to `__virt_addr_valid' kernel/built-in.o: In function `snapshot_write_next': (.text+0x4e890): undefined reference to `__virt_addr_valid' make[1]: *** [vmlinux] Error 1 make: *** [sub-make] Error 2 I suspect that __virt_addr_valid() is fine for mips 64. I moved it to mmap.c such that it gets compiled for mips 64 and 32. Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Cc: linux-kernel@vger.kernel.org Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/4842/Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
-