greybus-dev February 2022

greybus-dev@lists.linaro.org

31 participants
14 discussions

[PATCH] staging: greybus: Remove redundant 'flush_workqueue()' calls

by cgel.zte＠gmail.com

From: Minghao Chi (CGEL ZTE) <chi.minghao(a)zte.com.cn> 'destroy_workqueue()' already drains the queue before destroying it, so there is no need to flush it explicitly. Remove the redundant 'flush_workqueue()' calls. Reported-by: Zeal Robot <zealci(a)zte.com.cn> Signed-off-by: Minghao Chi (CGEL ZTE) <chi.minghao(a)zte.com.cn> --- drivers/staging/greybus/sdio.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/greybus/sdio.c b/drivers/staging/greybus/sdio.c index 37bf04c22dbc..25bee5335c70 100644 --- a/drivers/staging/greybus/sdio.c +++ b/drivers/staging/greybus/sdio.c @@ -858,7 +858,6 @@ static void gb_sdio_remove(struct gbphy_device *gbphy_dev) gb_connection_set_data(connection, NULL); mutex_unlock(&host->lock); - flush_workqueue(host->mrq_workqueue); destroy_workqueue(host->mrq_workqueue); gb_connection_disable_rx(connection); mmc_remove_host(mmc); -- 2.25.1

2 years, 10 months

[PATCH v2 0/7] Provide and use generic_handle_irq_safe() where appropriate.

by Sebastian Andrzej Siewior

generic_handle_irq() must be used from primary IRQ-handler (chain handler/ interrupt controller entry). It is low level code and the function expects that interrupts are disabled at entry point. This isn't the case for invocations from tasklets, workqueues or the primary interrupt handler on PREEMPT_RT. Once this gets noticed a "local_irq_disable|safe()" is added. To avoid further confusion this series adds generic_handle_irq_safe() which can be used from any context and adds a few user. v2…v1: - Redo kernel-doc for generic_handle_irq_safe() in #1. - Use generic_handle_irq_safe() instead of generic_handle_irq() in the patch description where I accidently used the wrong one. v1: https://lore.kernel.org/all/20220127113303.3012207-1-bigeasy@linutronix.de/ Sebastian

2 years, 10 months

[PATCH 0/3] greybus: svc: fix hello processing

by Johan Hovold

Dan found and fixed a bug in the SVC HELLO request error handling which was introduced when adding a temporary hack to reconfigure the link at HELLO. The implementation of the hack abuses the deferred-request processing mechanism to send the link-configuration request, which makes the HELLO processing a bit hard to follow. The last two patches attempt to remedy this. This could go into either 5.17-rc or -next. Johan Dan Carpenter (1): greybus: svc: fix an error handling bug in gb_svc_hello() Johan Hovold (2): greybus: svc: clean up hello error path greybus: svc: clean up link configuration hack at hello drivers/greybus/svc.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) -- 2.34.1

2 years, 10 months

[PATCH] staging: greybus: fix an error handling bug in gb_svc_hello()

by Dan Carpenter

Cleanup if gb_svc_queue_deferred_request() fails. Fixes: ee2f2074fdb2 ("greybus: svc: reconfig APBridgeA-Switch link to handle required load") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> --- From static analysis. Not tested. drivers/greybus/svc.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/greybus/svc.c b/drivers/greybus/svc.c index ce7740ef449b..b19651048081 100644 --- a/drivers/greybus/svc.c +++ b/drivers/greybus/svc.c @@ -866,8 +866,14 @@ static int gb_svc_hello(struct gb_operation *op) gb_svc_debugfs_init(svc); - return gb_svc_queue_deferred_request(op); + ret = gb_svc_queue_deferred_request(op); + if (ret) + goto remove_debugfs; + + return 0; +remove_debugfs: + gb_svc_debugfs_exit(svc); err_unregister_device: gb_svc_watchdog_destroy(svc); device_del(&svc->dev); -- 2.20.1

2 years, 10 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

greybus-dev February 2022