aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/auxdisplay/ht16k33.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2018-04-12auxdisplay: Replace licenses with SPDX identifiersMiguel Ojeda1-9/+1
Cc: Philippe Ombredanne <pombredanne@nexb.com> Acked-by: Willy Tarreau <w@1wt.eu> Acked-by: Linus Walleij <triad@dflund.se> Acked-by: Robin van der Gracht <robin@protonic.nl> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
2017-04-08auxdisplay: ht16k33: use le16_to_cpup() to fetch LE16 dataDmitry Torokhov1-4/+8
The data read from the device is 3 little-endian words, so let's annotate them as such and use le16_to_cpu() to convert them to host endianness - it might turn out to be a bit more performant, and it expresses the conversion more clearly. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-04-08auxdisplay: ht16k33: don't access uninitialized dataArnd Bergmann1-1/+7
gcc-7.0.1 points out that we copy uninitialized data from the stack into a per-device structure: drivers/auxdisplay/ht16k33.c: In function 'ht16k33_keypad_irq_thread': arch/x86/include/asm/string_32.h:78:16: error: 'new_state' may be used uninitialized in this function [-Werror=maybe-uninitialized] arch/x86/include/asm/string_32.h:79:22: error: '*((void *)&new_state+4)' may be used uninitialized in this function [-Werror=maybe-uninitialized] The access is harmless because we never read the data, but we are better off not doing this, so this changes the code to only copy the data that was actually initialized. To make sure we don't overflow the stack with an incorrect DT, we also need to add a sanity checkin the probe function. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Robin van der Gracht <robin@protonic.nl> Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-02-10auxdisplay: ht16k33: remove private workqueueDmitry Torokhov1-15/+5
There is no need for the driver to use private workqueue, standard system workqueue should suffice as they are going to use the same worker pool anyway. Acked-by: Robin van der Gracht <robin@protonic.nl> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-02-10auxdisplay: ht16k33: rework input device initializationDmitry Torokhov1-153/+145
This patch fixes following issues in input device (keypad) handling: - requesting IRQ before allocating and initializing parts of the device that can be referenced from IRQ handler is racy, even if we try to disable interrupt after requesting it. Let's move allocations around so that everything is ready by the time we request IRQ. - using threaded interrupt handler to schedule a work item it sub-optimal. Disabling and then re-enabling interrupts in work item and in open/close methods is prone to races and exactly the reason theraded interrupts were introduced. Let's use the infrastructure properly and keep scanning the matrix array in IRQ thread, stopping when there are no keys, or when told to do so. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Tested-by: Robin van der Gracht <robin@protonic.nl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-02-10auxdisplay: ht16k33: do not try to free fbdevDmitry Torokhov1-3/+1
'fbdev' is allocated as part of larger ht16k33_priv structure; trying to free it will cause troubles. Acked-by: Robin van der Gracht <robin@protonic.nl> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-11-10auxdisplay: ht16k33: Driver for LED controllerRobin van der Gracht1-0/+563
Added a driver for the Holtek HT16K33 LED controller with keyscan. Signed-off-by: Robin van der Gracht <robin@protonic.nl> CC: Miguel Ojeda Sandonis <miguel.ojeda.sandonis@gmail.com> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>