>>> +* to = \(kvmalloc@p\|kvzalloc@p\)(size,\(GFP_KERNEL\|GFP_USER\));
>>> + if (to==NULL || ...) S1
>>> + if (copy_from_user(to, from, size) != 0)
>>> + S2
>>
>> How does the SmPL asterisk functionality fit to the operation
>> modes “org” and “report”?
>
> Make coccicheck uses
> Check that the rule matches vmemdup_user implementation.
> memdup_user is out of scope because we are not matching
> kmalloc_track_caller() function.
I find this change description improvable.
Will it become helpful (for example) to mention that you would like to
add another operation mode?
>
> Don't match original implementations.
I find such a change description insufficient.
Regards,
Markus
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
…
+++ b/scripts/coccinelle/api/memdup_user.cocci
@@ -39,6 +39,28 @@ …
…
> +@depends on patch@
> +expression from,to,size;
> +identifier l1,l2;
> +@@
> +
> +- to = \(kvmalloc\|kvzalloc\)(size,\(GFP_KERNEL\|GFP_USER\));
> ++ to = vmemdup_user(from,size);
I suggest to combine the desired
> Match GFP_USER and optional __GFP_NOWARN allocations with
> memdup_user.cocci rule.
You suggest another interesting software extension.
…
> +++ b/scripts/coccinelle/api/memdup_user.cocci
> @@ -20,7 +20,9 @@ expression from,to,size;
> identifier l1,l2;
> @@
>
> -- to =
> Patches for improving the C parsing of attributes[1] introduced a lot
> redundant code in the C parser. This patch series resolves this by adding
> a rule for optional end attributes and merging the redundant code
> together.
>
> [1]
> [PATCH v2 00/25] cocci: Improve C parsing of attributes
>
> OK, basically I worry about converting a list of 35 000 file names to python.
Can such development concerns be adjusted?
> But maybe it's not a big deal.
Will additional search filters, dependencies and better algorithms improve
the software situation finally?
Regards,
Markus
> > … But I wonder if the difference
> > between "the file is not in the initial list" and "the file is in the
> > initial list but it is ignored" is important for you?
>
> "the file is in the initial list but it is ignored" is ok to me. I don't know
> how to get it.
Which information are you
> > … But I wonder if the difference
> > between "the file is not in the initial list" and "the file is in the
> > initial list but it is ignored" is important for you?
>
> "the file is in the initial list but it is ignored" is ok to me. I don't know
> how to get it.
Which information are you
>> Should the software be able to determine just the amount of script code
>> between the curly brackets?
>
> What if there is a string or comment inside the script code, ant it
> contains only a }?
I suggest to consider corresponding escaping (or quoting) of questionable text.
> Anyway the
> I need a list of all files spatch tries to process.
I am curious about this expectation.
> A list of files in which spatch finds some matches is not enough.
> Otherwise the approach will incorrectly work when cocci script runs on
> a subset of kernel files, e.g.,
> make coccicheck
> > > @r depends on !patch@
> > // It doesn't work. Is it normal?
> > //position p: script:python() { matches.extend(p); relevant(p) };
>
> "Doesn't work" means you get a parse error? The parser of the code inside
> the {} is pretty fragile.
I find such information also interesting.
> Perhaps
> Let us suppose that I want to suppress a couple of matches because they are
> false-positives.
Do you try to avoid the generation of false positives for your source code
analysis?
> However, I still want to check they exists in finalize block and print a
> warning otherwise.
> This is some
>> Coccinelle is not able to optimize its search process
>
> The software contains some limitations which might be changeable.
>
>
>> according to the information in constraints.
>
> Will related solution ideas become more interesting?
I propose to move parts of the mentioned concerns out of the
>> But hiding information that could be apparent to the SmPL compiler
>> and could be used to improve the performance of the matching
>> process is not one of them.
>
> Will any software extensions become possible also in this area?
You pointed out that SmPL disjunctions can trigger specific
>> * A limited search approach was expressed. Will additional source code
>> variations
>> become relevant?
>> + switch statement
>> + if branches with single statements
>> + conditional operator
>
> The point is that there is a kmalloc in one branch and a vmalloc in
> another branch, so
> +@choice@
> +expression E, E1;
> +position kok, vok;
> +@@
> +
> +(
> + if (...) {
> +...
> +E = \(kmalloc@kok\|…\)(...)
Further implementation details from this SmPL script caught my software
development attention.
* Is there a need to add the specification “when any” to the SmPL
> So there are a lot of reasons why constraints are useful.
Thanks for such a view.
Thus I dare to point the possibility out to consider their application
for mentioned function name lists (besides using SmPL disjunctions).
Can coding style concerns be resolved in a more constructive way then?
>>> +E =
>>> \(kmalloc@kok\|kzalloc@kok\|krealloc@kok\|kcalloc@kok\|kmalloc_node@kok\|kzalloc_node@kok\|kmalloc_array@kok\|kmalloc_array_node@kok\|kcalloc_node@kok\)(...)
>>
>> I would prefer an other coding style here.
>>
>> * Items for such SmPL disjunctions can be specified also on
>>> +E =
>>> \(kmalloc@kok\|kzalloc@kok\|krealloc@kok\|kcalloc@kok\|kmalloc_node@kok\|kzalloc_node@kok\|kmalloc_array@kok\|kmalloc_array_node@kok\|kcalloc_node@kok\)(...)
>>
>> I would prefer an other coding style here.
>>
>> * Items for such SmPL disjunctions can be specified also on
> Check that alloc and free types of functions match each other.
Further software development challenges are interesting also for such an use
case.
> +/// Check that kvmalloc'ed memory is freed by kfree functions,
> +/// vmalloc'ed by vfree functions and kvmalloc'ed by kvfree
> +/// functions.
> Is avoiding transforming the case where E is not verified to be a pointer a
> concern?
I imagine that answers to this question have got consequences also on
the confidence level for such SmPL scripts.
The desire and requirement to specify data type restrictions (for expressions)
can influence
> Check for memset()/memset_explicit() with 0 followed by
> kfree()/vfree()/kvfree().
Another software evolution will become interesting here.
> +/// memset_explicit with 0 followed by kfree
How do you think about to extend this comment?
Would you like to take the following SmPL code
> On the other hand, do you really require E to be a pointer?
> If you do that, it will have to find the type of E.
I suggest to reconsider this information.
> If E refers to a structure field, then the type might not be available
> in the current function, and you may need command line
> … when run trough
I hope that a typo will be avoided for the final change description.
Regards,
Markus
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
>>> +virtual context
>>> +virtual org
>>> +virtual report
>>> +virtual patch
>>
>> +virtual context, org, report, patch
>
> This is pointless.
I find the proposed SmPL code variant more succinct.
>> How does the SmPL asterisk functionality fit to the operation
>> modes “org” and “report”?
>
>
> Check for memset() with 0 followed by kfree().
I suggest to simplify the SmPL code a bit like the following.
> +virtual context
> +virtual org
> +virtual report
> +virtual patch
+virtual context, org, report, patch
…
> +@@
> +
> +(
> +* memset(E, 0, ...);
> +|
> +* memset(E, '\0', ...);
>
> subE is a expressionof whatever expression was previously matched to E in
> the rule ifm. <= can only be used when the metavariable on the right side
> is inherited from another rule.
Under which circumstances will a clearer explanation appear also for
software documentation formats besides a
> I'm trying to write a rule to match consecutive function calls. For example:
> @r@
> expression E, E1;
> @@
>
> call_func(E);
> ... when != E = E1
> * call_func(E);
>
> It works well, but not in case "E == p->f" and p is updated in between calls.
> So, I'm to understand how can I avoid these
>> Do you find the following source code search approach helpful for
>> your software development needs?
>
> No.
It is a pity that this SmPL example does still not work in the way
which you expect so far.
> It's the first approach I tried and it didn't match anything anymore;
> I couldn't
> I couldn't find a way to do that from the first rule, so I whitelisted
> send_drop_notify() with a second rule (rule2 below). That seems rather
> cumbersome and I'm wondering if there's maybe a simpler approach?
Do you find the following source code search approach helpful for
your software
> +@rv depends on !patch@
> +expression from,to,size;
> +position p;
> +statement S1,S2;
> +@@
> +
> +* to = \(kvmalloc@p\|kvzalloc@p\)(size,\(GFP_KERNEL\|GFP_USER\));
> + if (to==NULL || ...) S1
> + if (copy_from_user(to, from, size) != 0)
> + S2
How does the SmPL asterisk functionality
> Unfortunately, the Coccinelle software does not like the following
> SmPL code variant so far.
>
> to =
> (
> - \( kmalloc \| kzalloc \)
> + memdup_user
> |
> - \( kvmalloc \| kvzalloc \)
> + vmemdup_user
> )
> (
> - size, \( GFP_KERNEL \|
> Add vmemdup_user() transformations to the memdup_user.cocci rule.
> Commit 50fd2f298bef ("new primitive: vmemdup_user()") introduced
> vmemdup_user(). The function uses kvmalloc with GPF_USER flag.
Such a software evolution is also interesting.
> +@depends on patch@
> +- to =
> Match GFP_USER allocations with memdup_user.cocci rule.
Can this software extension help also for the clarification of the topic
“Safer source code analysis by "memdup_user.cocci"”?
https://github.com/coccinelle/coccinelle/issues/78
Regards,
Markus
…
[1]https://www.mail-archive.com/cocci@systeme.lip6.fr/msg07133.html
…
Would a link variant like the following be safer for the desired information?
[1]:
[RFC PATCH 00/25] cocci: Improve C parsing of attributes
https://systeme.lip6.fr/pipermail/cocci/2020-April/007205.html
> It will call devm_request_irq() after platform_get_irq() function
> in many drivers, sometimes, it is not right for the error handling
> of these two functions in some drivers. so provide this function
> to simplify the driver.
I recommend to improve also this change description.
How do you
> I'm having trouble expressing my smPL to understand the ellipses correctly.
I am curious how the application of scripts for the semantic patch language
will grow according to your software development needs.
> > @@
> > expression L, F;
> > @@
> >
> > - func_old(L, F, ...);
> > + func_old(__func_, ...);
>
> You can't add ... Coccinelle has no idea what it refers to.
The software knows something about the involved source code.
This knowledge can be applied according to the functionality
of the SmPL
> func_old(__func__, "%s: hello: %d, %d", myvar, x, y);
>
> I'm having trouble expressing my smPL to understand the ellipses correctly.
This can be usual.
> Here's what I have so far:
>
> @@
> expression L, F;
> @@
>
> - func_old(L, F, ...);
> + func_old(__func_, ...);
>
> ... but here, things
>>> I already asked above what you expected the ++ code to be attached to.
>>> All added code has to be attached to something.
>>
>> Can the connection to the desired source code position be achieved also
>> by the application of the SmPL ellipsis together with code exclusions?
>
> No.
Do you
>> ;
>> ... when any
>> when != S
>> ++ V2 = E;
>> …
>>> I already asked above what you expected the ++ code to be attached to.
>>> All added code has to be attached to something.
>>
>> Can the connection to the desired source code position be achieved also
>> by the
;
... when any
when != S
++ V2 = E;
…
> I already asked above what you expected the ++ code to be attached to.
> All added code has to be attached to something.
Can the connection to the desired source code position be achieved also
by the application of the SmPL
@movement@
expression E;
identifier V1, V2, Vx;
statement S;
type T1, T2;
@@
T1 V1;
... when any
T2 V2
- = \( <+... Vx ...+> \& E \)
>>>
>>> What is Vx for? He wants an expression that involves a.
>>
>> I chose a slightly more unique
>> @movement@
>> expression E;
>> identifier V1, V2, Vx;
>> statement S;
>> type T1, T2;
>> @@
>> T1 V1;
>> ... when any
>> T2 V2
>> - = \( <+... Vx ...+> \& E \)
>
> What is Vx for? He wants an expression that involves a.
I chose a slightly more unique metavariable identifier for the
> > I am trying to move local variable initialization of some variable to
> > first statement. …
I find such a source code transformation task also interesting.
But it points some software development challenges out also for the safe
application
of the semantic patch language for this use case.
>>> If it is working on a function definition, it works only on that function
>>> definition.
>>
>> Does the position of the define directive influence this view?
>
> I believe that the #defines inside of other top-level definitions are ignored.
I find such a feedback surprising.
It seems that
>> With which SmPL constructs should be ensured that a search pattern
>> like “<+... f(...) ...+>” refers only to content from the same logical
>> source line?
>> https://en.cppreference.com/w/c/language/translation_phases#Phase_2
>
> Please stop asking the same question over and over.
I hope
>> Can the semantic patch language help to insist for a search that a bit
>> of source code belongs to the implementation of a function-like macro?
>
> That's what the search that was written does. The pattern that comes
> after #define has to be in the definition of the macro.
I suggest to
> If the developer forgets the \ there would likely be a parsing problem.
Another information can be helpful then.
elfring@Sonne:~/Projekte/Coccinelle/Probe> spatch --parse-c
INIT_WORK-Test-20200518.c
…
SUSPICIOUS: a \ character appears outside of a #define at
INIT_WORK-Test-20200518.c:4
>> Can the semantic patch language help to insist for a search that a bit
>> of source code belongs to the implementation of a function-like macro?
>
> That's what the search that was written does.
I interpret the example in another way.
*#define mac(...) <+... f(...) ...+>
> The pattern that
>>> If the developer forgets the \ there would likely be a parsing problem.
>>
>> I find it helpful to clarify parsing challenges around such an use case.
>> It might occasionally be relevant if a line continuation indication
>> was accidentally forgotten or was intentionally omitted.
>>
>> *
>> How would (or should) the Coccinelle software handle the mentioned search
>> pattern
>> if such a line continuation indication was omitted between a macro
>> declaration
>> and subsequent source code?
>
> The macro ends at the first line that doesn't end with a \
This is fine.
> If the
>>> @@
>>> identifier mac,f;
>>> @@
>>>
>>> *#define mac(...) <+... f(...) ...+>
>>
>> Does such an analysis approach restrict the source code search really on
>> complete definitions for function-like macros?
>
> Coccinelle knows where the macro ends.
This is good to know.
> A macro has to be
> @@
> identifier mac,f;
> @@
>
> *#define mac(...) <+... f(...) ...+>
Does such an analysis approach restrict the source code search really on
complete definitions for function-like macros?
Will it become interesting for clarify corresponding special cases?
* How are empty macros treated by
> Hence, func_new() reduces the number of arguments to just one
> -- a format string, and variadic arguments.
* Does this wording contain a contradiction?
* Would you like to fiddle with any more variadic functions?
> My question is how would I go about trying to get coccinelle to help me
>
Hello,
The manual for the semantic patch language provides the following information.
https://github.com/coccinelle/coccinelle/blob/7cf2c23e64066d5249a64a316cc5347831f7a63f/docs/manual/cocci_syntax.tex#L1122
…
when ::= when != when_code
…
when_code ::= OPTDOTSEQ(decl_stmt+, when)
> Normally, Coccinelle will match code inside of macro definitions,
> but only if it is able to parse the macro definition,
This is good to know.
> and the ability to parse macro definitions is somewhat limited.
How are the chances to reduce any software limitations in this area?
Regards,
>> @display@
>> @@
>> (dev_err
>> |dev_info
>> ) (
>> *<+... get_device(...) ...+>
>> )
>>
>>
>> Is such a test result worth for further software development considerations?
>
> No.
>
> <+... ...+> as an expression matches a single expression.
How does this information fit
Hello,
I have tried further script variants out for the semantic patch language
(according to the software combination “Coccinelle 1.0.8-00087-g7cf2c23e”).
Source code example:
// SPDX-License-Identifier: GPL-2.0-only
// deleted part
static int sca3000_read_data(struct sca3000_state *st,
> We're only planning to add Coccinelle rules in the future.
I am curious how software extensions will evolve further in this area.
> If we need more complex post-processing,
I imagine that the selection of nicer data structures can occasionally
become more interesting.
> we'll likely
> For the record, I enabled Coccinelle in our CI (GitHub Actions)
> yesterday and worked around that issue with the following script:
>
> make -C bpf/ coccicheck | tee /tmp/stdout
> exit $(grep -c "[prefix of warning messages]" /tmp/stdout)
I propose to improve the data processing approach
> I hoped for another clarification also for the message “warning: iso drop_else
> does not match the code below on line 55” (and the corresponding debug
> display).
I imagine that there is another bit of fine-tuning possible.
>> There is an isomorphism that drops else's in ifs, but that only
>>> In this case, the problem entirely on your side. You should separate the
>>> two top-level declarations into two separate rules, just like any other
>>> two top-level declarations you would like to match.
>>
>> My SmPL script example affects the understanding of the software behaviour
>> also
>> @display@
>> identifier action;
>> type return_type;
>> @@
>> *return_type action(...)
>> {
>> ...
>> }
>> EXPORT_SYMBOL(action);
…
> In this case, the problem entirely on your side. You should separate the
> two top-level declarations into two separate rules, just like any other
> two
>> @display@
>> identifier action;
>> type return_type;
>> @@
>> *return_type action(...)
>> {
>> ...
>> }
>> EXPORT_SYMBOL(action);
>>
>>
>> But I get the following error message so far.
>>
>> elfring@Sonne:~/Projekte/Coccinelle/janitor> spatch --parse-cocci
>> show_exported_functions1.cocci
Hello,
I would like to determine specific information also by the means of another
script for the semantic patch language.
@display@
identifier action;
type return_type;
@@
*return_type action(...)
{
...
}
EXPORT_SYMBOL(action);
But I get the following error message so far.
>> @display@
>> int i;
>> @@
>> return
>> * -i
>> ;
…
>> Why are source code places presented which do not contain a key word
>> I was looking for this test approach?
>
> I don't know. With --debug you can see that there are only two matches.
> So maybe it is a pretty printing problem.
Hello,
I have tried another tiny script out for the semantic patch language
(according to the software combination “Coccinelle 1.0.8-00029-ga549b9f0”).
@display@
int i;
@@
return
* -i
;
Are the following search results worth for further software development
considerations?
>> I suggest to handle the desired search result counter
>> by an other data processing interface.
>> How would you like to treat program execution failures otherwise?
>
> I'm trying to run SmPL programs as part of a CI pipeline, so execution
> failure and (buggy) code pattern not found really
> I am trying to exit spatch with a non-zero exit status when required
> changes have been found.
I got used to the interpretation that a zero exit status
should indicate a successful execution of the program.
> @finalize:python@
> @@
> exit(cnt)
>
> where cnt is incremented by another
> Fixes coccicheck warning:
> ./drivers/net/ethernet/freescale/dpaa/dpaa_eth.c:2110:30-31:
> WARNING comparing pointer to 0
Such information is actually provided by a known script for
the semantic patch language.
>>> These parsing errors were discovered by running a build of
>>> Coccinelle's
>>
>> Would you like to omit the word “These”?
…
> Could you please keep your feedback relevant to the actual patch itself
> (or the commit messages)?
I contributed another review comment also at this place.
>
Hello,
I have tried another small script out for the semantic patch language
(according to the software combination “Coccinelle 1.0.8-00029-ga549b9f0”).
@display@
expression e, x != { PTR_ERR }, y;
statement is, es;
type t;
@@
*e = (t) x(...)
... when != if (<+... e ...+>) is else es
when
> Paramter attributes are added to the C AST.
Please avoid a typo in the first word for this change description.
Regards,
Markus
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
> This also makes sure that the test case unstruct does not break when
> attributes are identified correctly by the C parser.
Would the wording “are correctly identified” be more appropriate?
Regards,
Markus
___
Cocci mailing list
Cocci@systeme.lip6.fr
> A better way of denoting attributes is to pass attribute information
> from SmPL to the C parser.
Such information sounds promising.
> However, a temporary solution is to introduce a MACROANNOTATION hint
> to cpp_token_c.ml so that the parser can identify attributes easily.
Have you got any
> This patch series aims to improve parsing of attributes in C by
> Coccinelle's C parser.
How do you think about to use the wording “in C source code by”?
> These parsing errors were discovered by running a build of Coccinelle's
Would you like to omit the word “These”?
> Coccinelle
> Sorry, I do not know how to use the SmPL script.
I would like to try again to make you more familiar with applications
of the Coccinelle software.
> Please note you are responding to someone who many kernel maintainers,
> myself included, have on their blacklist
You configured your communication filters for some reasons in this way.
> as they are totally unhelpful.
The development views can vary also around my software contributions.
It
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/scripts/coccinelle/free/iounmap.cocci
…
> Sorry, I do not know how to use the SmPL script.
I proposed to take another look at the header of such a file.
I imagine that provided information can trigger further development
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/scripts/coccinelle/free/iounmap.cocci
>>
>> How do you think about to extend presented software analysis approaches?
>>
> Sorry, I am not familiar with it, I don't know.
Do you find the comments helpful at the beginning of
> if do_take_over_console() return an error in the newport_probe(),
> due to the io virtual address is not released, it will cause a leak.
How do you think about a wording variant like the following?
Subject:
[PATCH v2] console: Complete exception handling in newport_probe()
Change
>> @deletion@
>> expression input, storage, target;
>> @@
>> storage
>> -= input
>> ... when != storage
>> target = ...
>>
>>
>> elfring@Sonne:~/Projekte/Coccinelle/janitor> spatch --parse-cocci
>> delete_unused_value4.cocci
>> …
>> the simple assignment expression on line 4 contains
Hello,
I have taken another look at the following information.
https://github.com/coccinelle/coccinelle/blob/6b4bb692f208bfe86e62a616724570d9310c7150/standard.iso#L544
…
// Affectation/initialisation isomorphism
…
// They are handled in engine.
// 'X = Y' should also match 'type X = Y';
…
I
>> But i have to say there are so many code not follow the kernel code-style in
>> amdgpu module.
>> And also the ./scripts/checkpatch.pl did not throw any warning or error.
>
> That is unfortunately true, yes. But we try to push new code through the
> usual code review and improve things as we
>> * How many software implementations use identical type definitions
>> and function-like macros?
>
> I don't know.
Can it become interesting to find more about such usage patterns out?
> For what it's worth, it's valid C. Unless I'm mistaken,
> Coccinelle tries to support as much of C as
>>> * spatch seems to have trouble parsing
>>>
>>> ARMSSE *s = ARMSSE(opaque);
>>>
>>> where ARMSSE is a typedef, and ARMSSE() is a function-like macro.
>>> Yes, I know that's in rather poor taste.
>>
>> I am curious for the safe handling of related software development
>> challenges.
>>
> Another possibility should be taken into account for source code variations.
>
> SmPL script example:
> @replacement@
> expression base, device1, device2, index, private;
> @@
> -private->res = platform_get_resource(device1, IORESOURCE_MEM, index);
> base =
> - devm_ioremap_resource
> +
> use devm_platform_ioremap_resource_byname() to simplify code,
> it contains platform_get_resource_byname() and
> devm_ioremap_resource(), and also remove some duplicate error
> message.
How do you think about a wording variant like the following?
Use the function
>> But I have now lost track of what the semantic patch actually is,
>> so I don't know what is the problem.
Another possibility should be taken into account for source code variations.
SmPL script example:
@replacement@
expression base, device1, device2, index, private;
@@
-private->res =
> But I have now lost track of what the semantic patch actually is,
> so I don't know what is the problem.
Do you find the following transformation approach easier to clarify?
SmPL script:
@replacement@
expression base, device, index, private;
@@
-private->res = platform_get_resource(device,
> OK, it seems that the structure is defined in the same file so no include
> options should be needed. But I have now lost track of what the
> semantic patch actually is, so I don't know what is the problem.
1. Unfortunately, I needed a bit longer to become more aware of relevant
differences
>> Would I need any extra parameters here?
>
> Perhaps -I options to help it find the relevant .h file.
The dependencies for the data structure “device” can become also more
interesting.
https://elixir.bootlin.com/linux/v5.7-rc1/source/include/linux/device.h#L451
>> Would I need any extra parameters here?
>
> Perhaps -I options to help it find the relevant .h file.
I wonder why the relevant header files would not be found directly
from the corresponding Git repository.
Can a file inclusion failure become an immediate SmPL script execution error
when a
> I don't think that there is any need for the * in the metavariable
> declaration.
I can try another SmPL script variant out also without the specification
of an extra asterisk. If I test with the following source file example,
a patch is generated by the Coccinelle software in the expected
>> elfring@Sonne:~/Projekte/Linux/next-patched> spatch
>> --include-headers-for-types
>> ~/Projekte/Coccinelle/janitor/use_devm_platform_get_and_ioremap_resource3.cocci
>> drivers/i2c/busses/i2c-rcar.c
>
> No, include headers for types doesn't have any impact on how many header
> files are
>> @replacement@
>> expression* base, device, resource;
>> @@
>> -resource = platform_get_resource(device, IORESOURCE_MEM, 0);
>> base =
>> - devm_ioremap_resource(>dev, resource)
>> + devm_platform_get_and_ioremap_resource(device, 0, )
>> ;
…
>> static int rcar_i2c_probe(struct
>> static int rcar_i2c_probe(struct platform_device *pdev)
>> {
>> struct rcar_i2c_priv *priv;
…
>> struct device *dev = >dev;
>> // deleted part
>> priv->res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>
>> priv->io = devm_ioremap_resource(dev, priv->res);
…
>> }
…
>
Hello,
I noticed the suggestion “i2c: busses: convert to
devm_platform_get_and_ioremap_resource”.
https://lore.kernel.org/linux-i2c/20200414134827.18674-1-zhengdej...@gmail.com/
https://lore.kernel.org/patchwork/patch/1223734/
I got into the mood to try another script out for the semantic patch
101 - 200 of 1468 matches
Mail list logo
