The misc control register is 32bit wide, the used readw/writew
accessors only mainipulate the low 16bit of this register. It
currently doesn't matter as all the bit changed are located in
the lower half, but together with the u32 variable used to hold
the contents of the register it is seriously confusing.
Switch to 32bit accessors to avoid any future breakage.
Signed-off-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Keep the quirk bits, as Tegra30 and Tegra114 host have different levels
of support for UHS-I modes and so need different spare bits to be set,
but change the logic to be positive.
Tegra210 needs a different tuning sequence than Tegra30+. Disable
UHS modes until support for this is properly added.
Signed-off-by: Lucas Stach <dev@lynxeye.de>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This allows the build system to know that it can't attempt to
configure the Lustre virtual block device, for example, when tilepro
is using 64KB pages (as it does by default). The tilegx build
already provided those symbols.
Previously we required that the tilepro hypervisor be rebuilt with
a different hardcoded page size in its headers, and then Linux be
rebuilt using the updated hypervisor header. Now we allow each of
the hypervisor and Linux to be built independently. We still check
at boot time to ensure that the page size provided by the hypervisor
matches what Linux expects.
Signed-off-by: Chris Metcalf <cmetcalf@ezchip.com>
Cc: stable@vger.kernel.org [3.19+]
This provide the fix for firmware memory by freeing the pointer in driver
remove where it is safe to do so
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Using mremap() to shrink the map size of a VM_PFNMAP range causes
the following error message, and leaves the pfn range allocated.
x86/PAT: test:3493 freeing invalid memtype [mem 0x483200000-0x4863fffff]
This is because rbt_memtype_erase(), called from free_memtype()
with spin_lock held, only supports to free a whole memtype node in
memtype_rbroot. Therefore, this patch changes rbt_memtype_erase()
to support a request that shrinks the size of a memtype node for
mremap().
memtype_rb_exact_match() is renamed to memtype_rb_match(), and
is enhanced to support EXACT_MATCH and END_MATCH in @match_type.
Since the memtype_rbroot tree allows overlapping ranges,
rbt_memtype_erase() checks with EXACT_MATCH first, i.e. free
a whole node for the munmap case. If no such entry is found,
it then checks with END_MATCH, i.e. shrink the size of a node
from the end for the mremap case.
On the mremap case, rbt_memtype_erase() proceeds in two steps,
1) remove the node, and then 2) insert the updated node. This
allows proper update of augmented values, subtree_max_end, in
the tree.
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: stsp@list.ru
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/1450832064-10093-3-git-send-email-toshi.kani@hpe.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
mremap() with MREMAP_FIXED on a VM_PFNMAP range causes the following
WARN_ON_ONCE() message in untrack_pfn().
WARNING: CPU: 1 PID: 3493 at arch/x86/mm/pat.c:985 untrack_pfn+0xbd/0xd0()
Call Trace:
[<ffffffff817729ea>] dump_stack+0x45/0x57
[<ffffffff8109e4b6>] warn_slowpath_common+0x86/0xc0
[<ffffffff8109e5ea>] warn_slowpath_null+0x1a/0x20
[<ffffffff8106a88d>] untrack_pfn+0xbd/0xd0
[<ffffffff811d2d5e>] unmap_single_vma+0x80e/0x860
[<ffffffff811d3725>] unmap_vmas+0x55/0xb0
[<ffffffff811d916c>] unmap_region+0xac/0x120
[<ffffffff811db86a>] do_munmap+0x28a/0x460
[<ffffffff811dec33>] move_vma+0x1b3/0x2e0
[<ffffffff811df113>] SyS_mremap+0x3b3/0x510
[<ffffffff817793ee>] entry_SYSCALL_64_fastpath+0x12/0x71
MREMAP_FIXED moves a pfnmap from old vma to new vma. untrack_pfn() is
called with the old vma after its pfnmap page table has been removed,
which causes follow_phys() to fail. The new vma has a new pfnmap to
the same pfn & cache type with VM_PAT set. Therefore, we only need to
clear VM_PAT from the old vma in this case.
Add untrack_pfn_moved(), which clears VM_PAT from a given old vma.
move_vma() is changed to call this function with the old vma when
VM_PFNMAP is set. move_vma() then calls do_munmap(), and untrack_pfn()
is a no-op since VM_PAT is cleared.
Reported-by: Stas Sergeev <stsp@list.ru>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/1450832064-10093-2-git-send-email-toshi.kani@hpe.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
On 2015/11/06, Dmitry Vyukov reported a deadlock involving the splice
system call and AF_UNIX sockets,
http://lists.openwall.net/netdev/2015/11/06/24
The situation was analyzed as
(a while ago) A: socketpair()
B: splice() from a pipe to /mnt/regular_file
does sb_start_write() on /mnt
C: try to freeze /mnt
wait for B to finish with /mnt
A: bind() try to bind our socket to /mnt/new_socket_name
lock our socket, see it not bound yet
decide that it needs to create something in /mnt
try to do sb_start_write() on /mnt, block (it's
waiting for C).
D: splice() from the same pipe to our socket
lock the pipe, see that socket is connected
try to lock the socket, block waiting for A
B: get around to actually feeding a chunk from
pipe to file, try to lock the pipe. Deadlock.
on 2015/11/10 by Al Viro,
http://lists.openwall.net/netdev/2015/11/10/4
The patch fixes this by removing the kern_path_create related code from
unix_mknod and executing it as part of unix_bind prior acquiring the
readlock of the socket in question. This means that A (as used above)
will sb_start_write on /mnt before it acquires the readlock, hence, it
won't indirectly block B which first did a sb_start_write and then
waited for a thread trying to acquire the readlock. Consequently, A
being blocked by C waiting for B won't cause a deadlock anymore
(effectively, both A and B acquire two locks in opposite order in the
situation described above).
Dmitry Vyukov(<dvyukov@google.com>) tested the original patch.
Signed-off-by: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commands run in a vrf context are not failing as expected on a route lookup:
root@kenny:~# ip ro ls table vrf-red
unreachable default
root@kenny:~# ping -I vrf-red -c1 -w1 10.100.1.254
ping: Warning: source address might be selected on device other than vrf-red.
PING 10.100.1.254 (10.100.1.254) from 0.0.0.0 vrf-red: 56(84) bytes of data.
--- 10.100.1.254 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 999ms
Since the vrf table does not have a route for 10.100.1.254 the ping
should have failed. The saddr lookup causes a full VRF table lookup.
Propogating a lookup failure to the user allows the command to fail as
expected:
root@kenny:~# ping -I vrf-red -c1 -w1 10.100.1.254
connect: No route to host
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When the reset_resume() is called, the flag of SELECTIVE_SUSPEND should be
cleared and reinitialize the device, whether the SELECTIVE_SUSPEND is set
or not. If reset_resume() is called, it means the power supply is cut or the
device is reset. That is, the device wouldn't be in runtime suspend state and
the reinitialization is necessary.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Dmitry reports memleak with syskaller program.
Problem is that connector bumps skb usecount but might not invoke callback.
So move skb_get to where we invoke the callback.
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Since t4_alloc_mem can be failed in memory pressure,
if not properly handled, NULL dereference could be happened.
Signed-off-by: Insu Yun <wuninsu@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Since qlcnic_alloc_mbx_args can be failed,
return value should be checked.
Signed-off-by: Insu Yun <wuninsu@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When we do cat /sys/kernel/debug/tracing/printk_formats, we hit kernel
panic at t_show.
general protection fault: 0000 [#1] PREEMPT SMP
CPU: 0 PID: 2957 Comm: sh Tainted: G W O 3.14.55-x86_64-01062-gd4acdc7 #2
RIP: 0010:[<ffffffff811375b2>]
[<ffffffff811375b2>] t_show+0x22/0xe0
RSP: 0000:ffff88002b4ebe80 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000004
RDX: 0000000000000004 RSI: ffffffff81fd26a6 RDI: ffff880032f9f7b1
RBP: ffff88002b4ebe98 R08: 0000000000001000 R09: 000000000000ffec
R10: 0000000000000000 R11: 000000000000000f R12: ffff880004d9b6c0
R13: 7365725f6d706400 R14: ffff880004d9b6c0 R15: ffffffff82020570
FS: 0000000000000000(0000) GS:ffff88003aa00000(0063) knlGS:00000000f776bc40
CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 00000000f6c02ff0 CR3: 000000002c2b3000 CR4: 00000000001007f0
Call Trace:
[<ffffffff811dc076>] seq_read+0x2f6/0x3e0
[<ffffffff811b749b>] vfs_read+0x9b/0x160
[<ffffffff811b7f69>] SyS_read+0x49/0xb0
[<ffffffff81a3a4b9>] ia32_do_call+0x13/0x13
---[ end trace 5bd9eb630614861e ]---
Kernel panic - not syncing: Fatal exception
When the first time find_next calls find_next_mod_format, it should
iterate the trace_bprintk_fmt_list to find the first print format of
the module. However in current code, start_index is smaller than *pos
at first, and code will not iterate the list. Latter container_of will
get the wrong address with former v, which will cause mod_fmt be a
meaningless object and so is the returned mod_fmt->fmt.
This patch will fix it by correcting the start_index. After fixed,
when the first time calls find_next_mod_format, start_index will be
equal to *pos, and code will iterate the trace_bprintk_fmt_list to
get the right module printk format, so is the returned mod_fmt->fmt.
Link: http://lkml.kernel.org/r/5684B900.9000309@intel.com
Cc: stable@vger.kernel.org # 3.12+
Fixes: 102c9323c3 "tracing: Add __tracepoint_string() to export string pointers"
Signed-off-by: Qiu Peiyang <peiyangx.qiu@intel.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Commit 807f16d4db ("mtd: core: set some defaults when dev.parent is
set") attempted to provide some default settings for MTDs that
(a) assign the parent device and
(b) don't provide their own name or owner
However, this isn't a perfect drop-in replacement for the boilerplate
found in some drivers, because the MTD name is used by partition
parsers like cmdlinepart, but the name isn't set until add_mtd_device(),
after the parsing is completed. This means cmdlinepart sees a NULL name
and therefore will not work properly.
Fix this by moving the default name and owner assignment to be first in
the MTD registration process.
[Note: this does not fix all reported issues, particularly with NAND
drivers. Will require an additional fix for drivers/mtd/nand/]
Fixes: 807f16d4db ("mtd: core: set some defaults when dev.parent is set")
Reported-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Frans Klaver <fransklaver@gmail.com>
The aem_rw_sensor_template and aem_ro_sensor_template structures are never
modified, so declare them as const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Fix build warning:
scripts/recordmcount.c:589:4: warning: format not a string
literal and no format arguments [-Wformat-security]
sprintf("%s: failed\n", file);
Fixes: a50bd43935 ("ftrace/scripts: Have recordmcount copy the object file")
Link: http://lkml.kernel.org/r/1451516801-16951-1-git-send-email-colin.king@canonical.com
Cc: Li Bin <huawei.libin@huawei.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Will Deacon <will.deacon@arm.com>
Cc: stable@vger.kernel.org # 2.6.37+
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Ran into this on UML:
drivers/built-in.o: In function `bcm6328_leds_probe':
drivers/leds/leds-bcm6328.c:340: undefined reference to `devm_ioremap_resource'
drivers/built-in.o: In function `bcm6358_leds_probe':
drivers/leds/leds-bcm6358.c:173: undefined reference to `devm_ioremap_resource'
collect2: error: ld returned 1 exit status
devm_ioremap_resource() is defined only when HAS_IOMEM is selected.
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: linux-leds@vger.kernel.org
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Complementing devm_led_classdev_register add a managed version of
led_trigger_register.
I omit a managed version of led_classdev_unregister as the equivalent
devm_led_classdev_unregister isn't used in the kernel as of today.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
The busy status checking isn't needed while reading initial LED status.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
BCM6328 controller has a margin of 20ms per blink step, which means that
we can only set it to 20, 40, 60 ... 1260 ms (0x3f * 20ms).
However, when checking if delay_on == delay_off, we were not considering
the case when the user had set delay_on=20 and delay_off=21, since this
will cause the driver to fallback to software blinking.
This update fixes this issue and improves blink steps by rounding them
in a more sensible way. Now 30-49ms is rounded to 40 ms, and previous
behaviour implied 40-59ms being rounded to 40 ms.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
bcm6358_led_mode is now only called by bcm6358_led_set, so merge both
in one single function.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Instead of duplicating the unlock we can store the return value and use a
single unlock before returning that value, which simplifies the code.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
This adds little endian support while keeping big endian support.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
This adds little endian support while keeping big endian support.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
This lock isn't really needed, since we're only reading the register and
changes made to other LEDs aren't relevant.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Replaces bcm6358_led_mode with bcm6358_led_set so we don't need to handle
the lock.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
This lock isn't really needed, since we're only reading the register and
changes made to other LEDs aren't relevant.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
The Kconfig currently controlling compilation of this code is:
drivers/leds/Kconfig:config LEDS_SYSCON
drivers/leds/Kconfig: bool "LED support for LEDs on system controllers"
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.
We explicitly disallow a driver unbind, since that doesn't have a
sensible use case anyway, and it allows us to drop the ".remove"
code for non-modular drivers.
Since module_platform_driver() uses the same init level priority as
builtin_platform_driver() the init ordering remains unchanged with
this commit.
Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: linux-leds@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
The Kconfig for this driver is currently:
config LEDS_TRIGGER_IDE_DISK
bool "LED IDE Disk Trigger"
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.
Since module_init translates to device_initcall in the non-modular
case, the init ordering remains unchanged with this commit.
We also delete the MODULE_LICENSE tag etc. since all that information
is already contained at the top of the file in the comments.
Cc: Bryan Wu <cooloney@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: linux-leds@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
The Kconfig for this driver is currently:
config LEDS_TRIGGER_CPU
bool "LED CPU Trigger"
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.
Since module_init translates to device_initcall in the non-modular
case, the init ordering remains unchanged with this commit.
We also delete the MODULE_LICENSE tag etc. since all that information
is already contained at the top of the file in the comments.
Cc: Bryan Wu <cooloney@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: linux-leds@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
These new helpers simplify implementing multi-driver modules and
properly handle failure to register one driver by unregistering all
previously registered drivers.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Each break out of the for_each_available_child_of_node loop requires
of_node_put().
This patch adds missing of_node_put() when loop breaks on conflicting
values of led-sources DT property.
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
The refcount of device_node increases after of_get_next_available_child()
is called. Make sure it is decremented also in case of DT parsing error.
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
Since brightness setting can sleep for this driver, implement
brightness_set_blocking op, instead of brightness_set.
It makes this driver compatible with LED triggers.
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Cc: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Since brightness setting can sleep for this driver, implement
brightness_set_blocking op, instead of brightness_set.
It makes this driver compatible with LED triggers.
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
No need to explicitly check for pointer to be null,
of_prop_next_string anyways returns NULL, if passed pointer is NULL
and hence loop will continue.
Signed-off-by: Saurabh Sengar <saurabh.truth@gmail.com>
Acked-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
The values of BCM6328_LED_MODE_ON and BCM6328_LED_MODE_OFF were named
for active low LEDs. These should be swapped so that they are named for
the default case of active high LEDs.
Signed-off-by: Simon Arlott <simon@fire.lp0.eu>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
When ensuring a consistent initial LED state in bcm6328_led (as they may
be blinking instead of on/off), the LED register is set using an inverted
copy of bcm6328_led_set(). To avoid further errors relating to active low
handling, call this function directly instead.
As bcm6328_led_set() acquires the same spinlock again when updating the
register, it is called after unlocking.
Signed-off-by: Simon Arlott <simon@fire.lp0.eu>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Now the core implements the work queue, remove it from the drivers,
and switch to using brightness_set_blocking op.
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Tested-by: Simon Guinot <simon.guinot@sequanux.org>
Workqueue, 'set_brightness_work' is used for scheduling brightness control.
This workqueue is canceled when the LED class device is unregistered.
Currently, LED subsystem handles like below.
cancel_work_sync(&led_cdev->set_brightness_work)
led_set_brightness(led_cdev, LED_OFF)
However, this could be a problem.
Workqueue is going to be canceled but LED device needs to be off.
The worst case is null pointer access due to scheduling a workqueue.
LED module is loaded.
LED driver private data is allocated by using devm_zalloc().
LED module is unloaded.
led_classdev_unregister() is called.
cancel_work_sync()
led_set_brightness(led_cdev, LED_OFF)
schedule_work() if LED driver uses brightness_set_blocking()
In the meantime, driver private data will be freed.
..scheduling..
brightness_set_blocking() callback is invoked.
For the brightness control, LED driver tries to access private
data but resource is removed!
To avoid this problem, LED subsystem should turn off the brightness first
and wait for completion.
led_set_brightness(led_cdev, LED_OFF)
flush_work(&led_cdev->set_brightness_work)
It guarantees that LED driver turns off the brightness prior to
resource management.
Cc: linux-leds@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Strobe state variable is declared as unsigned long, remove
the check for values less than zero then.
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Reported-by: David Binderman <dcb314@hotmail.com>
The refcount of device_node increases after of_node_get() is called.
So, a break out of the loop requires of_node_put().
This patch adds missing of_node_put() when loop breaks.
Signed-off-by: Ingi Kim <ingi2.kim@samsung.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Some PWMs are disabled by default or the default pin setting
does not match the LED_OFF state (e.g., active-low leds).
Hence, the driver may end up reporting 0 brightness, but
the leds are actually on using full brightness, because
it never enforces its default configuration.
So enforce it by calling led_pwm_set() after successfully
registering the device.
Tested on a Phytec phyFLEX i.MX6Q board based on kernel
v3.19.5.
Signed-off-by: Markus Hofstaetter <markus.hofstaetter@ait.ac.at>
Tested-by: Markus Hofstaetter <markus.hofstaetter@ait.ac.at>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
The header of this file fixes the license to GPL 2 only without the
option to use later version. So use the string "GPL v2" that is to be
used in this case.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Fabio Baltieri <fabio.baltieri@gmail.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
The transient trigger duration is documented to be in msec units, but is
actually in jiffies units. Other time based triggers are in msec units
as well. Fix the timer setup to convert from msec.
This could break an existing userspace that worked around this problem,
but exposing jiffies to userspace is just wrong and would break anyway
if HZ is changed.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Shuah Khan <shuahkhan@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: linux-leds@vger.kernel.org
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Lucas Stach