On Sat, 19 Oct 2019, Markus Elfring wrote:

> > Now I would like to point another analysis concern out.
>
> You informed me about an approach for the usage of when constraints
> with the semantic patch language in the following way according to
> the discussion topic “Detection of unused function return values”
> (on 2011-12-11).
>
> “…
> Rule r checks that there is no use on any execution path.
> …”
>
>
> I came along the use case again to work with related information.
> The currently discussed SmPL script variant points also the following
> source code place out for further considerations.
> https://elixir.bootlin.com/linux/v5.4-rc2/source/drivers/gpu/drm/arm/display/komeda/komeda_dev.c#L210
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/arm/display/komeda/komeda_dev.c?id=c4b9850b3676869ac0def5885d781d17f64b3a86#n222
>
> …
> @@ -222,… @@ struct komeda_dev *komeda_dev_create(str
>
>  	clk_prepare_enable(mdev->aclk);
>
> -	mdev->funcs = product->identify(mdev->reg_base, &mdev->chip);
>  	if (!komeda_product_match(mdev, product->product_id)) {
> …
> 	mdev->funcs->init_format_table(mdev);
>
> 	err = mdev->funcs->enum_resources(mdev);
> …
>
>
> Now I would appreciate once more if the description for the supported
> software behaviour can be completed for the safe usage of SmPL
> code exclusion specifications.
> I see that a function pointer is appropriately used here.
> Thus I wonder where my understanding of the software situation around
> the program “spatch” seems still too incomplete.

I have no idea what you are asking about here.  Are you concerned that you
don't know the return type of mdev->funcs->init_format_table?  Coccinelle
has limited access to type information, as it may not be able to find some
relevant header files.  It doesn't even try very hard to find header files
unless you use options such as --all-includes or --recursive-includes,
which will incur a substantial performance overhead.

julia