#
38a523a2 |
|
27-Jun-2022 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
Revert "devcoredump: remove the useless gfp_t parameter in dev_coredumpv and dev_coredumpm" This reverts commit 77515ebaf01920e2db49e04672ef669a7c2907f2 as it causes build problems in linux-next. It needs to be reintroduced in a way that can allow the api to evolve and not require a "flag day" to catch all users. Link: https://lore.kernel.org/r/20220623160723.7a44b573@canb.auug.org.au Cc: Duoming Zhou <duoming@zju.edu.cn> Cc: Brian Norris <briannorris@chromium.org> Cc: Johannes Berg <johannes@sipsolutions.net> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
77515eba |
|
06-Jun-2022 |
Duoming Zhou <duoming@zju.edu.cn> |
devcoredump: remove the useless gfp_t parameter in dev_coredumpv and dev_coredumpm The dev_coredumpv() and dev_coredumpm() could not be used in atomic context, because they call kvasprintf_const() and kstrdup() with GFP_KERNEL parameter. The process is shown below: dev_coredumpv(.., gfp_t gfp) dev_coredumpm(.., gfp_t gfp) dev_set_name kobject_set_name_vargs kvasprintf_const(GFP_KERNEL, ...); //may sleep kstrdup(s, GFP_KERNEL); //may sleep This patch removes gfp_t parameter of dev_coredumpv() and dev_coredumpm() and changes the gfp_t parameter of kzalloc() in dev_coredumpm() to GFP_KERNEL in order to show they could not be used in atomic context. Fixes: 833c95456a70 ("device coredump: add new device coredump class") Reviewed-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Duoming Zhou <duoming@zju.edu.cn> Link: https://lore.kernel.org/r/df72af3b1862bac7d8e793d1f3931857d3779dfd.1654569290.git.duoming@zju.edu.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
1dba745c |
|
22-Jul-2022 |
Marc Kleine-Budde <mkl@pengutronix.de> |
can: mcp251xfd: mcp251xfd_dump(): fix comment The driver uses only 1 TEF and 1 TX ring, but a variable number of RX rings. Fix comment accordingly. Fixes: e0ab3dd5f98f ("can: mcp251xfd: add dev coredump support") Link: https://lore.kernel.org/all/20220726084328.4042678-1-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
#
c912f19e |
|
21-May-2021 |
Marc Kleine-Budde <mkl@pengutronix.de> |
can: mcp251xfd: introduce struct mcp251xfd_tx_ring::nr and ::fifo_nr and make use of it This patch removes the hard coded assumption that the TX ring uses hardware FIFO 1. This allows the hardware FIFO 1 to be used for RX and the next free FIFO for TX. This gives the opportunity to minimize the number of SPI transfers in the IRQ handler. The read of the IRQ status register and RX FIFO status registers can be combined into single SPI transfer. If the RX ring uses FIFO 1, the overall length of the transfer is smaller than in the original layout, where the RX FIFO comes after the TX FIFO. Link: https://lore.kernel.org/all/20220217103826.2299157-2-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
#
e0ab3dd5 |
|
23-Dec-2020 |
Marc Kleine-Budde <mkl@pengutronix.de> |
can: mcp251xfd: add dev coredump support For easier debugging this patch adds dev coredump support to the driver. A dev coredump is generated in case the chip fails to start or an error in the interrupt handler is detected. The dev coredump consists of all chip registers and chip memory, as well as the driver's internal state of the TEF-, RX- and TX-FIFOs, it can be analyzed with the mcp251xfd-dump tool of the can-utils: https://github.com/linux-can/can-utils/tree/master/mcp251xfd Link: https://lore.kernel.org/r/20210304160328.2752293-2-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|