[cocci] Checking pointer dereferences with SmPL

[cocci] Checking pointer dereferences with SmPL

[Markus Elfring]

Hello,

Script variants for the semantic patch language can help also to take another
look at the usage of various pointers.

Will development interests grow for the avoidance of undefined behaviour?
https://wiki.sei.cmu.edu/confluence/display/c/EXP34-C.+Do+not+dereference+null+pointers

Regards,
Markus

[cocci] Reconsidering pointer dereferences before null pointer checks (with SmPL)

[Markus Elfring]

Hello,

I tried the following SmPL script out also on the source files from
the software “Linux next-20230406”.

@display@
expression action, input, target;
identifier member, var;
type t;
@@
(
*t var = \( &input->member \| action(..., &input->member, ...) \);
 ... when != input
     when any
|
*target = \( &input->member \| action(..., &input->member, ...) \);
 ... when != input
     when any
)
*if (input == NULL || ...)
    return ...;


31 source files were found where it was tried to determine the address of
a data structure member (which includes a pointer dereference)
before a null pointer check.
I imagine that such code should be reconsidered once more and improved accordingly.

How do you think about to achieve any adjustments in this design direction?

Regards,
Markus

Re: [cocci] Reconsidering pointer dereferences before null pointer checks (with SmPL)

[Julia Lawall]

[-- Attachment #1: Type: text/plain, Size: 1046 bytes --]



On Sun, 9 Apr 2023, Markus Elfring wrote:

> Hello,
>
> I tried the following SmPL script out also on the source files from
> the software “Linux next-20230406”.
>
> @display@
> expression action, input, target;
> identifier member, var;
> type t;
> @@
> (
> *t var = \( &input->member \| action(..., &input->member, ...) \);
>  ... when != input
>      when any
> |
> *target = \( &input->member \| action(..., &input->member, ...) \);
>  ... when != input
>      when any
> )
> *if (input == NULL || ...)
>     return ...;
>
>
> 31 source files were found where it was tried to determine the address of
> a data structure member (which includes a pointer dereference)
> before a null pointer check.
> I imagine that such code should be reconsidered once more and improved accordingly.
>
> How do you think about to achieve any adjustments in this design direction?

Setting var to &input->member does not cause any immediate problem.  If
there is a dereference of &input->member that can happen at run time
that would be a problem.

julia

Re: [cocci] Reconsidering pointer dereferences before null pointer checks (with SmPL)

[Markus Elfring]

> Setting var to &input->member does not cause any immediate problem.

Undefined behaviour would be involved if the expression variable “input”
will actually be resolved to a null pointer, wouldn't it?

Some implementation details should be reconsidered if null pointer checks
are occasionally performed a bit too late.
How do you think about to move variable assignments accordingly?

Regards,
Markus

Re: [cocci] Reconsidering pointer dereferences before null pointer checks (with SmPL)

[Julia Lawall]

[-- Attachment #1: Type: text/plain, Size: 326 bytes --]



On Mon, 10 Apr 2023, Markus Elfring wrote:

> > Setting var to &input->member does not cause any immediate problem.
>
> Undefined behaviour would be involved if the expression variable “input”
> will actually be resolved to a null pointer, wouldn't it?

No.  &input->member adds an offset to the address of input.

julia

Re: [cocci] Reconsidering pointer dereferences before null pointer checks (with SmPL)

[Markus Elfring]

>>> Setting var to &input->member does not cause any immediate problem.
>>
>> Undefined behaviour would be involved if the expression variable “input”
>> will actually be resolved to a null pointer, wouldn't it?
>
> No.  &input->member adds an offset to the address of input.

It seems that we represent different development views according to the question
“Does taking address of member variable through a null pointer yield undefined behavior?”.
https://stackoverflow.com/questions/25725286/does-taking-address-of-member-variable-through-a-null-pointer-yield-undefined-be
https://en.cppreference.com/w/c/language/behavior


Regards,
Markus

Re: [cocci] Reconsidering pointer dereferences before null pointer checks (with SmPL)

[Julia Lawall]

[-- Attachment #1: Type: text/plain, Size: 955 bytes --]



On Mon, 10 Apr 2023, Markus Elfring wrote:

> >>> Setting var to &input->member does not cause any immediate problem.
> >>
> >> Undefined behaviour would be involved if the expression variable “input”
> >> will actually be resolved to a null pointer, wouldn't it?
> >
> > No.  &input->member adds an offset to the address of input.
>
> It seems that we represent different development views according to the question
> “Does taking address of member variable through a null pointer yield undefined behavior?”.
> https://stackoverflow.com/questions/25725286/does-taking-address-of-member-variable-through-a-null-pointer-yield-undefined-be
> https://en.cppreference.com/w/c/language/behavior

The statement:

"... &((*ptr).second) which dereferences an object instance pointer"

is not correct.  &((*ptr).second) does not dereference *ptr any more than
&x deferences x.  The semantics of & doesn't work like that.

julia

>
>
> Regards,
> Markus
>

Re: [cocci] Reconsidering pointer dereferences before null pointer checks (with SmPL)

[Markus Elfring]

>> https://stackoverflow.com/questions/25725286/does-taking-address-of-member-variable-through-a-null-pointer-yield-undefined-be
>> https://en.cppreference.com/w/c/language/behavior
>
> The statement:
>
> "... &((*ptr).second) which dereferences an object instance pointer"
>
> is not correct.  &((*ptr).second) does not dereference *ptr any more than
> &x deferences x.  The semantics of & doesn't work like that.

Does the usage of the operator “member access through pointer” (arrow) mean also
a dereference in comparison to the asterisk operator in the C programming language?

Regards,
Markus

Re: [cocci] Reconsidering pointer dereferences before null pointer checks (with SmPL)

[Markus Elfring]

>> Does the usage of the operator “member access through pointer” (arrow) mean also
>> a dereference in comparison to the asterisk operator in the C programming language?
>
> Not when there is a & in front.

Is such an interpretation of programming language specification questionable?


> you can just look at the generated assembly code to see that.

I would like to be more sure about the expected software behaviour
according to programming language standards (than a concrete output
from a selected compiler version).


> The goal of & is to take the address of something,

Usually, yes.

Should null pointers be excluded from “something”?


> not to evaluate the thing.

Does such an expectation fit better to the operator “sizeof”?

Regards,
Markus

Re: [cocci] Reconsidering pointer dereferences before null pointer checks (with SmPL)

[Markus Elfring]

>>>> https://stackoverflow.com/questions/25725286/does-taking-address-of-member-variable-through-a-null-pointer-yield-undefined-be
>>>> https://en.cppreference.com/w/c/language/behavior
>>>
>>> The statement:
>>>
>>> "... &((*ptr).second) which dereferences an object instance pointer"
>>>
>>> is not correct.  &((*ptr).second) does not dereference *ptr any more than
>>> &x deferences x.  The semantics of & doesn't work like that.
>>
>> Does the usage of the operator “member access through pointer” (arrow) mean also
>> a dereference in comparison to the asterisk operator in the C programming language?
>
> Not when there is a & in front.  you can just look at the generated
> assembly code to see that.  The goal of & is to take the address of
> something, not to evaluate the thing.

Would you like to take another look at recent responses by David Svoboda?
https://wiki.sei.cmu.edu/confluence/display/c/EXP34-C.+Do+not+dereference+null+pointers?focusedCommentId=405504153#comment-405504153

Regards,
Markus

Re: [cocci] Reconsidering pointer dereferences before null pointer checks (with SmPL)

[Julia Lawall]

[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]



On Tue, 11 Apr 2023, Markus Elfring wrote:

> >>>> https://stackoverflow.com/questions/25725286/does-taking-address-of-member-variable-through-a-null-pointer-yield-undefined-be
> >>>> https://en.cppreference.com/w/c/language/behavior
> >>>
> >>> The statement:
> >>>
> >>> "... &((*ptr).second) which dereferences an object instance pointer"
> >>>
> >>> is not correct.  &((*ptr).second) does not dereference *ptr any more than
> >>> &x deferences x.  The semantics of & doesn't work like that.
> >>
> >> Does the usage of the operator “member access through pointer” (arrow) mean also
> >> a dereference in comparison to the asterisk operator in the C programming language?
> >
> > Not when there is a & in front.  you can just look at the generated
> > assembly code to see that.  The goal of & is to take the address of
> > something, not to evaluate the thing.
>
> Would you like to take another look at recent responses by David Svoboda?
> https://wiki.sei.cmu.edu/confluence/display/c/EXP34-C.+Do+not+dereference+null+pointers?focusedCommentId=405504153#comment-405504153

His previous comment says that the standard doesn't mention &a->b so it is
a problem.  He is surely more of an expert on the C standard than I am.

julia

Re: [cocci] Reconsidering pointer dereferences before null pointer checks (with SmPL)

[Dan Carpenter]

On Tue, Apr 11, 2023 at 09:40:23AM +0200, Julia Lawall wrote:
> 
> 
> On Tue, 11 Apr 2023, Markus Elfring wrote:
> 
> > >>>> https://stackoverflow.com/questions/25725286/does-taking-address-of-member-variable-through-a-null-pointer-yield-undefined-be
> > >>>> https://en.cppreference.com/w/c/language/behavior
> > >>>
> > >>> The statement:
> > >>>
> > >>> "... &((*ptr).second) which dereferences an object instance pointer"
> > >>>
> > >>> is not correct.  &((*ptr).second) does not dereference *ptr any more than
> > >>> &x deferences x.  The semantics of & doesn't work like that.
> > >>
> > >> Does the usage of the operator “member access through pointer” (arrow) mean also
> > >> a dereference in comparison to the asterisk operator in the C programming language?
> > >
> > > Not when there is a & in front.  you can just look at the generated
> > > assembly code to see that.  The goal of & is to take the address of
> > > something, not to evaluate the thing.
> >
> > Would you like to take another look at recent responses by David Svoboda?
> > https://wiki.sei.cmu.edu/confluence/display/c/EXP34-C.+Do+not+dereference+null+pointers?focusedCommentId=405504153#comment-405504153
> 
> His previous comment says that the standard doesn't mention &a->b so it is
> a problem.  He is surely more of an expert on the C standard than I am.

In the linux-kernel we do a lot of things that are not in the C
standard.  The linux-kernel is written with specific versions of GCC
and Clang in mind.  It's not expected that other compilers will be able
to compile the kernel.

So &a->b is just fine in the linux kernel.

regards,
dan carpenter

Re: [cocci] Reconsidering pointer dereferences before null pointer checks (with SmPL)

[Markus Elfring]

> So &a->b is just fine in the linux kernel.

I find it occasionally nicer and safe to use such an expression only after
special condition checks.
How do you think about to move any misplaced code parts to other places?

Regards,
Markus

[cocci] [PATCH 0/5] drm/amd: Adjustments for three function implementations

Date: Tue, 11 Apr 2023 14:36:36 +0200

Some update suggestions were taken into account
from static source code analysis.

Markus Elfring (5)
  amdgpu: Move a variable assignment behind a null pointer check in amdgpu_ras_interrupt_dispatch()
  display: Move three variable assignments behind condition checks in trigger_hotplug()
  display: Delete three unnecessary variable initialisations in trigger_hotplug()
  display: Delete a redundant statement in trigger_hotplug()
  display: Move an expression into a return statement in dcn201_link_encoder_create()

 drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c       |  3 ++-
 .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 19 ++++++++++---------
 .../amd/display/dc/dcn201/dcn201_resource.c   |  4 +---
 3 files changed, 13 insertions(+), 13 deletions(-)

--
2.40.0

[PATCH 0/5] drm/amd: Adjustments for three function implementations

[Markus Elfring]

Date: Tue, 11 Apr 2023 14:36:36 +0200

Some update suggestions were taken into account
from static source code analysis.

Markus Elfring (5)
  amdgpu: Move a variable assignment behind a null pointer check in amdgpu_ras_interrupt_dispatch()
  display: Move three variable assignments behind condition checks in trigger_hotplug()
  display: Delete three unnecessary variable initialisations in trigger_hotplug()
  display: Delete a redundant statement in trigger_hotplug()
  display: Move an expression into a return statement in dcn201_link_encoder_create()

 drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c       |  3 ++-
 .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 19 ++++++++++---------
 .../amd/display/dc/dcn201/dcn201_resource.c   |  4 +---
 3 files changed, 13 insertions(+), 13 deletions(-)

--
2.40.0

[PATCH 1/5] drm/amdgpu: Move a variable assignment behind a null pointer check in amdgpu_ras_interrupt_dispatch()

[Markus Elfring]

Date: Tue, 11 Apr 2023 10:52:48 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “amdgpu_ras_interrupt_dispatch”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “data” behind the null pointer check.

This issue was detected by using the Coccinelle software.

Fixes: c030f2e4166c3f5597c7e7a70bcd9ab383695de4 ("drm/amdgpu: add amdgpu_ras.c to support ras (v2)")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index 4069bce9479f..a920c7888d07 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
@@ -1730,11 +1730,12 @@ int amdgpu_ras_interrupt_dispatch(struct amdgpu_device *adev,
 		struct ras_dispatch_if *info)
 {
 	struct ras_manager *obj = amdgpu_ras_find_obj(adev, &info->head);
-	struct ras_ih_data *data = &obj->ih_data;
+	struct ras_ih_data *data;

 	if (!obj)
 		return -EINVAL;

+	data = &obj->ih_data;
 	if (data->inuse == 0)
 		return 0;

--
2.40.0

[cocci] [PATCH 1/5] drm/amdgpu: Move a variable assignment behind a null pointer check in amdgpu_ras_interrupt_dispatch()

[Markus Elfring]

Date: Tue, 11 Apr 2023 10:52:48 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “amdgpu_ras_interrupt_dispatch”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “data” behind the null pointer check.

This issue was detected by using the Coccinelle software.

Fixes: c030f2e4166c3f5597c7e7a70bcd9ab383695de4 ("drm/amdgpu: add amdgpu_ras.c to support ras (v2)")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index 4069bce9479f..a920c7888d07 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
@@ -1730,11 +1730,12 @@ int amdgpu_ras_interrupt_dispatch(struct amdgpu_device *adev,
 		struct ras_dispatch_if *info)
 {
 	struct ras_manager *obj = amdgpu_ras_find_obj(adev, &info->head);
-	struct ras_ih_data *data = &obj->ih_data;
+	struct ras_ih_data *data;

 	if (!obj)
 		return -EINVAL;

+	data = &obj->ih_data;
 	if (data->inuse == 0)
 		return 0;

--
2.40.0

Re: [PATCH 1/5] drm/amdgpu: Move a variable assignment behind a null pointer check in amdgpu_ras_interrupt_dispatch()

[Felix Kuehling]

Am 2023-04-11 um 09:42 schrieb Markus Elfring:
> Date: Tue, 11 Apr 2023 10:52:48 +0200
>
> The address of a data structure member was determined before
> a corresponding null pointer check in the implementation of
> the function “amdgpu_ras_interrupt_dispatch”.
>
> Thus avoid the risk for undefined behaviour by moving the assignment
> for the variable “data” behind the null pointer check.
>
> This issue was detected by using the Coccinelle software.
>
> Fixes: c030f2e4166c3f5597c7e7a70bcd9ab383695de4 ("drm/amdgpu: add amdgpu_ras.c to support ras (v2)")
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> index 4069bce9479f..a920c7888d07 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> @@ -1730,11 +1730,12 @@ int amdgpu_ras_interrupt_dispatch(struct amdgpu_device *adev,
>   		struct ras_dispatch_if *info)
>   {
>   	struct ras_manager *obj = amdgpu_ras_find_obj(adev, &info->head);
> -	struct ras_ih_data *data = &obj->ih_data;
> +	struct ras_ih_data *data;
I'm curious, this only takes the address of obj->ih_data. It doesn't 
dereference the pointer until after the !obj check below. How is this 
undefined behaviour? Is this about the compiler being free to reorder 
stuff for optimization, unaware of the dependency? Is there a link to an 
explanation that could be added to the commit description?

Thanks,
   Felix


>
>   	if (!obj)
>   		return -EINVAL;
>
> +	data = &obj->ih_data;
>   	if (data->inuse == 0)
>   		return 0;
>
> --
> 2.40.0
>

Re: [cocci] [PATCH 1/5] drm/amdgpu: Move a variable assignment behind a null pointer check in amdgpu_ras_interrupt_dispatch()

[Markus Elfring]

>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
>> @@ -1730,11 +1730,12 @@ int amdgpu_ras_interrupt_dispatch(struct amdgpu_device *adev,
>>           struct ras_dispatch_if *info)
>>   {
>>       struct ras_manager *obj = amdgpu_ras_find_obj(adev, &info->head);
>> -    struct ras_ih_data *data = &obj->ih_data;
>> +    struct ras_ih_data *data;
> I'm curious, this only takes the address of obj->ih_data.

Even if a null pointer would accidentally be returned by a call of
the function “amdgpu_ras_find_obj”?
https://elixir.bootlin.com/linux/v6.3-rc6/source/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c#L618


> It doesn't dereference the pointer until after the !obj check below.

Does the used arrow operator indicate a pointer dereference?


> How is this undefined behaviour?

I guess that another information source can be helpful for such an issue.
https://wiki.sei.cmu.edu/confluence/display/c/EXP34-C.+Do+not+dereference+null+pointers?focusedCommentId=405504153#comment-405504153

Regards,
Markus

Re: [PATCH 1/5] drm/amdgpu: Move a variable assignment behind a null pointer check in amdgpu_ras_interrupt_dispatch()

[Markus Elfring]

>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
>> @@ -1730,11 +1730,12 @@ int amdgpu_ras_interrupt_dispatch(struct amdgpu_device *adev,
>>           struct ras_dispatch_if *info)
>>   {
>>       struct ras_manager *obj = amdgpu_ras_find_obj(adev, &info->head);
>> -    struct ras_ih_data *data = &obj->ih_data;
>> +    struct ras_ih_data *data;
> I'm curious, this only takes the address of obj->ih_data.

Even if a null pointer would accidentally be returned by a call of
the function “amdgpu_ras_find_obj”?
https://elixir.bootlin.com/linux/v6.3-rc6/source/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c#L618


> It doesn't dereference the pointer until after the !obj check below.

Does the used arrow operator indicate a pointer dereference?


> How is this undefined behaviour?

I guess that another information source can be helpful for such an issue.
https://wiki.sei.cmu.edu/confluence/display/c/EXP34-C.+Do+not+dereference+null+pointers?focusedCommentId=405504153#comment-405504153

Regards,
Markus

[cocci] [PATCH 2/5] drm/amd/display: Move three variable assignments behind condition checks in trigger_hotplug()

[Markus Elfring]

Date: Tue, 11 Apr 2023 11:39:02 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “trigger_hotplug”.

Thus avoid the risk for undefined behaviour by moving the assignment
for three local variables behind some condition checks.

This issue was detected by using the Coccinelle software.

Fixes: 6f77b2ac628073f647041a92b36c824ae3aef16e ("drm/amd/display: Add connector HPD trigger debugfs entry")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c  | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index 827fcb4fb3b3..b3cfd7dfbb28 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -1205,10 +1205,10 @@ static ssize_t trigger_hotplug(struct file *f, const char __user *buf,
 							size_t size, loff_t *pos)
 {
 	struct amdgpu_dm_connector *aconnector = file_inode(f)->i_private;
-	struct drm_connector *connector = &aconnector->base;
+	struct drm_connector *connector;
 	struct dc_link *link = NULL;
-	struct drm_device *dev = connector->dev;
-	struct amdgpu_device *adev = drm_to_adev(dev);
+	struct drm_device *dev;
+	struct amdgpu_device *adev;
 	enum dc_connection_type new_connection_type = dc_connection_none;
 	char *wr_buf = NULL;
 	uint32_t wr_buf_size = 42;
@@ -1253,12 +1253,16 @@ static ssize_t trigger_hotplug(struct file *f, const char __user *buf,
 		return -EINVAL;
 	}

+	connector = &aconnector->base;
+	dev = connector->dev;
+
 	if (param[0] == 1) {

 		if (!dc_link_detect_connection_type(aconnector->dc_link, &new_connection_type) &&
 			new_connection_type != dc_connection_none)
 			goto unlock;

+		adev = drm_to_adev(dev);
 		mutex_lock(&adev->dm.dc_lock);
 		ret = dc_link_detect(aconnector->dc_link, DETECT_REASON_HPD);
 		mutex_unlock(&adev->dm.dc_lock);
--
2.40.0

[PATCH 2/5] drm/amd/display: Move three variable assignments behind condition checks in trigger_hotplug()

[Markus Elfring]

Date: Tue, 11 Apr 2023 11:39:02 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “trigger_hotplug”.

Thus avoid the risk for undefined behaviour by moving the assignment
for three local variables behind some condition checks.

This issue was detected by using the Coccinelle software.

Fixes: 6f77b2ac628073f647041a92b36c824ae3aef16e ("drm/amd/display: Add connector HPD trigger debugfs entry")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c  | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index 827fcb4fb3b3..b3cfd7dfbb28 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -1205,10 +1205,10 @@ static ssize_t trigger_hotplug(struct file *f, const char __user *buf,
 							size_t size, loff_t *pos)
 {
 	struct amdgpu_dm_connector *aconnector = file_inode(f)->i_private;
-	struct drm_connector *connector = &aconnector->base;
+	struct drm_connector *connector;
 	struct dc_link *link = NULL;
-	struct drm_device *dev = connector->dev;
-	struct amdgpu_device *adev = drm_to_adev(dev);
+	struct drm_device *dev;
+	struct amdgpu_device *adev;
 	enum dc_connection_type new_connection_type = dc_connection_none;
 	char *wr_buf = NULL;
 	uint32_t wr_buf_size = 42;
@@ -1253,12 +1253,16 @@ static ssize_t trigger_hotplug(struct file *f, const char __user *buf,
 		return -EINVAL;
 	}

+	connector = &aconnector->base;
+	dev = connector->dev;
+
 	if (param[0] == 1) {

 		if (!dc_link_detect_connection_type(aconnector->dc_link, &new_connection_type) &&
 			new_connection_type != dc_connection_none)
 			goto unlock;

+		adev = drm_to_adev(dev);
 		mutex_lock(&adev->dm.dc_lock);
 		ret = dc_link_detect(aconnector->dc_link, DETECT_REASON_HPD);
 		mutex_unlock(&adev->dm.dc_lock);
--
2.40.0

Re: [PATCH 2/5] drm/amd/display: Move three variable assignments behind condition checks in trigger_hotplug()

[Christian König]

Am 11.04.23 um 15:43 schrieb Markus Elfring:
> Date: Tue, 11 Apr 2023 11:39:02 +0200
>
> The address of a data structure member was determined before
> a corresponding null pointer check in the implementation of
> the function “trigger_hotplug”.
>
> Thus avoid the risk for undefined behaviour by moving the assignment
> for three local variables behind some condition checks.

It might be that the NULL check doesn't make sense in the first place, 
but since I'm not an expert for this code I can't fully judge.

On the other hand the patches clearly look like nice cleanups to me, so 
feel free to add an Acked-by: Christian König <christian.koenig@amd.com> 
to the series.

Thanks,
Christian.

>
> This issue was detected by using the Coccinelle software.
>
> Fixes: 6f77b2ac628073f647041a92b36c824ae3aef16e ("drm/amd/display: Add connector HPD trigger debugfs entry")
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
>   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c  | 10 +++++++---
>   1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> index 827fcb4fb3b3..b3cfd7dfbb28 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> @@ -1205,10 +1205,10 @@ static ssize_t trigger_hotplug(struct file *f, const char __user *buf,
>   							size_t size, loff_t *pos)
>   {
>   	struct amdgpu_dm_connector *aconnector = file_inode(f)->i_private;
> -	struct drm_connector *connector = &aconnector->base;
> +	struct drm_connector *connector;
>   	struct dc_link *link = NULL;
> -	struct drm_device *dev = connector->dev;
> -	struct amdgpu_device *adev = drm_to_adev(dev);
> +	struct drm_device *dev;
> +	struct amdgpu_device *adev;
>   	enum dc_connection_type new_connection_type = dc_connection_none;
>   	char *wr_buf = NULL;
>   	uint32_t wr_buf_size = 42;
> @@ -1253,12 +1253,16 @@ static ssize_t trigger_hotplug(struct file *f, const char __user *buf,
>   		return -EINVAL;
>   	}
>
> +	connector = &aconnector->base;
> +	dev = connector->dev;
> +
>   	if (param[0] == 1) {
>
>   		if (!dc_link_detect_connection_type(aconnector->dc_link, &new_connection_type) &&
>   			new_connection_type != dc_connection_none)
>   			goto unlock;
>
> +		adev = drm_to_adev(dev);
>   		mutex_lock(&adev->dm.dc_lock);
>   		ret = dc_link_detect(aconnector->dc_link, DETECT_REASON_HPD);
>   		mutex_unlock(&adev->dm.dc_lock);
> --
> 2.40.0
>

Re: [PATCH 2/5] drm/amd/display: Move three variable assignments behind condition checks in trigger_hotplug()

[Christian König]

Am 11.04.23 um 15:43 schrieb Markus Elfring:
> Date: Tue, 11 Apr 2023 11:39:02 +0200
>
> The address of a data structure member was determined before
> a corresponding null pointer check in the implementation of
> the function “trigger_hotplug”.
>
> Thus avoid the risk for undefined behaviour by moving the assignment
> for three local variables behind some condition checks.

It might be that the NULL check doesn't make sense in the first place, 
but since I'm not an expert for this code I can't fully judge.

On the other hand the patches clearly look like nice cleanups to me, so 
feel free to add an Acked-by: Christian König <christian.koenig@amd.com> 
to the series.

Thanks,
Christian.

>
> This issue was detected by using the Coccinelle software.
>
> Fixes: 6f77b2ac628073f647041a92b36c824ae3aef16e ("drm/amd/display: Add connector HPD trigger debugfs entry")
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
>   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c  | 10 +++++++---
>   1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> index 827fcb4fb3b3..b3cfd7dfbb28 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> @@ -1205,10 +1205,10 @@ static ssize_t trigger_hotplug(struct file *f, const char __user *buf,
>   							size_t size, loff_t *pos)
>   {
>   	struct amdgpu_dm_connector *aconnector = file_inode(f)->i_private;
> -	struct drm_connector *connector = &aconnector->base;
> +	struct drm_connector *connector;
>   	struct dc_link *link = NULL;
> -	struct drm_device *dev = connector->dev;
> -	struct amdgpu_device *adev = drm_to_adev(dev);
> +	struct drm_device *dev;
> +	struct amdgpu_device *adev;
>   	enum dc_connection_type new_connection_type = dc_connection_none;
>   	char *wr_buf = NULL;
>   	uint32_t wr_buf_size = 42;
> @@ -1253,12 +1253,16 @@ static ssize_t trigger_hotplug(struct file *f, const char __user *buf,
>   		return -EINVAL;
>   	}
>
> +	connector = &aconnector->base;
> +	dev = connector->dev;
> +
>   	if (param[0] == 1) {
>
>   		if (!dc_link_detect_connection_type(aconnector->dc_link, &new_connection_type) &&
>   			new_connection_type != dc_connection_none)
>   			goto unlock;
>
> +		adev = drm_to_adev(dev);
>   		mutex_lock(&adev->dm.dc_lock);
>   		ret = dc_link_detect(aconnector->dc_link, DETECT_REASON_HPD);
>   		mutex_unlock(&adev->dm.dc_lock);
> --
> 2.40.0
>

Re: [cocci] [PATCH 2/5] drm/amd/display: Move three variable assignments behind condition checks in trigger_hotplug()

[Markus Elfring]

>> The address of a data structure member was determined before
>> a corresponding null pointer check in the implementation of
>> the function “trigger_hotplug”.
>>
>> Thus avoid the risk for undefined behaviour by moving the assignment
>> for three local variables behind some condition checks.
>
> It might be that the NULL check doesn't make sense in the first place, but since I'm not an expert for this code I can't fully judge.

Will the source code and patch review evolve any more?


> On the other hand the patches clearly look like nice cleanups to me, so feel free to add an Acked-by: Christian König <christian.koenig@amd.com> to the series.

Will such a positive feedback trigger any further collateral evolution?

Regards,
Markus

Re: [PATCH 2/5] drm/amd/display: Move three variable assignments behind condition checks in trigger_hotplug()

[Markus Elfring]

>> The address of a data structure member was determined before
>> a corresponding null pointer check in the implementation of
>> the function “trigger_hotplug”.
>>
>> Thus avoid the risk for undefined behaviour by moving the assignment
>> for three local variables behind some condition checks.
>
> It might be that the NULL check doesn't make sense in the first place, but since I'm not an expert for this code I can't fully judge.

Will the source code and patch review evolve any more?


> On the other hand the patches clearly look like nice cleanups to me, so feel free to add an Acked-by: Christian König <christian.koenig@amd.com> to the series.

Will such a positive feedback trigger any further collateral evolution?

Regards,
Markus

[cocci] [PATCH 3/5] drm/amd/display: Delete three unnecessary variable initialisations in trigger_hotplug()

[Markus Elfring]

Date: Tue, 11 Apr 2023 12:34:42 +0200

The variables “link”, “wr_buf” and “ret” will eventually be set
to appropriate values a bit later.
Thus omit the explicit initialisation at the beginning.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index b3cfd7dfbb28..a37d23a13d7b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -1206,16 +1206,16 @@ static ssize_t trigger_hotplug(struct file *f, const char __user *buf,
 {
 	struct amdgpu_dm_connector *aconnector = file_inode(f)->i_private;
 	struct drm_connector *connector;
-	struct dc_link *link = NULL;
+	struct dc_link *link;
 	struct drm_device *dev;
 	struct amdgpu_device *adev;
 	enum dc_connection_type new_connection_type = dc_connection_none;
-	char *wr_buf = NULL;
+	char *wr_buf;
 	uint32_t wr_buf_size = 42;
 	int max_param_num = 1;
 	long param[1] = {0};
 	uint8_t param_nums = 0;
-	bool ret = false;
+	bool ret;

 	if (!aconnector || !aconnector->dc_link)
 		return -EINVAL;
--
2.40.0

[PATCH 3/5] drm/amd/display: Delete three unnecessary variable initialisations in trigger_hotplug()

[Markus Elfring]

Date: Tue, 11 Apr 2023 12:34:42 +0200

The variables “link”, “wr_buf” and “ret” will eventually be set
to appropriate values a bit later.
Thus omit the explicit initialisation at the beginning.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index b3cfd7dfbb28..a37d23a13d7b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -1206,16 +1206,16 @@ static ssize_t trigger_hotplug(struct file *f, const char __user *buf,
 {
 	struct amdgpu_dm_connector *aconnector = file_inode(f)->i_private;
 	struct drm_connector *connector;
-	struct dc_link *link = NULL;
+	struct dc_link *link;
 	struct drm_device *dev;
 	struct amdgpu_device *adev;
 	enum dc_connection_type new_connection_type = dc_connection_none;
-	char *wr_buf = NULL;
+	char *wr_buf;
 	uint32_t wr_buf_size = 42;
 	int max_param_num = 1;
 	long param[1] = {0};
 	uint8_t param_nums = 0;
-	bool ret = false;
+	bool ret;

 	if (!aconnector || !aconnector->dc_link)
 		return -EINVAL;
--
2.40.0

[cocci] [PATCH 4/5] drm/amd/display: Delete a redundant statement in trigger_hotplug()

[Markus Elfring]

Date: Tue, 11 Apr 2023 13:26:35 +0200

An immediate return is performed by this function after a null pointer
was detected for the member “dc_link” in the data
structure “amdgpu_dm_connector”.
This check was repeated within one if branch.

Thus omit such a redundant statement.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index a37d23a13d7b..4805a482dc49 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -1278,9 +1278,6 @@ static ssize_t trigger_hotplug(struct file *f, const char __user *buf,

 		drm_kms_helper_connector_hotplug_event(connector);
 	} else if (param[0] == 0) {
-		if (!aconnector->dc_link)
-			goto unlock;
-
 		link = aconnector->dc_link;

 		if (link->local_sink) {
--
2.40.0



Am 11.04.23 um 15:36 schrieb Markus Elfring:
> Date: Tue, 11 Apr 2023 14:36:36 +0200
>
> Some update suggestions were taken into account
> from static source code analysis.
>
> Markus Elfring (5)
>   amdgpu: Move a variable assignment behind a null pointer check in amdgpu_ras_interrupt_dispatch()
>   display: Move three variable assignments behind condition checks in trigger_hotplug()
>   display: Delete three unnecessary variable initialisations in trigger_hotplug()
>   display: Delete a redundant statement in trigger_hotplug()
>   display: Move an expression into a return statement in dcn201_link_encoder_create()
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c       |  3 ++-
>  .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 19 ++++++++++---------
>  .../amd/display/dc/dcn201/dcn201_resource.c   |  4 +---
>  3 files changed, 13 insertions(+), 13 deletions(-)
>

[PATCH 4/5] drm/amd/display: Delete a redundant statement in trigger_hotplug()

[Markus Elfring]

Date: Tue, 11 Apr 2023 13:26:35 +0200

An immediate return is performed by this function after a null pointer
was detected for the member “dc_link” in the data
structure “amdgpu_dm_connector”.
This check was repeated within one if branch.

Thus omit such a redundant statement.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index a37d23a13d7b..4805a482dc49 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -1278,9 +1278,6 @@ static ssize_t trigger_hotplug(struct file *f, const char __user *buf,

 		drm_kms_helper_connector_hotplug_event(connector);
 	} else if (param[0] == 0) {
-		if (!aconnector->dc_link)
-			goto unlock;
-
 		link = aconnector->dc_link;

 		if (link->local_sink) {
--
2.40.0



Am 11.04.23 um 15:36 schrieb Markus Elfring:
> Date: Tue, 11 Apr 2023 14:36:36 +0200
>
> Some update suggestions were taken into account
> from static source code analysis.
>
> Markus Elfring (5)
>   amdgpu: Move a variable assignment behind a null pointer check in amdgpu_ras_interrupt_dispatch()
>   display: Move three variable assignments behind condition checks in trigger_hotplug()
>   display: Delete three unnecessary variable initialisations in trigger_hotplug()
>   display: Delete a redundant statement in trigger_hotplug()
>   display: Move an expression into a return statement in dcn201_link_encoder_create()
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c       |  3 ++-
>  .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 19 ++++++++++---------
>  .../amd/display/dc/dcn201/dcn201_resource.c   |  4 +---
>  3 files changed, 13 insertions(+), 13 deletions(-)
>

[cocci] [PATCH 5/5] drm/amd/display: Move an expression into a return statement in dcn201_link_encoder_create()

[Markus Elfring]

Date: Tue, 11 Apr 2023 14:04:57 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “dcn201_link_encoder_create”.

Thus avoid the risk for undefined behaviour by moving the usage
of an expression into a return statement.

This issue was detected by using the Coccinelle software.

Fixes: 3f68c01be9a2227de1e190317fe34a6fb835a094 ("drm/amd/display: add cyan_skillfish display support")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/amd/display/dc/dcn201/dcn201_resource.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_resource.c b/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_resource.c
index 6ea70da28aaa..a1b44c7bd34b 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_resource.c
@@ -791,7 +791,6 @@ static struct link_encoder *dcn201_link_encoder_create(
 {
 	struct dcn20_link_encoder *enc20 =
 		kzalloc(sizeof(struct dcn20_link_encoder), GFP_ATOMIC);
-	struct dcn10_link_encoder *enc10 = &enc20->enc10;

 	if (!enc20)
 		return NULL;
@@ -804,8 +803,7 @@ static struct link_encoder *dcn201_link_encoder_create(
 			&link_enc_hpd_regs[enc_init_data->hpd_source],
 			&le_shift,
 			&le_mask);
-
-	return &enc10->base;
+	return &enc20->enc10.base;
 }

 static struct clock_source *dcn201_clock_source_create(
--
2.40.0

[PATCH 5/5] drm/amd/display: Move an expression into a return statement in dcn201_link_encoder_create()

[Markus Elfring]

Date: Tue, 11 Apr 2023 14:04:57 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “dcn201_link_encoder_create”.

Thus avoid the risk for undefined behaviour by moving the usage
of an expression into a return statement.

This issue was detected by using the Coccinelle software.

Fixes: 3f68c01be9a2227de1e190317fe34a6fb835a094 ("drm/amd/display: add cyan_skillfish display support")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/amd/display/dc/dcn201/dcn201_resource.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_resource.c b/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_resource.c
index 6ea70da28aaa..a1b44c7bd34b 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_resource.c
@@ -791,7 +791,6 @@ static struct link_encoder *dcn201_link_encoder_create(
 {
 	struct dcn20_link_encoder *enc20 =
 		kzalloc(sizeof(struct dcn20_link_encoder), GFP_ATOMIC);
-	struct dcn10_link_encoder *enc10 = &enc20->enc10;

 	if (!enc20)
 		return NULL;
@@ -804,8 +803,7 @@ static struct link_encoder *dcn201_link_encoder_create(
 			&link_enc_hpd_regs[enc_init_data->hpd_source],
 			&le_shift,
 			&le_mask);
-
-	return &enc10->base;
+	return &enc20->enc10.base;
 }

 static struct clock_source *dcn201_clock_source_create(
--
2.40.0

Re: [PATCH 0/5] drm/amd: Adjustments for three function implementations

[Markus Elfring]

> Date: Tue, 11 Apr 2023 14:36:36 +0200
>
> Some update suggestions were taken into account
> from static source code analysis.
>
> Markus Elfring (5)
>   amdgpu: Move a variable assignment behind a null pointer check in amdgpu_ras_interrupt_dispatch()
>   display: Move three variable assignments behind condition checks in trigger_hotplug()
>   display: Delete three unnecessary variable initialisations in trigger_hotplug()
>   display: Delete a redundant statement in trigger_hotplug()
>   display: Move an expression into a return statement in dcn201_link_encoder_create()
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c       |  3 ++-
>  .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 19 ++++++++++---------
>  .../amd/display/dc/dcn201/dcn201_resource.c   |  4 +---
>  3 files changed, 13 insertions(+), 13 deletions(-)

Is this patch series still in review queues?

See also:
https://lore.kernel.org/cocci/2258ce64-2a14-6778-8319-b342b06a1f33@web.de/
https://sympa.inria.fr/sympa/arc/cocci/2023-04/msg00034.html

Regards,
Markus

Re: [PATCH 0/5] drm/amd: Adjustments for three function implementations

[Markus Elfring]

> Date: Tue, 11 Apr 2023 14:36:36 +0200
>
> Some update suggestions were taken into account
> from static source code analysis.
>
> Markus Elfring (5)
>   amdgpu: Move a variable assignment behind a null pointer check in amdgpu_ras_interrupt_dispatch()
>   display: Move three variable assignments behind condition checks in trigger_hotplug()
>   display: Delete three unnecessary variable initialisations in trigger_hotplug()
>   display: Delete a redundant statement in trigger_hotplug()
>   display: Move an expression into a return statement in dcn201_link_encoder_create()
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c       |  3 ++-
>  .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 19 ++++++++++---------
>  .../amd/display/dc/dcn201/dcn201_resource.c   |  4 +---
>  3 files changed, 13 insertions(+), 13 deletions(-)

Is this patch series still in review queues?

See also:
https://lore.kernel.org/cocci/2258ce64-2a14-6778-8319-b342b06a1f33@web.de/
https://sympa.inria.fr/sympa/arc/cocci/2023-04/msg00034.html

Regards,
Markus

Re: [cocci] [PATCH 0/5] drm/amd: Adjustments for three function implementations

[Markus Elfring]

> Date: Tue, 11 Apr 2023 14:36:36 +0200
>
> Some update suggestions were taken into account
> from static source code analysis.
>
> Markus Elfring (5)
>   amdgpu: Move a variable assignment behind a null pointer check in amdgpu_ras_interrupt_dispatch()
>   display: Move three variable assignments behind condition checks in trigger_hotplug()
>   display: Delete three unnecessary variable initialisations in trigger_hotplug()
>   display: Delete a redundant statement in trigger_hotplug()
>   display: Move an expression into a return statement in dcn201_link_encoder_create()
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c       |  3 ++-
>  .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 19 ++++++++++---------
>  .../amd/display/dc/dcn201/dcn201_resource.c   |  4 +---
>  3 files changed, 13 insertions(+), 13 deletions(-)

Is this patch series still in review queues?

See also:
https://lore.kernel.org/cocci/2258ce64-2a14-6778-8319-b342b06a1f33@web.de/
https://sympa.inria.fr/sympa/arc/cocci/2023-04/msg00034.html

Regards,
Markus

[cocci] [PATCH] drm/msm/dpu: Delete a variable initialisation before a null pointer check in two functions

[Markus Elfring]

Date: Tue, 11 Apr 2023 18:24:24 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the functions “dpu_hw_pp_enable_te” and “dpu_hw_pp_get_vsync_info”.

Thus avoid the risk for undefined behaviour by removing extra
initialisations for the variable “c” (also because it was already
reassigned with the same value behind this pointer check).

This issue was detected by using the Coccinelle software.

Fixes: 25fdd5933e4c0f5fe2ea5cd59994f8ac5fbe90ef ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
index 0fcad9760b6f..870ab3ebbc94 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
@@ -176,7 +176,7 @@ static int dpu_hw_pp_enable_te(struct dpu_hw_pingpong *pp, bool enable)
 static int dpu_hw_pp_connect_external_te(struct dpu_hw_pingpong *pp,
 		bool enable_external_te)
 {
-	struct dpu_hw_blk_reg_map *c = &pp->hw;
+	struct dpu_hw_blk_reg_map *c;
 	u32 cfg;
 	int orig;

@@ -221,7 +221,7 @@ static int dpu_hw_pp_get_vsync_info(struct dpu_hw_pingpong *pp,

 static u32 dpu_hw_pp_get_line_count(struct dpu_hw_pingpong *pp)
 {
-	struct dpu_hw_blk_reg_map *c = &pp->hw;
+	struct dpu_hw_blk_reg_map *c;
 	u32 height, init;
 	u32 line = 0xFFFF;

--
2.40.0

[PATCH] drm/msm/dpu: Delete a variable initialisation before a null pointer check in two functions

[Markus Elfring]

Date: Tue, 11 Apr 2023 18:24:24 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the functions “dpu_hw_pp_enable_te” and “dpu_hw_pp_get_vsync_info”.

Thus avoid the risk for undefined behaviour by removing extra
initialisations for the variable “c” (also because it was already
reassigned with the same value behind this pointer check).

This issue was detected by using the Coccinelle software.

Fixes: 25fdd5933e4c0f5fe2ea5cd59994f8ac5fbe90ef ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
index 0fcad9760b6f..870ab3ebbc94 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
@@ -176,7 +176,7 @@ static int dpu_hw_pp_enable_te(struct dpu_hw_pingpong *pp, bool enable)
 static int dpu_hw_pp_connect_external_te(struct dpu_hw_pingpong *pp,
 		bool enable_external_te)
 {
-	struct dpu_hw_blk_reg_map *c = &pp->hw;
+	struct dpu_hw_blk_reg_map *c;
 	u32 cfg;
 	int orig;

@@ -221,7 +221,7 @@ static int dpu_hw_pp_get_vsync_info(struct dpu_hw_pingpong *pp,

 static u32 dpu_hw_pp_get_line_count(struct dpu_hw_pingpong *pp)
 {
-	struct dpu_hw_blk_reg_map *c = &pp->hw;
+	struct dpu_hw_blk_reg_map *c;
 	u32 height, init;
 	u32 line = 0xFFFF;

--
2.40.0

Re: [PATCH] drm/msm/dpu: Delete a variable initialisation before a null pointer check in two functions

[Dmitry Baryshkov]

On 11/04/2023 19:38, Markus Elfring wrote:
> Date: Tue, 11 Apr 2023 18:24:24 +0200
> 
> The address of a data structure member was determined before
> a corresponding null pointer check in the implementation of
> the functions “dpu_hw_pp_enable_te” and “dpu_hw_pp_get_vsync_info”.
> 
> Thus avoid the risk for undefined behaviour by removing extra
> initialisations for the variable “c” (also because it was already
> reassigned with the same value behind this pointer check).
> 
> This issue was detected by using the Coccinelle software.
> 
> Fixes: 25fdd5933e4c0f5fe2ea5cd59994f8ac5fbe90ef ("drm/msm: Add SDM845 DPU support")

Plese follow the format for the Fixes tags and limit the hash to 12 
chars. Proper tag:

Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")

Other than that LGTM.

> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
>   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> index 0fcad9760b6f..870ab3ebbc94 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> @@ -176,7 +176,7 @@ static int dpu_hw_pp_enable_te(struct dpu_hw_pingpong *pp, bool enable)
>   static int dpu_hw_pp_connect_external_te(struct dpu_hw_pingpong *pp,
>   		bool enable_external_te)
>   {
> -	struct dpu_hw_blk_reg_map *c = &pp->hw;
> +	struct dpu_hw_blk_reg_map *c;
>   	u32 cfg;
>   	int orig;
> 
> @@ -221,7 +221,7 @@ static int dpu_hw_pp_get_vsync_info(struct dpu_hw_pingpong *pp,
> 
>   static u32 dpu_hw_pp_get_line_count(struct dpu_hw_pingpong *pp)
>   {
> -	struct dpu_hw_blk_reg_map *c = &pp->hw;
> +	struct dpu_hw_blk_reg_map *c;
>   	u32 height, init;
>   	u32 line = 0xFFFF;
> 
> --
> 2.40.0
> 

-- 
With best wishes
Dmitry

Re: [PATCH] drm/msm/dpu: Delete a variable initialisation before a null pointer check in two functions

[Dmitry Baryshkov]

On 11/04/2023 19:38, Markus Elfring wrote:
> Date: Tue, 11 Apr 2023 18:24:24 +0200
> 
> The address of a data structure member was determined before
> a corresponding null pointer check in the implementation of
> the functions “dpu_hw_pp_enable_te” and “dpu_hw_pp_get_vsync_info”.
> 
> Thus avoid the risk for undefined behaviour by removing extra
> initialisations for the variable “c” (also because it was already
> reassigned with the same value behind this pointer check).
> 
> This issue was detected by using the Coccinelle software.
> 
> Fixes: 25fdd5933e4c0f5fe2ea5cd59994f8ac5fbe90ef ("drm/msm: Add SDM845 DPU support")

Plese follow the format for the Fixes tags and limit the hash to 12 
chars. Proper tag:

Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")

Other than that LGTM.

> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
>   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> index 0fcad9760b6f..870ab3ebbc94 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> @@ -176,7 +176,7 @@ static int dpu_hw_pp_enable_te(struct dpu_hw_pingpong *pp, bool enable)
>   static int dpu_hw_pp_connect_external_te(struct dpu_hw_pingpong *pp,
>   		bool enable_external_te)
>   {
> -	struct dpu_hw_blk_reg_map *c = &pp->hw;
> +	struct dpu_hw_blk_reg_map *c;
>   	u32 cfg;
>   	int orig;
> 
> @@ -221,7 +221,7 @@ static int dpu_hw_pp_get_vsync_info(struct dpu_hw_pingpong *pp,
> 
>   static u32 dpu_hw_pp_get_line_count(struct dpu_hw_pingpong *pp)
>   {
> -	struct dpu_hw_blk_reg_map *c = &pp->hw;
> +	struct dpu_hw_blk_reg_map *c;
>   	u32 height, init;
>   	u32 line = 0xFFFF;
> 
> --
> 2.40.0
> 

-- 
With best wishes
Dmitry

Re: [PATCH] drm/msm/dpu: Delete a variable initialisation before a null pointer check in two functions

[Abhinav Kumar]

On 4/11/2023 9:38 AM, Markus Elfring wrote:
> Date: Tue, 11 Apr 2023 18:24:24 +0200
> 
> The address of a data structure member was determined before
> a corresponding null pointer check in the implementation of
> the functions “dpu_hw_pp_enable_te” and “dpu_hw_pp_get_vsync_info”.
> 
> Thus avoid the risk for undefined behaviour by removing extra
> initialisations for the variable “c” (also because it was already
> reassigned with the same value behind this pointer check).
> 
> This issue was detected by using the Coccinelle software.
> 
> Fixes: 25fdd5933e4c0f5fe2ea5cd59994f8ac5fbe90ef ("drm/msm: Add SDM845 DPU support")

Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")

We usually have 12 chars of the hash. Other than that,

Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>

> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
>   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> index 0fcad9760b6f..870ab3ebbc94 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> @@ -176,7 +176,7 @@ static int dpu_hw_pp_enable_te(struct dpu_hw_pingpong *pp, bool enable)
>   static int dpu_hw_pp_connect_external_te(struct dpu_hw_pingpong *pp,
>   		bool enable_external_te)
>   {
> -	struct dpu_hw_blk_reg_map *c = &pp->hw;
> +	struct dpu_hw_blk_reg_map *c;
>   	u32 cfg;
>   	int orig;
> 
> @@ -221,7 +221,7 @@ static int dpu_hw_pp_get_vsync_info(struct dpu_hw_pingpong *pp,
> 
>   static u32 dpu_hw_pp_get_line_count(struct dpu_hw_pingpong *pp)
>   {
> -	struct dpu_hw_blk_reg_map *c = &pp->hw;
> +	struct dpu_hw_blk_reg_map *c;
>   	u32 height, init;
>   	u32 line = 0xFFFF;
> 
> --
> 2.40.0
> 

Re: [PATCH] drm/msm/dpu: Delete a variable initialisation before a null pointer check in two functions

[Abhinav Kumar]

On 4/11/2023 9:38 AM, Markus Elfring wrote:
> Date: Tue, 11 Apr 2023 18:24:24 +0200
> 
> The address of a data structure member was determined before
> a corresponding null pointer check in the implementation of
> the functions “dpu_hw_pp_enable_te” and “dpu_hw_pp_get_vsync_info”.
> 
> Thus avoid the risk for undefined behaviour by removing extra
> initialisations for the variable “c” (also because it was already
> reassigned with the same value behind this pointer check).
> 
> This issue was detected by using the Coccinelle software.
> 
> Fixes: 25fdd5933e4c0f5fe2ea5cd59994f8ac5fbe90ef ("drm/msm: Add SDM845 DPU support")

Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")

We usually have 12 chars of the hash. Other than that,

Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>

> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
>   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> index 0fcad9760b6f..870ab3ebbc94 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> @@ -176,7 +176,7 @@ static int dpu_hw_pp_enable_te(struct dpu_hw_pingpong *pp, bool enable)
>   static int dpu_hw_pp_connect_external_te(struct dpu_hw_pingpong *pp,
>   		bool enable_external_te)
>   {
> -	struct dpu_hw_blk_reg_map *c = &pp->hw;
> +	struct dpu_hw_blk_reg_map *c;
>   	u32 cfg;
>   	int orig;
> 
> @@ -221,7 +221,7 @@ static int dpu_hw_pp_get_vsync_info(struct dpu_hw_pingpong *pp,
> 
>   static u32 dpu_hw_pp_get_line_count(struct dpu_hw_pingpong *pp)
>   {
> -	struct dpu_hw_blk_reg_map *c = &pp->hw;
> +	struct dpu_hw_blk_reg_map *c;
>   	u32 height, init;
>   	u32 line = 0xFFFF;
> 
> --
> 2.40.0
> 

[cocci] [PATCH] qed: Move a variable assignment behind a null pointer check in two functions

[Markus Elfring]

Date: Tue, 11 Apr 2023 19:33:53 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the functions “qed_ll2_rxq_completion” and “qed_ll2_txq_completion”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the variables “p_rx” and “p_tx” behind the null pointer check.

This issue was detected by using the Coccinelle software.

Fixes: 0a7fb11c23c0fb8f5ad37f285f40348f1ab9ccbd ("qed: Add Light L2 support")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/net/ethernet/qlogic/qed/qed_ll2.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/qlogic/qed/qed_ll2.c b/drivers/net/ethernet/qlogic/qed/qed_ll2.c
index 717a0b3f89bd..941c02fccaaf 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_ll2.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_ll2.c
@@ -346,7 +346,7 @@ static void qed_ll2_txq_flush(struct qed_hwfn *p_hwfn, u8 connection_handle)
 static int qed_ll2_txq_completion(struct qed_hwfn *p_hwfn, void *p_cookie)
 {
 	struct qed_ll2_info *p_ll2_conn = p_cookie;
-	struct qed_ll2_tx_queue *p_tx = &p_ll2_conn->tx_queue;
+	struct qed_ll2_tx_queue *p_tx;
 	u16 new_idx = 0, num_bds = 0, num_bds_in_packet = 0;
 	struct qed_ll2_tx_packet *p_pkt;
 	bool b_last_frag = false;
@@ -356,6 +356,7 @@ static int qed_ll2_txq_completion(struct qed_hwfn *p_hwfn, void *p_cookie)
 	if (!p_ll2_conn)
 		return rc;

+	p_tx = &p_ll2_conn->tx_queue;
 	spin_lock_irqsave(&p_tx->lock, flags);
 	if (p_tx->b_completing_packet) {
 		rc = -EBUSY;
@@ -523,7 +524,7 @@ qed_ll2_rxq_handle_completion(struct qed_hwfn *p_hwfn,
 static int qed_ll2_rxq_completion(struct qed_hwfn *p_hwfn, void *cookie)
 {
 	struct qed_ll2_info *p_ll2_conn = (struct qed_ll2_info *)cookie;
-	struct qed_ll2_rx_queue *p_rx = &p_ll2_conn->rx_queue;
+	struct qed_ll2_rx_queue *p_rx;
 	union core_rx_cqe_union *cqe = NULL;
 	u16 cq_new_idx = 0, cq_old_idx = 0;
 	unsigned long flags = 0;
@@ -532,6 +533,7 @@ static int qed_ll2_rxq_completion(struct qed_hwfn *p_hwfn, void *cookie)
 	if (!p_ll2_conn)
 		return rc;

+	p_rx = &p_ll2_conn->rx_queue;
 	spin_lock_irqsave(&p_rx->lock, flags);

 	if (!QED_LL2_RX_REGISTERED(p_ll2_conn)) {
--
2.40.0

[cocci] [PATCH] ASoC: SOF: topology: Move a variable assignment behind condition checks in sof_dai_load()

[Markus Elfring]

Date: Thu, 13 Apr 2023 13:56:44 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “sof_dai_load”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the local variable “private” behind some condition checks.

This issue was detected by using the Coccinelle software.

Fixes: c5232c0171428f005a3204e1c264231fb5999b28 ("ASoC: SOF: topology: parse and store d0i3_compatible flag")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 sound/soc/sof/topology.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/sound/soc/sof/topology.c b/sound/soc/sof/topology.c
index d3d536b0a8f5..3fffe3826160 100644
--- a/sound/soc/sof/topology.c
+++ b/sound/soc/sof/topology.c
@@ -1680,7 +1680,7 @@ static int sof_dai_load(struct snd_soc_component *scomp, int index,
 	struct snd_sof_dev *sdev = snd_soc_component_get_drvdata(scomp);
 	const struct sof_ipc_pcm_ops *ipc_pcm_ops = sof_ipc_get_ops(sdev, pcm);
 	struct snd_soc_tplg_stream_caps *caps;
-	struct snd_soc_tplg_private *private = &pcm->priv;
+	struct snd_soc_tplg_private *private;
 	struct snd_sof_pcm *spcm;
 	int stream;
 	int ret;
@@ -1716,6 +1716,7 @@ static int sof_dai_load(struct snd_soc_component *scomp, int index,
 	dai_drv->dobj.private = spcm;
 	list_add(&spcm->list, &sdev->pcm_list);

+	private = &pcm->priv;
 	ret = sof_parse_tokens(scomp, spcm, stream_tokens,
 			       ARRAY_SIZE(stream_tokens), private->array,
 			       le32_to_cpu(private->size));
--
2.40.0

[PATCH] ASoC: SOF: topology: Move a variable assignment behind condition checks in sof_dai_load()

[Markus Elfring]

Date: Thu, 13 Apr 2023 13:56:44 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “sof_dai_load”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the local variable “private” behind some condition checks.

This issue was detected by using the Coccinelle software.

Fixes: c5232c0171428f005a3204e1c264231fb5999b28 ("ASoC: SOF: topology: parse and store d0i3_compatible flag")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 sound/soc/sof/topology.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/sound/soc/sof/topology.c b/sound/soc/sof/topology.c
index d3d536b0a8f5..3fffe3826160 100644
--- a/sound/soc/sof/topology.c
+++ b/sound/soc/sof/topology.c
@@ -1680,7 +1680,7 @@ static int sof_dai_load(struct snd_soc_component *scomp, int index,
 	struct snd_sof_dev *sdev = snd_soc_component_get_drvdata(scomp);
 	const struct sof_ipc_pcm_ops *ipc_pcm_ops = sof_ipc_get_ops(sdev, pcm);
 	struct snd_soc_tplg_stream_caps *caps;
-	struct snd_soc_tplg_private *private = &pcm->priv;
+	struct snd_soc_tplg_private *private;
 	struct snd_sof_pcm *spcm;
 	int stream;
 	int ret;
@@ -1716,6 +1716,7 @@ static int sof_dai_load(struct snd_soc_component *scomp, int index,
 	dai_drv->dobj.private = spcm;
 	list_add(&spcm->list, &sdev->pcm_list);

+	private = &pcm->priv;
 	ret = sof_parse_tokens(scomp, spcm, stream_tokens,
 			       ARRAY_SIZE(stream_tokens), private->array,
 			       le32_to_cpu(private->size));
--
2.40.0

[cocci] [PATCH] perf map: Delete two variable initialisations before null pointer checks in sort__sym_from_cmp()

[Markus Elfring]

Date: Thu, 13 Apr 2023 14:46:39 +0200

Addresses of two data structure members were determined before
corresponding null pointer checks in the implementation of
the function “sort__sym_from_cmp”.

Thus avoid the risk for undefined behaviour by removing extra
initialisations for the local variables “from_l” and “from_r”
(also because they were already reassigned with the same value
behind this pointer check).

This issue was detected by using the Coccinelle software.

Fixes: 1b9e97a2a95e4941dcfa968c4b2e04022e9a343e ("perf tools: Fix report -F symbol_from for data without branch info")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 tools/perf/util/sort.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index 80c9960c37e5..f2ffaf90648e 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -1020,8 +1020,7 @@ static int hist_entry__dso_to_filter(struct hist_entry *he, int type,
 static int64_t
 sort__sym_from_cmp(struct hist_entry *left, struct hist_entry *right)
 {
-	struct addr_map_symbol *from_l = &left->branch_info->from;
-	struct addr_map_symbol *from_r = &right->branch_info->from;
+	struct addr_map_symbol *from_l, *from_r;

 	if (!left->branch_info || !right->branch_info)
 		return cmp_null(left->branch_info, right->branch_info);
--
2.40.0

Re: [PATCH] perf map: Delete two variable initialisations before null pointer checks in sort__sym_from_cmp()

[Ian Rogers]

On Thu, Apr 13, 2023 at 6:03 AM Markus Elfring <Markus.Elfring@web.de> wrote:
>
> Date: Thu, 13 Apr 2023 14:46:39 +0200
>
> Addresses of two data structure members were determined before
> corresponding null pointer checks in the implementation of
> the function “sort__sym_from_cmp”.
>
> Thus avoid the risk for undefined behaviour by removing extra
> initialisations for the local variables “from_l” and “from_r”
> (also because they were already reassigned with the same value
> behind this pointer check).
>
> This issue was detected by using the Coccinelle software.
>
> Fixes: 1b9e97a2a95e4941dcfa968c4b2e04022e9a343e ("perf tools: Fix report -F symbol_from for data without branch info")
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>

Acked-by: Ian Rogers <irogers@google.com>

Thanks,
Ian

> ---
>  tools/perf/util/sort.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
> index 80c9960c37e5..f2ffaf90648e 100644
> --- a/tools/perf/util/sort.c
> +++ b/tools/perf/util/sort.c
> @@ -1020,8 +1020,7 @@ static int hist_entry__dso_to_filter(struct hist_entry *he, int type,
>  static int64_t
>  sort__sym_from_cmp(struct hist_entry *left, struct hist_entry *right)
>  {
> -       struct addr_map_symbol *from_l = &left->branch_info->from;
> -       struct addr_map_symbol *from_r = &right->branch_info->from;
> +       struct addr_map_symbol *from_l, *from_r;
>
>         if (!left->branch_info || !right->branch_info)
>                 return cmp_null(left->branch_info, right->branch_info);
> --
> 2.40.0
>

[cocci] [PATCH] tipc: Reduce scope for the variable “fdefq” in tipc_link_tnl_prepare()

[Markus Elfring]

Date: Thu, 13 Apr 2023 17:00:11 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “tipc_link_tnl_prepare”.

Thus avoid the risk for undefined behaviour by moving the definition
for the local variable “fdefq” into an if branch at the end.

This issue was detected by using the Coccinelle software.

Fixes: 58ee86b8c7750a6b67d665a031aa3ff13a9b6863 ("tipc: adapt link failover for new Gap-ACK algorithm")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 net/tipc/link.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/tipc/link.c b/net/tipc/link.c
index b3ce24823f50..5aa645e3cb35 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -1973,7 +1973,6 @@ void tipc_link_create_dummy_tnl_msg(struct tipc_link *l,
 void tipc_link_tnl_prepare(struct tipc_link *l, struct tipc_link *tnl,
 			   int mtyp, struct sk_buff_head *xmitq)
 {
-	struct sk_buff_head *fdefq = &tnl->failover_deferdq;
 	struct sk_buff *skb, *tnlskb;
 	struct tipc_msg *hdr, tnlhdr;
 	struct sk_buff_head *queue = &l->transmq;
@@ -2100,6 +2099,8 @@ void tipc_link_tnl_prepare(struct tipc_link *l, struct tipc_link *tnl,
 	tipc_link_xmit(tnl, &tnlq, xmitq);

 	if (mtyp == FAILOVER_MSG) {
+		struct sk_buff_head *fdefq = &tnl->failover_deferdq;
+
 		tnl->drop_point = l->rcv_nxt;
 		tnl->failover_reasm_skb = l->reasm_buf;
 		l->reasm_buf = NULL;
--
2.40.0

[cocci] [PATCH] gfs2: Move a variable assignment behind a null pointer check in inode_go_dump()

[Markus Elfring]

Date: Thu, 13 Apr 2023 20:54:30 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “inode_go_dump”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “inode” behind the null pointer check.

This issue was detected by using the Coccinelle software.

Fixes: 27a2660f1ef944724956d92e8a312b6da0936fae ("gfs2: Dump nrpages for inodes and their glocks")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 fs/gfs2/glops.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/gfs2/glops.c b/fs/gfs2/glops.c
index b65950e76be5..6e33c8058059 100644
--- a/fs/gfs2/glops.c
+++ b/fs/gfs2/glops.c
@@ -535,12 +535,13 @@ static void inode_go_dump(struct seq_file *seq, struct gfs2_glock *gl,
 			  const char *fs_id_buf)
 {
 	struct gfs2_inode *ip = gl->gl_object;
-	struct inode *inode = &ip->i_inode;
+	struct inode *inode;
 	unsigned long nrpages;

 	if (ip == NULL)
 		return;

+	inode = &ip->i_inode;
 	xa_lock_irq(&inode->i_data.i_pages);
 	nrpages = inode->i_data.nrpages;
 	xa_unlock_irq(&inode->i_data.i_pages);
--
2.40.0

[Cluster-devel] [PATCH] gfs2: Move a variable assignment behind a null pointer check in inode_go_dump()

[Markus Elfring]

Date: Thu, 13 Apr 2023 20:54:30 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function ?inode_go_dump?.

Thus avoid the risk for undefined behaviour by moving the assignment
for the variable ?inode? behind the null pointer check.

This issue was detected by using the Coccinelle software.

Fixes: 27a2660f1ef944724956d92e8a312b6da0936fae ("gfs2: Dump nrpages for inodes and their glocks")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 fs/gfs2/glops.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/gfs2/glops.c b/fs/gfs2/glops.c
index b65950e76be5..6e33c8058059 100644
--- a/fs/gfs2/glops.c
+++ b/fs/gfs2/glops.c
@@ -535,12 +535,13 @@ static void inode_go_dump(struct seq_file *seq, struct gfs2_glock *gl,
 			  const char *fs_id_buf)
 {
 	struct gfs2_inode *ip = gl->gl_object;
-	struct inode *inode = &ip->i_inode;
+	struct inode *inode;
 	unsigned long nrpages;

 	if (ip == NULL)
 		return;

+	inode = &ip->i_inode;
 	xa_lock_irq(&inode->i_data.i_pages);
 	nrpages = inode->i_data.nrpages;
 	xa_unlock_irq(&inode->i_data.i_pages);
--
2.40.0

Re: [PATCH] gfs2: Move a variable assignment behind a null pointer check in inode_go_dump()

[Andreas Gruenbacher]

Hi Markus,

On Thu, Apr 13, 2023 at 9:23 PM Markus Elfring <Markus.Elfring@web.de> wrote:
> Date: Thu, 13 Apr 2023 20:54:30 +0200
>
> The address of a data structure member was determined before
> a corresponding null pointer check in the implementation of
> the function “inode_go_dump”.
>
> Thus avoid the risk for undefined behaviour by moving the assignment
> for the variable “inode” behind the null pointer check.
>
> This issue was detected by using the Coccinelle software.
>
> Fixes: 27a2660f1ef944724956d92e8a312b6da0936fae ("gfs2: Dump nrpages for inodes and their glocks")

Okay, that's a worthwhile cleanup. It doesn't actually fix a bug, so
I'm not going to add a Fixes tag, though.

> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
>  fs/gfs2/glops.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/fs/gfs2/glops.c b/fs/gfs2/glops.c
> index b65950e76be5..6e33c8058059 100644
> --- a/fs/gfs2/glops.c
> +++ b/fs/gfs2/glops.c
> @@ -535,12 +535,13 @@ static void inode_go_dump(struct seq_file *seq, struct gfs2_glock *gl,
>                           const char *fs_id_buf)
>  {
>         struct gfs2_inode *ip = gl->gl_object;
> -       struct inode *inode = &ip->i_inode;
> +       struct inode *inode;
>         unsigned long nrpages;
>
>         if (ip == NULL)
>                 return;
>
> +       inode = &ip->i_inode;
>         xa_lock_irq(&inode->i_data.i_pages);
>         nrpages = inode->i_data.nrpages;
>         xa_unlock_irq(&inode->i_data.i_pages);
> --
> 2.40.0
>

Thanks,
Andreas

[Cluster-devel] [PATCH] gfs2: Move a variable assignment behind a null pointer check in inode_go_dump()

[Andreas Gruenbacher]

Hi Markus,

On Thu, Apr 13, 2023 at 9:23?PM Markus Elfring <Markus.Elfring@web.de> wrote:
> Date: Thu, 13 Apr 2023 20:54:30 +0200
>
> The address of a data structure member was determined before
> a corresponding null pointer check in the implementation of
> the function ?inode_go_dump?.
>
> Thus avoid the risk for undefined behaviour by moving the assignment
> for the variable ?inode? behind the null pointer check.
>
> This issue was detected by using the Coccinelle software.
>
> Fixes: 27a2660f1ef944724956d92e8a312b6da0936fae ("gfs2: Dump nrpages for inodes and their glocks")

Okay, that's a worthwhile cleanup. It doesn't actually fix a bug, so
I'm not going to add a Fixes tag, though.

> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
>  fs/gfs2/glops.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/fs/gfs2/glops.c b/fs/gfs2/glops.c
> index b65950e76be5..6e33c8058059 100644
> --- a/fs/gfs2/glops.c
> +++ b/fs/gfs2/glops.c
> @@ -535,12 +535,13 @@ static void inode_go_dump(struct seq_file *seq, struct gfs2_glock *gl,
>                           const char *fs_id_buf)
>  {
>         struct gfs2_inode *ip = gl->gl_object;
> -       struct inode *inode = &ip->i_inode;
> +       struct inode *inode;
>         unsigned long nrpages;
>
>         if (ip == NULL)
>                 return;
>
> +       inode = &ip->i_inode;
>         xa_lock_irq(&inode->i_data.i_pages);
>         nrpages = inode->i_data.nrpages;
>         xa_unlock_irq(&inode->i_data.i_pages);
> --
> 2.40.0
>

Thanks,
Andreas

[cocci] [PATCH] video: au1100fb: Move a variable assignment behind a null pointer check in au1100fb_setmode()

[Markus Elfring]

Date: Thu, 13 Apr 2023 21:35:36 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “au1100fb_setmode”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “info” behind the null pointer check.

This issue was detected by using the Coccinelle software.

Fixes: 3b495f2bb749b828499135743b9ddec46e34fda8 ("Au1100 FB driver uplift for 2.6.")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/video/fbdev/au1100fb.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/au1100fb.c b/drivers/video/fbdev/au1100fb.c
index cb317398e71a..fcb47b350bc9 100644
--- a/drivers/video/fbdev/au1100fb.c
+++ b/drivers/video/fbdev/au1100fb.c
@@ -137,13 +137,15 @@ static int au1100fb_fb_blank(int blank_mode, struct fb_info *fbi)
 	 */
 int au1100fb_setmode(struct au1100fb_device *fbdev)
 {
-	struct fb_info *info = &fbdev->info;
+	struct fb_info *info;
 	u32 words;
 	int index;

 	if (!fbdev)
 		return -EINVAL;

+	info = &fbdev->info;
+
 	/* Update var-dependent FB info */
 	if (panel_is_active(fbdev->panel) || panel_is_color(fbdev->panel)) {
 		if (info->var.bits_per_pixel <= 8) {
--
2.40.0

[PATCH] video: au1100fb: Move a variable assignment behind a null pointer check in au1100fb_setmode()

[Markus Elfring]

Date: Thu, 13 Apr 2023 21:35:36 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “au1100fb_setmode”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “info” behind the null pointer check.

This issue was detected by using the Coccinelle software.

Fixes: 3b495f2bb749b828499135743b9ddec46e34fda8 ("Au1100 FB driver uplift for 2.6.")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/video/fbdev/au1100fb.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/au1100fb.c b/drivers/video/fbdev/au1100fb.c
index cb317398e71a..fcb47b350bc9 100644
--- a/drivers/video/fbdev/au1100fb.c
+++ b/drivers/video/fbdev/au1100fb.c
@@ -137,13 +137,15 @@ static int au1100fb_fb_blank(int blank_mode, struct fb_info *fbi)
 	 */
 int au1100fb_setmode(struct au1100fb_device *fbdev)
 {
-	struct fb_info *info = &fbdev->info;
+	struct fb_info *info;
 	u32 words;
 	int index;

 	if (!fbdev)
 		return -EINVAL;

+	info = &fbdev->info;
+
 	/* Update var-dependent FB info */
 	if (panel_is_active(fbdev->panel) || panel_is_color(fbdev->panel)) {
 		if (info->var.bits_per_pixel <= 8) {
--
2.40.0

[cocci] [PATCH] media: atomisp: Move a variable assignment behind a null pointer check in atomisp_cp_general_isp_parameters()

[Markus Elfring]

Date: Thu, 13 Apr 2023 22:08:42 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “atomisp_cp_general_isp_parameters”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “cur_config” behind the null pointer check.

This issue was detected by using the Coccinelle software.

Fixes: ad85094b293e40e7a2f831b0311a389d952ebd5e ("Revert 'media: staging: atomisp: Remove driver'")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/staging/media/atomisp/pci/atomisp_cmd.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp_cmd.c b/drivers/staging/media/atomisp/pci/atomisp_cmd.c
index 47f18ac5e40e..733a239b5d8a 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_cmd.c
@@ -2723,11 +2723,13 @@ int atomisp_cp_general_isp_parameters(struct atomisp_sub_device *asd,
 				      struct atomisp_css_params *css_param,
 				      bool from_user)
 {
-	struct atomisp_parameters *cur_config = &css_param->update_flag;
+	struct atomisp_parameters *cur_config;

 	if (!arg || !asd || !css_param)
 		return -EINVAL;

+	cur_config = &css_param->update_flag;
+
 	if (arg->wb_config && (from_user || !cur_config->wb_config)) {
 		if (copy_from_compatible(&css_param->wb_config, arg->wb_config,
 					 sizeof(struct ia_css_wb_config),
--
2.40.0

[PATCH] media: atomisp: Move a variable assignment behind a null pointer check in atomisp_cp_general_isp_parameters()

[Markus Elfring]

Date: Thu, 13 Apr 2023 22:08:42 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “atomisp_cp_general_isp_parameters”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “cur_config” behind the null pointer check.

This issue was detected by using the Coccinelle software.

Fixes: ad85094b293e40e7a2f831b0311a389d952ebd5e ("Revert 'media: staging: atomisp: Remove driver'")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/staging/media/atomisp/pci/atomisp_cmd.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp_cmd.c b/drivers/staging/media/atomisp/pci/atomisp_cmd.c
index 47f18ac5e40e..733a239b5d8a 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_cmd.c
@@ -2723,11 +2723,13 @@ int atomisp_cp_general_isp_parameters(struct atomisp_sub_device *asd,
 				      struct atomisp_css_params *css_param,
 				      bool from_user)
 {
-	struct atomisp_parameters *cur_config = &css_param->update_flag;
+	struct atomisp_parameters *cur_config;

 	if (!arg || !asd || !css_param)
 		return -EINVAL;

+	cur_config = &css_param->update_flag;
+
 	if (arg->wb_config && (from_user || !cur_config->wb_config)) {
 		if (copy_from_compatible(&css_param->wb_config, arg->wb_config,
 					 sizeof(struct ia_css_wb_config),
--
2.40.0

Re: [PATCH] media: atomisp: Move a variable assignment behind a null pointer check in atomisp_cp_general_isp_parameters()

[Andy Shevchenko]

On Thu, Apr 13, 2023 at 10:20:15PM +0200, Markus Elfring wrote:
> Date: Thu, 13 Apr 2023 22:08:42 +0200
> 
> The address of a data structure member was determined before
> a corresponding null pointer check in the implementation of
> the function “atomisp_cp_general_isp_parameters”.
> 
> Thus avoid the risk for undefined behaviour by moving the assignment
> for the variable “cur_config” behind the null pointer check.

I don't think this is what is happening here. The check might be removed by
optimizer in the compiler.

> This issue was detected by using the Coccinelle software.
> 
> Fixes: ad85094b293e40e7a2f831b0311a389d952ebd5e ("Revert 'media: staging: atomisp: Remove driver'")

Wrong tag format.

Code-wise I'm not against this, but it's up to Hans.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] media: atomisp: Move a variable assignment behind a null pointer check in atomisp_cp_general_isp_parameters()

[Hans de Goede]

Hi,

On 4/14/23 19:13, Andy Shevchenko wrote:
> On Thu, Apr 13, 2023 at 10:20:15PM +0200, Markus Elfring wrote:
>> Date: Thu, 13 Apr 2023 22:08:42 +0200
>>
>> The address of a data structure member was determined before
>> a corresponding null pointer check in the implementation of
>> the function “atomisp_cp_general_isp_parameters”.
>>
>> Thus avoid the risk for undefined behaviour by moving the assignment
>> for the variable “cur_config” behind the null pointer check.
> 
> I don't think this is what is happening here. The check might be removed by
> optimizer in the compiler.

Right, Markus thank you for the patch.

Instead of this patch, can you please audit the callers of this
function? I expect that you will likely find that the callers
already unconditionally deref css_param themselves, or they
guarantee a non NULL value in other ways (e.g. address of local
variable).

So I expect that the check can simply be dropped completely,
which would be a much better fix.

Regards,

Hans





> 
>> This issue was detected by using the Coccinelle software.
>>
>> Fixes: ad85094b293e40e7a2f831b0311a389d952ebd5e ("Revert 'media: staging: atomisp: Remove driver'")
> 
> Wrong tag format.
> 
> Code-wise I'm not against this, but it's up to Hans.
> 

Re: [PATCH] media: atomisp: Move a variable assignment behind a null pointer check in atomisp_cp_general_isp_parameters()

[Markus Elfring]

> Instead of this patch, can you please audit the callers of this function?

Did any analysis tool publish a call tree already (according to your enquiry)?
https://elixir.bootlin.com/linux/v6.3-rc6/source/drivers/staging/media/atomisp/pci/atomisp_cmd.c#L2721


> I expect that you will likely find that the callers
> already unconditionally deref css_param themselves, or they
> guarantee a non NULL value in other ways (e.g. address of
> local variable).
>
> So I expect that the check can simply be dropped completely,
> which would be a much better fix.

Are you really looking for ways to omit null pointer checks
for three input parameters here?

Would you like to increase the application of any annotations
or API attributes?

Regards,
Markus

Re: [cocci] [PATCH] media: atomisp: Move a variable assignment behind a null pointer check in atomisp_cp_general_isp_parameters()

[Markus Elfring]

> Instead of this patch, can you please audit the callers of this function?

Did any analysis tool publish a call tree already (according to your enquiry)?
https://elixir.bootlin.com/linux/v6.3-rc6/source/drivers/staging/media/atomisp/pci/atomisp_cmd.c#L2721


> I expect that you will likely find that the callers
> already unconditionally deref css_param themselves, or they
> guarantee a non NULL value in other ways (e.g. address of
> local variable).
>
> So I expect that the check can simply be dropped completely,
> which would be a much better fix.

Are you really looking for ways to omit null pointer checks
for three input parameters here?

Would you like to increase the application of any annotations
or API attributes?

Regards,
Markus

Re: [cocci] media: atomisp: Move a variable assignment behind a null pointer check in atomisp_cp_general_isp_parameters()

[Markus Elfring]

> Instead of this patch, can you please audit the callers of this function?

How will the determination evolve further if null pointer checks would be still
relevant for three input parameters according to this function implementation
at the moment?
https://elixir.bootlin.com/linux/v6.3-rc7/source/drivers/staging/media/atomisp/pci/atomisp_cmd.c#L2721


> I expect that you will likely find that the callers
> already unconditionally deref css_param themselves,
> or they guarantee a non NULL value in other ways
> (e.g. address of local variable).
>
> So I expect that the check can simply be dropped completely,
> which would be a much better fix.

Will affected implementation details be reconsidered any more?

Regards,
Markus

Re: media: atomisp: Move a variable assignment behind a null pointer check in atomisp_cp_general_isp_parameters()

[Markus Elfring]

> Instead of this patch, can you please audit the callers of this function?

How will the determination evolve further if null pointer checks would be still
relevant for three input parameters according to this function implementation
at the moment?
https://elixir.bootlin.com/linux/v6.3-rc7/source/drivers/staging/media/atomisp/pci/atomisp_cmd.c#L2721


> I expect that you will likely find that the callers
> already unconditionally deref css_param themselves,
> or they guarantee a non NULL value in other ways
> (e.g. address of local variable).
>
> So I expect that the check can simply be dropped completely,
> which would be a much better fix.

Will affected implementation details be reconsidered any more?

Regards,
Markus

Re: [cocci] [PATCH] media: atomisp: Move a variable assignment behind a null pointer check in atomisp_cp_general_isp_parameters()

[Markus Elfring]

> Instead of this patch, can you please audit the callers of this function?

Would you like to add any advices for a similarly affected implementation
of the function “atomisp_set_parameters”?
https://elixir.bootlin.com/linux/v6.3-rc7/source/drivers/staging/media/atomisp/pci/atomisp_cmd.c#L3619

Regards,
Markus

Re: [PATCH] media: atomisp: Move a variable assignment behind a null pointer check in atomisp_cp_general_isp_parameters()

[Markus Elfring]

> Instead of this patch, can you please audit the callers of this function?

Would you like to add any advices for a similarly affected implementation
of the function “atomisp_set_parameters”?
https://elixir.bootlin.com/linux/v6.3-rc7/source/drivers/staging/media/atomisp/pci/atomisp_cmd.c#L3619

Regards,
Markus

[cocci] [PATCH] scsi: hpsa: Move two variable assignments behind condition checks in hpsa_scsi_ioaccel_raid_map()

[Markus Elfring]

Date: Fri, 14 Apr 2023 11:00:40 +0200

Addresses of two data structure members were determined before
a corresponding null pointer check in the implementation of
the function “hpsa_scsi_ioaccel_raid_map”.

Thus avoid the risk for undefined behaviour by moving the assignment
for two local variables behind some condition checks.

This issue was detected by using the Coccinelle software.

Fixes: 283b4a9b98b192ebc0e15351fd6fb60e1be78c5d ("[SCSI] hpsa: add ioaccell mode 1 RAID offload support.")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/scsi/hpsa.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index af18d20f3079..562bb5eab134 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -5104,8 +5104,8 @@ static int hpsa_scsi_ioaccel_raid_map(struct ctlr_info *h,
 {
 	struct scsi_cmnd *cmd = c->scsi_cmd;
 	struct hpsa_scsi_dev_t *dev = cmd->device->hostdata;
-	struct raid_map_data *map = &dev->raid_map;
-	struct raid_map_disk_data *dd = &map->data[0];
+	struct raid_map_data *map;
+	struct raid_map_disk_data *dd;
 	int is_write = 0;
 	u32 map_index;
 	u64 first_block, last_block;
@@ -5209,6 +5209,8 @@ static int hpsa_scsi_ioaccel_raid_map(struct ctlr_info *h,
 	if (is_write && dev->raid_level != 0)
 		return IO_ACCEL_INELIGIBLE;

+	map = &dev->raid_map;
+
 	/* check for invalid block or wraparound */
 	if (last_block >= le64_to_cpu(map->volume_blk_cnt) ||
 		last_block < first_block)
@@ -5397,6 +5399,7 @@ static int hpsa_scsi_ioaccel_raid_map(struct ctlr_info *h,
 	if (!c->phys_disk)
 		return IO_ACCEL_INELIGIBLE;

+	dd = &map->data[0];
 	disk_handle = dd[map_index].ioaccel_handle;
 	disk_block = le64_to_cpu(map->disk_starting_blk) +
 			first_row * le16_to_cpu(map->strip_size) +
--
2.40.0

[PATCH] nvdimm: Replace the usage of a variable by a direct function call in nd_pfn_validate()

[Markus Elfring]

Date: Fri, 14 Apr 2023 12:01:15 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “nd_pfn_validate”.

Thus avoid the risk for undefined behaviour by replacing the usage of
the local variable “parent_uuid” by a direct function call within
a later condition check.

This issue was detected by using the Coccinelle software.

Fixes: d1c6e08e7503649e4a4f3f9e700e2c05300b6379 ("libnvdimm/labels: Add uuid helpers")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/nvdimm/pfn_devs.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/nvdimm/pfn_devs.c b/drivers/nvdimm/pfn_devs.c
index af7d9301520c..f14cbfa500ed 100644
--- a/drivers/nvdimm/pfn_devs.c
+++ b/drivers/nvdimm/pfn_devs.c
@@ -456,7 +456,6 @@ int nd_pfn_validate(struct nd_pfn *nd_pfn, const char *sig)
 	unsigned long align, start_pad;
 	struct nd_pfn_sb *pfn_sb = nd_pfn->pfn_sb;
 	struct nd_namespace_common *ndns = nd_pfn->ndns;
-	const uuid_t *parent_uuid = nd_dev_to_uuid(&ndns->dev);

 	if (!pfn_sb || !ndns)
 		return -ENODEV;
@@ -476,7 +475,7 @@ int nd_pfn_validate(struct nd_pfn *nd_pfn, const char *sig)
 		return -ENODEV;
 	pfn_sb->checksum = cpu_to_le64(checksum);

-	if (memcmp(pfn_sb->parent_uuid, parent_uuid, 16) != 0)
+	if (memcmp(pfn_sb->parent_uuid, nd_dev_to_uuid(&ndns->dev), 16) != 0)
 		return -ENODEV;

 	if (__le16_to_cpu(pfn_sb->version_minor) < 1) {
--
2.40.0

[cocci] [PATCH] nvdimm: Replace the usage of a variable by a direct function call in nd_pfn_validate()

[Markus Elfring]

Date: Fri, 14 Apr 2023 12:01:15 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “nd_pfn_validate”.

Thus avoid the risk for undefined behaviour by replacing the usage of
the local variable “parent_uuid” by a direct function call within
a later condition check.

This issue was detected by using the Coccinelle software.

Fixes: d1c6e08e7503649e4a4f3f9e700e2c05300b6379 ("libnvdimm/labels: Add uuid helpers")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/nvdimm/pfn_devs.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/nvdimm/pfn_devs.c b/drivers/nvdimm/pfn_devs.c
index af7d9301520c..f14cbfa500ed 100644
--- a/drivers/nvdimm/pfn_devs.c
+++ b/drivers/nvdimm/pfn_devs.c
@@ -456,7 +456,6 @@ int nd_pfn_validate(struct nd_pfn *nd_pfn, const char *sig)
 	unsigned long align, start_pad;
 	struct nd_pfn_sb *pfn_sb = nd_pfn->pfn_sb;
 	struct nd_namespace_common *ndns = nd_pfn->ndns;
-	const uuid_t *parent_uuid = nd_dev_to_uuid(&ndns->dev);

 	if (!pfn_sb || !ndns)
 		return -ENODEV;
@@ -476,7 +475,7 @@ int nd_pfn_validate(struct nd_pfn *nd_pfn, const char *sig)
 		return -ENODEV;
 	pfn_sb->checksum = cpu_to_le64(checksum);

-	if (memcmp(pfn_sb->parent_uuid, parent_uuid, 16) != 0)
+	if (memcmp(pfn_sb->parent_uuid, nd_dev_to_uuid(&ndns->dev), 16) != 0)
 		return -ENODEV;

 	if (__le16_to_cpu(pfn_sb->version_minor) < 1) {
--
2.40.0

Re: [PATCH] nvdimm: Replace the usage of a variable by a direct function call in nd_pfn_validate()

[Alison Schofield]

On Fri, Apr 14, 2023 at 12:12:37PM +0200, Markus Elfring wrote:
> Date: Fri, 14 Apr 2023 12:01:15 +0200
> 
> The address of a data structure member was determined before
> a corresponding null pointer check in the implementation of
> the function “nd_pfn_validate”.
> 
> Thus avoid the risk for undefined behaviour by replacing the usage of
> the local variable “parent_uuid” by a direct function call within
> a later condition check.

Hi Markus,

I think I understand what you are saying above, but I don't follow
how that applies here. This change seems to be a nice simplification,
parent_uuid, is used once, just grab it when needed.

What is the risk of undefined behavior?

> 
> This issue was detected by using the Coccinelle software.
Which cocci script?

> 
> Fixes: d1c6e08e7503649e4a4f3f9e700e2c05300b6379 ("libnvdimm/labels: Add uuid helpers")

This fixes tag seems to be the wrong tag. It is a tag from when the
uuid helpers were introduce, not where parent_uuid was first introduced
and used. I'm not clear this warrants a Fixes tag anyway. Is there
really a bug here? Perhaps I'm missing something in the previous
explanation of risk.

checkpatch is WARNING on the tag format:
WARNING: Please use correct Fixes: style 'Fixes: <12 chars of sha1> ("<title line>")' - ie: 'Fixes: d1c6e08e7503 ("libnvdimm/labels: Add uuid helpers")'
#17:
    Fixes: d1c6e08e7503649e4a4f3f9e700e2c05300b6379 ("libnvdimm/labels: Add uuid helpers")

checkpatch is also WARNING on the commit msg:
WARNING: Possible unwrapped commit description (prefer a maximum 75 chars per line)
#5:
    nvdimm: Replace the usage of a variable by a direct function call in nd_pfn_validate()

Also, possible only my pet peeve, the long commit message spoils my
pretty 80 column view. Please trim it to not wrap here:

$git log --oneline pfn_devs.c
52b639e56a46 nvdimm: Replace the usage of a variable by a direct function call in nd_pfn_validate()
c91d71363084 nvdimm: Support sizeof(struct page) > MAX_STRUCT_PAGE_SIZE
6e9f05dc66f9 libnvdimm/pfn_dev: increase MAX_STRUCT_PAGE_SIZE
81beea55cb74 nvdimm: Drop nd_device_lock()
4a0079bc7aae nvdimm: Replace lockdep_mutex with local lock classes
322cbb50de71 block: remove genhd.h

Alison


> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
>  drivers/nvdimm/pfn_devs.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/nvdimm/pfn_devs.c b/drivers/nvdimm/pfn_devs.c
> index af7d9301520c..f14cbfa500ed 100644
> --- a/drivers/nvdimm/pfn_devs.c
> +++ b/drivers/nvdimm/pfn_devs.c
> @@ -456,7 +456,6 @@ int nd_pfn_validate(struct nd_pfn *nd_pfn, const char *sig)
>  	unsigned long align, start_pad;
>  	struct nd_pfn_sb *pfn_sb = nd_pfn->pfn_sb;
>  	struct nd_namespace_common *ndns = nd_pfn->ndns;
> -	const uuid_t *parent_uuid = nd_dev_to_uuid(&ndns->dev);
> 
>  	if (!pfn_sb || !ndns)
>  		return -ENODEV;
> @@ -476,7 +475,7 @@ int nd_pfn_validate(struct nd_pfn *nd_pfn, const char *sig)
>  		return -ENODEV;
>  	pfn_sb->checksum = cpu_to_le64(checksum);
> 
> -	if (memcmp(pfn_sb->parent_uuid, parent_uuid, 16) != 0)
> +	if (memcmp(pfn_sb->parent_uuid, nd_dev_to_uuid(&ndns->dev), 16) != 0)
>  		return -ENODEV;
> 
>  	if (__le16_to_cpu(pfn_sb->version_minor) < 1) {
> --
> 2.40.0
> 

Re: [PATCH] nvdimm: Replace the usage of a variable by a direct function call in nd_pfn_validate()

[Markus Elfring]

>> The address of a data structure member was determined before
>> a corresponding null pointer check in the implementation of
>> the function “nd_pfn_validate”.
>>
>> Thus avoid the risk for undefined behaviour by replacing the usage of
>> the local variable “parent_uuid” by a direct function call within
>> a later condition check.
>
> Hi Markus,
>
> I think I understand what you are saying above, but I don't follow
> how that applies here. This change seems to be a nice simplification,
> parent_uuid, is used once, just grab it when needed.

Thanks for your positive feedback.


> What is the risk of undefined behavior?

See also:
https://wiki.sei.cmu.edu/confluence/display/c/EXP34-C.+Do+not+dereference+null+pointers?focusedCommentId=405504137#comment-405504137


>> This issue was detected by using the Coccinelle software.
> Which cocci script?

See also:
Reconsidering pointer dereferences before null pointer checks (with SmPL)
https://lore.kernel.org/cocci/1a11455f-ab57-dce0-1677-6beb8492a257@web.de/
https://sympa.inria.fr/sympa/arc/cocci/2023-04/msg00021.html


How do you think about to review and improve any similarly affected software components?

Regards,
Markus

Re: [cocci] [PATCH] nvdimm: Replace the usage of a variable by a direct function call in nd_pfn_validate()

[Markus Elfring]

>> The address of a data structure member was determined before
>> a corresponding null pointer check in the implementation of
>> the function “nd_pfn_validate”.
>>
>> Thus avoid the risk for undefined behaviour by replacing the usage of
>> the local variable “parent_uuid” by a direct function call within
>> a later condition check.
>
> Hi Markus,
>
> I think I understand what you are saying above, but I don't follow
> how that applies here. This change seems to be a nice simplification,
> parent_uuid, is used once, just grab it when needed.

Thanks for your positive feedback.


> What is the risk of undefined behavior?

See also:
https://wiki.sei.cmu.edu/confluence/display/c/EXP34-C.+Do+not+dereference+null+pointers?focusedCommentId=405504137#comment-405504137


>> This issue was detected by using the Coccinelle software.
> Which cocci script?

See also:
Reconsidering pointer dereferences before null pointer checks (with SmPL)
https://lore.kernel.org/cocci/1a11455f-ab57-dce0-1677-6beb8492a257@web.de/
https://sympa.inria.fr/sympa/arc/cocci/2023-04/msg00021.html


How do you think about to review and improve any similarly affected software components?

Regards,
Markus

Re: [PATCH] nvdimm: Replace the usage of a variable by a direct function call in nd_pfn_validate()

[Alison Schofield]

On Fri, Apr 14, 2023 at 06:50:59PM +0200, Markus Elfring wrote:
> >> The address of a data structure member was determined before
> >> a corresponding null pointer check in the implementation of
> >> the function “nd_pfn_validate”.
> >>
> >> Thus avoid the risk for undefined behaviour by replacing the usage of
> >> the local variable “parent_uuid” by a direct function call within
> >> a later condition check.
> >
> > Hi Markus,
> >
> > I think I understand what you are saying above, but I don't follow
> > how that applies here. This change seems to be a nice simplification,
> > parent_uuid, is used once, just grab it when needed.
> 
> Thanks for your positive feedback.

Hi Markus,

FYI - I'm a tiny bit taken aback that in response to me applying, and
providing feedback, on your patch, you respond with 2 links for me to
follow and cut off a chunk of my feedback.

Seems like it would taken the same amount of time to just answer my
two questions directly.

Was this part of a larger patch set? Andy's comment seems to indicate
that. Would have been nice to be CC'd on the cover letter.


More below...

> 
> 
> > What is the risk of undefined behavior?
> 
> See also:
> https://wiki.sei.cmu.edu/confluence/display/c/EXP34-C.+Do+not+dereference+null+pointers?focusedCommentId=405504137#comment-405504137

Where is the NULL pointer dereference here?

> 
> 
> >> This issue was detected by using the Coccinelle software.
> > Which cocci script?
> 
> See also:
> Reconsidering pointer dereferences before null pointer checks (with SmPL)
> https://lore.kernel.org/cocci/1a11455f-ab57-dce0-1677-6beb8492a257@web.de/
> https://sympa.inria.fr/sympa/arc/cocci/2023-04/msg00021.html
> 

The cocci script linked above does not seem to apply here.

> 
> How do you think about to review and improve any similarly affected software components?
> 
> Regards,
> Markus
> 

Re: nvdimm: Replace the usage of a variable by a direct function call in nd_pfn_validate()

[Markus Elfring]

> FYI - I'm a tiny bit taken aback that in response to me applying,
> and providing feedback, on your patch,

This will probably trigger collateral evolution, won't it?


> you respond with 2 links for me to follow

I offered another bit of background information according to your enquiry.


> and cut off a chunk of my feedback.

Will this part become relevant for a subsequent patch?


> Seems like it would taken the same amount of time to just answer my
> two questions directly.

Do you find linked information sources also helpful?


> Was this part of a larger patch set?

Not for this software module.

But one of my scripts for the semantic patch language pointed several update candidates out.
Thus I sent 19 patches according to these change possibilities so far.
(Would you become interested to take another look by the means of mailing list archives?)


> Andy's comment seems to indicate that.

Andy Shevchenko was informed because he is involved also in the evolution of other components.


>>> What is the risk of undefined behavior?
>>
>> See also:
>> https://wiki.sei.cmu.edu/confluence/display/c/EXP34-C.+Do+not+dereference+null+pointers?focusedCommentId=405504137#comment-405504137
>
> Where is the NULL pointer dereference here?

I hope that you can become more aware that access attempts for data structure members
(also by using the arrow operator) can occasionally be problematic before null pointer checks.



>>>> This issue was detected by using the Coccinelle software.
>>> Which cocci script?
>>
>> See also:
>> Reconsidering pointer dereferences before null pointer checks (with SmPL)
>> https://lore.kernel.org/cocci/1a11455f-ab57-dce0-1677-6beb8492a257@web.de/
>> https://sympa.inria.fr/sympa/arc/cocci/2023-04/msg00021.html
>
> The cocci script linked above does not seem to apply here.

Which command did you try out?

Do you find the following data processing result reasonable?

Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> spatch …/Projekte/Coccinelle/janitor/show_pointer_dereferences_before_check7.cocci drivers/nvdimm/pfn_devs.c
…
@@ -456,9 +456,7 @@ int nd_pfn_validate(struct nd_pfn *nd_pf
        unsigned long align, start_pad;
        struct nd_pfn_sb *pfn_sb = nd_pfn->pfn_sb;
        struct nd_namespace_common *ndns = nd_pfn->ndns;
-       const uuid_t *parent_uuid = nd_dev_to_uuid(&ndns->dev);

-       if (!pfn_sb || !ndns)
                return -ENODEV;

        if (!is_memory(nd_pfn->dev.parent))


Regards,
Markus

Re: [cocci] nvdimm: Replace the usage of a variable by a direct function call in nd_pfn_validate()

[Markus Elfring]

> FYI - I'm a tiny bit taken aback that in response to me applying,
> and providing feedback, on your patch,

This will probably trigger collateral evolution, won't it?


> you respond with 2 links for me to follow

I offered another bit of background information according to your enquiry.


> and cut off a chunk of my feedback.

Will this part become relevant for a subsequent patch?


> Seems like it would taken the same amount of time to just answer my
> two questions directly.

Do you find linked information sources also helpful?


> Was this part of a larger patch set?

Not for this software module.

But one of my scripts for the semantic patch language pointed several update candidates out.
Thus I sent 19 patches according to these change possibilities so far.
(Would you become interested to take another look by the means of mailing list archives?)


> Andy's comment seems to indicate that.

Andy Shevchenko was informed because he is involved also in the evolution of other components.


>>> What is the risk of undefined behavior?
>>
>> See also:
>> https://wiki.sei.cmu.edu/confluence/display/c/EXP34-C.+Do+not+dereference+null+pointers?focusedCommentId=405504137#comment-405504137
>
> Where is the NULL pointer dereference here?

I hope that you can become more aware that access attempts for data structure members
(also by using the arrow operator) can occasionally be problematic before null pointer checks.



>>>> This issue was detected by using the Coccinelle software.
>>> Which cocci script?
>>
>> See also:
>> Reconsidering pointer dereferences before null pointer checks (with SmPL)
>> https://lore.kernel.org/cocci/1a11455f-ab57-dce0-1677-6beb8492a257@web.de/
>> https://sympa.inria.fr/sympa/arc/cocci/2023-04/msg00021.html
>
> The cocci script linked above does not seem to apply here.

Which command did you try out?

Do you find the following data processing result reasonable?

Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> spatch …/Projekte/Coccinelle/janitor/show_pointer_dereferences_before_check7.cocci drivers/nvdimm/pfn_devs.c
…
@@ -456,9 +456,7 @@ int nd_pfn_validate(struct nd_pfn *nd_pf
        unsigned long align, start_pad;
        struct nd_pfn_sb *pfn_sb = nd_pfn->pfn_sb;
        struct nd_namespace_common *ndns = nd_pfn->ndns;
-       const uuid_t *parent_uuid = nd_dev_to_uuid(&ndns->dev);

-       if (!pfn_sb || !ndns)
                return -ENODEV;

        if (!is_memory(nd_pfn->dev.parent))


Regards,
Markus

Re: [PATCH] nvdimm: Replace the usage of a variable by a direct function call in nd_pfn_validate()

[Andy Shevchenko]

On Fri, Apr 14, 2023 at 12:12:37PM +0200, Markus Elfring wrote:
> Date: Fri, 14 Apr 2023 12:01:15 +0200
> 
> The address of a data structure member was determined before
> a corresponding null pointer check in the implementation of
> the function “nd_pfn_validate”.
> 
> Thus avoid the risk for undefined behaviour by replacing the usage of
> the local variable “parent_uuid” by a direct function call within
> a later condition check.

> This issue was detected by using the Coccinelle software.
> 
> Fixes: d1c6e08e7503649e4a4f3f9e700e2c05300b6379 ("libnvdimm/labels: Add uuid helpers")

Same issues as per patch 1.

...

> -	if (memcmp(pfn_sb->parent_uuid, parent_uuid, 16) != 0)
> +	if (memcmp(pfn_sb->parent_uuid, nd_dev_to_uuid(&ndns->dev), 16) != 0)

If parent_uuid is of uuid_t type, you better to replace memcmp() with
uuid_equal().

>  		return -ENODEV;

-- 
With Best Regards,
Andy Shevchenko

[cocci] [PATCH] media: adv748x: Move a variable assignment behind condition checks in adv748x_hdmi_query_dv_timings()

[Markus Elfring]

Date: Fri, 14 Apr 2023 16:56:07 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “adv748x_hdmi_query_dv_timings”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “bt” behind some condition checks.

This issue was detected by using the Coccinelle software.

Fixes: 3e89586a64dfd2860d596db0c84ec999d2eb5591 ("media: i2c: adv748x: add adv748x driver")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/media/i2c/adv748x/adv748x-hdmi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/adv748x/adv748x-hdmi.c b/drivers/media/i2c/adv748x/adv748x-hdmi.c
index 52fa7bd75660..28757a5efd6d 100644
--- a/drivers/media/i2c/adv748x/adv748x-hdmi.c
+++ b/drivers/media/i2c/adv748x/adv748x-hdmi.c
@@ -274,7 +274,7 @@ static int adv748x_hdmi_query_dv_timings(struct v4l2_subdev *sd,
 {
 	struct adv748x_hdmi *hdmi = adv748x_sd_to_hdmi(sd);
 	struct adv748x_state *state = adv748x_hdmi_to_state(hdmi);
-	struct v4l2_bt_timings *bt = &timings->bt;
+	struct v4l2_bt_timings *bt;
 	int pixelclock;
 	int polarity;

@@ -291,7 +291,7 @@ static int adv748x_hdmi_query_dv_timings(struct v4l2_subdev *sd,
 		return -ENODATA;

 	timings->type = V4L2_DV_BT_656_1120;
-
+	bt = &timings->bt;
 	bt->pixelclock = pixelclock;
 	bt->interlaced = hdmi_read(state, ADV748X_HDMI_F1H1) &
 				ADV748X_HDMI_F1H1_INTERLACED ?
--
2.40.0

[cocci] [PATCH v2 0/3] media: adv748x: Adjustments for adv748x_hdmi_query_dv_timings()

[Markus Elfring]

Date: Tue, 18 Apr 2023 11:56:11 +0200

The deletion of an if statement was requested by Hans Verkuil.
This update triggered further change possibilities.

Markus Elfring (3):
  Delete a null pointer check
  Move a variable assignment behind condition checks
  Improve a size determination

 drivers/media/i2c/adv748x/adv748x-hdmi.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

--
2.40.0

[cocci] [PATCH v2 1/3] media: adv748x: Delete a null pointer check in adv748x_hdmi_query_dv_timings()

[Markus Elfring]

Date: Tue, 18 Apr 2023 09:11:39 +0200

An extra null pointer check became unwanted
for the input parameter validation in the implementation of
the function “adv748x_hdmi_query_dv_timings”.
Thus omit an if statement at the beginning.

Link: https://lore.kernel.org/kernel-janitors/8153cc88-2cea-0528-9d54-bda72cbaac5b@xs4all.nl/
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/media/i2c/adv748x/adv748x-hdmi.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/media/i2c/adv748x/adv748x-hdmi.c b/drivers/media/i2c/adv748x/adv748x-hdmi.c
index 400d71c2745c..b10263f4c0c0 100644
--- a/drivers/media/i2c/adv748x/adv748x-hdmi.c
+++ b/drivers/media/i2c/adv748x/adv748x-hdmi.c
@@ -278,9 +278,6 @@ static int adv748x_hdmi_query_dv_timings(struct v4l2_subdev *sd,
 	int pixelclock;
 	int polarity;

-	if (!timings)
-		return -EINVAL;
-
 	memset(timings, 0, sizeof(struct v4l2_dv_timings));

 	/*
--
2.40.0

[cocci] [PATCH v2 2/3] media: adv748x: Move a variable assignment behind condition checks in adv748x_hdmi_query_dv_timings()

[Markus Elfring]

Date: Tue, 18 Apr 2023 09:30:25 +0200

Convert the explicit initialisation of the local variable “bt”
at the beginning to an assignment statement directly before
the source code place where this pointer is used.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---

v2:
The change was rebased on source files from Linux next-20230417.

 drivers/media/i2c/adv748x/adv748x-hdmi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/adv748x/adv748x-hdmi.c b/drivers/media/i2c/adv748x/adv748x-hdmi.c
index b10263f4c0c0..14ff27aabe89 100644
--- a/drivers/media/i2c/adv748x/adv748x-hdmi.c
+++ b/drivers/media/i2c/adv748x/adv748x-hdmi.c
@@ -274,7 +274,7 @@ static int adv748x_hdmi_query_dv_timings(struct v4l2_subdev *sd,
 {
 	struct adv748x_hdmi *hdmi = adv748x_sd_to_hdmi(sd);
 	struct adv748x_state *state = adv748x_hdmi_to_state(hdmi);
-	struct v4l2_bt_timings *bt = &timings->bt;
+	struct v4l2_bt_timings *bt;
 	int pixelclock;
 	int polarity;

@@ -298,7 +298,7 @@ static int adv748x_hdmi_query_dv_timings(struct v4l2_subdev *sd,
 		return -ENODATA;

 	timings->type = V4L2_DV_BT_656_1120;
-
+	bt = &timings->bt;
 	bt->pixelclock = pixelclock;
 	bt->interlaced = hdmi_read(state, ADV748X_HDMI_F1H1) &
 				ADV748X_HDMI_F1H1_INTERLACED ?
--
2.40.0

[cocci] [PATCH v2 3/3] media: adv748x: Improve a size determination in adv748x_hdmi_query_dv_timings()

[Markus Elfring]

Date: Tue, 18 Apr 2023 11:00:13 +0200

Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/media/i2c/adv748x/adv748x-hdmi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/adv748x/adv748x-hdmi.c b/drivers/media/i2c/adv748x/adv748x-hdmi.c
index 14ff27aabe89..13bf9983a674 100644
--- a/drivers/media/i2c/adv748x/adv748x-hdmi.c
+++ b/drivers/media/i2c/adv748x/adv748x-hdmi.c
@@ -278,7 +278,7 @@ static int adv748x_hdmi_query_dv_timings(struct v4l2_subdev *sd,
 	int pixelclock;
 	int polarity;

-	memset(timings, 0, sizeof(struct v4l2_dv_timings));
+	memset(timings, 0, sizeof(*timings));

 	/*
 	 * If the pattern generator is enabled the device shall not be queried
--
2.40.0

[cocci] [PATCH] media: adv7604: Move a variable assignment behind condition checks in adv76xx_query_dv_timings()

[Markus Elfring]

Date: Fri, 14 Apr 2023 18:26:08 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “adv76xx_query_dv_timings”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “bt” behind some condition checks.

This issue was detected by using the Coccinelle software.

Fixes: 54450f591c9927496b3d41c041fa802d0ef96885 ("[media] adv7604: driver for the Analog Devices ADV7604 video decoder")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/media/i2c/adv7604.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 9d218962d7c8..ed4ec2151d68 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -1562,7 +1562,7 @@ static int adv76xx_query_dv_timings(struct v4l2_subdev *sd,
 {
 	struct adv76xx_state *state = to_state(sd);
 	const struct adv76xx_chip_info *info = state->info;
-	struct v4l2_bt_timings *bt = &timings->bt;
+	struct v4l2_bt_timings *bt;
 	struct stdi_readback stdi;

 	if (!timings)
@@ -1581,6 +1581,8 @@ static int adv76xx_query_dv_timings(struct v4l2_subdev *sd,
 		v4l2_dbg(1, debug, sd, "%s: STDI/SSPD not locked\n", __func__);
 		return -ENOLINK;
 	}
+
+	bt = &timings->bt;
 	bt->interlaced = stdi.interlaced ?
 		V4L2_DV_INTERLACED : V4L2_DV_PROGRESSIVE;

--
2.40.0

[cocci] [PATCH v2 0/4] media: adv7604: Adjustments for two function implementations

[Markus Elfring]

Date: Tue, 18 Apr 2023 19:32:19 +0200

The deletion of an if statement was requested by Hans Verkuil.
This update triggered further change possibilities.

Markus Elfring (4):
  Delete a null pointer check
  Move a variable assignment behind condition checks
  Improve three size determinations
  Reduce scope for the variable “info”

 drivers/media/i2c/adv7604.c | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

--
2.40.0

[cocci] [PATCH v2 1/4] media: adv7604: Delete a null pointer check in adv76xx_query_dv_timings()

[Markus Elfring]

Date: Tue, 18 Apr 2023 18:21:00 +0200

An extra null pointer check became unwanted
for the input parameter validation in the implementation of
the function “adv76xx_query_dv_timings”.
Thus omit an if statement at the beginning.

Link: https://lore.kernel.org/kernel-janitors/8153cc88-2cea-0528-9d54-bda72cbaac5b@xs4all.nl/
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/media/i2c/adv7604.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 3d0898c4175e..d92a681f9176 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -1565,9 +1565,6 @@ static int adv76xx_query_dv_timings(struct v4l2_subdev *sd,
 	struct v4l2_bt_timings *bt = &timings->bt;
 	struct stdi_readback stdi;

-	if (!timings)
-		return -EINVAL;
-
 	memset(timings, 0, sizeof(struct v4l2_dv_timings));

 	if (no_signal(sd)) {
--
2.40.0

[cocci] [PATCH v2 2/4] media: adv7604: Move a variable assignment behind condition checks in adv76xx_query_dv_timings()

[Markus Elfring]

Date: Tue, 18 Apr 2023 18:30:41 +0200

Convert the explicit initialisation of the local variable “bt”
at the beginning to an assignment statement directly before
the source code place where this pointer is used.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/media/i2c/adv7604.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index d92a681f9176..1f743b89f31b 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -1562,7 +1562,7 @@ static int adv76xx_query_dv_timings(struct v4l2_subdev *sd,
 {
 	struct adv76xx_state *state = to_state(sd);
 	const struct adv76xx_chip_info *info = state->info;
-	struct v4l2_bt_timings *bt = &timings->bt;
+	struct v4l2_bt_timings *bt;
 	struct stdi_readback stdi;

 	memset(timings, 0, sizeof(struct v4l2_dv_timings));
@@ -1578,6 +1578,8 @@ static int adv76xx_query_dv_timings(struct v4l2_subdev *sd,
 		v4l2_dbg(1, debug, sd, "%s: STDI/SSPD not locked\n", __func__);
 		return -ENOLINK;
 	}
+
+	bt = &timings->bt;
 	bt->interlaced = stdi.interlaced ?
 		V4L2_DV_INTERLACED : V4L2_DV_PROGRESSIVE;

--
2.40.0

[cocci] [PATCH v2 3/4] media: adv7604: Improve three size determinations

[Markus Elfring]

Date: Tue, 18 Apr 2023 18:45:22 +0200

Replace the specification of data structures by pointer dereferences
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/media/i2c/adv7604.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 1f743b89f31b..4d0df7f325db 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -1464,7 +1464,7 @@ static int read_stdi(struct v4l2_subdev *sd, struct stdi_readback *stdi)

 	if (stdi->lcf < 239 || stdi->bl < 8 || stdi->bl == 0x3fff) {
 		v4l2_dbg(2, debug, sd, "%s: invalid signal\n", __func__);
-		memset(stdi, 0, sizeof(struct stdi_readback));
+		memset(stdi, 0, sizeof(*stdi));
 		return -1;
 	}

@@ -1565,7 +1565,7 @@ static int adv76xx_query_dv_timings(struct v4l2_subdev *sd,
 	struct v4l2_bt_timings *bt;
 	struct stdi_readback stdi;

-	memset(timings, 0, sizeof(struct v4l2_dv_timings));
+	memset(timings, 0, sizeof(*timings));

 	if (no_signal(sd)) {
 		state->restart_stdi_once = true;
@@ -1668,7 +1668,7 @@ static int adv76xx_query_dv_timings(struct v4l2_subdev *sd,

 	if (no_signal(sd)) {
 		v4l2_dbg(1, debug, sd, "%s: signal lost during readout\n", __func__);
-		memset(timings, 0, sizeof(struct v4l2_dv_timings));
+		memset(timings, 0, sizeof(*timings));
 		return -ENOLINK;
 	}

--
2.40.0

[cocci] [PATCH v2 4/4] media: adv7604: Reduce scope for the variable “info” in adv76xx_query_dv_timings()

[Markus Elfring]

Date: Tue, 18 Apr 2023 19:00:10 +0200

A local variable was used only within an if branch.
Thus move the definition for the variable “info” into
the corresponding code block.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/media/i2c/adv7604.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 4d0df7f325db..a693427e8f45 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -1561,7 +1561,6 @@ static int adv76xx_query_dv_timings(struct v4l2_subdev *sd,
 			struct v4l2_dv_timings *timings)
 {
 	struct adv76xx_state *state = to_state(sd);
-	const struct adv76xx_chip_info *info = state->info;
 	struct v4l2_bt_timings *bt;
 	struct stdi_readback stdi;

@@ -1586,6 +1585,7 @@ static int adv76xx_query_dv_timings(struct v4l2_subdev *sd,
 	if (is_digital_input(sd)) {
 		bool hdmi_signal = hdmi_read(sd, 0x05) & 0x80;
 		u8 vic = 0;
+		const struct adv76xx_chip_info *info = state->info;
 		u32 w, h;

 		w = hdmi_read16(sd, 0x07, info->linewidth_mask);
--
2.40.0

[cocci] [PATCH] media: mediatek: vcodec: Move a variable assignment behind condition checks in vdec_vp9_slice_single_decode()

[Markus Elfring]

Date: Fri, 14 Apr 2023 20:07:01 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “vdec_vp9_slice_single_decode”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “pfc” behind some condition checks.

This issue was detected by using the Coccinelle software.

Fixes: b0f407c19648ae9110c932c91d6e1b9381ec0aeb ("media: mediatek: vcodec: add vp9 decoder driver for mt8186")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 .../media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c  | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c b/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c
index cf16cf2807f0..22b27f7b57bf 100644
--- a/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c
+++ b/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c
@@ -1990,7 +1990,7 @@ static int vdec_vp9_slice_single_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
 					struct vdec_fb *fb, bool *res_chg)
 {
 	struct vdec_vp9_slice_instance *instance = h_vdec;
-	struct vdec_vp9_slice_pfc *pfc = &instance->sc_pfc;
+	struct vdec_vp9_slice_pfc *pfc;
 	struct vdec_vp9_slice_vsi *vsi;
 	struct mtk_vcodec_ctx *ctx;
 	int ret;
@@ -2007,6 +2007,7 @@ static int vdec_vp9_slice_single_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
 	if (!fb)
 		return -EBUSY;

+	pfc = &instance->sc_pfc;
 	vsi = &pfc->vsi;

 	ret = vdec_vp9_slice_setup_single(instance, bs, fb, pfc);
--
2.40.0

[PATCH] media: mediatek: vcodec: Move a variable assignment behind condition checks in vdec_vp9_slice_single_decode()

[Markus Elfring]

Date: Fri, 14 Apr 2023 20:07:01 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “vdec_vp9_slice_single_decode”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “pfc” behind some condition checks.

This issue was detected by using the Coccinelle software.

Fixes: b0f407c19648ae9110c932c91d6e1b9381ec0aeb ("media: mediatek: vcodec: add vp9 decoder driver for mt8186")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 .../media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c  | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c b/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c
index cf16cf2807f0..22b27f7b57bf 100644
--- a/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c
+++ b/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c
@@ -1990,7 +1990,7 @@ static int vdec_vp9_slice_single_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
 					struct vdec_fb *fb, bool *res_chg)
 {
 	struct vdec_vp9_slice_instance *instance = h_vdec;
-	struct vdec_vp9_slice_pfc *pfc = &instance->sc_pfc;
+	struct vdec_vp9_slice_pfc *pfc;
 	struct vdec_vp9_slice_vsi *vsi;
 	struct mtk_vcodec_ctx *ctx;
 	int ret;
@@ -2007,6 +2007,7 @@ static int vdec_vp9_slice_single_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
 	if (!fb)
 		return -EBUSY;

+	pfc = &instance->sc_pfc;
 	vsi = &pfc->vsi;

 	ret = vdec_vp9_slice_setup_single(instance, bs, fb, pfc);
--
2.40.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH] media: mediatek: vcodec: Move a variable assignment behind condition checks in vdec_vp9_slice_single_decode()

[Markus Elfring]

Date: Fri, 14 Apr 2023 20:07:01 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “vdec_vp9_slice_single_decode”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “pfc” behind some condition checks.

This issue was detected by using the Coccinelle software.

Fixes: b0f407c19648ae9110c932c91d6e1b9381ec0aeb ("media: mediatek: vcodec: add vp9 decoder driver for mt8186")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 .../media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c  | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c b/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c
index cf16cf2807f0..22b27f7b57bf 100644
--- a/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c
+++ b/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c
@@ -1990,7 +1990,7 @@ static int vdec_vp9_slice_single_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
 					struct vdec_fb *fb, bool *res_chg)
 {
 	struct vdec_vp9_slice_instance *instance = h_vdec;
-	struct vdec_vp9_slice_pfc *pfc = &instance->sc_pfc;
+	struct vdec_vp9_slice_pfc *pfc;
 	struct vdec_vp9_slice_vsi *vsi;
 	struct mtk_vcodec_ctx *ctx;
 	int ret;
@@ -2007,6 +2007,7 @@ static int vdec_vp9_slice_single_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
 	if (!fb)
 		return -EBUSY;

+	pfc = &instance->sc_pfc;
 	vsi = &pfc->vsi;

 	ret = vdec_vp9_slice_setup_single(instance, bs, fb, pfc);
--
2.40.0

Re: [PATCH] media: mediatek: vcodec: Move a variable assignment behind condition checks in vdec_vp9_slice_single_decode()

[AngeloGioacchino Del Regno]

Il 14/04/23 20:30, Markus Elfring ha scritto:
> Date: Fri, 14 Apr 2023 20:07:01 +0200
> 
> The address of a data structure member was determined before
> a corresponding null pointer check in the implementation of
> the function “vdec_vp9_slice_single_decode”.
> 
> Thus avoid the risk for undefined behaviour by moving the assignment
> for the variable “pfc” behind some condition checks.
> 
> This issue was detected by using the Coccinelle software.
> 
> Fixes: b0f407c19648ae9110c932c91d6e1b9381ec0aeb ("media: mediatek: vcodec: add vp9 decoder driver for mt8186")
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>

Re: [PATCH] media: mediatek: vcodec: Move a variable assignment behind condition checks in vdec_vp9_slice_single_decode()

[AngeloGioacchino Del Regno]

Il 14/04/23 20:30, Markus Elfring ha scritto:
> Date: Fri, 14 Apr 2023 20:07:01 +0200
> 
> The address of a data structure member was determined before
> a corresponding null pointer check in the implementation of
> the function “vdec_vp9_slice_single_decode”.
> 
> Thus avoid the risk for undefined behaviour by moving the assignment
> for the variable “pfc” behind some condition checks.
> 
> This issue was detected by using the Coccinelle software.
> 
> Fixes: b0f407c19648ae9110c932c91d6e1b9381ec0aeb ("media: mediatek: vcodec: add vp9 decoder driver for mt8186")
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] media: mediatek: vcodec: Move a variable assignment behind condition checks in vdec_vp9_slice_single_decode()

[Hans Verkuil]

On 14/04/2023 20:30, Markus Elfring wrote:
> Date: Fri, 14 Apr 2023 20:07:01 +0200
> 
> The address of a data structure member was determined before
> a corresponding null pointer check in the implementation of
> the function “vdec_vp9_slice_single_decode”.
> 
> Thus avoid the risk for undefined behaviour by moving the assignment
> for the variable “pfc” behind some condition checks.
> 
> This issue was detected by using the Coccinelle software.
> 
> Fixes: b0f407c19648ae9110c932c91d6e1b9381ec0aeb ("media: mediatek: vcodec: add vp9 decoder driver for mt8186")

Not a fix, it was never broken.

> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
>  .../media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c  | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c b/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c
> index cf16cf2807f0..22b27f7b57bf 100644
> --- a/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c
> +++ b/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c
> @@ -1990,7 +1990,7 @@ static int vdec_vp9_slice_single_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
>  					struct vdec_fb *fb, bool *res_chg)
>  {
>  	struct vdec_vp9_slice_instance *instance = h_vdec;

Just drop these lines instead:

        if (!instance || !instance->ctx)
                return -EINVAL;

That can never happen.

Regards,

	Hans

> -	struct vdec_vp9_slice_pfc *pfc = &instance->sc_pfc;
> +	struct vdec_vp9_slice_pfc *pfc;
>  	struct vdec_vp9_slice_vsi *vsi;
>  	struct mtk_vcodec_ctx *ctx;
>  	int ret;
> @@ -2007,6 +2007,7 @@ static int vdec_vp9_slice_single_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
>  	if (!fb)
>  		return -EBUSY;
> 
> +	pfc = &instance->sc_pfc;
>  	vsi = &pfc->vsi;
> 
>  	ret = vdec_vp9_slice_setup_single(instance, bs, fb, pfc);
> --
> 2.40.0
> 

Re: [PATCH] media: mediatek: vcodec: Move a variable assignment behind condition checks in vdec_vp9_slice_single_decode()

[Hans Verkuil]

On 14/04/2023 20:30, Markus Elfring wrote:
> Date: Fri, 14 Apr 2023 20:07:01 +0200
> 
> The address of a data structure member was determined before
> a corresponding null pointer check in the implementation of
> the function “vdec_vp9_slice_single_decode”.
> 
> Thus avoid the risk for undefined behaviour by moving the assignment
> for the variable “pfc” behind some condition checks.
> 
> This issue was detected by using the Coccinelle software.
> 
> Fixes: b0f407c19648ae9110c932c91d6e1b9381ec0aeb ("media: mediatek: vcodec: add vp9 decoder driver for mt8186")

Not a fix, it was never broken.

> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
>  .../media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c  | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c b/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c
> index cf16cf2807f0..22b27f7b57bf 100644
> --- a/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c
> +++ b/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c
> @@ -1990,7 +1990,7 @@ static int vdec_vp9_slice_single_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
>  					struct vdec_fb *fb, bool *res_chg)
>  {
>  	struct vdec_vp9_slice_instance *instance = h_vdec;

Just drop these lines instead:

        if (!instance || !instance->ctx)
                return -EINVAL;

That can never happen.

Regards,

	Hans

> -	struct vdec_vp9_slice_pfc *pfc = &instance->sc_pfc;
> +	struct vdec_vp9_slice_pfc *pfc;
>  	struct vdec_vp9_slice_vsi *vsi;
>  	struct mtk_vcodec_ctx *ctx;
>  	int ret;
> @@ -2007,6 +2007,7 @@ static int vdec_vp9_slice_single_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
>  	if (!fb)
>  		return -EBUSY;
> 
> +	pfc = &instance->sc_pfc;
>  	vsi = &pfc->vsi;
> 
>  	ret = vdec_vp9_slice_setup_single(instance, bs, fb, pfc);
> --
> 2.40.0
> 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[cocci] [PATCH 0/2] media: mediatek: vcodec: Adjustments for vdec_vp9_slice_single_decode()

[Markus Elfring]

Date: Mon, 17 Apr 2023 14:32:14 +0200

The deletion of an if statement was requested by Hans Verkuil.
This update triggered another change possibility.

Markus Elfring (2):
  Delete null pointer checks
  Move variable assignments behind null pointer checks

 .../mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c        | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

--
2.40.0

[PATCH 0/2] media: mediatek: vcodec: Adjustments for vdec_vp9_slice_single_decode()

[Markus Elfring]

Date: Mon, 17 Apr 2023 14:32:14 +0200

The deletion of an if statement was requested by Hans Verkuil.
This update triggered another change possibility.

Markus Elfring (2):
  Delete null pointer checks
  Move variable assignments behind null pointer checks

 .../mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c        | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

--
2.40.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 0/2] media: mediatek: vcodec: Adjustments for vdec_vp9_slice_single_decode()

[Markus Elfring]

Date: Mon, 17 Apr 2023 14:32:14 +0200

The deletion of an if statement was requested by Hans Verkuil.
This update triggered another change possibility.

Markus Elfring (2):
  Delete null pointer checks
  Move variable assignments behind null pointer checks

 .../mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c        | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

--
2.40.0

[cocci] [PATCH 1/2] media: mediatek: vcodec: Delete null pointer checks in vdec_vp9_slice_single_decode()

[Markus Elfring]

Date: Mon, 17 Apr 2023 13:43:31 +0200

Extra null pointer checks became unwanted for
the input parameter validation in the implementation of
the function “vdec_vp9_slice_single_decode”.
Thus omit an if statement at the beginning.

Link: https://lore.kernel.org/kernel-janitors/0341924c-7f0a-28aa-eeae-f7de69ab36d8@xs4all.nl/
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 .../media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c   | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c b/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c
index cf16cf2807f0..8430098ed0b1 100644
--- a/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c
+++ b/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c
@@ -1995,8 +1995,6 @@ static int vdec_vp9_slice_single_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
 	struct mtk_vcodec_ctx *ctx;
 	int ret;

-	if (!instance || !instance->ctx)
-		return -EINVAL;
 	ctx = instance->ctx;

 	/* bs NULL means flush decoder */
--
2.40.0

[PATCH 1/2] media: mediatek: vcodec: Delete null pointer checks in vdec_vp9_slice_single_decode()

[Markus Elfring]

Date: Mon, 17 Apr 2023 13:43:31 +0200

Extra null pointer checks became unwanted for
the input parameter validation in the implementation of
the function “vdec_vp9_slice_single_decode”.
Thus omit an if statement at the beginning.

Link: https://lore.kernel.org/kernel-janitors/0341924c-7f0a-28aa-eeae-f7de69ab36d8@xs4all.nl/
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 .../media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c   | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c b/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c
index cf16cf2807f0..8430098ed0b1 100644
--- a/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c
+++ b/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c
@@ -1995,8 +1995,6 @@ static int vdec_vp9_slice_single_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
 	struct mtk_vcodec_ctx *ctx;
 	int ret;

-	if (!instance || !instance->ctx)
-		return -EINVAL;
 	ctx = instance->ctx;

 	/* bs NULL means flush decoder */
--
2.40.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 1/2] media: mediatek: vcodec: Delete null pointer checks in vdec_vp9_slice_single_decode()

[Markus Elfring]

Date: Mon, 17 Apr 2023 13:43:31 +0200

Extra null pointer checks became unwanted for
the input parameter validation in the implementation of
the function “vdec_vp9_slice_single_decode”.
Thus omit an if statement at the beginning.

Link: https://lore.kernel.org/kernel-janitors/0341924c-7f0a-28aa-eeae-f7de69ab36d8@xs4all.nl/
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 .../media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c   | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c b/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c
index cf16cf2807f0..8430098ed0b1 100644
--- a/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c
+++ b/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c
@@ -1995,8 +1995,6 @@ static int vdec_vp9_slice_single_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
 	struct mtk_vcodec_ctx *ctx;
 	int ret;

-	if (!instance || !instance->ctx)
-		return -EINVAL;
 	ctx = instance->ctx;

 	/* bs NULL means flush decoder */
--
2.40.0

[cocci] [PATCH 2/2] media: mediatek: vcodec: Move variable assignments behind null pointer checks in vdec_vp9_slice_single_decode()

[Markus Elfring]

Date: Mon, 17 Apr 2023 14:19:13 +0200

The addresses which were assigned to the variables “instance”,
“pfc” and “ctx” would not be used if a null pointer was passed by
the input parameter “bs”.
Thus move these assignments behind corresponding pointer checks.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 .../platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c  | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c b/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c
index 8430098ed0b1..562fe07d3731 100644
--- a/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c
+++ b/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c
@@ -1989,22 +1989,23 @@ static int vdec_vp9_slice_get_param(void *h_vdec, enum vdec_get_param_type type,
 static int vdec_vp9_slice_single_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
 					struct vdec_fb *fb, bool *res_chg)
 {
-	struct vdec_vp9_slice_instance *instance = h_vdec;
-	struct vdec_vp9_slice_pfc *pfc = &instance->sc_pfc;
+	struct vdec_vp9_slice_instance *instance;
+	struct vdec_vp9_slice_pfc *pfc;
 	struct vdec_vp9_slice_vsi *vsi;
 	struct mtk_vcodec_ctx *ctx;
 	int ret;

-	ctx = instance->ctx;
-
 	/* bs NULL means flush decoder */
 	if (!bs)
 		return vdec_vp9_slice_flush(h_vdec, bs, fb, res_chg);

+	instance = h_vdec;
+	ctx = instance->ctx;
 	fb = ctx->dev->vdec_pdata->get_cap_buffer(ctx);
 	if (!fb)
 		return -EBUSY;

+	pfc = &instance->sc_pfc;
 	vsi = &pfc->vsi;

 	ret = vdec_vp9_slice_setup_single(instance, bs, fb, pfc);
--
2.40.0

[PATCH 2/2] media: mediatek: vcodec: Move variable assignments behind null pointer checks in vdec_vp9_slice_single_decode()

[Markus Elfring]

Date: Mon, 17 Apr 2023 14:19:13 +0200

The addresses which were assigned to the variables “instance”,
“pfc” and “ctx” would not be used if a null pointer was passed by
the input parameter “bs”.
Thus move these assignments behind corresponding pointer checks.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 .../platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c  | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c b/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c
index 8430098ed0b1..562fe07d3731 100644
--- a/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c
+++ b/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c
@@ -1989,22 +1989,23 @@ static int vdec_vp9_slice_get_param(void *h_vdec, enum vdec_get_param_type type,
 static int vdec_vp9_slice_single_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
 					struct vdec_fb *fb, bool *res_chg)
 {
-	struct vdec_vp9_slice_instance *instance = h_vdec;
-	struct vdec_vp9_slice_pfc *pfc = &instance->sc_pfc;
+	struct vdec_vp9_slice_instance *instance;
+	struct vdec_vp9_slice_pfc *pfc;
 	struct vdec_vp9_slice_vsi *vsi;
 	struct mtk_vcodec_ctx *ctx;
 	int ret;

-	ctx = instance->ctx;
-
 	/* bs NULL means flush decoder */
 	if (!bs)
 		return vdec_vp9_slice_flush(h_vdec, bs, fb, res_chg);

+	instance = h_vdec;
+	ctx = instance->ctx;
 	fb = ctx->dev->vdec_pdata->get_cap_buffer(ctx);
 	if (!fb)
 		return -EBUSY;

+	pfc = &instance->sc_pfc;
 	vsi = &pfc->vsi;

 	ret = vdec_vp9_slice_setup_single(instance, bs, fb, pfc);
--
2.40.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 2/2] media: mediatek: vcodec: Move variable assignments behind null pointer checks in vdec_vp9_slice_single_decode()

[Markus Elfring]

Date: Mon, 17 Apr 2023 14:19:13 +0200

The addresses which were assigned to the variables “instance”,
“pfc” and “ctx” would not be used if a null pointer was passed by
the input parameter “bs”.
Thus move these assignments behind corresponding pointer checks.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 .../platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c  | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c b/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c
index 8430098ed0b1..562fe07d3731 100644
--- a/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c
+++ b/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c
@@ -1989,22 +1989,23 @@ static int vdec_vp9_slice_get_param(void *h_vdec, enum vdec_get_param_type type,
 static int vdec_vp9_slice_single_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
 					struct vdec_fb *fb, bool *res_chg)
 {
-	struct vdec_vp9_slice_instance *instance = h_vdec;
-	struct vdec_vp9_slice_pfc *pfc = &instance->sc_pfc;
+	struct vdec_vp9_slice_instance *instance;
+	struct vdec_vp9_slice_pfc *pfc;
 	struct vdec_vp9_slice_vsi *vsi;
 	struct mtk_vcodec_ctx *ctx;
 	int ret;

-	ctx = instance->ctx;
-
 	/* bs NULL means flush decoder */
 	if (!bs)
 		return vdec_vp9_slice_flush(h_vdec, bs, fb, res_chg);

+	instance = h_vdec;
+	ctx = instance->ctx;
 	fb = ctx->dev->vdec_pdata->get_cap_buffer(ctx);
 	if (!fb)
 		return -EBUSY;

+	pfc = &instance->sc_pfc;
 	vsi = &pfc->vsi;

 	ret = vdec_vp9_slice_setup_single(instance, bs, fb, pfc);
--
2.40.0

[cocci] [PATCH] media: au0828: Move a variable assignment behind condition checks in au0828_isoc_copy()

[Markus Elfring]

Date: Fri, 14 Apr 2023 21:00:45 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “au0828_isoc_copy”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “vbi_dma_q” behind some condition checks.

This issue was detected by using the Coccinelle software.

Fixes: 7f8eacd2162a39ca7fc1240883118a786f147ccb ("V4L/DVB: Add closed captioning support for the HVR-950q")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/media/usb/au0828/au0828-video.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/media/usb/au0828/au0828-video.c b/drivers/media/usb/au0828/au0828-video.c
index fd9fc43d47e0..c0c5f2ed65e3 100644
--- a/drivers/media/usb/au0828/au0828-video.c
+++ b/drivers/media/usb/au0828/au0828-video.c
@@ -491,7 +491,7 @@ static inline int au0828_isoc_copy(struct au0828_dev *dev, struct urb *urb)
 	struct au0828_buffer    *buf;
 	struct au0828_buffer    *vbi_buf;
 	struct au0828_dmaqueue  *dma_q = urb->context;
-	struct au0828_dmaqueue  *vbi_dma_q = &dev->vbiq;
+	struct au0828_dmaqueue  *vbi_dma_q;
 	unsigned char *outp = NULL;
 	unsigned char *vbioutp = NULL;
 	int i, len = 0, rc = 1;
@@ -521,6 +521,8 @@ static inline int au0828_isoc_copy(struct au0828_dev *dev, struct urb *urb)
 	if (vbi_buf != NULL)
 		vbioutp = vb2_plane_vaddr(&vbi_buf->vb.vb2_buf, 0);

+	vbi_dma_q = &dev->vbiq;
+
 	for (i = 0; i < urb->number_of_packets; i++) {
 		int status = urb->iso_frame_desc[i].status;

--
2.40.0

Re: [PATCH] media: au0828: Move a variable assignment behind condition checks in au0828_isoc_copy()

[Hans Verkuil]

On 14/04/2023 21:10, Markus Elfring wrote:
> Date: Fri, 14 Apr 2023 21:00:45 +0200
> 
> The address of a data structure member was determined before
> a corresponding null pointer check in the implementation of
> the function “au0828_isoc_copy”.
> 
> Thus avoid the risk for undefined behaviour by moving the assignment
> for the variable “vbi_dma_q” behind some condition checks.

Just drop these lines instead:

        if (!dev)
                return 0;

If you analyze the code then you'll see that dev is never NULL.

> 
> This issue was detected by using the Coccinelle software.
> 
> Fixes: 7f8eacd2162a39ca7fc1240883118a786f147ccb ("V4L/DVB: Add closed captioning support for the HVR-950q")

This doesn't actually fix anything since nothing was wrong. Drop the
Fixes tag. Same for all the other patches.

Regards,

	Hans

> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
>  drivers/media/usb/au0828/au0828-video.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/usb/au0828/au0828-video.c b/drivers/media/usb/au0828/au0828-video.c
> index fd9fc43d47e0..c0c5f2ed65e3 100644
> --- a/drivers/media/usb/au0828/au0828-video.c
> +++ b/drivers/media/usb/au0828/au0828-video.c
> @@ -491,7 +491,7 @@ static inline int au0828_isoc_copy(struct au0828_dev *dev, struct urb *urb)
>  	struct au0828_buffer    *buf;
>  	struct au0828_buffer    *vbi_buf;
>  	struct au0828_dmaqueue  *dma_q = urb->context;
> -	struct au0828_dmaqueue  *vbi_dma_q = &dev->vbiq;
> +	struct au0828_dmaqueue  *vbi_dma_q;
>  	unsigned char *outp = NULL;
>  	unsigned char *vbioutp = NULL;
>  	int i, len = 0, rc = 1;
> @@ -521,6 +521,8 @@ static inline int au0828_isoc_copy(struct au0828_dev *dev, struct urb *urb)
>  	if (vbi_buf != NULL)
>  		vbioutp = vb2_plane_vaddr(&vbi_buf->vb.vb2_buf, 0);
> 
> +	vbi_dma_q = &dev->vbiq;
> +
>  	for (i = 0; i < urb->number_of_packets; i++) {
>  		int status = urb->iso_frame_desc[i].status;
> 
> --
> 2.40.0
> 

[cocci] [PATCH 0/5] media: au0828: Adjustments for four function implementations

[Markus Elfring]

Date: Mon, 17 Apr 2023 18:32:28 +0200

The deletion of an if statement was requested by Hans Verkuil.
This update triggered further change possibilities.

Markus Elfring (5):
  Delete a null pointer check in au0828_isoc_copy()
  Move variable assignments behind condition checks in au0828_isoc_copy()
  Return a status code only as a constant in au0828_isoc_copy()
  Delete an unnecessary return statement in two functions
  Use common error handling code in au0828_init_isoc()

 drivers/media/usb/au0828/au0828-video.c | 40 +++++++++++--------------
 1 file changed, 17 insertions(+), 23 deletions(-)

--
2.40.0

[cocci] [PATCH 1/5] media: au0828: Delete a null pointer check in au0828_isoc_copy()

[Markus Elfring]

Date: Mon, 17 Apr 2023 16:05:04 +0200

An extra null pointer check became unwanted for the input parameter
validation in the implementation of the function “au0828_isoc_copy”.
Thus omit an if statement at the beginning.

Link: https://lore.kernel.org/kernel-janitors/8153cc88-2cea-0528-9d54-bda72cbaac5b@xs4all.nl/
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/media/usb/au0828/au0828-video.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/media/usb/au0828/au0828-video.c b/drivers/media/usb/au0828/au0828-video.c
index fd9fc43d47e0..ce25ddc7fc7b 100644
--- a/drivers/media/usb/au0828/au0828-video.c
+++ b/drivers/media/usb/au0828/au0828-video.c
@@ -500,9 +500,6 @@ static inline int au0828_isoc_copy(struct au0828_dev *dev, struct urb *urb)
 	unsigned int vbi_field_size;
 	unsigned int remain, lencopy;

-	if (!dev)
-		return 0;
-
 	if (test_bit(DEV_DISCONNECTED, &dev->dev_state) ||
 	    test_bit(DEV_MISCONFIGURED, &dev->dev_state))
 		return 0;
--
2.40.0

[cocci] [PATCH 2/5] media: au0828: Move variable assignments behind condition checks in au0828_isoc_copy()

[Markus Elfring]

Date: Mon, 17 Apr 2023 16:47:24 +0200

Some local variables will be set to an appropriate value before usage.
Thus omit explicit initialisations at the beginning of this function.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/media/usb/au0828/au0828-video.c | 17 +++++++----------
 1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/media/usb/au0828/au0828-video.c b/drivers/media/usb/au0828/au0828-video.c
index ce25ddc7fc7b..27bb62e2b20c 100644
--- a/drivers/media/usb/au0828/au0828-video.c
+++ b/drivers/media/usb/au0828/au0828-video.c
@@ -490,11 +490,9 @@ static inline int au0828_isoc_copy(struct au0828_dev *dev, struct urb *urb)
 {
 	struct au0828_buffer    *buf;
 	struct au0828_buffer    *vbi_buf;
-	struct au0828_dmaqueue  *dma_q = urb->context;
-	struct au0828_dmaqueue  *vbi_dma_q = &dev->vbiq;
-	unsigned char *outp = NULL;
-	unsigned char *vbioutp = NULL;
-	int i, len = 0, rc = 1;
+	struct au0828_dmaqueue *dma_q, *vbi_dma_q;
+	unsigned char *outp, *vbioutp;
+	int i, len, rc = 1;
 	unsigned char *p;
 	unsigned char fbyte;
 	unsigned int vbi_field_size;
@@ -511,12 +509,11 @@ static inline int au0828_isoc_copy(struct au0828_dev *dev, struct urb *urb)
 	}

 	buf = dev->isoc_ctl.buf;
-	if (buf != NULL)
-		outp = vb2_plane_vaddr(&buf->vb.vb2_buf, 0);
-
+	outp = (buf ? vb2_plane_vaddr(&buf->vb.vb2_buf, 0) : NULL);
 	vbi_buf = dev->isoc_ctl.vbi_buf;
-	if (vbi_buf != NULL)
-		vbioutp = vb2_plane_vaddr(&vbi_buf->vb.vb2_buf, 0);
+	vbioutp = (vbi_buf ? vb2_plane_vaddr(&vbi_buf->vb.vb2_buf, 0) : NULL);
+	dma_q = urb->context;
+	vbi_dma_q = &dev->vbiq;

 	for (i = 0; i < urb->number_of_packets; i++) {
 		int status = urb->iso_frame_desc[i].status;
--
2.40.0

[cocci] [PATCH 3/5] media: au0828: Return a status code only as a constant in au0828_isoc_copy()

[Markus Elfring]

Date: Mon, 17 Apr 2023 17:06:00 +0200

* Return a status code without storing it in an intermediate variable.

* Delete the local variable “rc” which became unnecessary
  with this refactoring.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/media/usb/au0828/au0828-video.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/usb/au0828/au0828-video.c b/drivers/media/usb/au0828/au0828-video.c
index 27bb62e2b20c..448cc296f0f7 100644
--- a/drivers/media/usb/au0828/au0828-video.c
+++ b/drivers/media/usb/au0828/au0828-video.c
@@ -492,7 +492,7 @@ static inline int au0828_isoc_copy(struct au0828_dev *dev, struct urb *urb)
 	struct au0828_buffer    *vbi_buf;
 	struct au0828_dmaqueue *dma_q, *vbi_dma_q;
 	unsigned char *outp, *vbioutp;
-	int i, len, rc = 1;
+	int i, len;
 	unsigned char *p;
 	unsigned char fbyte;
 	unsigned int vbi_field_size;
@@ -613,7 +613,7 @@ static inline int au0828_isoc_copy(struct au0828_dev *dev, struct urb *urb)
 		if (dev->vbi_read >= vbi_field_size && buf != NULL)
 			au0828_copy_video(dev, dma_q, buf, p, outp, len);
 	}
-	return rc;
+	return 1;
 }

 void au0828_usb_v4l2_media_release(struct au0828_dev *dev)
--
2.40.0

[cocci] [PATCH 4/5] media: au0828: Delete an unnecessary return statement in two functions

[Markus Elfring]

Date: Mon, 17 Apr 2023 18:14:10 +0200

The script "checkpatch.pl" pointed information out like the following.

WARNING: void function return statements are not generally useful

Thus remove such a statement in the affected functions.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/media/usb/au0828/au0828-video.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/media/usb/au0828/au0828-video.c b/drivers/media/usb/au0828/au0828-video.c
index 448cc296f0f7..ce8050186a4c 100644
--- a/drivers/media/usb/au0828/au0828-video.c
+++ b/drivers/media/usb/au0828/au0828-video.c
@@ -405,8 +405,6 @@ static inline void get_next_buf(struct au0828_dmaqueue *dma_q,
 	dma_q->pos = 0;
 	(*buf)->vb_buf = (*buf)->mem;
 	dev->isoc_ctl.buf = *buf;
-
-	return;
 }

 static void au0828_copy_vbi(struct au0828_dev *dev,
@@ -480,7 +478,6 @@ static inline void vbi_get_next_buf(struct au0828_dmaqueue *dma_q,
 	dma_q->pos = 0;
 	(*buf)->vb_buf = (*buf)->mem;
 	dev->isoc_ctl.vbi_buf = *buf;
-	return;
 }

 /*
--
2.40.0

[cocci] [PATCH 5/5] media: au0828: Use common error handling code in au0828_init_isoc()

[Markus Elfring]

Date: Mon, 17 Apr 2023 18:32:10 +0200

Add two jump targets so that a bit of exception handling can be better
reused at the end of this function.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/media/usb/au0828/au0828-video.c | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/media/usb/au0828/au0828-video.c b/drivers/media/usb/au0828/au0828-video.c
index ce8050186a4c..9ca20f411ce8 100644
--- a/drivers/media/usb/au0828/au0828-video.c
+++ b/drivers/media/usb/au0828/au0828-video.c
@@ -232,8 +232,7 @@ static int au0828_init_isoc(struct au0828_dev *dev, int max_packets,
 		urb = usb_alloc_urb(max_packets, GFP_KERNEL);
 		if (!urb) {
 			au0828_isocdbg("cannot allocate URB\n");
-			au0828_uninit_isoc(dev);
-			return -ENOMEM;
+			goto e_nomem;
 		}
 		dev->isoc_ctl.urb[i] = urb;

@@ -241,8 +240,7 @@ static int au0828_init_isoc(struct au0828_dev *dev, int max_packets,
 			sb_size, GFP_KERNEL, &urb->transfer_dma);
 		if (!dev->isoc_ctl.transfer_buffer[i]) {
 			au0828_isocdbg("cannot allocate transfer buffer\n");
-			au0828_uninit_isoc(dev);
-			return -ENOMEM;
+			goto e_nomem;
 		}
 		memset(dev->isoc_ctl.transfer_buffer[i], 0, sb_size);

@@ -271,12 +269,17 @@ static int au0828_init_isoc(struct au0828_dev *dev, int max_packets,
 		if (rc) {
 			au0828_isocdbg("submit of urb %i failed (error=%i)\n",
 				       i, rc);
-			au0828_uninit_isoc(dev);
-			return rc;
+			goto uninit_isoc;
 		}
 	}

 	return 0;
+
+e_nomem:
+	rc = -ENOMEM;
+uninit_isoc:
+	au0828_uninit_isoc(dev);
+	return rc;
 }

 /*
--
2.40.0

[cocci] [PATCH 0/9] GPU-DRM-nouveau: Adjustments for seven function implementations

[Markus Elfring]

Date: Sun, 16 Apr 2023 11:22:23 +0200

Several update suggestions were taken into account
from static source code analysis.

Markus Elfring (9):
  debugfs: Move an expression into a function call parameter
    in nouveau_debugfs_pstate_set()
  debugfs: Move a variable assignment behind a null pointer check
    in nouveau_debugfs_pstate_get()
  debugfs: Use seq_putc()
    in nouveau_debugfs_pstate_get()
  debugfs: Replace five seq_printf() calls by seq_puts()
    in nouveau_debugfs_pstate_get()
  power_budget: Move an expression into a macro call parameter
    in nvbios_power_budget_header()
  clk: Move a variable assignment behind a null pointer check
    in nvkm_pstate_new()
  pci: Move a variable assignment behind condition checks
    in nvkm_pcie_set_link()
  pci: Move an expression into a function call parameter
    in nvkm_pcie_set_link()
  therm: Move an assignment statement behind a null pointer check
    in two functions

 drivers/gpu/drm/nouveau/nouveau_debugfs.c     | 19 ++++++++++---------
 .../nouveau/nvkm/subdev/bios/power_budget.c   |  3 +--
 .../gpu/drm/nouveau/nvkm/subdev/clk/base.c    |  2 +-
 .../gpu/drm/nouveau/nvkm/subdev/pci/pcie.c    |  7 +++----
 .../drm/nouveau/nvkm/subdev/therm/fanpwm.c    |  2 +-
 .../drm/nouveau/nvkm/subdev/therm/fantog.c    |  2 +-
 6 files changed, 17 insertions(+), 18 deletions(-)

--
2.40.0

[Nouveau] [PATCH 0/9] GPU-DRM-nouveau: Adjustments for seven function implementations

[Markus Elfring]

Date: Sun, 16 Apr 2023 11:22:23 +0200

Several update suggestions were taken into account
from static source code analysis.

Markus Elfring (9):
  debugfs: Move an expression into a function call parameter
    in nouveau_debugfs_pstate_set()
  debugfs: Move a variable assignment behind a null pointer check
    in nouveau_debugfs_pstate_get()
  debugfs: Use seq_putc()
    in nouveau_debugfs_pstate_get()
  debugfs: Replace five seq_printf() calls by seq_puts()
    in nouveau_debugfs_pstate_get()
  power_budget: Move an expression into a macro call parameter
    in nvbios_power_budget_header()
  clk: Move a variable assignment behind a null pointer check
    in nvkm_pstate_new()
  pci: Move a variable assignment behind condition checks
    in nvkm_pcie_set_link()
  pci: Move an expression into a function call parameter
    in nvkm_pcie_set_link()
  therm: Move an assignment statement behind a null pointer check
    in two functions

 drivers/gpu/drm/nouveau/nouveau_debugfs.c     | 19 ++++++++++---------
 .../nouveau/nvkm/subdev/bios/power_budget.c   |  3 +--
 .../gpu/drm/nouveau/nvkm/subdev/clk/base.c    |  2 +-
 .../gpu/drm/nouveau/nvkm/subdev/pci/pcie.c    |  7 +++----
 .../drm/nouveau/nvkm/subdev/therm/fanpwm.c    |  2 +-
 .../drm/nouveau/nvkm/subdev/therm/fantog.c    |  2 +-
 6 files changed, 17 insertions(+), 18 deletions(-)

--
2.40.0

[PATCH 0/9] GPU-DRM-nouveau: Adjustments for seven function implementations

[Markus Elfring]

Date: Sun, 16 Apr 2023 11:22:23 +0200

Several update suggestions were taken into account
from static source code analysis.

Markus Elfring (9):
  debugfs: Move an expression into a function call parameter
    in nouveau_debugfs_pstate_set()
  debugfs: Move a variable assignment behind a null pointer check
    in nouveau_debugfs_pstate_get()
  debugfs: Use seq_putc()
    in nouveau_debugfs_pstate_get()
  debugfs: Replace five seq_printf() calls by seq_puts()
    in nouveau_debugfs_pstate_get()
  power_budget: Move an expression into a macro call parameter
    in nvbios_power_budget_header()
  clk: Move a variable assignment behind a null pointer check
    in nvkm_pstate_new()
  pci: Move a variable assignment behind condition checks
    in nvkm_pcie_set_link()
  pci: Move an expression into a function call parameter
    in nvkm_pcie_set_link()
  therm: Move an assignment statement behind a null pointer check
    in two functions

 drivers/gpu/drm/nouveau/nouveau_debugfs.c     | 19 ++++++++++---------
 .../nouveau/nvkm/subdev/bios/power_budget.c   |  3 +--
 .../gpu/drm/nouveau/nvkm/subdev/clk/base.c    |  2 +-
 .../gpu/drm/nouveau/nvkm/subdev/pci/pcie.c    |  7 +++----
 .../drm/nouveau/nvkm/subdev/therm/fanpwm.c    |  2 +-
 .../drm/nouveau/nvkm/subdev/therm/fantog.c    |  2 +-
 6 files changed, 17 insertions(+), 18 deletions(-)

--
2.40.0

[cocci] [PATCH 1/9] drm/nouveau/debugfs: Move an expression into a function call parameter in nouveau_debugfs_pstate_set()

[Markus Elfring]

Date: Sat, 15 Apr 2023 21:06:06 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “nouveau_debugfs_pstate_set”.

Thus avoid the risk for undefined behaviour by moving the usage
of an expression into a parameter for a function call at the end.

This issue was detected by using the Coccinelle software.

Fixes: 6e9fc177399f08446293fec7607913fdbc95e191 ("drm/nouveau/debugfs: add copy of sysfs pstate interface ported to debugfs")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/nouveau/nouveau_debugfs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
index 2a36d1ca8fda..44e26b6e74c7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
+++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
@@ -144,7 +144,6 @@ nouveau_debugfs_pstate_set(struct file *file, const char __user *ubuf,
 	struct seq_file *m = file->private_data;
 	struct drm_device *drm = m->private;
 	struct nouveau_debugfs *debugfs = nouveau_debugfs(drm);
-	struct nvif_object *ctrl = &debugfs->ctrl;
 	struct nvif_control_pstate_user_v0 args = { .pwrsrc = -EINVAL };
 	char buf[32] = {}, *tmp, *cur = buf;
 	long value, ret;
@@ -188,7 +187,8 @@ nouveau_debugfs_pstate_set(struct file *file, const char __user *ubuf,
 		return ret;
 	}

-	ret = nvif_mthd(ctrl, NVIF_CONTROL_PSTATE_USER, &args, sizeof(args));
+	ret = nvif_mthd(&debugfs->ctrl, NVIF_CONTROL_PSTATE_USER,
+			&args, sizeof(args));
 	pm_runtime_put_autosuspend(drm->dev);
 	if (ret < 0)
 		return ret;
--
2.40.0

[Nouveau] [PATCH 1/9] drm/nouveau/debugfs: Move an expression into a function call parameter in nouveau_debugfs_pstate_set()

[Markus Elfring]

Date: Sat, 15 Apr 2023 21:06:06 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “nouveau_debugfs_pstate_set”.

Thus avoid the risk for undefined behaviour by moving the usage
of an expression into a parameter for a function call at the end.

This issue was detected by using the Coccinelle software.

Fixes: 6e9fc177399f08446293fec7607913fdbc95e191 ("drm/nouveau/debugfs: add copy of sysfs pstate interface ported to debugfs")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/nouveau/nouveau_debugfs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
index 2a36d1ca8fda..44e26b6e74c7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
+++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
@@ -144,7 +144,6 @@ nouveau_debugfs_pstate_set(struct file *file, const char __user *ubuf,
 	struct seq_file *m = file->private_data;
 	struct drm_device *drm = m->private;
 	struct nouveau_debugfs *debugfs = nouveau_debugfs(drm);
-	struct nvif_object *ctrl = &debugfs->ctrl;
 	struct nvif_control_pstate_user_v0 args = { .pwrsrc = -EINVAL };
 	char buf[32] = {}, *tmp, *cur = buf;
 	long value, ret;
@@ -188,7 +187,8 @@ nouveau_debugfs_pstate_set(struct file *file, const char __user *ubuf,
 		return ret;
 	}

-	ret = nvif_mthd(ctrl, NVIF_CONTROL_PSTATE_USER, &args, sizeof(args));
+	ret = nvif_mthd(&debugfs->ctrl, NVIF_CONTROL_PSTATE_USER,
+			&args, sizeof(args));
 	pm_runtime_put_autosuspend(drm->dev);
 	if (ret < 0)
 		return ret;
--
2.40.0

[PATCH 1/9] drm/nouveau/debugfs: Move an expression into a function call parameter in nouveau_debugfs_pstate_set()

[Markus Elfring]

Date: Sat, 15 Apr 2023 21:06:06 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “nouveau_debugfs_pstate_set”.

Thus avoid the risk for undefined behaviour by moving the usage
of an expression into a parameter for a function call at the end.

This issue was detected by using the Coccinelle software.

Fixes: 6e9fc177399f08446293fec7607913fdbc95e191 ("drm/nouveau/debugfs: add copy of sysfs pstate interface ported to debugfs")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/nouveau/nouveau_debugfs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
index 2a36d1ca8fda..44e26b6e74c7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
+++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
@@ -144,7 +144,6 @@ nouveau_debugfs_pstate_set(struct file *file, const char __user *ubuf,
 	struct seq_file *m = file->private_data;
 	struct drm_device *drm = m->private;
 	struct nouveau_debugfs *debugfs = nouveau_debugfs(drm);
-	struct nvif_object *ctrl = &debugfs->ctrl;
 	struct nvif_control_pstate_user_v0 args = { .pwrsrc = -EINVAL };
 	char buf[32] = {}, *tmp, *cur = buf;
 	long value, ret;
@@ -188,7 +187,8 @@ nouveau_debugfs_pstate_set(struct file *file, const char __user *ubuf,
 		return ret;
 	}

-	ret = nvif_mthd(ctrl, NVIF_CONTROL_PSTATE_USER, &args, sizeof(args));
+	ret = nvif_mthd(&debugfs->ctrl, NVIF_CONTROL_PSTATE_USER,
+			&args, sizeof(args));
 	pm_runtime_put_autosuspend(drm->dev);
 	if (ret < 0)
 		return ret;
--
2.40.0

[cocci] [PATCH 2/9] drm/nouveau/debugfs: Move a variable assignment behind a null pointer check in nouveau_debugfs_pstate_get()

[Markus Elfring]

Date: Sat, 15 Apr 2023 21:24:43 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “nouveau_debugfs_pstate_get”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “ctrl” behind the null pointer check.

This issue was detected by using the Coccinelle software.

Fixes: 6e9fc177399f08446293fec7607913fdbc95e191 ("drm/nouveau/debugfs: add copy of sysfs pstate interface ported to debugfs")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/nouveau/nouveau_debugfs.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
index 44e26b6e74c7..a859a086f308 100644
--- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
+++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
@@ -73,13 +73,14 @@ nouveau_debugfs_pstate_get(struct seq_file *m, void *data)
 {
 	struct drm_device *drm = m->private;
 	struct nouveau_debugfs *debugfs = nouveau_debugfs(drm);
-	struct nvif_object *ctrl = &debugfs->ctrl;
+	struct nvif_object *ctrl;
 	struct nvif_control_pstate_info_v0 info = {};
 	int ret, i;

 	if (!debugfs)
 		return -ENODEV;

+	ctrl = &debugfs->ctrl;
 	ret = nvif_mthd(ctrl, NVIF_CONTROL_PSTATE_INFO, &info, sizeof(info));
 	if (ret)
 		return ret;
--
2.40.0

[Nouveau] [PATCH 2/9] drm/nouveau/debugfs: Move a variable assignment behind a null pointer check in nouveau_debugfs_pstate_get()

[Markus Elfring]

Date: Sat, 15 Apr 2023 21:24:43 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “nouveau_debugfs_pstate_get”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “ctrl” behind the null pointer check.

This issue was detected by using the Coccinelle software.

Fixes: 6e9fc177399f08446293fec7607913fdbc95e191 ("drm/nouveau/debugfs: add copy of sysfs pstate interface ported to debugfs")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/nouveau/nouveau_debugfs.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
index 44e26b6e74c7..a859a086f308 100644
--- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
+++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
@@ -73,13 +73,14 @@ nouveau_debugfs_pstate_get(struct seq_file *m, void *data)
 {
 	struct drm_device *drm = m->private;
 	struct nouveau_debugfs *debugfs = nouveau_debugfs(drm);
-	struct nvif_object *ctrl = &debugfs->ctrl;
+	struct nvif_object *ctrl;
 	struct nvif_control_pstate_info_v0 info = {};
 	int ret, i;

 	if (!debugfs)
 		return -ENODEV;

+	ctrl = &debugfs->ctrl;
 	ret = nvif_mthd(ctrl, NVIF_CONTROL_PSTATE_INFO, &info, sizeof(info));
 	if (ret)
 		return ret;
--
2.40.0

[PATCH 2/9] drm/nouveau/debugfs: Move a variable assignment behind a null pointer check in nouveau_debugfs_pstate_get()

[Markus Elfring]

Date: Sat, 15 Apr 2023 21:24:43 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “nouveau_debugfs_pstate_get”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “ctrl” behind the null pointer check.

This issue was detected by using the Coccinelle software.

Fixes: 6e9fc177399f08446293fec7607913fdbc95e191 ("drm/nouveau/debugfs: add copy of sysfs pstate interface ported to debugfs")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/nouveau/nouveau_debugfs.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
index 44e26b6e74c7..a859a086f308 100644
--- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
+++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
@@ -73,13 +73,14 @@ nouveau_debugfs_pstate_get(struct seq_file *m, void *data)
 {
 	struct drm_device *drm = m->private;
 	struct nouveau_debugfs *debugfs = nouveau_debugfs(drm);
-	struct nvif_object *ctrl = &debugfs->ctrl;
+	struct nvif_object *ctrl;
 	struct nvif_control_pstate_info_v0 info = {};
 	int ret, i;

 	if (!debugfs)
 		return -ENODEV;

+	ctrl = &debugfs->ctrl;
 	ret = nvif_mthd(ctrl, NVIF_CONTROL_PSTATE_INFO, &info, sizeof(info));
 	if (ret)
 		return ret;
--
2.40.0

[Nouveau] [PATCH 3/9] drm/nouveau/debugfs: Use seq_putc() in nouveau_debugfs_pstate_get()

[Markus Elfring]

Date: Sat, 15 Apr 2023 21:48:47 +0200

A single character (line break) should be put into a sequence.
Thus use the corresponding function “seq_putc”.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/nouveau/nouveau_debugfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
index a859a086f308..13c82eea8828 100644
--- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
+++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
@@ -132,7 +132,7 @@ nouveau_debugfs_pstate_get(struct seq_file *m, void *data)
 				seq_printf(m, " DC");
 		}

-		seq_printf(m, "\n");
+		seq_putc(m, '\n');
 	}

 	return 0;
--
2.40.0

[PATCH 3/9] drm/nouveau/debugfs: Use seq_putc() in nouveau_debugfs_pstate_get()

[Markus Elfring]

Date: Sat, 15 Apr 2023 21:48:47 +0200

A single character (line break) should be put into a sequence.
Thus use the corresponding function “seq_putc”.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/nouveau/nouveau_debugfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
index a859a086f308..13c82eea8828 100644
--- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
+++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
@@ -132,7 +132,7 @@ nouveau_debugfs_pstate_get(struct seq_file *m, void *data)
 				seq_printf(m, " DC");
 		}

-		seq_printf(m, "\n");
+		seq_putc(m, '\n');
 	}

 	return 0;
--
2.40.0

[cocci] [PATCH 3/9] drm/nouveau/debugfs: Use seq_putc() in nouveau_debugfs_pstate_get()

[Markus Elfring]

Date: Sat, 15 Apr 2023 21:48:47 +0200

A single character (line break) should be put into a sequence.
Thus use the corresponding function “seq_putc”.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/nouveau/nouveau_debugfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
index a859a086f308..13c82eea8828 100644
--- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
+++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
@@ -132,7 +132,7 @@ nouveau_debugfs_pstate_get(struct seq_file *m, void *data)
 				seq_printf(m, " DC");
 		}

-		seq_printf(m, "\n");
+		seq_putc(m, '\n');
 	}

 	return 0;
--
2.40.0

[Nouveau] [PATCH 4/9] drm/nouveau/debugfs: Replace five seq_printf() calls by seq_puts() in nouveau_debugfs_pstate_get()

[Markus Elfring]

Date: Sat, 15 Apr 2023 22:02:31 +0200

Five strings which did not contain a data format specification should
be put into a sequence. Thus use the corresponding function “seq_puts”.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/nouveau/nouveau_debugfs.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
index 13c82eea8828..99d022a91afc 100644
--- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
+++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
@@ -120,16 +120,16 @@ nouveau_debugfs_pstate_get(struct seq_file *m, void *data)

 		if (state >= 0) {
 			if (info.ustate_ac == state)
-				seq_printf(m, " AC");
+				seq_puts(m, " AC");
 			if (info.ustate_dc == state)
-				seq_printf(m, " DC");
+				seq_puts(m, " DC");
 			if (info.pstate == state)
-				seq_printf(m, " *");
+				seq_puts(m, " *");
 		} else {
 			if (info.ustate_ac < -1)
-				seq_printf(m, " AC");
+				seq_puts(m, " AC");
 			if (info.ustate_dc < -1)
-				seq_printf(m, " DC");
+				seq_puts(m, " DC");
 		}

 		seq_putc(m, '\n');
--
2.40.0

[PATCH 4/9] drm/nouveau/debugfs: Replace five seq_printf() calls by seq_puts() in nouveau_debugfs_pstate_get()

[Markus Elfring]

Date: Sat, 15 Apr 2023 22:02:31 +0200

Five strings which did not contain a data format specification should
be put into a sequence. Thus use the corresponding function “seq_puts”.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/nouveau/nouveau_debugfs.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
index 13c82eea8828..99d022a91afc 100644
--- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
+++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
@@ -120,16 +120,16 @@ nouveau_debugfs_pstate_get(struct seq_file *m, void *data)

 		if (state >= 0) {
 			if (info.ustate_ac == state)
-				seq_printf(m, " AC");
+				seq_puts(m, " AC");
 			if (info.ustate_dc == state)
-				seq_printf(m, " DC");
+				seq_puts(m, " DC");
 			if (info.pstate == state)
-				seq_printf(m, " *");
+				seq_puts(m, " *");
 		} else {
 			if (info.ustate_ac < -1)
-				seq_printf(m, " AC");
+				seq_puts(m, " AC");
 			if (info.ustate_dc < -1)
-				seq_printf(m, " DC");
+				seq_puts(m, " DC");
 		}

 		seq_putc(m, '\n');
--
2.40.0

[cocci] [PATCH 4/9] drm/nouveau/debugfs: Replace five seq_printf() calls by seq_puts() in nouveau_debugfs_pstate_get()

[Markus Elfring]

Date: Sat, 15 Apr 2023 22:02:31 +0200

Five strings which did not contain a data format specification should
be put into a sequence. Thus use the corresponding function “seq_puts”.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/nouveau/nouveau_debugfs.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
index 13c82eea8828..99d022a91afc 100644
--- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
+++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
@@ -120,16 +120,16 @@ nouveau_debugfs_pstate_get(struct seq_file *m, void *data)

 		if (state >= 0) {
 			if (info.ustate_ac == state)
-				seq_printf(m, " AC");
+				seq_puts(m, " AC");
 			if (info.ustate_dc == state)
-				seq_printf(m, " DC");
+				seq_puts(m, " DC");
 			if (info.pstate == state)
-				seq_printf(m, " *");
+				seq_puts(m, " *");
 		} else {
 			if (info.ustate_ac < -1)
-				seq_printf(m, " AC");
+				seq_puts(m, " AC");
 			if (info.ustate_dc < -1)
-				seq_printf(m, " DC");
+				seq_puts(m, " DC");
 		}

 		seq_putc(m, '\n');
--
2.40.0

[Nouveau] [PATCH 5/9] drm/nouveau/bios/power_budget: Move an expression into a macro call parameter in nvbios_power_budget_header()

[Markus Elfring]

Date: Sat, 15 Apr 2023 22:30:30 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “nvbios_power_budget_header”.

Thus avoid the risk for undefined behaviour by moving the usage
of an expression into a parameter for a macro call in one if branch.

This issue was detected by using the Coccinelle software.

Fixes: e5f8eabc0077ea3f77b3362e28d3969ae62e70f0 ("drm/nouveau/bios/power_budget: Add basic power budget parsing")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/power_budget.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/power_budget.c b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/power_budget.c
index 03d2f970a29f..2ba992bdb19d 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/power_budget.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/power_budget.c
@@ -59,7 +59,6 @@ int
 nvbios_power_budget_header(struct nvkm_bios *bios,
                            struct nvbios_power_budget *budget)
 {
-	struct nvkm_subdev *subdev = &bios->subdev;
 	u8 ver, hdr, cnt, len, cap_entry;
 	u32 header;

@@ -82,7 +81,7 @@ nvbios_power_budget_header(struct nvkm_bios *bios,
 	}

 	if (cap_entry >= cnt && cap_entry != 0xff) {
-		nvkm_warn(subdev,
+		nvkm_warn(&bios->subdev,
 		          "invalid cap_entry in power budget table found\n");
 		budget->cap_entry = 0xff;
 		return -EINVAL;
--
2.40.0

[PATCH 5/9] drm/nouveau/bios/power_budget: Move an expression into a macro call parameter in nvbios_power_budget_header()

[Markus Elfring]

Date: Sat, 15 Apr 2023 22:30:30 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “nvbios_power_budget_header”.

Thus avoid the risk for undefined behaviour by moving the usage
of an expression into a parameter for a macro call in one if branch.

This issue was detected by using the Coccinelle software.

Fixes: e5f8eabc0077ea3f77b3362e28d3969ae62e70f0 ("drm/nouveau/bios/power_budget: Add basic power budget parsing")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/power_budget.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/power_budget.c b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/power_budget.c
index 03d2f970a29f..2ba992bdb19d 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/power_budget.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/power_budget.c
@@ -59,7 +59,6 @@ int
 nvbios_power_budget_header(struct nvkm_bios *bios,
                            struct nvbios_power_budget *budget)
 {
-	struct nvkm_subdev *subdev = &bios->subdev;
 	u8 ver, hdr, cnt, len, cap_entry;
 	u32 header;

@@ -82,7 +81,7 @@ nvbios_power_budget_header(struct nvkm_bios *bios,
 	}

 	if (cap_entry >= cnt && cap_entry != 0xff) {
-		nvkm_warn(subdev,
+		nvkm_warn(&bios->subdev,
 		          "invalid cap_entry in power budget table found\n");
 		budget->cap_entry = 0xff;
 		return -EINVAL;
--
2.40.0

[cocci] [PATCH 5/9] drm/nouveau/bios/power_budget: Move an expression into a macro call parameter in nvbios_power_budget_header()

[Markus Elfring]

Date: Sat, 15 Apr 2023 22:30:30 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “nvbios_power_budget_header”.

Thus avoid the risk for undefined behaviour by moving the usage
of an expression into a parameter for a macro call in one if branch.

This issue was detected by using the Coccinelle software.

Fixes: e5f8eabc0077ea3f77b3362e28d3969ae62e70f0 ("drm/nouveau/bios/power_budget: Add basic power budget parsing")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/power_budget.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/power_budget.c b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/power_budget.c
index 03d2f970a29f..2ba992bdb19d 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/power_budget.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/power_budget.c
@@ -59,7 +59,6 @@ int
 nvbios_power_budget_header(struct nvkm_bios *bios,
                            struct nvbios_power_budget *budget)
 {
-	struct nvkm_subdev *subdev = &bios->subdev;
 	u8 ver, hdr, cnt, len, cap_entry;
 	u32 header;

@@ -82,7 +81,7 @@ nvbios_power_budget_header(struct nvkm_bios *bios,
 	}

 	if (cap_entry >= cnt && cap_entry != 0xff) {
-		nvkm_warn(subdev,
+		nvkm_warn(&bios->subdev,
 		          "invalid cap_entry in power budget table found\n");
 		budget->cap_entry = 0xff;
 		return -EINVAL;
--
2.40.0

[Nouveau] [PATCH 6/9] drm/nouveau/clk: Move a variable assignment behind a null pointer check in nvkm_pstate_new()

[Markus Elfring]

Date: Sun, 16 Apr 2023 07:45:54 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “nvkm_pstate_new”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “cstate” behind the null pointer check.

This issue was detected by using the Coccinelle software.

Fixes: 7c856522069755ab9d163a24ac332cd3cb35fe30 ("drm/nouveau/clk: implement power state and engine clock control in core")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
index da07a2fbef06..178dc56909c2 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
@@ -417,7 +417,6 @@ nvkm_pstate_new(struct nvkm_clk *clk, int idx)
 		return 0;

 	pstate = kzalloc(sizeof(*pstate), GFP_KERNEL);
-	cstate = &pstate->base;
 	if (!pstate)
 		return -ENOMEM;

@@ -427,6 +426,7 @@ nvkm_pstate_new(struct nvkm_clk *clk, int idx)
 	pstate->fanspeed = perfE.fanspeed;
 	pstate->pcie_speed = perfE.pcie_speed;
 	pstate->pcie_width = perfE.pcie_width;
+	cstate = &pstate->base;
 	cstate->voltage = perfE.voltage;
 	cstate->domain[nv_clk_src_core] = perfE.core;
 	cstate->domain[nv_clk_src_shader] = perfE.shader;
--
2.40.0

[PATCH 6/9] drm/nouveau/clk: Move a variable assignment behind a null pointer check in nvkm_pstate_new()

[Markus Elfring]

Date: Sun, 16 Apr 2023 07:45:54 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “nvkm_pstate_new”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “cstate” behind the null pointer check.

This issue was detected by using the Coccinelle software.

Fixes: 7c856522069755ab9d163a24ac332cd3cb35fe30 ("drm/nouveau/clk: implement power state and engine clock control in core")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
index da07a2fbef06..178dc56909c2 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
@@ -417,7 +417,6 @@ nvkm_pstate_new(struct nvkm_clk *clk, int idx)
 		return 0;

 	pstate = kzalloc(sizeof(*pstate), GFP_KERNEL);
-	cstate = &pstate->base;
 	if (!pstate)
 		return -ENOMEM;

@@ -427,6 +426,7 @@ nvkm_pstate_new(struct nvkm_clk *clk, int idx)
 	pstate->fanspeed = perfE.fanspeed;
 	pstate->pcie_speed = perfE.pcie_speed;
 	pstate->pcie_width = perfE.pcie_width;
+	cstate = &pstate->base;
 	cstate->voltage = perfE.voltage;
 	cstate->domain[nv_clk_src_core] = perfE.core;
 	cstate->domain[nv_clk_src_shader] = perfE.shader;
--
2.40.0

[cocci] [PATCH 6/9] drm/nouveau/clk: Move a variable assignment behind a null pointer check in nvkm_pstate_new()

[Markus Elfring]

Date: Sun, 16 Apr 2023 07:45:54 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “nvkm_pstate_new”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “cstate” behind the null pointer check.

This issue was detected by using the Coccinelle software.

Fixes: 7c856522069755ab9d163a24ac332cd3cb35fe30 ("drm/nouveau/clk: implement power state and engine clock control in core")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
index da07a2fbef06..178dc56909c2 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
@@ -417,7 +417,6 @@ nvkm_pstate_new(struct nvkm_clk *clk, int idx)
 		return 0;

 	pstate = kzalloc(sizeof(*pstate), GFP_KERNEL);
-	cstate = &pstate->base;
 	if (!pstate)
 		return -ENOMEM;

@@ -427,6 +426,7 @@ nvkm_pstate_new(struct nvkm_clk *clk, int idx)
 	pstate->fanspeed = perfE.fanspeed;
 	pstate->pcie_speed = perfE.pcie_speed;
 	pstate->pcie_width = perfE.pcie_width;
+	cstate = &pstate->base;
 	cstate->voltage = perfE.voltage;
 	cstate->domain[nv_clk_src_core] = perfE.core;
 	cstate->domain[nv_clk_src_shader] = perfE.shader;
--
2.40.0

[Nouveau] [PATCH 7/9] drm/nouveau/pci: Move a variable assignment behind condition checks in nvkm_pcie_set_link()

[Markus Elfring]

Date: Sun, 16 Apr 2023 08:18:40 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “nvkm_pcie_set_link”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “subdev” behind some condition checks.

This issue was detected by using the Coccinelle software.

Fixes: bcc19d9bf5cd8d49428c487adced1aa101271b18 ("drm/nouveau/pci: implement generic code for pcie speed change")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c
index d71e5db5028a..b295f100e1c1 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c
@@ -114,7 +114,7 @@ nvkm_pcie_init(struct nvkm_pci *pci)
 int
 nvkm_pcie_set_link(struct nvkm_pci *pci, enum nvkm_pcie_speed speed, u8 width)
 {
-	struct nvkm_subdev *subdev = &pci->subdev;
+	struct nvkm_subdev *subdev;
 	enum nvkm_pcie_speed cur_speed, max_speed;
 	struct pci_bus *pbus;
 	int ret;
@@ -126,6 +126,7 @@ nvkm_pcie_set_link(struct nvkm_pci *pci, enum nvkm_pcie_speed speed, u8 width)
 	if (!pci->func->pcie.set_link)
 		return -ENOSYS;

+	subdev = &pci->subdev;
 	nvkm_trace(subdev, "requested %s\n", nvkm_pcie_speeds[speed]);

 	if (pci->func->pcie.version(pci) < 2) {
--
2.40.0

[PATCH 7/9] drm/nouveau/pci: Move a variable assignment behind condition checks in nvkm_pcie_set_link()

[Markus Elfring]

Date: Sun, 16 Apr 2023 08:18:40 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “nvkm_pcie_set_link”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “subdev” behind some condition checks.

This issue was detected by using the Coccinelle software.

Fixes: bcc19d9bf5cd8d49428c487adced1aa101271b18 ("drm/nouveau/pci: implement generic code for pcie speed change")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c
index d71e5db5028a..b295f100e1c1 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c
@@ -114,7 +114,7 @@ nvkm_pcie_init(struct nvkm_pci *pci)
 int
 nvkm_pcie_set_link(struct nvkm_pci *pci, enum nvkm_pcie_speed speed, u8 width)
 {
-	struct nvkm_subdev *subdev = &pci->subdev;
+	struct nvkm_subdev *subdev;
 	enum nvkm_pcie_speed cur_speed, max_speed;
 	struct pci_bus *pbus;
 	int ret;
@@ -126,6 +126,7 @@ nvkm_pcie_set_link(struct nvkm_pci *pci, enum nvkm_pcie_speed speed, u8 width)
 	if (!pci->func->pcie.set_link)
 		return -ENOSYS;

+	subdev = &pci->subdev;
 	nvkm_trace(subdev, "requested %s\n", nvkm_pcie_speeds[speed]);

 	if (pci->func->pcie.version(pci) < 2) {
--
2.40.0

[cocci] [PATCH 7/9] drm/nouveau/pci: Move a variable assignment behind condition checks in nvkm_pcie_set_link()

[Markus Elfring]

Date: Sun, 16 Apr 2023 08:18:40 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “nvkm_pcie_set_link”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “subdev” behind some condition checks.

This issue was detected by using the Coccinelle software.

Fixes: bcc19d9bf5cd8d49428c487adced1aa101271b18 ("drm/nouveau/pci: implement generic code for pcie speed change")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c
index d71e5db5028a..b295f100e1c1 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c
@@ -114,7 +114,7 @@ nvkm_pcie_init(struct nvkm_pci *pci)
 int
 nvkm_pcie_set_link(struct nvkm_pci *pci, enum nvkm_pcie_speed speed, u8 width)
 {
-	struct nvkm_subdev *subdev = &pci->subdev;
+	struct nvkm_subdev *subdev;
 	enum nvkm_pcie_speed cur_speed, max_speed;
 	struct pci_bus *pbus;
 	int ret;
@@ -126,6 +126,7 @@ nvkm_pcie_set_link(struct nvkm_pci *pci, enum nvkm_pcie_speed speed, u8 width)
 	if (!pci->func->pcie.set_link)
 		return -ENOSYS;

+	subdev = &pci->subdev;
 	nvkm_trace(subdev, "requested %s\n", nvkm_pcie_speeds[speed]);

 	if (pci->func->pcie.version(pci) < 2) {
--
2.40.0

[Nouveau] [PATCH 8/9] drm/nouveau/pci: Move an expression into a function call parameter in nvkm_pcie_set_link()

[Markus Elfring]

Date: Sun, 16 Apr 2023 08:45:31 +0200

The variable “pbus” was read only once in the implementation of
the function “nvkm_pcie_set_link”.
Thus move the usage of an expression into a parameter for a function call.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c
index b295f100e1c1..dd18d9d0bade 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c
@@ -116,12 +116,10 @@ nvkm_pcie_set_link(struct nvkm_pci *pci, enum nvkm_pcie_speed speed, u8 width)
 {
 	struct nvkm_subdev *subdev;
 	enum nvkm_pcie_speed cur_speed, max_speed;
-	struct pci_bus *pbus;
 	int ret;

 	if (!pci || !pci_is_pcie(pci->pdev))
 		return 0;
-	pbus = pci->pdev->bus;

 	if (!pci->func->pcie.set_link)
 		return -ENOSYS;
@@ -135,7 +133,7 @@ nvkm_pcie_set_link(struct nvkm_pci *pci, enum nvkm_pcie_speed speed, u8 width)
 	}

 	cur_speed = pci->func->pcie.cur_speed(pci);
-	max_speed = min(nvkm_pcie_speed(pbus->max_bus_speed),
+	max_speed = min(nvkm_pcie_speed(pci->pdev->bus->max_bus_speed),
 			pci->func->pcie.max_speed(pci));

 	nvkm_trace(subdev, "current speed: %s\n", nvkm_pcie_speeds[cur_speed]);
--
2.40.0

[PATCH 8/9] drm/nouveau/pci: Move an expression into a function call parameter in nvkm_pcie_set_link()

[Markus Elfring]

Date: Sun, 16 Apr 2023 08:45:31 +0200

The variable “pbus” was read only once in the implementation of
the function “nvkm_pcie_set_link”.
Thus move the usage of an expression into a parameter for a function call.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c
index b295f100e1c1..dd18d9d0bade 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c
@@ -116,12 +116,10 @@ nvkm_pcie_set_link(struct nvkm_pci *pci, enum nvkm_pcie_speed speed, u8 width)
 {
 	struct nvkm_subdev *subdev;
 	enum nvkm_pcie_speed cur_speed, max_speed;
-	struct pci_bus *pbus;
 	int ret;

 	if (!pci || !pci_is_pcie(pci->pdev))
 		return 0;
-	pbus = pci->pdev->bus;

 	if (!pci->func->pcie.set_link)
 		return -ENOSYS;
@@ -135,7 +133,7 @@ nvkm_pcie_set_link(struct nvkm_pci *pci, enum nvkm_pcie_speed speed, u8 width)
 	}

 	cur_speed = pci->func->pcie.cur_speed(pci);
-	max_speed = min(nvkm_pcie_speed(pbus->max_bus_speed),
+	max_speed = min(nvkm_pcie_speed(pci->pdev->bus->max_bus_speed),
 			pci->func->pcie.max_speed(pci));

 	nvkm_trace(subdev, "current speed: %s\n", nvkm_pcie_speeds[cur_speed]);
--
2.40.0

[cocci] [PATCH 8/9] drm/nouveau/pci: Move an expression into a function call parameter in nvkm_pcie_set_link()

[Markus Elfring]

Date: Sun, 16 Apr 2023 08:45:31 +0200

The variable “pbus” was read only once in the implementation of
the function “nvkm_pcie_set_link”.
Thus move the usage of an expression into a parameter for a function call.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c
index b295f100e1c1..dd18d9d0bade 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c
@@ -116,12 +116,10 @@ nvkm_pcie_set_link(struct nvkm_pci *pci, enum nvkm_pcie_speed speed, u8 width)
 {
 	struct nvkm_subdev *subdev;
 	enum nvkm_pcie_speed cur_speed, max_speed;
-	struct pci_bus *pbus;
 	int ret;

 	if (!pci || !pci_is_pcie(pci->pdev))
 		return 0;
-	pbus = pci->pdev->bus;

 	if (!pci->func->pcie.set_link)
 		return -ENOSYS;
@@ -135,7 +133,7 @@ nvkm_pcie_set_link(struct nvkm_pci *pci, enum nvkm_pcie_speed speed, u8 width)
 	}

 	cur_speed = pci->func->pcie.cur_speed(pci);
-	max_speed = min(nvkm_pcie_speed(pbus->max_bus_speed),
+	max_speed = min(nvkm_pcie_speed(pci->pdev->bus->max_bus_speed),
 			pci->func->pcie.max_speed(pci));

 	nvkm_trace(subdev, "current speed: %s\n", nvkm_pcie_speeds[cur_speed]);
--
2.40.0

[Nouveau] [PATCH 9/9] drm/nouveau/therm: Move an assignment statement behind a null pointer check in two functions

[Markus Elfring]

Date: Sun, 16 Apr 2023 10:50:12 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the functions “nvkm_fanpwm_create” and “nvkm_fantog_create”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the data structure member “fan” behind two null pointer checks.

This issue was detected by using the Coccinelle software.

Fixes: da06b46b720687117178d3ee85a601762f1c36b5 ("drm/nouveau/therm: cosmetic changes")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/fanpwm.c | 2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/fantog.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/fanpwm.c b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/fanpwm.c
index 340f37a299dc..b13ba9b2f6be 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/fanpwm.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/fanpwm.c
@@ -98,10 +98,10 @@ nvkm_fanpwm_create(struct nvkm_therm *therm, struct dcb_gpio_func *func)
 		return -ENODEV;

 	fan = kzalloc(sizeof(*fan), GFP_KERNEL);
-	therm->fan = &fan->base;
 	if (!fan)
 		return -ENOMEM;

+	therm->fan = &fan->base;
 	fan->base.type = "PWM";
 	fan->base.get = nvkm_fanpwm_get;
 	fan->base.set = nvkm_fanpwm_set;
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/fantog.c b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/fantog.c
index ff9fbe7950e5..bfdf4ca5625c 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/fantog.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/fantog.c
@@ -100,10 +100,10 @@ nvkm_fantog_create(struct nvkm_therm *therm, struct dcb_gpio_func *func)
 	}

 	fan = kzalloc(sizeof(*fan), GFP_KERNEL);
-	therm->fan = &fan->base;
 	if (!fan)
 		return -ENOMEM;

+	therm->fan = &fan->base;
 	fan->base.type = "toggle";
 	fan->base.get = nvkm_fantog_get;
 	fan->base.set = nvkm_fantog_set;
--
2.40.0

[PATCH 9/9] drm/nouveau/therm: Move an assignment statement behind a null pointer check in two functions

[Markus Elfring]

Date: Sun, 16 Apr 2023 10:50:12 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the functions “nvkm_fanpwm_create” and “nvkm_fantog_create”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the data structure member “fan” behind two null pointer checks.

This issue was detected by using the Coccinelle software.

Fixes: da06b46b720687117178d3ee85a601762f1c36b5 ("drm/nouveau/therm: cosmetic changes")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/fanpwm.c | 2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/fantog.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/fanpwm.c b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/fanpwm.c
index 340f37a299dc..b13ba9b2f6be 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/fanpwm.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/fanpwm.c
@@ -98,10 +98,10 @@ nvkm_fanpwm_create(struct nvkm_therm *therm, struct dcb_gpio_func *func)
 		return -ENODEV;

 	fan = kzalloc(sizeof(*fan), GFP_KERNEL);
-	therm->fan = &fan->base;
 	if (!fan)
 		return -ENOMEM;

+	therm->fan = &fan->base;
 	fan->base.type = "PWM";
 	fan->base.get = nvkm_fanpwm_get;
 	fan->base.set = nvkm_fanpwm_set;
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/fantog.c b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/fantog.c
index ff9fbe7950e5..bfdf4ca5625c 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/fantog.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/fantog.c
@@ -100,10 +100,10 @@ nvkm_fantog_create(struct nvkm_therm *therm, struct dcb_gpio_func *func)
 	}

 	fan = kzalloc(sizeof(*fan), GFP_KERNEL);
-	therm->fan = &fan->base;
 	if (!fan)
 		return -ENOMEM;

+	therm->fan = &fan->base;
 	fan->base.type = "toggle";
 	fan->base.get = nvkm_fantog_get;
 	fan->base.set = nvkm_fantog_set;
--
2.40.0

[cocci] [PATCH 9/9] drm/nouveau/therm: Move an assignment statement behind a null pointer check in two functions

[Markus Elfring]

Date: Sun, 16 Apr 2023 10:50:12 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the functions “nvkm_fanpwm_create” and “nvkm_fantog_create”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the data structure member “fan” behind two null pointer checks.

This issue was detected by using the Coccinelle software.

Fixes: da06b46b720687117178d3ee85a601762f1c36b5 ("drm/nouveau/therm: cosmetic changes")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/fanpwm.c | 2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/fantog.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/fanpwm.c b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/fanpwm.c
index 340f37a299dc..b13ba9b2f6be 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/fanpwm.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/fanpwm.c
@@ -98,10 +98,10 @@ nvkm_fanpwm_create(struct nvkm_therm *therm, struct dcb_gpio_func *func)
 		return -ENODEV;

 	fan = kzalloc(sizeof(*fan), GFP_KERNEL);
-	therm->fan = &fan->base;
 	if (!fan)
 		return -ENOMEM;

+	therm->fan = &fan->base;
 	fan->base.type = "PWM";
 	fan->base.get = nvkm_fanpwm_get;
 	fan->base.set = nvkm_fanpwm_set;
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/fantog.c b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/fantog.c
index ff9fbe7950e5..bfdf4ca5625c 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/fantog.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/fantog.c
@@ -100,10 +100,10 @@ nvkm_fantog_create(struct nvkm_therm *therm, struct dcb_gpio_func *func)
 	}

 	fan = kzalloc(sizeof(*fan), GFP_KERNEL);
-	therm->fan = &fan->base;
 	if (!fan)
 		return -ENOMEM;

+	therm->fan = &fan->base;
 	fan->base.type = "toggle";
 	fan->base.get = nvkm_fantog_get;
 	fan->base.set = nvkm_fantog_set;
--
2.40.0

Re: [PATCH 0/9] GPU-DRM-nouveau: Adjustments for seven function implementations

[Karol Herbst]

On Sun, Apr 16, 2023 at 11:30 AM Markus Elfring <Markus.Elfring@web.de> wrote:
>
> Date: Sun, 16 Apr 2023 11:22:23 +0200
>
> Several update suggestions were taken into account
> from static source code analysis.
>

Reviewed-by: Karol Herbst <kherbst@redhat.com>

> Markus Elfring (9):
>   debugfs: Move an expression into a function call parameter
>     in nouveau_debugfs_pstate_set()
>   debugfs: Move a variable assignment behind a null pointer check
>     in nouveau_debugfs_pstate_get()
>   debugfs: Use seq_putc()
>     in nouveau_debugfs_pstate_get()
>   debugfs: Replace five seq_printf() calls by seq_puts()
>     in nouveau_debugfs_pstate_get()
>   power_budget: Move an expression into a macro call parameter
>     in nvbios_power_budget_header()
>   clk: Move a variable assignment behind a null pointer check
>     in nvkm_pstate_new()
>   pci: Move a variable assignment behind condition checks
>     in nvkm_pcie_set_link()
>   pci: Move an expression into a function call parameter
>     in nvkm_pcie_set_link()
>   therm: Move an assignment statement behind a null pointer check
>     in two functions
>
>  drivers/gpu/drm/nouveau/nouveau_debugfs.c     | 19 ++++++++++---------
>  .../nouveau/nvkm/subdev/bios/power_budget.c   |  3 +--
>  .../gpu/drm/nouveau/nvkm/subdev/clk/base.c    |  2 +-
>  .../gpu/drm/nouveau/nvkm/subdev/pci/pcie.c    |  7 +++----
>  .../drm/nouveau/nvkm/subdev/therm/fanpwm.c    |  2 +-
>  .../drm/nouveau/nvkm/subdev/therm/fantog.c    |  2 +-
>  6 files changed, 17 insertions(+), 18 deletions(-)
>
> --
> 2.40.0
>

Re: [PATCH 0/9] GPU-DRM-nouveau: Adjustments for seven function implementations

[Karol Herbst]

On Sun, Apr 16, 2023 at 11:30 AM Markus Elfring <Markus.Elfring@web.de> wrote:
>
> Date: Sun, 16 Apr 2023 11:22:23 +0200
>
> Several update suggestions were taken into account
> from static source code analysis.
>

Reviewed-by: Karol Herbst <kherbst@redhat.com>

> Markus Elfring (9):
>   debugfs: Move an expression into a function call parameter
>     in nouveau_debugfs_pstate_set()
>   debugfs: Move a variable assignment behind a null pointer check
>     in nouveau_debugfs_pstate_get()
>   debugfs: Use seq_putc()
>     in nouveau_debugfs_pstate_get()
>   debugfs: Replace five seq_printf() calls by seq_puts()
>     in nouveau_debugfs_pstate_get()
>   power_budget: Move an expression into a macro call parameter
>     in nvbios_power_budget_header()
>   clk: Move a variable assignment behind a null pointer check
>     in nvkm_pstate_new()
>   pci: Move a variable assignment behind condition checks
>     in nvkm_pcie_set_link()
>   pci: Move an expression into a function call parameter
>     in nvkm_pcie_set_link()
>   therm: Move an assignment statement behind a null pointer check
>     in two functions
>
>  drivers/gpu/drm/nouveau/nouveau_debugfs.c     | 19 ++++++++++---------
>  .../nouveau/nvkm/subdev/bios/power_budget.c   |  3 +--
>  .../gpu/drm/nouveau/nvkm/subdev/clk/base.c    |  2 +-
>  .../gpu/drm/nouveau/nvkm/subdev/pci/pcie.c    |  7 +++----
>  .../drm/nouveau/nvkm/subdev/therm/fanpwm.c    |  2 +-
>  .../drm/nouveau/nvkm/subdev/therm/fantog.c    |  2 +-
>  6 files changed, 17 insertions(+), 18 deletions(-)
>
> --
> 2.40.0
>

Re: [Nouveau] [PATCH 0/9] GPU-DRM-nouveau: Adjustments for seven function implementations

[Karol Herbst]

On Sun, Apr 16, 2023 at 11:30 AM Markus Elfring <Markus.Elfring@web.de> wrote:
>
> Date: Sun, 16 Apr 2023 11:22:23 +0200
>
> Several update suggestions were taken into account
> from static source code analysis.
>

Reviewed-by: Karol Herbst <kherbst@redhat.com>

> Markus Elfring (9):
>   debugfs: Move an expression into a function call parameter
>     in nouveau_debugfs_pstate_set()
>   debugfs: Move a variable assignment behind a null pointer check
>     in nouveau_debugfs_pstate_get()
>   debugfs: Use seq_putc()
>     in nouveau_debugfs_pstate_get()
>   debugfs: Replace five seq_printf() calls by seq_puts()
>     in nouveau_debugfs_pstate_get()
>   power_budget: Move an expression into a macro call parameter
>     in nvbios_power_budget_header()
>   clk: Move a variable assignment behind a null pointer check
>     in nvkm_pstate_new()
>   pci: Move a variable assignment behind condition checks
>     in nvkm_pcie_set_link()
>   pci: Move an expression into a function call parameter
>     in nvkm_pcie_set_link()
>   therm: Move an assignment statement behind a null pointer check
>     in two functions
>
>  drivers/gpu/drm/nouveau/nouveau_debugfs.c     | 19 ++++++++++---------
>  .../nouveau/nvkm/subdev/bios/power_budget.c   |  3 +--
>  .../gpu/drm/nouveau/nvkm/subdev/clk/base.c    |  2 +-
>  .../gpu/drm/nouveau/nvkm/subdev/pci/pcie.c    |  7 +++----
>  .../drm/nouveau/nvkm/subdev/therm/fanpwm.c    |  2 +-
>  .../drm/nouveau/nvkm/subdev/therm/fantog.c    |  2 +-
>  6 files changed, 17 insertions(+), 18 deletions(-)
>
> --
> 2.40.0
>

[cocci] [PATCH] drm/bridge: it6505: Move a variable assignment behind a null pointer check in receive_timing_debugfs_show()

[Markus Elfring]

Date: Sun, 16 Apr 2023 17:30:46 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “receive_timing_debugfs_show”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “vid” behind the null pointer check.

This issue was detected by using the Coccinelle software.

Fixes: b5c84a9edcd418cd055becad6a22439e7c5e3bf8 ("drm/bridge: add it6505 driver")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/bridge/ite-it6505.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/ite-it6505.c b/drivers/gpu/drm/bridge/ite-it6505.c
index abaf6e23775e..45f579c365e7 100644
--- a/drivers/gpu/drm/bridge/ite-it6505.c
+++ b/drivers/gpu/drm/bridge/ite-it6505.c
@@ -3207,7 +3207,7 @@ static ssize_t receive_timing_debugfs_show(struct file *file, char __user *buf,
 					   size_t len, loff_t *ppos)
 {
 	struct it6505 *it6505 = file->private_data;
-	struct drm_display_mode *vid = &it6505->video_info;
+	struct drm_display_mode *vid;
 	u8 read_buf[READ_BUFFER_SIZE];
 	u8 *str = read_buf, *end = read_buf + READ_BUFFER_SIZE;
 	ssize_t ret, count;
@@ -3216,6 +3216,7 @@ static ssize_t receive_timing_debugfs_show(struct file *file, char __user *buf,
 		return -ENODEV;

 	it6505_calc_video_info(it6505);
+	vid = &it6505->video_info;
 	str += scnprintf(str, end - str, "---video timing---\n");
 	str += scnprintf(str, end - str, "PCLK:%d.%03dMHz\n",
 			 vid->clock / 1000, vid->clock % 1000);
--
2.40.0

[PATCH] drm/bridge: it6505: Move a variable assignment behind a null pointer check in receive_timing_debugfs_show()

[Markus Elfring]

Date: Sun, 16 Apr 2023 17:30:46 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “receive_timing_debugfs_show”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “vid” behind the null pointer check.

This issue was detected by using the Coccinelle software.

Fixes: b5c84a9edcd418cd055becad6a22439e7c5e3bf8 ("drm/bridge: add it6505 driver")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/bridge/ite-it6505.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/ite-it6505.c b/drivers/gpu/drm/bridge/ite-it6505.c
index abaf6e23775e..45f579c365e7 100644
--- a/drivers/gpu/drm/bridge/ite-it6505.c
+++ b/drivers/gpu/drm/bridge/ite-it6505.c
@@ -3207,7 +3207,7 @@ static ssize_t receive_timing_debugfs_show(struct file *file, char __user *buf,
 					   size_t len, loff_t *ppos)
 {
 	struct it6505 *it6505 = file->private_data;
-	struct drm_display_mode *vid = &it6505->video_info;
+	struct drm_display_mode *vid;
 	u8 read_buf[READ_BUFFER_SIZE];
 	u8 *str = read_buf, *end = read_buf + READ_BUFFER_SIZE;
 	ssize_t ret, count;
@@ -3216,6 +3216,7 @@ static ssize_t receive_timing_debugfs_show(struct file *file, char __user *buf,
 		return -ENODEV;

 	it6505_calc_video_info(it6505);
+	vid = &it6505->video_info;
 	str += scnprintf(str, end - str, "---video timing---\n");
 	str += scnprintf(str, end - str, "PCLK:%d.%03dMHz\n",
 			 vid->clock / 1000, vid->clock % 1000);
--
2.40.0

Re: [PATCH] drm/bridge: it6505: Move a variable assignment behind a null pointer check in receive_timing_debugfs_show()

[Robert Foss]

Hey Markus,

This patch seems to be a part of a series without being marked as
such, this causes issues when importing this patch with maintainer
tools like b4 which automatically pull in the entire series and not
just the specific patch. Either label the patch as being part of a
series ( [PATCH 1/XX] ), or submit it separately.

On Sun, Apr 16, 2023 at 5:47 PM Markus Elfring <Markus.Elfring@web.de> wrote:
>
> Date: Sun, 16 Apr 2023 17:30:46 +0200
>
> The address of a data structure member was determined before
> a corresponding null pointer check in the implementation of
> the function “receive_timing_debugfs_show”.
>
> Thus avoid the risk for undefined behaviour by moving the assignment
> for the variable “vid” behind the null pointer check.
>
> This issue was detected by using the Coccinelle software.
>
> Fixes: b5c84a9edcd418cd055becad6a22439e7c5e3bf8 ("drm/bridge: add it6505 driver")
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>

The email in the Signed-off tag should match the email of the sender,
which it doesn't.

With the two above issues fixed, please add my r-b.
Reviewed-by: Robert Foss <rfoss@kernel.org>

> ---
>  drivers/gpu/drm/bridge/ite-it6505.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/ite-it6505.c b/drivers/gpu/drm/bridge/ite-it6505.c
> index abaf6e23775e..45f579c365e7 100644
> --- a/drivers/gpu/drm/bridge/ite-it6505.c
> +++ b/drivers/gpu/drm/bridge/ite-it6505.c
> @@ -3207,7 +3207,7 @@ static ssize_t receive_timing_debugfs_show(struct file *file, char __user *buf,
>                                            size_t len, loff_t *ppos)
>  {
>         struct it6505 *it6505 = file->private_data;
> -       struct drm_display_mode *vid = &it6505->video_info;
> +       struct drm_display_mode *vid;
>         u8 read_buf[READ_BUFFER_SIZE];
>         u8 *str = read_buf, *end = read_buf + READ_BUFFER_SIZE;
>         ssize_t ret, count;
> @@ -3216,6 +3216,7 @@ static ssize_t receive_timing_debugfs_show(struct file *file, char __user *buf,
>                 return -ENODEV;
>
>         it6505_calc_video_info(it6505);
> +       vid = &it6505->video_info;
>         str += scnprintf(str, end - str, "---video timing---\n");
>         str += scnprintf(str, end - str, "PCLK:%d.%03dMHz\n",
>                          vid->clock / 1000, vid->clock % 1000);
> --
> 2.40.0
>

Re: [PATCH] drm/bridge: it6505: Move a variable assignment behind a null pointer check in receive_timing_debugfs_show()

[Robert Foss]

Hey Markus,

This patch seems to be a part of a series without being marked as
such, this causes issues when importing this patch with maintainer
tools like b4 which automatically pull in the entire series and not
just the specific patch. Either label the patch as being part of a
series ( [PATCH 1/XX] ), or submit it separately.

On Sun, Apr 16, 2023 at 5:47 PM Markus Elfring <Markus.Elfring@web.de> wrote:
>
> Date: Sun, 16 Apr 2023 17:30:46 +0200
>
> The address of a data structure member was determined before
> a corresponding null pointer check in the implementation of
> the function “receive_timing_debugfs_show”.
>
> Thus avoid the risk for undefined behaviour by moving the assignment
> for the variable “vid” behind the null pointer check.
>
> This issue was detected by using the Coccinelle software.
>
> Fixes: b5c84a9edcd418cd055becad6a22439e7c5e3bf8 ("drm/bridge: add it6505 driver")
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>

The email in the Signed-off tag should match the email of the sender,
which it doesn't.

With the two above issues fixed, please add my r-b.
Reviewed-by: Robert Foss <rfoss@kernel.org>

> ---
>  drivers/gpu/drm/bridge/ite-it6505.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/ite-it6505.c b/drivers/gpu/drm/bridge/ite-it6505.c
> index abaf6e23775e..45f579c365e7 100644
> --- a/drivers/gpu/drm/bridge/ite-it6505.c
> +++ b/drivers/gpu/drm/bridge/ite-it6505.c
> @@ -3207,7 +3207,7 @@ static ssize_t receive_timing_debugfs_show(struct file *file, char __user *buf,
>                                            size_t len, loff_t *ppos)
>  {
>         struct it6505 *it6505 = file->private_data;
> -       struct drm_display_mode *vid = &it6505->video_info;
> +       struct drm_display_mode *vid;
>         u8 read_buf[READ_BUFFER_SIZE];
>         u8 *str = read_buf, *end = read_buf + READ_BUFFER_SIZE;
>         ssize_t ret, count;
> @@ -3216,6 +3216,7 @@ static ssize_t receive_timing_debugfs_show(struct file *file, char __user *buf,
>                 return -ENODEV;
>
>         it6505_calc_video_info(it6505);
> +       vid = &it6505->video_info;
>         str += scnprintf(str, end - str, "---video timing---\n");
>         str += scnprintf(str, end - str, "PCLK:%d.%03dMHz\n",
>                          vid->clock / 1000, vid->clock % 1000);
> --
> 2.40.0
>

Re: [cocci] drm/bridge: it6505: Move a variable assignment behind a null pointer check in receive_timing_debugfs_show()

[Markus Elfring]

> This patch seems to be a part of a series without being marked as such,

The mentioned patch affects only a single function implementation.


> this causes issues when importing this patch with maintainer tools
> like b4 which automatically pull in the entire series and not
> just the specific patch.

It is a pity that there are special technical difficulties.


> Either label the patch as being part of a series ( [PATCH 1/XX] ),

Further software modules were similarly affected.

See also:
Reconsidering pointer dereferences before null pointer checks (with SmPL)
https://lore.kernel.org/cocci/1a11455f-ab57-dce0-1677-6beb8492a257@web.de/
https://sympa.inria.fr/sympa/arc/cocci/2023-04/msg00021.html


> or submit it separately.

I thought that I did that (in principle).

Regards,
Markus

Re: drm/bridge: it6505: Move a variable assignment behind a null pointer check in receive_timing_debugfs_show()

[Markus Elfring]

> This patch seems to be a part of a series without being marked as such,

The mentioned patch affects only a single function implementation.


> this causes issues when importing this patch with maintainer tools
> like b4 which automatically pull in the entire series and not
> just the specific patch.

It is a pity that there are special technical difficulties.


> Either label the patch as being part of a series ( [PATCH 1/XX] ),

Further software modules were similarly affected.

See also:
Reconsidering pointer dereferences before null pointer checks (with SmPL)
https://lore.kernel.org/cocci/1a11455f-ab57-dce0-1677-6beb8492a257@web.de/
https://sympa.inria.fr/sympa/arc/cocci/2023-04/msg00021.html


> or submit it separately.

I thought that I did that (in principle).

Regards,
Markus

Re: drm/bridge: it6505: Move a variable assignment behind a null pointer check in receive_timing_debugfs_show()

[Robert Foss]

On Tue, Apr 25, 2023 at 4:16 PM Markus Elfring <Markus.Elfring@web.de> wrote:
>
> > This patch seems to be a part of a series without being marked as such,
>
> The mentioned patch affects only a single function implementation.
>
>
> > this causes issues when importing this patch with maintainer tools
> > like b4 which automatically pull in the entire series and not
> > just the specific patch.
>
> It is a pity that there are special technical difficulties.
>
>
> > Either label the patch as being part of a series ( [PATCH 1/XX] ),
>
> Further software modules were similarly affected.
>
> See also:
> Reconsidering pointer dereferences before null pointer checks (with SmPL)
> https://lore.kernel.org/cocci/1a11455f-ab57-dce0-1677-6beb8492a257@web.de/
> https://sympa.inria.fr/sympa/arc/cocci/2023-04/msg00021.html
>
>
> > or submit it separately.
>
> I thought that I did that (in principle).

You can have a look at LKML for the email message-id to see the whole
thread of patches.
https://lore.kernel.org/all/14636275-4d26-d639-5f6e-293fc6d1c4c6@web.de/#r

Or https://lore.kernel.org/all/$MSG_ID

Fix the email Sign-off email != Sender email issue, resubmit and I'll
be able to apply this.

Re: drm/bridge: it6505: Move a variable assignment behind a null pointer check in receive_timing_debugfs_show()

[Robert Foss]

On Tue, Apr 25, 2023 at 4:16 PM Markus Elfring <Markus.Elfring@web.de> wrote:
>
> > This patch seems to be a part of a series without being marked as such,
>
> The mentioned patch affects only a single function implementation.
>
>
> > this causes issues when importing this patch with maintainer tools
> > like b4 which automatically pull in the entire series and not
> > just the specific patch.
>
> It is a pity that there are special technical difficulties.
>
>
> > Either label the patch as being part of a series ( [PATCH 1/XX] ),
>
> Further software modules were similarly affected.
>
> See also:
> Reconsidering pointer dereferences before null pointer checks (with SmPL)
> https://lore.kernel.org/cocci/1a11455f-ab57-dce0-1677-6beb8492a257@web.de/
> https://sympa.inria.fr/sympa/arc/cocci/2023-04/msg00021.html
>
>
> > or submit it separately.
>
> I thought that I did that (in principle).

You can have a look at LKML for the email message-id to see the whole
thread of patches.
https://lore.kernel.org/all/14636275-4d26-d639-5f6e-293fc6d1c4c6@web.de/#r

Or https://lore.kernel.org/all/$MSG_ID

Fix the email Sign-off email != Sender email issue, resubmit and I'll
be able to apply this.

Re: [cocci] drm/bridge: it6505: Move a variable assignment behind a null pointer check in receive_timing_debugfs_show()

[Markus Elfring]

> Fix the email Sign-off email != Sender email issue, resubmit and I'll
> be able to apply this.

You can pick the email from my tag “Signed-off-by” up also directly
as an ordinary patch author email, can't you?

Regards,
Markus

Re: drm/bridge: it6505: Move a variable assignment behind a null pointer check in receive_timing_debugfs_show()

[Markus Elfring]

> Fix the email Sign-off email != Sender email issue, resubmit and I'll
> be able to apply this.

You can pick the email from my tag “Signed-off-by” up also directly
as an ordinary patch author email, can't you?

Regards,
Markus

Re: drm/bridge: it6505: Move a variable assignment behind a null pointer check in receive_timing_debugfs_show()

[Robert Foss]

On Thu, Apr 27, 2023 at 9:40 PM Markus Elfring <Markus.Elfring@web.de> wrote:
>
> > Fix the email Sign-off email != Sender email issue, resubmit and I'll
> > be able to apply this.
>
> You can pick the email from my tag “Signed-off-by” up also directly
> as an ordinary patch author email, can't you?

Of course, I can change the email to anything, but drm maintainer
scripts checks for this, presumably for a reason, so it should be
correctly submitted.

>
> Regards,
> Markus
>

Re: drm/bridge: it6505: Move a variable assignment behind a null pointer check in receive_timing_debugfs_show()

[Robert Foss]

On Thu, Apr 27, 2023 at 9:40 PM Markus Elfring <Markus.Elfring@web.de> wrote:
>
> > Fix the email Sign-off email != Sender email issue, resubmit and I'll
> > be able to apply this.
>
> You can pick the email from my tag “Signed-off-by” up also directly
> as an ordinary patch author email, can't you?

Of course, I can change the email to anything, but drm maintainer
scripts checks for this, presumably for a reason, so it should be
correctly submitted.

>
> Regards,
> Markus
>

[cocci] [PATCH resent] drm/bridge: it6505: Move a variable assignment behind a null pointer check in receive_timing_debugfs_show()

[Markus Elfring]

From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 16 Apr 2023 17:30:46 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “receive_timing_debugfs_show”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “vid” behind the null pointer check.

This issue was detected by using the Coccinelle software.

Fixes: b5c84a9edcd418cd055becad6a22439e7c5e3bf8 ("drm/bridge: add it6505 driver")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/bridge/ite-it6505.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/ite-it6505.c b/drivers/gpu/drm/bridge/ite-it6505.c
index abaf6e23775e..45f579c365e7 100644
--- a/drivers/gpu/drm/bridge/ite-it6505.c
+++ b/drivers/gpu/drm/bridge/ite-it6505.c
@@ -3207,7 +3207,7 @@ static ssize_t receive_timing_debugfs_show(struct file *file, char __user *buf,
 					   size_t len, loff_t *ppos)
 {
 	struct it6505 *it6505 = file->private_data;
-	struct drm_display_mode *vid = &it6505->video_info;
+	struct drm_display_mode *vid;
 	u8 read_buf[READ_BUFFER_SIZE];
 	u8 *str = read_buf, *end = read_buf + READ_BUFFER_SIZE;
 	ssize_t ret, count;
@@ -3216,6 +3216,7 @@ static ssize_t receive_timing_debugfs_show(struct file *file, char __user *buf,
 		return -ENODEV;

 	it6505_calc_video_info(it6505);
+	vid = &it6505->video_info;
 	str += scnprintf(str, end - str, "---video timing---\n");
 	str += scnprintf(str, end - str, "PCLK:%d.%03dMHz\n",
 			 vid->clock / 1000, vid->clock % 1000);
--
2.40.0

[PATCH resent] drm/bridge: it6505: Move a variable assignment behind a null pointer check in receive_timing_debugfs_show()

[Markus Elfring]

From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 16 Apr 2023 17:30:46 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “receive_timing_debugfs_show”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “vid” behind the null pointer check.

This issue was detected by using the Coccinelle software.

Fixes: b5c84a9edcd418cd055becad6a22439e7c5e3bf8 ("drm/bridge: add it6505 driver")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/bridge/ite-it6505.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/ite-it6505.c b/drivers/gpu/drm/bridge/ite-it6505.c
index abaf6e23775e..45f579c365e7 100644
--- a/drivers/gpu/drm/bridge/ite-it6505.c
+++ b/drivers/gpu/drm/bridge/ite-it6505.c
@@ -3207,7 +3207,7 @@ static ssize_t receive_timing_debugfs_show(struct file *file, char __user *buf,
 					   size_t len, loff_t *ppos)
 {
 	struct it6505 *it6505 = file->private_data;
-	struct drm_display_mode *vid = &it6505->video_info;
+	struct drm_display_mode *vid;
 	u8 read_buf[READ_BUFFER_SIZE];
 	u8 *str = read_buf, *end = read_buf + READ_BUFFER_SIZE;
 	ssize_t ret, count;
@@ -3216,6 +3216,7 @@ static ssize_t receive_timing_debugfs_show(struct file *file, char __user *buf,
 		return -ENODEV;

 	it6505_calc_video_info(it6505);
+	vid = &it6505->video_info;
 	str += scnprintf(str, end - str, "---video timing---\n");
 	str += scnprintf(str, end - str, "PCLK:%d.%03dMHz\n",
 			 vid->clock / 1000, vid->clock % 1000);
--
2.40.0

Re: [PATCH resent] drm/bridge: it6505: Move a variable assignment behind a null pointer check in receive_timing_debugfs_show()

[Robert Foss]

On Fri, Apr 28, 2023 at 5:56 PM Markus Elfring <Markus.Elfring@web.de> wrote:
>
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sun, 16 Apr 2023 17:30:46 +0200
>
> The address of a data structure member was determined before
> a corresponding null pointer check in the implementation of
> the function “receive_timing_debugfs_show”.
>
> Thus avoid the risk for undefined behaviour by moving the assignment
> for the variable “vid” behind the null pointer check.
>
> This issue was detected by using the Coccinelle software.
>
> Fixes: b5c84a9edcd418cd055becad6a22439e7c5e3bf8 ("drm/bridge: add it6505 driver")
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
>  drivers/gpu/drm/bridge/ite-it6505.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/ite-it6505.c b/drivers/gpu/drm/bridge/ite-it6505.c
> index abaf6e23775e..45f579c365e7 100644
> --- a/drivers/gpu/drm/bridge/ite-it6505.c
> +++ b/drivers/gpu/drm/bridge/ite-it6505.c
> @@ -3207,7 +3207,7 @@ static ssize_t receive_timing_debugfs_show(struct file *file, char __user *buf,
>                                            size_t len, loff_t *ppos)
>  {
>         struct it6505 *it6505 = file->private_data;
> -       struct drm_display_mode *vid = &it6505->video_info;
> +       struct drm_display_mode *vid;
>         u8 read_buf[READ_BUFFER_SIZE];
>         u8 *str = read_buf, *end = read_buf + READ_BUFFER_SIZE;
>         ssize_t ret, count;
> @@ -3216,6 +3216,7 @@ static ssize_t receive_timing_debugfs_show(struct file *file, char __user *buf,
>                 return -ENODEV;
>
>         it6505_calc_video_info(it6505);
> +       vid = &it6505->video_info;
>         str += scnprintf(str, end - str, "---video timing---\n");
>         str += scnprintf(str, end - str, "PCLK:%d.%03dMHz\n",
>                          vid->clock / 1000, vid->clock % 1000);
> --
> 2.40.0
>

Applied to drm-misc-next.

Re: [PATCH resent] drm/bridge: it6505: Move a variable assignment behind a null pointer check in receive_timing_debugfs_show()

[Robert Foss]

On Fri, Apr 28, 2023 at 5:56 PM Markus Elfring <Markus.Elfring@web.de> wrote:
>
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sun, 16 Apr 2023 17:30:46 +0200
>
> The address of a data structure member was determined before
> a corresponding null pointer check in the implementation of
> the function “receive_timing_debugfs_show”.
>
> Thus avoid the risk for undefined behaviour by moving the assignment
> for the variable “vid” behind the null pointer check.
>
> This issue was detected by using the Coccinelle software.
>
> Fixes: b5c84a9edcd418cd055becad6a22439e7c5e3bf8 ("drm/bridge: add it6505 driver")
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
>  drivers/gpu/drm/bridge/ite-it6505.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/ite-it6505.c b/drivers/gpu/drm/bridge/ite-it6505.c
> index abaf6e23775e..45f579c365e7 100644
> --- a/drivers/gpu/drm/bridge/ite-it6505.c
> +++ b/drivers/gpu/drm/bridge/ite-it6505.c
> @@ -3207,7 +3207,7 @@ static ssize_t receive_timing_debugfs_show(struct file *file, char __user *buf,
>                                            size_t len, loff_t *ppos)
>  {
>         struct it6505 *it6505 = file->private_data;
> -       struct drm_display_mode *vid = &it6505->video_info;
> +       struct drm_display_mode *vid;
>         u8 read_buf[READ_BUFFER_SIZE];
>         u8 *str = read_buf, *end = read_buf + READ_BUFFER_SIZE;
>         ssize_t ret, count;
> @@ -3216,6 +3216,7 @@ static ssize_t receive_timing_debugfs_show(struct file *file, char __user *buf,
>                 return -ENODEV;
>
>         it6505_calc_video_info(it6505);
> +       vid = &it6505->video_info;
>         str += scnprintf(str, end - str, "---video timing---\n");
>         str += scnprintf(str, end - str, "PCLK:%d.%03dMHz\n",
>                          vid->clock / 1000, vid->clock % 1000);
> --
> 2.40.0
>

Applied to drm-misc-next.

[cocci] [PATCH] drm/mm: Adjust input parameter validation in DECLARE_NEXT_HOLE_ADDR()

[Markus Elfring]

Date: Mon, 17 Apr 2023 11:26:34 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the macro “DECLARE_NEXT_HOLE_ADDR”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “node” behind the null pointer check.

This issue was detected by using the Coccinelle software.

Fixes: 5fad79fd66ff90b8c0a95319dad0b099008f8347 ("drm/mm: cleanup and improve next_hole_*_addr()")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/drm_mm.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 8257f9d4f619..95c316aa36e5 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -389,9 +389,13 @@ first_hole(struct drm_mm *mm,
 #define DECLARE_NEXT_HOLE_ADDR(name, first, last)			\
 static struct drm_mm_node *name(struct drm_mm_node *entry, u64 size)	\
 {									\
-	struct rb_node *parent, *node = &entry->rb_hole_addr;		\
+	struct rb_node *parent, *node;					\
 									\
-	if (!entry || RB_EMPTY_NODE(node))				\
+	if (!entry)							\
+		return NULL;						\
+									\
+	node = &entry->rb_hole_addr;					\
+	if (RB_EMPTY_NODE(node))					\
 		return NULL;						\
 									\
 	if (usable_hole_addr(node->first, size)) {			\
--
2.40.0

[PATCH] drm/mm: Adjust input parameter validation in DECLARE_NEXT_HOLE_ADDR()

[Markus Elfring]

Date: Mon, 17 Apr 2023 11:26:34 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the macro “DECLARE_NEXT_HOLE_ADDR”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “node” behind the null pointer check.

This issue was detected by using the Coccinelle software.

Fixes: 5fad79fd66ff90b8c0a95319dad0b099008f8347 ("drm/mm: cleanup and improve next_hole_*_addr()")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/gpu/drm/drm_mm.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 8257f9d4f619..95c316aa36e5 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -389,9 +389,13 @@ first_hole(struct drm_mm *mm,
 #define DECLARE_NEXT_HOLE_ADDR(name, first, last)			\
 static struct drm_mm_node *name(struct drm_mm_node *entry, u64 size)	\
 {									\
-	struct rb_node *parent, *node = &entry->rb_hole_addr;		\
+	struct rb_node *parent, *node;					\
 									\
-	if (!entry || RB_EMPTY_NODE(node))				\
+	if (!entry)							\
+		return NULL;						\
+									\
+	node = &entry->rb_hole_addr;					\
+	if (RB_EMPTY_NODE(node))					\
 		return NULL;						\
 									\
 	if (usable_hole_addr(node->first, size)) {			\
--
2.40.0

[cocci] [PATCH] iwlegacy: Adjust input parameter validation in il_set_ht_add_station()

[Markus Elfring]

Date: Wed, 19 Apr 2023 18:35:55 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “il_set_ht_add_station”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “sta_ht_inf” behind the null pointer check.

This issue was detected by using the Coccinelle software.


Delete also the jump target “done” by using return statements directly
for two if branches.

Fixes: 046d2e7c50e3087a32a85fd384c21f896dbccf83 ("mac80211: prepare sta handling for MLO support")
Fixes: e7392364fcd1004a5e495f15cf21b1e0ef874215 ("iwlegacy: indentions and whitespaces")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/net/wireless/intel/iwlegacy/common.c | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlegacy/common.c b/drivers/net/wireless/intel/iwlegacy/common.c
index 96002121bb8b..8f6fd17b02a8 100644
--- a/drivers/net/wireless/intel/iwlegacy/common.c
+++ b/drivers/net/wireless/intel/iwlegacy/common.c
@@ -1863,11 +1863,15 @@ EXPORT_SYMBOL(il_send_add_sta);
 static void
 il_set_ht_add_station(struct il_priv *il, u8 idx, struct ieee80211_sta *sta)
 {
-	struct ieee80211_sta_ht_cap *sta_ht_inf = &sta->deflink.ht_cap;
+	struct ieee80211_sta_ht_cap *sta_ht_inf;
 	__le32 sta_flags;

-	if (!sta || !sta_ht_inf->ht_supported)
-		goto done;
+	if (!sta)
+		return;
+
+	sta_ht_inf = &sta->deflink.ht_cap;
+	if (!sta_ht_inf->ht_supported)
+		return;

 	D_ASSOC("spatial multiplexing power save mode: %s\n",
 		(sta->deflink.smps_mode == IEEE80211_SMPS_STATIC) ? "static" :
@@ -1906,8 +1910,6 @@ il_set_ht_add_station(struct il_priv *il, u8 idx, struct ieee80211_sta *sta)
 		sta_flags &= ~STA_FLG_HT40_EN_MSK;

 	il->stations[idx].sta.station_flags = sta_flags;
-done:
-	return;
 }

 /*
--
2.40.0

[cocci] [PATCH] iwlwifi: Adjust input parameter validation in iwl_sta_calc_ht_flags()

[Markus Elfring]

Date: Wed, 19 Apr 2023 19:19:34 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “iwl_sta_calc_ht_flags”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “sta_ht_inf” behind the null pointer check.

This issue was detected by using the Coccinelle software.

Fixes: 046d2e7c50e3087a32a85fd384c21f896dbccf83 ("mac80211: prepare sta handling for MLO support")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/net/wireless/intel/iwlwifi/dvm/sta.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/sta.c b/drivers/net/wireless/intel/iwlwifi/dvm/sta.c
index cef43cf80620..74814ce0155e 100644
--- a/drivers/net/wireless/intel/iwlwifi/dvm/sta.c
+++ b/drivers/net/wireless/intel/iwlwifi/dvm/sta.c
@@ -147,7 +147,7 @@ static void iwl_sta_calc_ht_flags(struct iwl_priv *priv,
 				  struct iwl_rxon_context *ctx,
 				  __le32 *flags, __le32 *mask)
 {
-	struct ieee80211_sta_ht_cap *sta_ht_inf = &sta->deflink.ht_cap;
+	struct ieee80211_sta_ht_cap *sta_ht_inf;

 	*mask = STA_FLG_RTS_MIMO_PROT_MSK |
 		STA_FLG_MIMO_DIS_MSK |
@@ -156,7 +156,11 @@ static void iwl_sta_calc_ht_flags(struct iwl_priv *priv,
 		STA_FLG_AGG_MPDU_DENSITY_MSK;
 	*flags = 0;

-	if (!sta || !sta_ht_inf->ht_supported)
+	if (!sta)
+		return;
+
+	sta_ht_inf = &sta->deflink.ht_cap;
+	if (!sta_ht_inf->ht_supported)
 		return;

 	IWL_DEBUG_INFO(priv, "STA %pM SM PS mode: %s\n",
--
2.40.0

[cocci] [PATCH] usb: dwc2: gadget: Move a variable assignment behind condition checks in dwc2_hsotg_handle_outdone()

[Markus Elfring]

Date: Wed, 19 Apr 2023 20:06:25 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “dwc2_hsotg_handle_outdone”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “req” behind some condition checks.

This issue was detected by using the Coccinelle software.

Fixes: 5b7d70c6dbf2db786395cbd21750a1a4ce222f84 ("USB: Gadget driver for Samsung HS/OtG block")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/usb/dwc2/gadget.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 8b15742d9e8a..cab04816dd6c 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2389,7 +2389,7 @@ static void dwc2_hsotg_handle_outdone(struct dwc2_hsotg *hsotg, int epnum)
 	u32 epsize = dwc2_readl(hsotg, DOEPTSIZ(epnum));
 	struct dwc2_hsotg_ep *hs_ep = hsotg->eps_out[epnum];
 	struct dwc2_hsotg_req *hs_req = hs_ep->req;
-	struct usb_request *req = &hs_req->req;
+	struct usb_request *req;
 	unsigned int size_left = DXEPTSIZ_XFERSIZE_GET(epsize);
 	int result = 0;

@@ -2408,6 +2408,8 @@ static void dwc2_hsotg_handle_outdone(struct dwc2_hsotg *hsotg, int epnum)
 	if (using_desc_dma(hsotg))
 		size_left = dwc2_gadget_get_xfersize_ddma(hs_ep);

+	req = &hs_req->req;
+
 	if (using_dma(hsotg)) {
 		unsigned int size_done;

--
2.40.0

Re: [PATCH] usb: dwc2: gadget: Move a variable assignment behind condition checks in dwc2_hsotg_handle_outdone()

[Minas Harutyunyan]

On 4/19/23 22:12, Markus Elfring wrote:
> Date: Wed, 19 Apr 2023 20:06:25 +0200
> 
> The address of a data structure member was determined before
> a corresponding null pointer check in the implementation of
> the function “dwc2_hsotg_handle_outdone”.
> 
> Thus avoid the risk for undefined behaviour by moving the assignment
> for the variable “req” behind some condition checks.
> 
> This issue was detected by using the Coccinelle software.
> 
> Fixes: 5b7d70c6dbf2db786395cbd21750a1a4ce222f84 ("USB: Gadget driver for Samsung HS/OtG block")
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>

Acked-by: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com>

> ---
>   drivers/usb/dwc2/gadget.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> index 8b15742d9e8a..cab04816dd6c 100644
> --- a/drivers/usb/dwc2/gadget.c
> +++ b/drivers/usb/dwc2/gadget.c
> @@ -2389,7 +2389,7 @@ static void dwc2_hsotg_handle_outdone(struct dwc2_hsotg *hsotg, int epnum)
>   	u32 epsize = dwc2_readl(hsotg, DOEPTSIZ(epnum));
>   	struct dwc2_hsotg_ep *hs_ep = hsotg->eps_out[epnum];
>   	struct dwc2_hsotg_req *hs_req = hs_ep->req;
> -	struct usb_request *req = &hs_req->req;
> +	struct usb_request *req;
>   	unsigned int size_left = DXEPTSIZ_XFERSIZE_GET(epsize);
>   	int result = 0;
> 
> @@ -2408,6 +2408,8 @@ static void dwc2_hsotg_handle_outdone(struct dwc2_hsotg *hsotg, int epnum)
>   	if (using_desc_dma(hsotg))
>   		size_left = dwc2_gadget_get_xfersize_ddma(hs_ep);
> 
> +	req = &hs_req->req;
> +
>   	if (using_dma(hsotg)) {
>   		unsigned int size_done;
> 
> --
> 2.40.0
> 

[cocci] [PATCH] ASoC: SOF: Intel: hda-stream: Move three variable assignments behind condition checks in hda_dsp_iccmax_stream_hw_params()

[Markus Elfring]

Date: Wed, 19 Apr 2023 20:42:19 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “hda_dsp_iccmax_stream_hw_params”.

Thus avoid the risk for undefined behaviour by moving the assignment
for three local variables behind some condition checks.

This issue was detected by using the Coccinelle software.

Fixes: 7d88b9608142f95ccdd3dfb190da4a5faddb1cc7 ("ASoC: SOF: Intel: hdac_ext_stream: consistent prefixes for variables/members")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 sound/soc/sof/intel/hda-stream.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/sound/soc/sof/intel/hda-stream.c b/sound/soc/sof/intel/hda-stream.c
index 79d818e6a0fa..9c44127014fc 100644
--- a/sound/soc/sof/intel/hda-stream.c
+++ b/sound/soc/sof/intel/hda-stream.c
@@ -407,10 +407,10 @@ int hda_dsp_iccmax_stream_hw_params(struct snd_sof_dev *sdev, struct hdac_ext_st
 				    struct snd_dma_buffer *dmab,
 				    struct snd_pcm_hw_params *params)
 {
-	struct hdac_stream *hstream = &hext_stream->hstream;
-	int sd_offset = SOF_STREAM_SD_OFFSET(hstream);
+	struct hdac_stream *hstream;
+	int sd_offset;
 	int ret;
-	u32 mask = 0x1 << hstream->index;
+	u32 mask;

 	if (!hext_stream) {
 		dev_err(sdev->dev, "error: no stream available\n");
@@ -422,9 +422,12 @@ int hda_dsp_iccmax_stream_hw_params(struct snd_sof_dev *sdev, struct hdac_ext_st
 		return -ENODEV;
 	}

+	hstream = &hext_stream->hstream;
 	if (hstream->posbuf)
 		*hstream->posbuf = 0;

+	sd_offset = SOF_STREAM_SD_OFFSET(hstream);
+
 	/* reset BDL address */
 	snd_sof_dsp_write(sdev, HDA_DSP_HDA_BAR,
 			  sd_offset + SOF_HDA_ADSP_REG_SD_BDLPL,
@@ -459,6 +462,8 @@ int hda_dsp_iccmax_stream_hw_params(struct snd_sof_dev *sdev, struct hdac_ext_st
 				sd_offset + SOF_HDA_ADSP_REG_SD_LVI,
 				0xffff, (hstream->frags - 1));

+	mask = 0x1 << hstream->index;
+
 	/* decouple host and link DMA, enable DSP features */
 	snd_sof_dsp_update_bits(sdev, HDA_DSP_PP_BAR, SOF_HDA_REG_PP_PPCTL,
 				mask, mask);
--
2.40.0

[PATCH] ASoC: SOF: Intel: hda-stream: Move three variable assignments behind condition checks in hda_dsp_iccmax_stream_hw_params()

[Markus Elfring]

Date: Wed, 19 Apr 2023 20:42:19 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “hda_dsp_iccmax_stream_hw_params”.

Thus avoid the risk for undefined behaviour by moving the assignment
for three local variables behind some condition checks.

This issue was detected by using the Coccinelle software.

Fixes: 7d88b9608142f95ccdd3dfb190da4a5faddb1cc7 ("ASoC: SOF: Intel: hdac_ext_stream: consistent prefixes for variables/members")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 sound/soc/sof/intel/hda-stream.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/sound/soc/sof/intel/hda-stream.c b/sound/soc/sof/intel/hda-stream.c
index 79d818e6a0fa..9c44127014fc 100644
--- a/sound/soc/sof/intel/hda-stream.c
+++ b/sound/soc/sof/intel/hda-stream.c
@@ -407,10 +407,10 @@ int hda_dsp_iccmax_stream_hw_params(struct snd_sof_dev *sdev, struct hdac_ext_st
 				    struct snd_dma_buffer *dmab,
 				    struct snd_pcm_hw_params *params)
 {
-	struct hdac_stream *hstream = &hext_stream->hstream;
-	int sd_offset = SOF_STREAM_SD_OFFSET(hstream);
+	struct hdac_stream *hstream;
+	int sd_offset;
 	int ret;
-	u32 mask = 0x1 << hstream->index;
+	u32 mask;

 	if (!hext_stream) {
 		dev_err(sdev->dev, "error: no stream available\n");
@@ -422,9 +422,12 @@ int hda_dsp_iccmax_stream_hw_params(struct snd_sof_dev *sdev, struct hdac_ext_st
 		return -ENODEV;
 	}

+	hstream = &hext_stream->hstream;
 	if (hstream->posbuf)
 		*hstream->posbuf = 0;

+	sd_offset = SOF_STREAM_SD_OFFSET(hstream);
+
 	/* reset BDL address */
 	snd_sof_dsp_write(sdev, HDA_DSP_HDA_BAR,
 			  sd_offset + SOF_HDA_ADSP_REG_SD_BDLPL,
@@ -459,6 +462,8 @@ int hda_dsp_iccmax_stream_hw_params(struct snd_sof_dev *sdev, struct hdac_ext_st
 				sd_offset + SOF_HDA_ADSP_REG_SD_LVI,
 				0xffff, (hstream->frags - 1));

+	mask = 0x1 << hstream->index;
+
 	/* decouple host and link DMA, enable DSP features */
 	snd_sof_dsp_update_bits(sdev, HDA_DSP_PP_BAR, SOF_HDA_REG_PP_PPCTL,
 				mask, mask);
--
2.40.0

Re: [PATCH] ASoC: SOF: Intel: hda-stream: Move three variable assignments behind condition checks in hda_dsp_iccmax_stream_hw_params()

[Pierre-Louis Bossart]

On 4/19/23 13:54, Markus Elfring wrote:
> Date: Wed, 19 Apr 2023 20:42:19 +0200
> 
> The address of a data structure member was determined before
> a corresponding null pointer check in the implementation of
> the function “hda_dsp_iccmax_stream_hw_params”.
> 
> Thus avoid the risk for undefined behaviour by moving the assignment
> for three local variables behind some condition checks.
> 
> This issue was detected by using the Coccinelle software.
> 
> Fixes: 7d88b9608142f95ccdd3dfb190da4a5faddb1cc7 ("ASoC: SOF: Intel: hdac_ext_stream: consistent prefixes for variables/members")
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>

Yes indeed, for some reason this was fixed in
hda_dsp_stream_hw_params() but not in the
hda_dsp_iccmax_stream_hw_params() variant.

Could we however use the same code as in hda_dsp_stream_hw_params() for
consistency?

	if (!hext_stream) {
		dev_err(sdev->dev, "error: no stream available\n");
		return -ENODEV;
	}

	if (!dmab) {
		dev_err(sdev->dev, "error: no dma buffer allocated!\n");
		return -ENODEV;
	}

	hstream = &hext_stream->hstream;
	sd_offset = SOF_STREAM_SD_OFFSET(hstream);
	mask = BIT(hstream->index);

Thanks!

> ---
>  sound/soc/sof/intel/hda-stream.c | 11 ++++++++---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/sound/soc/sof/intel/hda-stream.c b/sound/soc/sof/intel/hda-stream.c
> index 79d818e6a0fa..9c44127014fc 100644
> --- a/sound/soc/sof/intel/hda-stream.c
> +++ b/sound/soc/sof/intel/hda-stream.c
> @@ -407,10 +407,10 @@ int hda_dsp_iccmax_stream_hw_params(struct snd_sof_dev *sdev, struct hdac_ext_st
>  				    struct snd_dma_buffer *dmab,
>  				    struct snd_pcm_hw_params *params)
>  {
> -	struct hdac_stream *hstream = &hext_stream->hstream;
> -	int sd_offset = SOF_STREAM_SD_OFFSET(hstream);
> +	struct hdac_stream *hstream;
> +	int sd_offset;
>  	int ret;
> -	u32 mask = 0x1 << hstream->index;
> +	u32 mask;
> 
>  	if (!hext_stream) {
>  		dev_err(sdev->dev, "error: no stream available\n");
> @@ -422,9 +422,12 @@ int hda_dsp_iccmax_stream_hw_params(struct snd_sof_dev *sdev, struct hdac_ext_st
>  		return -ENODEV;
>  	}
> 
> +	hstream = &hext_stream->hstream;
>  	if (hstream->posbuf)
>  		*hstream->posbuf = 0;
> 
> +	sd_offset = SOF_STREAM_SD_OFFSET(hstream);
> +
>  	/* reset BDL address */
>  	snd_sof_dsp_write(sdev, HDA_DSP_HDA_BAR,
>  			  sd_offset + SOF_HDA_ADSP_REG_SD_BDLPL,
> @@ -459,6 +462,8 @@ int hda_dsp_iccmax_stream_hw_params(struct snd_sof_dev *sdev, struct hdac_ext_st
>  				sd_offset + SOF_HDA_ADSP_REG_SD_LVI,
>  				0xffff, (hstream->frags - 1));
> 
> +	mask = 0x1 << hstream->index;
> +
>  	/* decouple host and link DMA, enable DSP features */
>  	snd_sof_dsp_update_bits(sdev, HDA_DSP_PP_BAR, SOF_HDA_REG_PP_PPCTL,
>  				mask, mask);
> --
> 2.40.0
> 

Re: [PATCH] ASoC: SOF: Intel: hda-stream: Move three variable assignments behind condition checks in hda_dsp_iccmax_stream_hw_params()

[Markus Elfring]

>> The address of a data structure member was determined before
>> a corresponding null pointer check in the implementation of
>> the function “hda_dsp_iccmax_stream_hw_params”.
>>
>> Thus avoid the risk for undefined behaviour by moving the assignment
>> for three local variables behind some condition checks.
>>
>> This issue was detected by using the Coccinelle software.
>>
>> Fixes: 7d88b9608142f95ccdd3dfb190da4a5faddb1cc7 ("ASoC: SOF: Intel: hdac_ext_stream: consistent prefixes for variables/members")
>> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
>
> Yes indeed, for some reason this was fixed in
> hda_dsp_stream_hw_params() but not in the
> hda_dsp_iccmax_stream_hw_params() variant.

Would Peter Ujfalusi like to support similar source code adjustments
also according to his commit 09255c7ed8ca1f1ed99357b845d2f63fe2ef3e1e
("ASoC: SOF: Intel: hda-stream: Do not dereference hstream until it is safe")
from 2023-04-04?


> Could we however use the same code as in hda_dsp_stream_hw_params() for consistency?
…
> 	hstream = &hext_stream->hstream;
> 	sd_offset = SOF_STREAM_SD_OFFSET(hstream);
> 	mask = BIT(hstream->index);

Can it matter to move such assignment statements a bit closer to subsequent statements?

Regards,
Markus

Re: [cocci] [PATCH] ASoC: SOF: Intel: hda-stream: Move three variable assignments behind condition checks in hda_dsp_iccmax_stream_hw_params()

[Markus Elfring]

>> The address of a data structure member was determined before
>> a corresponding null pointer check in the implementation of
>> the function “hda_dsp_iccmax_stream_hw_params”.
>>
>> Thus avoid the risk for undefined behaviour by moving the assignment
>> for three local variables behind some condition checks.
>>
>> This issue was detected by using the Coccinelle software.
>>
>> Fixes: 7d88b9608142f95ccdd3dfb190da4a5faddb1cc7 ("ASoC: SOF: Intel: hdac_ext_stream: consistent prefixes for variables/members")
>> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
>
> Yes indeed, for some reason this was fixed in
> hda_dsp_stream_hw_params() but not in the
> hda_dsp_iccmax_stream_hw_params() variant.

Would Peter Ujfalusi like to support similar source code adjustments
also according to his commit 09255c7ed8ca1f1ed99357b845d2f63fe2ef3e1e
("ASoC: SOF: Intel: hda-stream: Do not dereference hstream until it is safe")
from 2023-04-04?


> Could we however use the same code as in hda_dsp_stream_hw_params() for consistency?
…
> 	hstream = &hext_stream->hstream;
> 	sd_offset = SOF_STREAM_SD_OFFSET(hstream);
> 	mask = BIT(hstream->index);

Can it matter to move such assignment statements a bit closer to subsequent statements?

Regards,
Markus

[PATCH 0/4] staging: rtl8712: Adjustments for process_link_qual()

[Markus Elfring]

Date: Thu, 20 Apr 2023 12:05:12 +0200

A few update suggestions were taken into account
from static source code analysis.

Markus Elfring (4):
  Delete null pointer checks
  Delete two variables
  Reduce scope for the variable “sqd”
  Simplify the usage of an expression

 drivers/staging/rtl8712/rtl8712_recv.c | 24 +++++++++++-------------
 1 file changed, 11 insertions(+), 13 deletions(-)

--
2.40.0

[cocci] [PATCH 0/4] staging: rtl8712: Adjustments for process_link_qual()

[Markus Elfring]

Date: Thu, 20 Apr 2023 12:05:12 +0200

A few update suggestions were taken into account
from static source code analysis.

Markus Elfring (4):
  Delete null pointer checks
  Delete two variables
  Reduce scope for the variable “sqd”
  Simplify the usage of an expression

 drivers/staging/rtl8712/rtl8712_recv.c | 24 +++++++++++-------------
 1 file changed, 11 insertions(+), 13 deletions(-)

--
2.40.0

[cocci] [PATCH 1/4] staging: rtl8712: Delete null pointer checks in process_link_qual()

[Markus Elfring]

Date: Thu, 20 Apr 2023 09:54:06 +0200

Omit extra null pointer checks for the input parameter validation
in the implementation of the function “process_link_qual” because
it should be called only with valid pointers.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/staging/rtl8712/rtl8712_recv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/staging/rtl8712/rtl8712_recv.c b/drivers/staging/rtl8712/rtl8712_recv.c
index 7da014ab0723..f0789b5ef59b 100644
--- a/drivers/staging/rtl8712/rtl8712_recv.c
+++ b/drivers/staging/rtl8712/rtl8712_recv.c
@@ -866,8 +866,6 @@ static void process_link_qual(struct _adapter *padapter,
 	struct rx_pkt_attrib *pattrib;
 	struct smooth_rssi_data *sqd = &padapter->recvpriv.signal_qual_data;

-	if (!prframe || !padapter)
-		return;
 	pattrib = &prframe->u.hdr.attrib;
 	if (pattrib->signal_qual != 0) {
 		/*
--
2.40.0

[PATCH 1/4] staging: rtl8712: Delete null pointer checks in process_link_qual()

[Markus Elfring]

Date: Thu, 20 Apr 2023 09:54:06 +0200

Omit extra null pointer checks for the input parameter validation
in the implementation of the function “process_link_qual” because
it should be called only with valid pointers.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/staging/rtl8712/rtl8712_recv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/staging/rtl8712/rtl8712_recv.c b/drivers/staging/rtl8712/rtl8712_recv.c
index 7da014ab0723..f0789b5ef59b 100644
--- a/drivers/staging/rtl8712/rtl8712_recv.c
+++ b/drivers/staging/rtl8712/rtl8712_recv.c
@@ -866,8 +866,6 @@ static void process_link_qual(struct _adapter *padapter,
 	struct rx_pkt_attrib *pattrib;
 	struct smooth_rssi_data *sqd = &padapter->recvpriv.signal_qual_data;

-	if (!prframe || !padapter)
-		return;
 	pattrib = &prframe->u.hdr.attrib;
 	if (pattrib->signal_qual != 0) {
 		/*
--
2.40.0

[cocci] [PATCH 2/4] staging: rtl8712: Delete two variables in process_link_qual()

[Markus Elfring]

Date: Thu, 20 Apr 2023 10:42:40 +0200

* Use two values for computations (in one if branch)
  without storing them in intermediate variables.

* Remove the local variables “last_evm” and “tmpVal”
  which became unnecessary with this refactoring.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/staging/rtl8712/rtl8712_recv.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/rtl8712/rtl8712_recv.c b/drivers/staging/rtl8712/rtl8712_recv.c
index f0789b5ef59b..3a72d0601dc0 100644
--- a/drivers/staging/rtl8712/rtl8712_recv.c
+++ b/drivers/staging/rtl8712/rtl8712_recv.c
@@ -862,7 +862,6 @@ static void query_rx_phy_status(struct _adapter *padapter,
 static void process_link_qual(struct _adapter *padapter,
 			      union recv_frame *prframe)
 {
-	u32	last_evm = 0, tmpVal;
 	struct rx_pkt_attrib *pattrib;
 	struct smooth_rssi_data *sqd = &padapter->recvpriv.signal_qual_data;

@@ -873,8 +872,7 @@ static void process_link_qual(struct _adapter *padapter,
 		 */
 		if (sqd->total_num++ >= PHY_LINKQUALITY_SLID_WIN_MAX) {
 			sqd->total_num = PHY_LINKQUALITY_SLID_WIN_MAX;
-			last_evm = sqd->elements[sqd->index];
-			sqd->total_val -= last_evm;
+			sqd->total_val -= sqd->elements[sqd->index];
 		}
 		sqd->total_val += pattrib->signal_qual;
 		sqd->elements[sqd->index++] = pattrib->signal_qual;
@@ -882,8 +880,8 @@ static void process_link_qual(struct _adapter *padapter,
 			sqd->index = 0;

 		/* <1> Showed on UI for user, in percentage. */
-		tmpVal = sqd->total_val / sqd->total_num;
-		padapter->recvpriv.signal = (u8)tmpVal;
+		padapter->recvpriv.signal = (u8)(sqd->total_val
+						/ sqd->total_num);
 	}
 }

--
2.40.0

[PATCH 2/4] staging: rtl8712: Delete two variables in process_link_qual()

[Markus Elfring]

Date: Thu, 20 Apr 2023 10:42:40 +0200

* Use two values for computations (in one if branch)
  without storing them in intermediate variables.

* Remove the local variables “last_evm” and “tmpVal”
  which became unnecessary with this refactoring.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/staging/rtl8712/rtl8712_recv.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/rtl8712/rtl8712_recv.c b/drivers/staging/rtl8712/rtl8712_recv.c
index f0789b5ef59b..3a72d0601dc0 100644
--- a/drivers/staging/rtl8712/rtl8712_recv.c
+++ b/drivers/staging/rtl8712/rtl8712_recv.c
@@ -862,7 +862,6 @@ static void query_rx_phy_status(struct _adapter *padapter,
 static void process_link_qual(struct _adapter *padapter,
 			      union recv_frame *prframe)
 {
-	u32	last_evm = 0, tmpVal;
 	struct rx_pkt_attrib *pattrib;
 	struct smooth_rssi_data *sqd = &padapter->recvpriv.signal_qual_data;

@@ -873,8 +872,7 @@ static void process_link_qual(struct _adapter *padapter,
 		 */
 		if (sqd->total_num++ >= PHY_LINKQUALITY_SLID_WIN_MAX) {
 			sqd->total_num = PHY_LINKQUALITY_SLID_WIN_MAX;
-			last_evm = sqd->elements[sqd->index];
-			sqd->total_val -= last_evm;
+			sqd->total_val -= sqd->elements[sqd->index];
 		}
 		sqd->total_val += pattrib->signal_qual;
 		sqd->elements[sqd->index++] = pattrib->signal_qual;
@@ -882,8 +880,8 @@ static void process_link_qual(struct _adapter *padapter,
 			sqd->index = 0;

 		/* <1> Showed on UI for user, in percentage. */
-		tmpVal = sqd->total_val / sqd->total_num;
-		padapter->recvpriv.signal = (u8)tmpVal;
+		padapter->recvpriv.signal = (u8)(sqd->total_val
+						/ sqd->total_num);
 	}
 }

--
2.40.0

[cocci] [PATCH 3/4] staging: rtl8712: Reduce scope for the variable “sqd” in process_link_qual()

[Markus Elfring]

Date: Thu, 20 Apr 2023 11:00:11 +0200

A local variable was used only within an if branch.
Thus move the definition for the variable “sqd” into
the corresponding code block.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/staging/rtl8712/rtl8712_recv.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8712/rtl8712_recv.c b/drivers/staging/rtl8712/rtl8712_recv.c
index 3a72d0601dc0..9135c92906ac 100644
--- a/drivers/staging/rtl8712/rtl8712_recv.c
+++ b/drivers/staging/rtl8712/rtl8712_recv.c
@@ -863,10 +863,11 @@ static void process_link_qual(struct _adapter *padapter,
 			      union recv_frame *prframe)
 {
 	struct rx_pkt_attrib *pattrib;
-	struct smooth_rssi_data *sqd = &padapter->recvpriv.signal_qual_data;

 	pattrib = &prframe->u.hdr.attrib;
 	if (pattrib->signal_qual != 0) {
+		struct smooth_rssi_data *sqd = &padapter->recvpriv.signal_qual_data;
+
 		/*
 		 * 1. Record the general EVM to the sliding window.
 		 */
--
2.40.0

[PATCH 3/4] staging: rtl8712: Reduce scope for the variable “sqd” in process_link_qual()

[Markus Elfring]

Date: Thu, 20 Apr 2023 11:00:11 +0200

A local variable was used only within an if branch.
Thus move the definition for the variable “sqd” into
the corresponding code block.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/staging/rtl8712/rtl8712_recv.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8712/rtl8712_recv.c b/drivers/staging/rtl8712/rtl8712_recv.c
index 3a72d0601dc0..9135c92906ac 100644
--- a/drivers/staging/rtl8712/rtl8712_recv.c
+++ b/drivers/staging/rtl8712/rtl8712_recv.c
@@ -863,10 +863,11 @@ static void process_link_qual(struct _adapter *padapter,
 			      union recv_frame *prframe)
 {
 	struct rx_pkt_attrib *pattrib;
-	struct smooth_rssi_data *sqd = &padapter->recvpriv.signal_qual_data;

 	pattrib = &prframe->u.hdr.attrib;
 	if (pattrib->signal_qual != 0) {
+		struct smooth_rssi_data *sqd = &padapter->recvpriv.signal_qual_data;
+
 		/*
 		 * 1. Record the general EVM to the sliding window.
 		 */
--
2.40.0

[PATCH 4/4] staging: rtl8712: Simplify the usage of an expression in process_link_qual()

[Markus Elfring]

Date: Thu, 20 Apr 2023 11:44:01 +0200

An expression was used at three source code places.
Thus use its value by a corresponding variable.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/staging/rtl8712/rtl8712_recv.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/rtl8712/rtl8712_recv.c b/drivers/staging/rtl8712/rtl8712_recv.c
index 9135c92906ac..3d0c48918510 100644
--- a/drivers/staging/rtl8712/rtl8712_recv.c
+++ b/drivers/staging/rtl8712/rtl8712_recv.c
@@ -862,10 +862,9 @@ static void query_rx_phy_status(struct _adapter *padapter,
 static void process_link_qual(struct _adapter *padapter,
 			      union recv_frame *prframe)
 {
-	struct rx_pkt_attrib *pattrib;
+	u8 signal_qual = prframe->u.hdr.attrib.signal_qual;

-	pattrib = &prframe->u.hdr.attrib;
-	if (pattrib->signal_qual != 0) {
+	if (signal_qual) {
 		struct smooth_rssi_data *sqd = &padapter->recvpriv.signal_qual_data;

 		/*
@@ -875,8 +874,10 @@ static void process_link_qual(struct _adapter *padapter,
 			sqd->total_num = PHY_LINKQUALITY_SLID_WIN_MAX;
 			sqd->total_val -= sqd->elements[sqd->index];
 		}
-		sqd->total_val += pattrib->signal_qual;
-		sqd->elements[sqd->index++] = pattrib->signal_qual;
+
+		sqd->total_val += signal_qual;
+		sqd->elements[sqd->index++] = signal_qual;
+
 		if (sqd->index >= PHY_LINKQUALITY_SLID_WIN_MAX)
 			sqd->index = 0;

--
2.40.0

[cocci] [PATCH 4/4] staging: rtl8712: Simplify the usage of an expression in process_link_qual()

[Markus Elfring]

Date: Thu, 20 Apr 2023 11:44:01 +0200

An expression was used at three source code places.
Thus use its value by a corresponding variable.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/staging/rtl8712/rtl8712_recv.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/rtl8712/rtl8712_recv.c b/drivers/staging/rtl8712/rtl8712_recv.c
index 9135c92906ac..3d0c48918510 100644
--- a/drivers/staging/rtl8712/rtl8712_recv.c
+++ b/drivers/staging/rtl8712/rtl8712_recv.c
@@ -862,10 +862,9 @@ static void query_rx_phy_status(struct _adapter *padapter,
 static void process_link_qual(struct _adapter *padapter,
 			      union recv_frame *prframe)
 {
-	struct rx_pkt_attrib *pattrib;
+	u8 signal_qual = prframe->u.hdr.attrib.signal_qual;

-	pattrib = &prframe->u.hdr.attrib;
-	if (pattrib->signal_qual != 0) {
+	if (signal_qual) {
 		struct smooth_rssi_data *sqd = &padapter->recvpriv.signal_qual_data;

 		/*
@@ -875,8 +874,10 @@ static void process_link_qual(struct _adapter *padapter,
 			sqd->total_num = PHY_LINKQUALITY_SLID_WIN_MAX;
 			sqd->total_val -= sqd->elements[sqd->index];
 		}
-		sqd->total_val += pattrib->signal_qual;
-		sqd->elements[sqd->index++] = pattrib->signal_qual;
+
+		sqd->total_val += signal_qual;
+		sqd->elements[sqd->index++] = signal_qual;
+
 		if (sqd->index >= PHY_LINKQUALITY_SLID_WIN_MAX)
 			sqd->index = 0;

--
2.40.0

Re: [PATCH 0/4] staging: rtl8712: Adjustments for process_link_qual()

[Philipp Hortmann]

On 4/20/23 12:54, Markus Elfring wrote:
> Date: Thu, 20 Apr 2023 12:05:12 +0200
> 
> A few update suggestions were taken into account
> from static source code analysis.
> 
> Markus Elfring (4):
>    Delete null pointer checks
>    Delete two variables
>    Reduce scope for the variable “sqd”
>    Simplify the usage of an expression
> 
>   drivers/staging/rtl8712/rtl8712_recv.c | 24 +++++++++++-------------
>   1 file changed, 11 insertions(+), 13 deletions(-)
> 
> --
> 2.40.0
> 
> 

Hi, you get the following checkpatch warning. Is this wanted?

WARNING: From:/Signed-off-by: email address mismatch: 'From: Markus 
Elfring <Markus.Elfring@web.de>' != 'Signed-off-by: Markus Elfring 
<elfring@users.sourceforge.net>'


Tested-by: Philipp Hortmann <philipp.g.hortmann@gmail.com> AW-NU120

[PATCH 0/4] staging: rtl8723bs: Adjustments for rtw_set_802_11_bssid_list_scan()

[Markus Elfring]

Date: Thu, 20 Apr 2023 16:16:32 +0200

A few update suggestions were taken into account
from static source code analysis.

Markus Elfring (4):
  Delete a null pointer check
  Return directly after a failed initialisation check
  Delete an unnecessary variable initialisation
  Move a variable assignment behind a condition check

 drivers/staging/rtl8723bs/core/rtw_ioctl_set.c | 17 +++++------------
 1 file changed, 5 insertions(+), 12 deletions(-)

--
2.40.0

[cocci] [PATCH 0/4] staging: rtl8723bs: Adjustments for rtw_set_802_11_bssid_list_scan()

[Markus Elfring]

Date: Thu, 20 Apr 2023 16:16:32 +0200

A few update suggestions were taken into account
from static source code analysis.

Markus Elfring (4):
  Delete a null pointer check
  Return directly after a failed initialisation check
  Delete an unnecessary variable initialisation
  Move a variable assignment behind a condition check

 drivers/staging/rtl8723bs/core/rtw_ioctl_set.c | 17 +++++------------
 1 file changed, 5 insertions(+), 12 deletions(-)

--
2.40.0

[cocci] [PATCH 1/4] staging: rtl8723bs: Delete a null pointer check in rtw_set_802_11_bssid_list_scan()

[Markus Elfring]

Date: Thu, 20 Apr 2023 15:30:23 +0200

Omit an extra null pointer check for the input parameter “padapter”
in the implementation of the function “rtw_set_802_11_bssid_list_scan”
because it should be called only with a valid pointer.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/staging/rtl8723bs/core/rtw_ioctl_set.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c b/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c
index 3b44f0dd5b0a..7c902f50d38b 100644
--- a/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c
+++ b/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c
@@ -371,10 +371,6 @@ u8 rtw_set_802_11_bssid_list_scan(struct adapter *padapter, struct ndis_802_11_s
 	struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
 	u8 res = true;

-	if (!padapter) {
-		res = false;
-		goto exit;
-	}
 	if (padapter->hw_init_completed == false) {
 		res = false;
 		goto exit;
--
2.40.0

[PATCH 1/4] staging: rtl8723bs: Delete a null pointer check in rtw_set_802_11_bssid_list_scan()

[Markus Elfring]

Date: Thu, 20 Apr 2023 15:30:23 +0200

Omit an extra null pointer check for the input parameter “padapter”
in the implementation of the function “rtw_set_802_11_bssid_list_scan”
because it should be called only with a valid pointer.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/staging/rtl8723bs/core/rtw_ioctl_set.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c b/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c
index 3b44f0dd5b0a..7c902f50d38b 100644
--- a/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c
+++ b/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c
@@ -371,10 +371,6 @@ u8 rtw_set_802_11_bssid_list_scan(struct adapter *padapter, struct ndis_802_11_s
 	struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
 	u8 res = true;

-	if (!padapter) {
-		res = false;
-		goto exit;
-	}
 	if (padapter->hw_init_completed == false) {
 		res = false;
 		goto exit;
--
2.40.0

[PATCH 2/4] staging: rtl8723bs: Return directly after a failed initialisation check in rtw_set_802_11_bssid_list_scan()

[Markus Elfring]

Date: Thu, 20 Apr 2023 15:46:37 +0200

1. Return directly if the hardware initialisation was not completed so far.

2. Delete the label “exit” which became unnecessary with this refactoring.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/staging/rtl8723bs/core/rtw_ioctl_set.c | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c b/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c
index 7c902f50d38b..0c2df854afe7 100644
--- a/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c
+++ b/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c
@@ -371,10 +371,8 @@ u8 rtw_set_802_11_bssid_list_scan(struct adapter *padapter, struct ndis_802_11_s
 	struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
 	u8 res = true;

-	if (padapter->hw_init_completed == false) {
-		res = false;
-		goto exit;
-	}
+	if (!padapter->hw_init_completed)
+		return false;

 	if ((check_fwstate(pmlmepriv, _FW_UNDER_SURVEY|_FW_UNDER_LINKING) == true) ||
 		(pmlmepriv->LinkDetectInfo.bBusyTraffic == true)) {
@@ -391,8 +389,6 @@ u8 rtw_set_802_11_bssid_list_scan(struct adapter *padapter, struct ndis_802_11_s

 		spin_unlock_bh(&pmlmepriv->lock);
 	}
-exit:
-
 	return res;
 }

--
2.40.0

[cocci] [PATCH 2/4] staging: rtl8723bs: Return directly after a failed initialisation check in rtw_set_802_11_bssid_list_scan()

[Markus Elfring]

Date: Thu, 20 Apr 2023 15:46:37 +0200

1. Return directly if the hardware initialisation was not completed so far.

2. Delete the label “exit” which became unnecessary with this refactoring.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/staging/rtl8723bs/core/rtw_ioctl_set.c | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c b/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c
index 7c902f50d38b..0c2df854afe7 100644
--- a/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c
+++ b/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c
@@ -371,10 +371,8 @@ u8 rtw_set_802_11_bssid_list_scan(struct adapter *padapter, struct ndis_802_11_s
 	struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
 	u8 res = true;

-	if (padapter->hw_init_completed == false) {
-		res = false;
-		goto exit;
-	}
+	if (!padapter->hw_init_completed)
+		return false;

 	if ((check_fwstate(pmlmepriv, _FW_UNDER_SURVEY|_FW_UNDER_LINKING) == true) ||
 		(pmlmepriv->LinkDetectInfo.bBusyTraffic == true)) {
@@ -391,8 +389,6 @@ u8 rtw_set_802_11_bssid_list_scan(struct adapter *padapter, struct ndis_802_11_s

 		spin_unlock_bh(&pmlmepriv->lock);
 	}
-exit:
-
 	return res;
 }

--
2.40.0

[cocci] [PATCH 3/4] staging: rtl8723bs: Delete an unnecessary variable initialisation in rtw_set_802_11_bssid_list_scan()

[Markus Elfring]

Date: Thu, 20 Apr 2023 15:55:48 +0200

The variable “res” will eventually be set to an appropriate value
a bit later.
Thus omit the explicit initialisation at the beginning.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/staging/rtl8723bs/core/rtw_ioctl_set.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c b/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c
index 0c2df854afe7..0716b704106d 100644
--- a/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c
+++ b/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c
@@ -369,7 +369,7 @@ u8 rtw_set_802_11_disassociate(struct adapter *padapter)
 u8 rtw_set_802_11_bssid_list_scan(struct adapter *padapter, struct ndis_802_11_ssid *pssid, int ssid_max_num)
 {
 	struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
-	u8 res = true;
+	u8 res;

 	if (!padapter->hw_init_completed)
 		return false;
--
2.40.0

[PATCH 3/4] staging: rtl8723bs: Delete an unnecessary variable initialisation in rtw_set_802_11_bssid_list_scan()

[Markus Elfring]

Date: Thu, 20 Apr 2023 15:55:48 +0200

The variable “res” will eventually be set to an appropriate value
a bit later.
Thus omit the explicit initialisation at the beginning.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/staging/rtl8723bs/core/rtw_ioctl_set.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c b/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c
index 0c2df854afe7..0716b704106d 100644
--- a/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c
+++ b/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c
@@ -369,7 +369,7 @@ u8 rtw_set_802_11_disassociate(struct adapter *padapter)
 u8 rtw_set_802_11_bssid_list_scan(struct adapter *padapter, struct ndis_802_11_ssid *pssid, int ssid_max_num)
 {
 	struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
-	u8 res = true;
+	u8 res;

 	if (!padapter->hw_init_completed)
 		return false;
--
2.40.0

[PATCH 4/4] staging: rtl8723bs: Move a variable assignment behind a condition check in rtw_set_802_11_bssid_list_scan()

[Markus Elfring]

Date: Thu, 20 Apr 2023 16:06:08 +0200

Convert the explicit initialisation of the local variable “pmlmepriv”
at the beginning to an assignment statement directly before
the source code place where this pointer is used.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/staging/rtl8723bs/core/rtw_ioctl_set.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c b/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c
index 0716b704106d..fc6875b4697e 100644
--- a/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c
+++ b/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c
@@ -368,12 +368,13 @@ u8 rtw_set_802_11_disassociate(struct adapter *padapter)

 u8 rtw_set_802_11_bssid_list_scan(struct adapter *padapter, struct ndis_802_11_ssid *pssid, int ssid_max_num)
 {
-	struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
+	struct mlme_priv *pmlmepriv;
 	u8 res;

 	if (!padapter->hw_init_completed)
 		return false;

+	pmlmepriv = &padapter->mlmepriv;
 	if ((check_fwstate(pmlmepriv, _FW_UNDER_SURVEY|_FW_UNDER_LINKING) == true) ||
 		(pmlmepriv->LinkDetectInfo.bBusyTraffic == true)) {
 		/*  Scan or linking is in progress, do nothing. */
--
2.40.0

[cocci] [PATCH 4/4] staging: rtl8723bs: Move a variable assignment behind a condition check in rtw_set_802_11_bssid_list_scan()

[Markus Elfring]

Date: Thu, 20 Apr 2023 16:06:08 +0200

Convert the explicit initialisation of the local variable “pmlmepriv”
at the beginning to an assignment statement directly before
the source code place where this pointer is used.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/staging/rtl8723bs/core/rtw_ioctl_set.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c b/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c
index 0716b704106d..fc6875b4697e 100644
--- a/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c
+++ b/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c
@@ -368,12 +368,13 @@ u8 rtw_set_802_11_disassociate(struct adapter *padapter)

 u8 rtw_set_802_11_bssid_list_scan(struct adapter *padapter, struct ndis_802_11_ssid *pssid, int ssid_max_num)
 {
-	struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
+	struct mlme_priv *pmlmepriv;
 	u8 res;

 	if (!padapter->hw_init_completed)
 		return false;

+	pmlmepriv = &padapter->mlmepriv;
 	if ((check_fwstate(pmlmepriv, _FW_UNDER_SURVEY|_FW_UNDER_LINKING) == true) ||
 		(pmlmepriv->LinkDetectInfo.bBusyTraffic == true)) {
 		/*  Scan or linking is in progress, do nothing. */
--
2.40.0