>> 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.
I hope that our communication difficulties can eventually be reduced also at this place. > Are you concerned that you don't know the return type of > mdev->funcs->init_format_table? No. - It should be clear that this is a member function call, shouldn't it? The used function pointer was set to the return value from a call of the function “product->identify(…)”. Should the subsequent statements (behind the line which was marked by the SmPL asterisk functionality with a minus character) qualify for the desired exclusion of pointer expressions by a SmPL when constraint for the metavariable “y”? Regards, Markus _______________________________________________ Cocci mailing list [email protected] https://systeme.lip6.fr/mailman/listinfo/cocci
