| Age | Commit message (Collapse) | Author |
|---|
|
The meson driver has always carried an unnecessary workaround for the
infamous low_latency behaviour of tty_flip_buffer_push(), which had
already been removed by the time the driver was added by commit
ff7693d079e5 ("ARM: meson: serial: add MesonX SoC on-chip uart driver").
Specifically, since commit a9c3f68f3cd8 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks around.
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20210421095509.3024-15-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Commit 5275ad70fed3 ("tty: serial: mcf: drop uart_port->lock before
calling tty_flip_buffer_push()") claimed to address a locking
issue but only provided a dubious lockdep splat from an unrelated
driver, which in the end turned out to be due a broken local change
carried by the author.
Unfortunately these patches were merged before the issue had been
analysed properly so the commit messages makes no sense whatsoever.
The real issue was first seen on RT which at the time effectively always
set the low_latency flag for all serial drivers by patching
tty_flip_buffer_push(). This in turn revealed that many drivers did not
handle the infamous low_latency behaviour which meant that data was
pushed immediately to the line discipline instead of being deferred to a
work queue.
Since commit a9c3f68f3cd8 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks
around.
Link: https://lore.kernel.org/linux-serial/cover.1376923198.git.viresh.kumar@linaro.org/
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20210421095509.3024-14-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Commit ec128510905c ("tty: serial: lpc32xx_hs: drop uart_port->lock
before calling tty_flip_buffer_push()") claimed to address a locking
issue but only provided a dubious lockdep splat from an unrelated
driver, which in the end turned out to be due a broken local change
carried by the author.
Unfortunately these patches were merged before the issue had been
analysed properly so the commit messages makes no sense whatsoever.
The real issue was first seen on RT which at the time effectively always
set the low_latency flag for all serial drivers by patching
tty_flip_buffer_push(). This in turn revealed that many drivers did not
handle the infamous low_latency behaviour which meant that data was
pushed immediately to the line discipline instead of being deferred to a
work queue.
Since commit a9c3f68f3cd8 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks
around.
Link: https://lore.kernel.org/linux-serial/cover.1376923198.git.viresh.kumar@linaro.org/
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20210421095509.3024-13-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Commit 5faf75d7fed2 ("tty: serial: icom: drop uart_port->lock before
calling tty_flip_buffer_push()") claimed to address a locking
issue but only provided a dubious lockdep splat from an unrelated
driver, which in the end turned out to be due a broken local change
carried by the author.
Unfortunately these patches were merged before the issue had been
analysed properly so the commit messages makes no sense whatsoever.
The real issue was first seen on RT which at the time effectively always
set the low_latency flag for all serial drivers by patching
tty_flip_buffer_push(). This in turn revealed that many drivers did not
handle the infamous low_latency behaviour which meant that data was
pushed immediately to the line discipline instead of being deferred to a
work queue.
Since commit a9c3f68f3cd8 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks
around.
Link: https://lore.kernel.org/linux-serial/cover.1376923198.git.viresh.kumar@linaro.org/
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20210421095509.3024-12-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Commit b4d499241c34 ("tty: serial: bcm63xx: drop uart_port->lock before
calling tty_flip_buffer_push()") claimed to address a locking
issue but only provided a dubious lockdep splat from an unrelated
driver, which in the end turned out to be due a broken local change
carried by the author.
Unfortunately these patches were merged before the issue had been
analysed properly so the commit messages makes no sense whatsoever.
The real issue was first seen on RT which at the time effectively always
set the low_latency flag for all serial drivers by patching
tty_flip_buffer_push(). This in turn revealed that many drivers did not
handle the infamous low_latency behaviour which meant that data was
pushed immediately to the line discipline instead of being deferred to a
work queue.
Since commit a9c3f68f3cd8 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks
around.
Link: https://lore.kernel.org/linux-serial/cover.1376923198.git.viresh.kumar@linaro.org/
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20210421095509.3024-11-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Commit 1ecc26bd2789 ("atmel_serial: split the interrupt handler") worked
around the infamous low_latency behaviour of tty_flip_buffer_push() by
dropping and reacquiring the port lock in the tasklet callback.
Since commit a9c3f68f3cd8 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks around.
Cc: Richard Genoud <richard.genoud@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20210421095509.3024-10-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Commit 3fa1200851c7 ("tty: serial: arc: drop uart_port->lock before
calling tty_flip_buffer_push()") claimed to address a locking
issue but only provided a dubious lockdep splat from an unrelated
driver, which in the end turned out to be due a broken local change
carried by the author.
Unfortunately these patches were merged before the issue had been
analysed properly so the commit messages makes no sense whatsoever.
The real issue was first seen on RT which at the time effectively always
set the low_latency flag for all serial drivers by patching
tty_flip_buffer_push(). This in turn revealed that many drivers did not
handle the infamous low_latency behaviour which meant that data was
pushed immediately to the line discipline instead of being deferred to a
work queue.
Since commit a9c3f68f3cd8 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks
around.
Link: https://lore.kernel.org/linux-serial/cover.1376923198.git.viresh.kumar@linaro.org/
Cc: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20210421095509.3024-9-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Commit b16c8e3eed12 ("tty: serial: ar933x: drop uart_port->lock before
calling tty_flip_buffer_push()") claimed to address a locking
issue but only provided a dubious lockdep splat from an unrelated
driver, which in the end turned out to be due a broken local change
carried by the author.
Unfortunately these patches were merged before the issue had been
analysed properly so the commit messages makes no sense whatsoever.
The real issue was first seen on RT which at the time effectively always
set the low_latency flag for all serial drivers by patching
tty_flip_buffer_push(). This in turn revealed that many drivers did not
handle the infamous low_latency behaviour which meant that data was
pushed immediately to the line discipline instead of being deferred to a
work queue.
Since commit a9c3f68f3cd8 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks
around.
Link: https://lore.kernel.org/linux-serial/cover.1376923198.git.viresh.kumar@linaro.org/
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20210421095509.3024-8-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Commit 78d34d75c84d ("tty: serial: apbuart: drop uart_port->lock before
calling tty_flip_buffer_push()") claimed to address a locking
issue but only provided a dubious lockdep splat from an unrelated
driver, which in the end turned out to be due a broken local change
carried by the author.
Unfortunately these patches were merged before the issue had been
analysed properly so the commit messages makes no sense whatsoever.
The real issue was first seen on RT which at the time effectively always
set the low_latency flag for all serial drivers by patching
tty_flip_buffer_push(). This in turn revealed that many drivers did not
handle the infamous low_latency behaviour which meant that data was
pushed immediately to the line discipline instead of being deferred to a
work queue.
Since commit a9c3f68f3cd8 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks
around.
Link: https://lore.kernel.org/linux-serial/cover.1376923198.git.viresh.kumar@linaro.org/
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20210421095509.3024-7-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Commit ead76f329f77 ("ARM: 6763/1: pl011: add optional RX DMA to PL011
v2") added RX DMA support and also reproduced the workaround for the
infamous low_latency behaviour of tty_flip_buffer_push() by dropping and
reacquiring the port lock during receive processing.
Since commit a9c3f68f3cd8 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks around.
Note that the port lock is also dropped in the PIO path
(see pl011_rx_chars), but it is not clear whether this is still needed
by the DMA code added by the aforementioned commit.
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Russell King <linux@armlinux.org.uk>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20210421095509.3024-6-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Commit 2389b272168c ("[ARM] 4417/1: Serial: Fix AMBA drivers locking")
worked around the infamous low_latency behaviour of
tty_flip_buffer_push() by simply dropping and reacquiring the port lock
in the interrupt handler.
Since commit a9c3f68f3cd8 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks around.
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20210421095509.3024-5-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Commit dd085ed8ef6c ("tty: serial: altera: drop uart_port->lock before
calling tty_flip_buffer_push()") claimed to address a locking
issue but only provided a dubious lockdep splat from an unrelated
driver, which in the end turned out to be due a broken local change
carried by the author.
Unfortunately these patches were merged before the issue had been
analysed properly so the commit messages makes no sense whatsoever.
The real issue was first seen on RT which at the time effectively always
set the low_latency flag for all serial drivers by patching
tty_flip_buffer_push(). This in turn revealed that many drivers did not
handle the infamous low_latency behaviour which meant that data was
pushed immediately to the line discipline instead of being deferred to a
work queue.
Since commit a9c3f68f3cd8 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks
around.
Link: https://lore.kernel.org/linux-serial/cover.1376923198.git.viresh.kumar@linaro.org/
Cc: Tobias Klauser <tklauser@distanz.ch>
Acked-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20210421095509.3024-4-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Commit 53dd0ba7a6f4 ("tty: serial: altera_jtag: drop uart_port->lock
before calling tty_flip_buffer_push()") claimed to address a locking
issue but only provided a dubious lockdep splat from an unrelated
driver, which in the end turned out to be due a broken local change
carried by the author.
Unfortunately these patches were merged before the issue had been
analysed properly so the commit messages makes no sense whatsoever.
The real issue was first seen on RT which at the time effectively always
set the low_latency flag for all serial drivers by patching
tty_flip_buffer_push(). This in turn revealed that many drivers did not
handle the infamous low_latency behaviour which meant that data was
pushed immediately to the line discipline instead of being deferred to a
work queue.
Since commit a9c3f68f3cd8 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks
around.
Link: https://lore.kernel.org/linux-serial/cover.1376923198.git.viresh.kumar@linaro.org/
Cc: Tobias Klauser <tklauser@distanz.ch>
Acked-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20210421095509.3024-3-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Commit 67d2bc58afdd ("Char: mxser_new, fix recursive locking") worked
around the infamous low_latency behaviour of tty_flip_buffer_push() by
simply dropping and reacquiring the port lock in the interrupt handler.
Since commit a9c3f68f3cd8 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks around.
Link: https://lore.kernel.org/lkml/3018694794025219@wsc.cz/T/#m06b04c640a7b6f41afb3d34a4cf29b1df4935d3a
Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20210421095509.3024-2-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Data received during half-duplex transmission must be filtered.
If the target device responds quickly, emptying the FIFO at the end of
the transmission can erase not only the echo characters but also part of
the response message.
By keeping the receive interrupt enabled even during transmission, it
allows you to filter each echo character and only in a number equal to
those transmitted.
The issue was generated by a target device that started responding
240us later having received a request in communication at 115200bps.
Sometimes, some messages received by the target were missing some of the
first bytes.
Fixes: 3a13884abea0 ("tty/serial: omap: empty the RX FIFO at the end of half-duplex TX")
Signed-off-by: Dario Binacchi <dariobin@libero.it>
Link: https://lore.kernel.org/r/20210418094705.27014-1-dariobin@libero.it
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
There are rs485 transceivers (e.g. MAX13487E/MAX13488E) which
automatically disable or enable the driver and receiver to keep the bus
in the correct state.
In these cases we don't need a GPIO for flow control.
Fixes: 4a0ac0f55b18 ("OMAP: add RS485 support")
Signed-off-by: Dario Binacchi <dariobin@libero.it>
Link: https://lore.kernel.org/r/20210415210945.25863-1-dariobin@libero.it
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Use the uart_unlock_and_check_sysrq() helper to defer sysrq processing
until receive processing is done and the port lock has been released.
This allows cleaning up the console_write() implementation by not having
to work around the recursive sysrq case (by dropping locking completely)
and also makes the console code work with PREEMPT_RT by no longer
relying on local_irq_save().
Reviewed-by: Valentin Caron<valentin.caron@foss.st.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20210416140557.25177-4-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
When DMA is enabled the receive handler runs in a threaded handler, but
the primary handler up until very recently neither disabled interrupts
in the device or used IRQF_ONESHOT. This would lead to a deadlock if an
interrupt comes in while the threaded receive handler is running under
the port lock.
Commit ad7676812437 ("serial: stm32: fix a deadlock condition with
wakeup event") claimed to fix an unrelated deadlock, but unfortunately
also disabled interrupts in the threaded handler. While this prevents
the deadlock mentioned in the previous paragraph it also defeats the
purpose of using a threaded handler in the first place.
Fix this by making the interrupt one-shot and not disabling interrupts
in the threaded handler.
Note that (receive) DMA must not be used for a console port as the
threaded handler could be interrupted while holding the port lock,
something which could lead to a deadlock in case an interrupt handler
ends up calling printk.
Fixes: ad7676812437 ("serial: stm32: fix a deadlock condition with wakeup event")
Fixes: 3489187204eb ("serial: stm32: adding dma support")
Cc: stable@vger.kernel.org # 4.9
Cc: Alexandre TORGUE <alexandre.torgue@st.com>
Cc: Gerald Baeza <gerald.baeza@st.com>
Reviewed-by: Valentin Caron<valentin.caron@foss.st.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20210416140557.25177-3-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The uart_unlock_and_check_sysrq() helper can be used to defer processing
of sysrq until the interrupt handler has released the port lock and is
about to return.
Since commit 81e2073c175b ("genirq: Disable interrupts for force
threaded handlers") interrupt handlers that are not explicitly requested
as threaded are always called with interrupts disabled and there is no
need to save the interrupt state when taking the port lock.
Instead of adding another sysrq helper for when the interrupt state has
not needlessly been saved, drop the state parameter from
uart_unlock_and_check_sysrq() and update its callers to no longer
explicitly disable interrupts in their interrupt handlers.
Cc: Joel Stanley <joel@jms.id.au>
Cc: Andrew Jeffery <andrew@aj.id.au>
Cc: Andy Gross <agross@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20210416140557.25177-2-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The variable count is being initialized with a value that is
never read and it is being updated later with a new value. The
initialization is redundant and can be removed.
Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Addresses-Coverity: ("Unused value")
Link: https://lore.kernel.org/r/20210420105718.377086-1-colin.king@canonical.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
syzbot is reporting hung task due to flood of
tty_warn(tty, "%s: tty->count = 1 port count = %d\n", __func__,
port->count);
message [1], for ioctl(TIOCVHANGUP) prevents tty_port_close() from
decrementing port->count due to tty_hung_up_p() == true.
----------
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <unistd.h>
int main(int argc, char *argv[])
{
int i;
int fd[10];
for (i = 0; i < 10; i++)
fd[i] = open("/dev/ttyprintk", O_WRONLY);
ioctl(fd[0], TIOCVHANGUP);
for (i = 0; i < 10; i++)
close(fd[i]);
close(open("/dev/ttyprintk", O_WRONLY));
return 0;
}
----------
When TTY hangup happens, port->count needs to be reset via
"struct tty_operations"->hangup callback.
[1] https://syzkaller.appspot.com/bug?id=39ea6caa479af471183997376dc7e90bc7d64a6a
Reported-by: syzbot <syzbot+43e93968b964e369db0b@syzkaller.appspotmail.com>
Reported-by: syzbot <syzbot+3ed715090790806d8b18@syzkaller.appspotmail.com>
Tested-by: syzbot <syzbot+43e93968b964e369db0b@syzkaller.appspotmail.com>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Fixes: 24b4b67d17c308aa ("add ttyprintk driver")
Link: https://lore.kernel.org/r/17e0652d-89b7-c8c0-fb53-e7566ac9add4@i-love.sakura.ne.jp
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Use 'for_each_child_of_node' instead of hand writing it.
This saves a few line of code.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/eaffe388e6c51e97caf3e8fa474de74428575455.1618920182.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Fixed warning from checkpatch for code block not being indented
correctly.
Signed-off-by: Amos Gross <email@amosgross.com>
Link: https://lore.kernel.org/r/YIAVfRxQ+XmKEf47@arch.localdomain
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The Enable and Linked parameters of _BeaconFunctionEnable are not used.
Remove them.
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Link: https://lore.kernel.org/r/20210419201126.25633-4-martin@kaiser.cx
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
cmdThread is the return value of kthread_run, i.e. a struct task_struct.
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Link: https://lore.kernel.org/r/20210419201126.25633-3-martin@kaiser.cx
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
g_wifi_on is always true. Remove the variable and the code that would
be run only if g_wifi_on was false.
While at it, remove a pointlesss comment that starts with /** and is
misinterpreted as a kernel-doc comment.
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Link: https://lore.kernel.org/r/20210419201126.25633-2-martin@kaiser.cx
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
bLeisurePs is used as a boolean variable. Change its type from
u8 to bool.
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Link: https://lore.kernel.org/r/20210419201126.25633-1-martin@kaiser.cx
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
remove #ifdef block left empty after DBG_871X_LEVEL
deletion.
Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
Link: https://lore.kernel.org/r/c2600c9a71d4e222963cbc600b2e703fe2b1289f.1618480688.git.fabioaiuto83@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
remove unused DBG_871X_LEVEL macro declarations.
DBG_871X_LEVEL macro wraps a raw printk call which is not
recommended in a device driver context, prefer using
netdev_*() log functions.
Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
Link: https://lore.kernel.org/r/ec371fd8a4e53b4730b45f0a1c9210106b2914f2.1618480688.git.fabioaiuto83@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
fix the following post-commit hook checkpatch issue.
WARNING: line length of 103 exceeds 100 columns
30: FILE: drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:711:
+
receive_disconnect(padapter, pmlmeinfo->network.MacAddress, 0);
Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
Link: https://lore.kernel.org/r/4e87fb741205b9f314aec739921405a7ebef908a.1618480688.git.fabioaiuto83@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
fix following post-commit hook checkpatch issues:
WARNING: suspect code indent for conditional statements (32, 48)
323: FILE: drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:708:
if (!ret) {
+
netdev_dbg(padapter->pnetdev,
Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
Link: https://lore.kernel.org/r/7f548510ebe2427e85f3fe8b33ed937160c64e9f.1618480688.git.fabioaiuto83@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
fix following post-commit hook checkpatch issues:
ERROR: code indent should use tabs where possible
887: FILE: drivers/staging/rtl8723bs/os_dep/os_intfs.c:1145:
+^I^I "%s: ### ERROR #### driver in IPS
+ ####ERROR###!!!\n",$
ERROR: code indent should use tabs where possible
888: FILE: drivers/staging/rtl8723bs/os_dep/os_intfs.c:1146:
+^I^I __func__);$
Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
Link: https://lore.kernel.org/r/2e0ba5214df41de7e46b8df4e62d2f38acea92ec.1618480688.git.fabioaiuto83@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Replace DBG_871X_LEVEL logs with netdev_*() functions
where possible (i.e. where a pointer to netdev is easily
available).
This is not possible in correspondance of redundant
log in module initialization.
So remove those ones.
DBG_871X_LEVEL macro wraps a raw printk call which is not
recommended in a device driver context, prefer using
netdev_*() log functions.
The remove/replace operation has been done with the
following semantic patch script:
@@
expression list args;
identifier padapter;
identifier func;
symbol _drv_always_, _drv_info_, _drv_warning_;
symbol _drv_err_, _drv_emerg_;
@@
func(..., struct adapter *padapter, ...) {
<...
(
- DBG_871X_LEVEL(_drv_always_, args);
+ netdev_dbg(padapter->pnetdev, args);
|
- DBG_871X_LEVEL(_drv_info_, args);
+ netdev_info(padapter->pnetdev, args);
|
- DBG_871X_LEVEL(_drv_warning_, args);
+ netdev_warn(padapter->pnetdev, args);
|
- DBG_871X_LEVEL(_drv_err_, args);
+ netdev_err(padapter->pnetdev, args);
|
- DBG_871X_LEVEL(_drv_emerg_, args);
+ netdev_emerg(padapter->pnetdev, args);
)
...>
}
@rule@
identifier func, context, padapter;
@@
func(void *context)
{
...
struct adapter *padapter = context;
...
}
@@
expression list args;
identifier rule.padapter;
identifier rule.func, rule.context;
@@
func(void *context)
{
<...
(
- DBG_871X_LEVEL(_drv_always_, args);
+ netdev_dbg(padapter->pnetdev, args);
|
- DBG_871X_LEVEL(_drv_info_, args);
+ netdev_info(padapter->pnetdev, args);
|
- DBG_871X_LEVEL(_drv_warning_, args);
+ netdev_warn(padapter->pnetdev, args);
|
- DBG_871X_LEVEL(_drv_err_, args);
+ netdev_err(padapter->pnetdev, args);
|
- DBG_871X_LEVEL(_drv_emerg_, args);
+ netdev_emerg(padapter->pnetdev, args);
)
...>
}
@@
expression list args;
expression get_dev;
identifier func, dev;
@@
func(...)
{
...
struct net_device *dev = get_dev;
<...
(
- DBG_871X_LEVEL(_drv_always_, args);
+ netdev_dbg(dev, args);
|
- DBG_871X_LEVEL(_drv_info_, args);
+ netdev_info(dev, args);
|
- DBG_871X_LEVEL(_drv_warning_, args);
+ netdev_warn(dev, args);
|
- DBG_871X_LEVEL(_drv_err_, args);
+ netdev_err(dev, args);
|
- DBG_871X_LEVEL(_drv_emerg_, args);
+ netdev_emerg(dev, args);
)
...>
}
@@
expression list args;
identifier func, dev;
@@
func(struct net_device *dev)
{
<...
(
- DBG_871X_LEVEL(_drv_always_, args);
+ netdev_dbg(dev, args);
|
- DBG_871X_LEVEL(_drv_info_, args);
+ netdev_info(dev, args);
|
- DBG_871X_LEVEL(_drv_warning_, args);
+ netdev_warn(dev, args);
|
- DBG_871X_LEVEL(_drv_err_, args);
+ netdev_err(dev, args);
|
- DBG_871X_LEVEL(_drv_emerg_, args);
+ netdev_emerg(dev, args);
)
...>
}
@@
expression list args;
identifier func, dvobj;
@@
func(struct dvobj_priv *dvobj)
{
<...
(
- DBG_871X_LEVEL(_drv_always_, args);
+ netdev_dbg(dvobj->if1->pnetdev, args);
|
- DBG_871X_LEVEL(_drv_info_, args);
+ netdev_info(dvobj->if1->pnetdev, args);
|
- DBG_871X_LEVEL(_drv_warning_, args);
+ netdev_warn(dvobj->if1->pnetdev, args);
|
- DBG_871X_LEVEL(_drv_err_, args);
+ netdev_err(dvobj->if1->pnetdev, args);
|
- DBG_871X_LEVEL(_drv_emerg_, args);
+ netdev_emerg(dvobj->if1->pnetdev, args);
)
...>
}
@@
@@
- DBG_871X_LEVEL(...);
Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
Link: https://lore.kernel.org/r/4a02f9f5665fa4b78c0b321ce0cc62254255c9dd.1618480688.git.fabioaiuto83@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Indent statement in an else branch. Reported by checkpatch:
WARNING:SUSPECT_CODE_INDENT: suspect code indent for
conditional statements (8, 8)
Signed-off-by: Ian Kewish <iankewish@gmail.com>
Link: https://lore.kernel.org/r/20210415180645.65699-1-iankewish@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
For code readability, the probe() function uses 'dev' variable instead
of '&pdev->dev', so update remaining places.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
The initialization of 'err' local variable is not needed as it is
shortly after overwritten.
Addresses-Coverity: Unused value
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Use of_device_get_match_data() to make the code slightly smaller.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Add a new PCI device entry for Green Sardine APU.
Signed-off-by: Devaraj Rangasamy <Devaraj.Rangasamy@amd.com>
Tested-by: Babulu Ellune <Babulu.Ellune@amd.com>
Signed-off-by: Rijo Thomas <Rijo-john.Thomas@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Since ccp_dev_suspend() and ccp_dev_resume() only return 0 which causes
ret to equal 0 in sp_suspend and sp_resume, making the if condition
impossible to use. it might be a more appropriate fix to have these be
void functions and eliminate the if condition in sp_suspend() and
sp_resume().
Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: John Allen <john.allen@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
OcteonTX2 series of silicons have multiple variants, the
98xx variant has two crypto (CPT0 & CPT1) blocks. This patch
adds support for firmware load on new CPT block(CPT1).
Signed-off-by: Srujana Challa <schalla@marvell.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
kernel version describes module state more accurately.
hence remove chcr versioning.
Signed-off-by: Vinay Kumar Yadav <vinay.yadav@chelsio.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Fix the following coccicheck warning:
./drivers/crypto/ux500/cryp/cryp_p.h:84:6-27:duplicated argument to |
Signed-off-by: Wan Jiabing <wanjiabing@vivo.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Fix the following clang warning:
drivers/crypto/chelsio/chcr_algo.c:129:19: warning: unused function
'is_ofld_imm' [-Wunused-function].
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
The sa2ul module in am64 have limited support for algorithms, and the
priv and priv_id used on the platform is different compared to AM654 or
j721e.
Use match data to get the SoC specific information and use it throughout
the driver.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Vaibhav Gupta <v_gupta@ti.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
On AM64 the DMA channel for sa2ul can be configured to be coherent or
non coherent via DT binding.
Use the dmaengine_get_device_for_dma_api() to get the device pointer which
should be used for with the dma_api to use matching dma_ops for the
channel coherency/non coherency.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Vaibhav Gupta <v_gupta@ti.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
QM adds 'qm_mailbox_timeout' and 'qm_flr_timeout' hardware error types on
Kunpeng930. This patch enables the new error types and configures the error
types as NFE.
Signed-off-by: Weili Qian <qianweili@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Kunpeng930 SEC adds several new hardware error types. This patch enables
the new error types and configures the error types as NFE.
Signed-off-by: Weili Qian <qianweili@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Kunpeng930 ZIP adds 'zip_axi_poison_err' 'zip_sva_err' and
'QM_ACC_DO_TASK_TIMEOUT' hardware error types. This patch enables the error
types and configures the error types as NFE.
Signed-off-by: Weili Qian <qianweili@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
'err_info' does not support dynamic configuration since it is const type.
Therefore, in order to support new error type later, 'err_info' is changed
to dynamic configuration.
Signed-off-by: Weili Qian <qianweili@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
The commit f1b206cf7c57 ("pinctrl: core: print gpio in pins debugfs file")
enabled GPIO pin number and label in debugfs for pin controller. However,
it limited that feature to the chips where base is positive number. This,
in particular, excluded chips where base is 0 for the historical or backward
compatibility reasons. Refactor the code to include the latter as well.
Fixes: f1b206cf7c57 ("pinctrl: core: print gpio in pins debugfs file")
Cc: Drew Fustini <drew@beagleboard.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Drew Fustini <drew@beagleboard.org>
Reviewed-by: Drew Fustini <drew@beagleboard.org>
Link: https://lore.kernel.org/r/20210415130356.15885-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
