[PATCH 01/23] drm/sun4i: Implement endpoint parsing using kfifo
From: Chen-Yu Tsai <hidden>
Date: 2017-10-17 09:19:32
Also in:
dri-devel, linux-clk, lkml
On Tue, Oct 17, 2017 at 5:06 PM, Maxime Ripard [off-list ref] wrote:
quoted hunk ↗ jump to hunk
The commit da82b8785eeb ("drm/sun4i: add components in breadth first traversal order") implemented a breadth first traversal of our device tree nodes graph. However, it was relying on the kernel linked lists, and those are not really safe for addition. Indeed, in a single pipeline stage, your first stage (ie, the mixer or fronted) will be queued, and it will be the final iteration of that list as far as list_for_each_entry_safe is concerned. Then, during that final iteration, we'll queue another element (the TCON or the backend) that list_for_each_entry_safe will not account for, and we will leave the loop without having iterated over all the elements. And since we won't have built our components list properly, the DRM driver will be left non-functional. We can instead use a kfifo to queue and enqueue components in-order, as was the original intention. This also has the benefit of removing any dynamic allocation, making the error handling path simpler too. The only thing we're losing is the ability to tell whether an element has already been queued, but that was only needed to remove spurious logs, and therefore purely cosmetic. This means that this commit effectively reverses e8afb7b67fba ("drm/sun4i: don't add components that are already in the queue"). Fixes: da82b8785eeb ("drm/sun4i: add components in breadth first traversal order") Signed-off-by: Maxime Ripard <redacted> --- drivers/gpu/drm/sun4i/sun4i_drv.c | 71 +++++--------------------------- 1 file changed, 13 insertions(+), 58 deletions(-)diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c index b5879d4620d8..a27efad9bc76 100644 --- a/drivers/gpu/drm/sun4i/sun4i_drv.c +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c@@ -11,6 +11,7 @@ */ #include <linux/component.h> +#include <linux/kfifo.h> #include <linux/of_graph.h> #include <linux/of_reserved_mem.h>@@ -222,29 +223,15 @@ static int compare_of(struct device *dev, void *data) * matching system handles this for us. */ struct endpoint_list { - struct device_node *node; - struct list_head list; + DECLARE_KFIFO(fifo, struct device_node *, 16); };
Is there any reason to keep using struct endpoint_list, other than to avoid using kfifo in function parameter lists? Otherwise the rest of the code looks sound. Reviewed-by: Chen-Yu Tsai <redacted>