Re: [v3] Coccinelle: suggest replacing strncpy+truncation by strscpy

> The problem is that I don't know if the script is correct Will the clarification of such a concern evolve into another interesting software development adventure? > - I'm not familiar with these string functions. How are the chances to improve the understanding of affected programming

Re: [v3] Coccinelle: suggest replacing strncpy+truncation by strscpy

> The problem is that I don't know if the script is correct Will the clarification of such a concern evolve into another interesting software development adventure? > - I'm not familiar with these string functions. How are the chances to improve the understanding of affected programming

[PATCH 4/6] Coccinelle: atomic_as_refcounter: Replace disjunction by a constraint in two SmPL rules

From: Markus Elfring Date: Mon, 2 Jul 2018 18:45:15 +0200 Three function names were specified for a search of function calls by the means of a disjunction in two rules of a script for the semantic patch language. Use a regular expression as a constraint for this source code search pattern

[PATCH 4/6] Coccinelle: atomic_as_refcounter: Replace disjunction by a constraint in two SmPL rules

From: Markus Elfring Date: Mon, 2 Jul 2018 18:45:15 +0200 Three function names were specified for a search of function calls by the means of a disjunction in two rules of a script for the semantic patch language. Use a regular expression as a constraint for this source code search pattern

[PATCH 3/6] Coccinelle: atomic_as_refcounter: Use type “expression” for another metavariable

From: Markus Elfring Date: Mon, 2 Jul 2018 17:55:27 +0200 The metavariable “a” is enclosed by parentheses in three rules of a script for the semantic patch language. Replace its type by “expression” so that the corresponding source code search becomes more powerful. Signed-off-by: Markus

[PATCH 3/6] Coccinelle: atomic_as_refcounter: Use type “expression” for another metavariable

From: Markus Elfring Date: Mon, 2 Jul 2018 17:55:27 +0200 The metavariable “a” is enclosed by parentheses in three rules of a script for the semantic patch language. Replace its type by “expression” so that the corresponding source code search becomes more powerful. Signed-off-by: Markus

[PATCH 0/6] Coccinelle: atomic_as_refcounter: Improvements for source code search specifications

From: Markus Elfring Date: Tue, 3 Jul 2018 09:15:26 +0200 This source code search pattern was programmed in the way that some implementation details could be improved further. I suggest to avoid unnecessary code repetition also in this script for the semantic patch language. Markus Elfring (6):

[PATCH 0/6] Coccinelle: atomic_as_refcounter: Improvements for source code search specifications

From: Markus Elfring Date: Tue, 3 Jul 2018 09:15:26 +0200 This source code search pattern was programmed in the way that some implementation details could be improved further. I suggest to avoid unnecessary code repetition also in this script for the semantic patch language. Markus Elfring (6):

Re: [PATCH v3 12/16] treewide: Use array_size() for kmalloc()-family

>> * The repetition of such a constraint in subsequent SmPL rules could be >> avoided >> if inheritance will be used for this metavariable. > > This is quite incorrect. I suggest to consider additional software design options. > Inheritance is only possible when a match of the previous rule

Re: [PATCH v3 12/16] treewide: Use array_size() for kmalloc()-family

>> * The repetition of such a constraint in subsequent SmPL rules could be >> avoided >> if inheritance will be used for this metavariable. > > This is quite incorrect. I suggest to consider additional software design options. > Inheritance is only possible when a match of the previous rule

Re: [PATCH v3 12/16] treewide: Use array_size() for kmalloc()-family

> For kmalloc()-family allocations, instead of A * B, use array_size(). > Similarly, instead of A * B *C, use array3_size(). It took a while until my software development attention was caught also by this update suggestion. > Note that: > kmalloc(array_size(a, b), ...); > could be written

Re: [PATCH v3 12/16] treewide: Use array_size() for kmalloc()-family

> For kmalloc()-family allocations, instead of A * B, use array_size(). > Similarly, instead of A * B *C, use array3_size(). It took a while until my software development attention was caught also by this update suggestion. > Note that: > kmalloc(array_size(a, b), ...); > could be written

Re: [v3] [media] Use common error handling code in 19 functions

> @@ -656,18 +656,18 @@ static int dvb_dmxdev_start_feed(struct dmxdev *dmxdev, > tsfeed->priv = filter; > > ret = tsfeed->set(tsfeed, feed->pid, ts_type, ts_pes, timeout); > - if (ret < 0) { > - dmxdev->demux->release_ts_feed(dmxdev->demux, tsfeed); > -

Re: [v3] [media] Use common error handling code in 19 functions

> @@ -656,18 +656,18 @@ static int dvb_dmxdev_start_feed(struct dmxdev *dmxdev, > tsfeed->priv = filter; > > ret = tsfeed->set(tsfeed, feed->pid, ts_type, ts_pes, timeout); > - if (ret < 0) { > - dmxdev->demux->release_ts_feed(dmxdev->demux, tsfeed); > -

Re: [v3] [media] Use common error handling code in 19 functions

> Adjust jump targets so that a bit of exception handling can be better > reused at the end of these functions. Why was this update suggestion rejected once more a moment ago? https://patchwork.linuxtv.org/patch/47827/

Re: [v3] [media] Use common error handling code in 19 functions

> Adjust jump targets so that a bit of exception handling can be better > reused at the end of these functions. Why was this update suggestion rejected once more a moment ago? https://patchwork.linuxtv.org/patch/47827/

Re: [0/9] UML vector network driver: Adjustments for three function implementations

> Date: Sun, 11 Mar 2018 16:06:16 +0100 > > Some update suggestions were taken into account > from static source code analysis. … > Delete unnecessary code in user_init_raw_fds() > Less checks in user_init_raw_fds() after error detection > Adjust an error message in user_init_socket_fds() >

Re: [0/9] UML vector network driver: Adjustments for three function implementations

> Date: Sun, 11 Mar 2018 16:06:16 +0100 > > Some update suggestions were taken into account > from static source code analysis. … > Delete unnecessary code in user_init_raw_fds() > Less checks in user_init_raw_fds() after error detection > Adjust an error message in user_init_socket_fds() >

Re: iio/gyro/bmg160_core: Improve unlocking of a mutex in five functions

>> The mutex was (and is still only) locked within case branches, isn't it? >> > You are correct, this does however reflect the issue with the resulting > lack of balance here. Do you find changes for the other function implementations easier to integrate? Regards, Markus

Re: iio/gyro/bmg160_core: Improve unlocking of a mutex in five functions

>> The mutex was (and is still only) locked within case branches, isn't it? >> > You are correct, this does however reflect the issue with the resulting > lack of balance here. Do you find changes for the other function implementations easier to integrate? Regards, Markus

Re: [2/4] scsi: hpsa: Less function calls in hpsa_big_passthru_ioctl() after error detection

>> @@ -6501,14 +6501,16 @@ static int hpsa_big_passthru_ioctl(struct ctlr_info >> *h, void __user *argp) >> cleanup0: >> cmd_free(h, c); >> cleanup1: >> - if (buff) { >> + { >> int i; >> >> for (i = 0; i < sg_used; i++) >>

Re: [2/4] scsi: hpsa: Less function calls in hpsa_big_passthru_ioctl() after error detection

>> @@ -6501,14 +6501,16 @@ static int hpsa_big_passthru_ioctl(struct ctlr_info >> *h, void __user *argp) >> cleanup0: >> cmd_free(h, c); >> cleanup1: >> - if (buff) { >> + { >> int i; >> >> for (i = 0; i < sg_used; i++) >>

Re: iio/gyro/bmg160_core: Improve unlocking of a mutex in five functions

>> The mutex was (and is still only) locked within case branches, isn't it? >> > You are correct, this does however reflect the issue with the resulting > lack of balance here. I suggest to reconsider affected software aspects a bit more. > I saw the mutex was getting unlocked outside the local

Re: iio/gyro/bmg160_core: Improve unlocking of a mutex in five functions

>> The mutex was (and is still only) locked within case branches, isn't it? >> > You are correct, this does however reflect the issue with the resulting > lack of balance here. I suggest to reconsider affected software aspects a bit more. > I saw the mutex was getting unlocked outside the local

Re: iio/gyro/bmg160_core: Improve unlocking of a mutex in five functions

Am 17.03.2018 um 20:54 schrieb Jonathan Cameron: > On Wed, 14 Mar 2018 16:15:32 +0100 > SF Markus Elfring <elfr...@users.sourceforge.net> wrote: > >> From: Markus Elfring <elfr...@users.sourceforge.net> >> Date: Wed, 14 Mar 2018 16:06:49 +0100 >&g

Re: iio/gyro/bmg160_core: Improve unlocking of a mutex in five functions

Am 17.03.2018 um 20:54 schrieb Jonathan Cameron: > On Wed, 14 Mar 2018 16:15:32 +0100 > SF Markus Elfring wrote: > >> From: Markus Elfring >> Date: Wed, 14 Mar 2018 16:06:49 +0100 >> >> * Add jump targets so that a call of the function "mutex_unlock"

[PATCH] cxgb4/cudbg_lib: Use common error handling code in cudbg_collect_tid()

From: Markus Elfring Date: Thu, 15 Mar 2018 14:56:10 +0100 Add a jump target so that a bit of exception handling can be better reused at the end of this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring

[PATCH] cxgb4/cudbg_lib: Use common error handling code in cudbg_collect_tid()

From: Markus Elfring Date: Thu, 15 Mar 2018 14:56:10 +0100 Add a jump target so that a bit of exception handling can be better reused at the end of this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

Re: [media] ov5645: Move an error code assignment in ov5645_probe()

>> Move an assignment for a specific error code so that it is stored only once >> in this function implementation. >> >> This issue was detected by using the Coccinelle software. > > How? Would you like to experiment a bit more with the following approach for the semantic patch language?

Re: [media] ov5645: Move an error code assignment in ov5645_probe()

>> Move an assignment for a specific error code so that it is stored only once >> in this function implementation. >> >> This issue was detected by using the Coccinelle software. > > How? Would you like to experiment a bit more with the following approach for the semantic patch language?

[PATCH] [media] ov5645: Move an error code assignment in ov5645_probe()

From: Markus Elfring Date: Wed, 14 Mar 2018 22:02:52 +0100 Move an assignment for a specific error code so that it is stored only once in this function implementation. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring

[PATCH] [media] ov5645: Move an error code assignment in ov5645_probe()

From: Markus Elfring Date: Wed, 14 Mar 2018 22:02:52 +0100 Move an assignment for a specific error code so that it is stored only once in this function implementation. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/media/i2c/ov5645.c | 6

[PATCH] iio/gyro/bmg160_core: Improve unlocking of a mutex in five functions

From: Markus Elfring Date: Wed, 14 Mar 2018 16:06:49 +0100 * Add jump targets so that a call of the function "mutex_unlock" is stored only once in these function implementations. * Replace 19 calls by goto statements. This issue was detected by using the

[PATCH] iio/gyro/bmg160_core: Improve unlocking of a mutex in five functions

From: Markus Elfring Date: Wed, 14 Mar 2018 16:06:49 +0100 * Add jump targets so that a call of the function "mutex_unlock" is stored only once in these function implementations. * Replace 19 calls by goto statements. This issue was detected by using the Coccinelle software. Signed-off-by:

[PATCH] iio/adc/nau7802: Improve unlocking of a mutex in nau7802_read_raw()

From: Markus Elfring Date: Tue, 13 Mar 2018 20:52:26 +0100 * Add a jump target so that a call of the function "mutex_unlock" is stored only once in this function implementation. * Replace two calls by goto statements. This issue was detected by using the

[PATCH] iio/adc/nau7802: Improve unlocking of a mutex in nau7802_read_raw()

From: Markus Elfring Date: Tue, 13 Mar 2018 20:52:26 +0100 * Add a jump target so that a call of the function "mutex_unlock" is stored only once in this function implementation. * Replace two calls by goto statements. This issue was detected by using the Coccinelle software. Signed-off-by:

[PATCH] iio/adc/ad7291: Improve unlocking of a mutex in ad7291_read_raw()

From: Markus Elfring Date: Tue, 13 Mar 2018 20:08:40 +0100 * Add a jump target so that a call of the function "mutex_unlock" is stored only once in this function implementation. * Replace three calls by goto statements. This issue was detected by using the

[PATCH] iio/adc/ad7291: Improve unlocking of a mutex in ad7291_read_raw()

From: Markus Elfring Date: Tue, 13 Mar 2018 20:08:40 +0100 * Add a jump target so that a call of the function "mutex_unlock" is stored only once in this function implementation. * Replace three calls by goto statements. This issue was detected by using the Coccinelle software.

[PATCH] iio/accel/kxcjk-1013: Improve unlocking of a mutex in three functions

From: Markus Elfring Date: Tue, 13 Mar 2018 13:40:12 +0100 * Add jump targets so that a call of the function "mutex_unlock" is stored less often in these function implementations. * Replace eight calls by goto statements. This issue was detected by using the

[PATCH] iio/accel/kxcjk-1013: Improve unlocking of a mutex in three functions

From: Markus Elfring Date: Tue, 13 Mar 2018 13:40:12 +0100 * Add jump targets so that a call of the function "mutex_unlock" is stored less often in these function implementations. * Replace eight calls by goto statements. This issue was detected by using the Coccinelle software.

Re: hwmon/sch5627: Use common error handling code in sch5627_probe()

>  1 file changed, 29 insertions(+), 31 deletions(-) > > So you are asking people to review 60 changed lines to save 2, A bit of object code reduction might become useful also in this case. > that alone should be the point where you stop yourself from > *even* sending this patch. I proposed

Re: hwmon/sch5627: Use common error handling code in sch5627_probe()

>  1 file changed, 29 insertions(+), 31 deletions(-) > > So you are asking people to review 60 changed lines to save 2, A bit of object code reduction might become useful also in this case. > that alone should be the point where you stop yourself from > *even* sending this patch. I proposed

Re: hwmon/sch5627: Use common error handling code in sch5627_probe()

>> Adjust jump targets so that a bit of exception handling can be better >> reused at the end of this function. … > goto-s going to a label calling another goto is completely unreadable. I got an other software development view. > I really do not see any reason for the proposed changes, I

Re: hwmon/sch5627: Use common error handling code in sch5627_probe()

>> Adjust jump targets so that a bit of exception handling can be better >> reused at the end of this function. … > goto-s going to a label calling another goto is completely unreadable. I got an other software development view. > I really do not see any reason for the proposed changes, I

Re: [PATCH 5/5] Bluetooth: btmrvl: Use common error handling code in btmrvl_sdio_download_fw_w_helper()

>> Add a jump target so that the setting of a specific error code is stored >> only once at the end of this function. >> >> Signed-off-by: Markus Elfring >> --- >> drivers/bluetooth/btmrvl_sdio.c | 13 +++-- >> 1 file changed, 7 insertions(+), 6 deletions(-)

Re: [PATCH 5/5] Bluetooth: btmrvl: Use common error handling code in btmrvl_sdio_download_fw_w_helper()

>> Add a jump target so that the setting of a specific error code is stored >> only once at the end of this function. >> >> Signed-off-by: Markus Elfring >> --- >> drivers/bluetooth/btmrvl_sdio.c | 13 +++-- >> 1 file changed, 7 insertions(+), 6 deletions(-) >> >> diff --git

Re: [3/5] Bluetooth: btmrvl: One check less in btmrvl_sdio_card_to_host()

>> @@ -797,12 +792,18 @@ static int btmrvl_sdio_card_to_host(struct >> btmrvl_private *priv) >> break; >> } >> >> -exit: >> -if (ret) { >> -hdev->stat.err_rx++; >> -kfree_skb(skb); >> -} >> +return 0; >> + >> +free_skb: >> +kfree_skb(skb);

Re: [3/5] Bluetooth: btmrvl: One check less in btmrvl_sdio_card_to_host()

>> @@ -797,12 +792,18 @@ static int btmrvl_sdio_card_to_host(struct >> btmrvl_private *priv) >> break; >> } >> >> -exit: >> -if (ret) { >> -hdev->stat.err_rx++; >> -kfree_skb(skb); >> -} >> +return 0; >> + >> +free_skb: >> +kfree_skb(skb);

Re: [2/2] net/usb/ax88179_178a: Delete three unnecessary variables in ax88179_chk_eee()

>> Use three values directly for a condition check without assigning them >> to intermediate variables. > > Hi, > > what is the benefit of this? I proposed a small source code reduction. Other software design directions might become more interesting for this use case. Regards, Markus

Re: [2/2] net/usb/ax88179_178a: Delete three unnecessary variables in ax88179_chk_eee()

>> Use three values directly for a condition check without assigning them >> to intermediate variables. > > Hi, > > what is the benefit of this? I proposed a small source code reduction. Other software design directions might become more interesting for this use case. Regards, Markus

Re: [v2 14/17 4/4] mfd: tps65910: Checking patch structures

> How have you managed to insert 4 patches into the x/17 thread? I dared to group the desired patch series into dedicated mail threads. Regards, Markus

Re: [v2 14/17 4/4] mfd: tps65910: Checking patch structures

> How have you managed to insert 4 patches into the x/17 thread? I dared to group the desired patch series into dedicated mail threads. Regards, Markus

Re: [2/9] um/drivers/vector_user: Less checks in user_init_raw_fds() after error detection

> +set_error_code: > + err = -errno; > + os_close_file(rxfd); I have taken another look at this change idea. Now I notice that I should have preserved a sanity check there. if (rxfd >= 0) os_close_file(rxfd); Regards, Markus

Re: [2/9] um/drivers/vector_user: Less checks in user_init_raw_fds() after error detection

> +set_error_code: > + err = -errno; > + os_close_file(rxfd); I have taken another look at this change idea. Now I notice that I should have preserved a sanity check there. if (rxfd >= 0) os_close_file(rxfd); Regards, Markus

[PATCH] hwmon/sch5627: Use common error handling code in sch5627_probe()

From: Markus Elfring Date: Mon, 12 Mar 2018 22:15:59 +0100 Adjust jump targets so that a bit of exception handling can be better reused at the end of this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring

[PATCH] hwmon/sch5627: Use common error handling code in sch5627_probe()

From: Markus Elfring Date: Mon, 12 Mar 2018 22:15:59 +0100 Adjust jump targets so that a bit of exception handling can be better reused at the end of this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/hwmon/sch5627.c | 60

[PATCH] altera_edac: Use common error handling code in altr_sdram_probe()

From: Markus Elfring Date: Mon, 12 Mar 2018 16:23:53 +0100 Add a jump target so that a specific error code is assigned to the local variable "res" at the end of this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring

[PATCH] altera_edac: Use common error handling code in altr_sdram_probe()

From: Markus Elfring Date: Mon, 12 Mar 2018 16:23:53 +0100 Add a jump target so that a specific error code is assigned to the local variable "res" at the end of this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

Re: dmaengine: edma: Use common error handling code in three functions

> Date: Sun, 22 Oct 2017 16:46:34 +0200 > > Add a jump target so that a bit of exception handling can be better reused > at the end of these functions. How are the chances to integrate such a change into another Linux repository? https://lkml.org/lkml/2017/10/22/78

Re: dmaengine: edma: Use common error handling code in three functions

> Date: Sun, 22 Oct 2017 16:46:34 +0200 > > Add a jump target so that a bit of exception handling can be better reused > at the end of these functions. How are the chances to integrate such a change into another Linux repository? https://lkml.org/lkml/2017/10/22/78

[PATCH 2/2] crypto: talitos: Delete an error message for a failed memory allocation in talitos_edesc_alloc()

From: Markus Elfring Date: Mon, 12 Mar 2018 14:18:23 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

[PATCH 2/2] crypto: talitos: Delete an error message for a failed memory allocation in talitos_edesc_alloc()

From: Markus Elfring Date: Mon, 12 Mar 2018 14:18:23 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/crypto/talitos.c | 1 - 1 file changed, 1 deletion(-) diff

[PATCH 1/2] crypto: talitos: Use common error handling code in talitos_edesc_alloc()

From: Markus Elfring Date: Mon, 12 Mar 2018 14:08:55 +0100 Add jump targets so that an error message and the setting of a specific error code is stored only once at the end of this function. Signed-off-by: Markus Elfring ---

[PATCH 1/2] crypto: talitos: Use common error handling code in talitos_edesc_alloc()

From: Markus Elfring Date: Mon, 12 Mar 2018 14:08:55 +0100 Add jump targets so that an error message and the setting of a specific error code is stored only once at the end of this function. Signed-off-by: Markus Elfring --- drivers/crypto/talitos.c | 24 1 file

[PATCH 0/2] crypto/talitos: Adjustments for talitos_edesc_alloc()

From: Markus Elfring Date: Mon, 12 Mar 2018 14:24:34 +0100 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Use common error handling code Delete an error message for a failed memory allocation

[PATCH 0/2] crypto/talitos: Adjustments for talitos_edesc_alloc()

From: Markus Elfring Date: Mon, 12 Mar 2018 14:24:34 +0100 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Use common error handling code Delete an error message for a failed memory allocation drivers/crypto/talitos.c | 25

[PATCH 5/5] Bluetooth: btmrvl: Use common error handling code in btmrvl_sdio_download_fw_w_helper()

From: Markus Elfring Date: Mon, 12 Mar 2018 11:30:28 +0100 Add a jump target so that the setting of a specific error code is stored only once at the end of this function. Signed-off-by: Markus Elfring ---

[PATCH 5/5] Bluetooth: btmrvl: Use common error handling code in btmrvl_sdio_download_fw_w_helper()

From: Markus Elfring Date: Mon, 12 Mar 2018 11:30:28 +0100 Add a jump target so that the setting of a specific error code is stored only once at the end of this function. Signed-off-by: Markus Elfring --- drivers/bluetooth/btmrvl_sdio.c | 13 +++-- 1 file changed, 7 insertions(+), 6

[PATCH 4/5] Bluetooth: btmrvl: Delete an unnecessary variable initialisation in btmrvl_sdio_card_to_host()

From: Markus Elfring Date: Mon, 12 Mar 2018 11:15:59 +0100 The variable "payload" will eventually be set to an appropriate pointer a bit later. Thus omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring

[PATCH 4/5] Bluetooth: btmrvl: Delete an unnecessary variable initialisation in btmrvl_sdio_card_to_host()

From: Markus Elfring Date: Mon, 12 Mar 2018 11:15:59 +0100 The variable "payload" will eventually be set to an appropriate pointer a bit later. Thus omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring --- drivers/bluetooth/btmrvl_sdio.c | 2 +- 1 file changed, 1

[PATCH 3/5] Bluetooth: btmrvl: One check less in btmrvl_sdio_card_to_host() after error detection

From: Markus Elfring Date: Mon, 12 Mar 2018 11:13:00 +0100 One check could be repeated by the btmrvl_sdio_card_to_host() function during error handling even if the relevant properties can be determined for the involved variables before by source code analysis. *

[PATCH 3/5] Bluetooth: btmrvl: One check less in btmrvl_sdio_card_to_host() after error detection

From: Markus Elfring Date: Mon, 12 Mar 2018 11:13:00 +0100 One check could be repeated by the btmrvl_sdio_card_to_host() function during error handling even if the relevant properties can be determined for the involved variables before by source code analysis. * Adjust jump targets so that an

[PATCH 2/5] Bluetooth: btmrvl: Delete an unnecessary variable initialisation in btmrvl_sdio_register_dev()

From: Markus Elfring Date: Mon, 12 Mar 2018 10:20:04 +0100 The local variable "ret" will be set to an appropriate value a bit later. Thus omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring ---

[PATCH 2/5] Bluetooth: btmrvl: Delete an unnecessary variable initialisation in btmrvl_sdio_register_dev()

From: Markus Elfring Date: Mon, 12 Mar 2018 10:20:04 +0100 The local variable "ret" will be set to an appropriate value a bit later. Thus omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring --- drivers/bluetooth/btmrvl_sdio.c | 2 +- 1 file changed, 1

[PATCH 1/5] Bluetooth: btmrvl: Use common error handling code in btmrvl_sdio_register_dev()

From: Markus Elfring Date: Mon, 12 Mar 2018 10:15:17 +0100 Adjust a jump target so that a bit of exception handling can be better reused at the end of this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring

[PATCH 1/5] Bluetooth: btmrvl: Use common error handling code in btmrvl_sdio_register_dev()

From: Markus Elfring Date: Mon, 12 Mar 2018 10:15:17 +0100 Adjust a jump target so that a bit of exception handling can be better reused at the end of this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/bluetooth/btmrvl_sdio.c |

[PATCH 0/5] Bluetooth/btmrvl_sdio: Adjustments for three function implementations

From: Markus Elfring Date: Mon, 12 Mar 2018 12:10:24 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (5): Use common error handling code in btmrvl_sdio_register_dev() Delete an unnecessary variable

[PATCH 0/5] Bluetooth/btmrvl_sdio: Adjustments for three function implementations

From: Markus Elfring Date: Mon, 12 Mar 2018 12:10:24 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (5): Use common error handling code in btmrvl_sdio_register_dev() Delete an unnecessary variable initialisation in

[PATCH 9/9] um/drivers/vector_user: Delete an unnecessary variable initialisation in user_init_tap_fds()

From: Markus Elfring Date: Sun, 11 Mar 2018 15:50:29 +0100 The local variable "fd" will eventually be set to an appropriate value a bit later. Thus omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring ---

[PATCH 9/9] um/drivers/vector_user: Delete an unnecessary variable initialisation in user_init_tap_fds()

From: Markus Elfring Date: Sun, 11 Mar 2018 15:50:29 +0100 The local variable "fd" will eventually be set to an appropriate value a bit later. Thus omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring --- arch/um/drivers/vector_user.c | 3 +-- 1 file changed, 1

[PATCH 8/9] um/drivers/vector_user: Less checks in user_init_tap_fds() after error detection

From: Markus Elfring Date: Sun, 11 Mar 2018 15:43:31 +0100 Three checks could be repeated by the user_init_tap_fds() function during error handling even if the relevant properties can be determined for the involved variables before by source code analysis. *

[PATCH 8/9] um/drivers/vector_user: Less checks in user_init_tap_fds() after error detection

From: Markus Elfring Date: Sun, 11 Mar 2018 15:43:31 +0100 Three checks could be repeated by the user_init_tap_fds() function during error handling even if the relevant properties can be determined for the involved variables before by source code analysis. * Adjust jump targets. * Delete three

[PATCH 7/9] um/drivers/vector_user: Adjust an error message in user_init_tap_fds()

From: Markus Elfring Date: Sun, 11 Mar 2018 15:10:05 +0100 Adjust an error message at the end of this function so that its name will be automatically determined as a parameter. Signed-off-by: Markus Elfring ---

[PATCH 7/9] um/drivers/vector_user: Adjust an error message in user_init_tap_fds()

From: Markus Elfring Date: Sun, 11 Mar 2018 15:10:05 +0100 Adjust an error message at the end of this function so that its name will be automatically determined as a parameter. Signed-off-by: Markus Elfring --- arch/um/drivers/vector_user.c | 3 ++- 1 file changed, 2 insertions(+), 1

[PATCH 6/9] um/drivers/vector_user: Less checks in user_init_socket_fds() after error detection

From: Markus Elfring Date: Sun, 11 Mar 2018 14:56:38 +0100 Two checks could be repeated by the user_init_socket_fds() function during error handling even if the relevant properties can be determined for the involved variables before by source code analysis. *

[PATCH 6/9] um/drivers/vector_user: Less checks in user_init_socket_fds() after error detection

From: Markus Elfring Date: Sun, 11 Mar 2018 14:56:38 +0100 Two checks could be repeated by the user_init_socket_fds() function during error handling even if the relevant properties can be determined for the involved variables before by source code analysis. * Adjust jump targets. * Delete two

[PATCH 5/9] um/drivers/vector_user: Delete two unnecessary checks before freeaddrinfo() in user_init_socket_fds()

From: Markus Elfring Date: Sun, 11 Mar 2018 14:20:46 +0100 The implementation returns from this function if a null pointer was detected in the local variable "gairesult". Thus the check before two calls of the function "freeaddrinfo" is not needed. Signed-off-by:

[PATCH 5/9] um/drivers/vector_user: Delete two unnecessary checks before freeaddrinfo() in user_init_socket_fds()

From: Markus Elfring Date: Sun, 11 Mar 2018 14:20:46 +0100 The implementation returns from this function if a null pointer was detected in the local variable "gairesult". Thus the check before two calls of the function "freeaddrinfo" is not needed. Signed-off-by: Markus Elfring ---

[PATCH 4/9] um/drivers/vector_user: Delete an unnecessary check before kfree() in user_init_socket_fds()

From: Markus Elfring Date: Sun, 11 Mar 2018 14:00:09 +0100 The kfree() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. Signed-off-by: Markus Elfring ---

[PATCH 4/9] um/drivers/vector_user: Delete an unnecessary check before kfree() in user_init_socket_fds()

From: Markus Elfring Date: Sun, 11 Mar 2018 14:00:09 +0100 The kfree() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. Signed-off-by: Markus Elfring --- arch/um/drivers/vector_user.c | 3 +-- 1 file changed, 1

[PATCH 3/9] um/drivers/vector_user: Adjust an error message in user_init_socket_fds()

From: Markus Elfring Date: Sun, 11 Mar 2018 13:53:08 +0100 * Adjust an error message at the end of this function. * Delete the local variable "err" which became unnecessary with this refactoring. Signed-off-by: Markus Elfring ---

[PATCH 3/9] um/drivers/vector_user: Adjust an error message in user_init_socket_fds()

From: Markus Elfring Date: Sun, 11 Mar 2018 13:53:08 +0100 * Adjust an error message at the end of this function. * Delete the local variable "err" which became unnecessary with this refactoring. Signed-off-by: Markus Elfring --- arch/um/drivers/vector_user.c | 5 +++-- 1 file changed, 3

[PATCH 2/9] um/drivers/vector_user: Less checks in user_init_raw_fds() after error detection

From: Markus Elfring Date: Sun, 11 Mar 2018 11:40:14 +0100 Up to two checks could be repeated by the user_init_raw_fds() function during error handling even if the relevant properties can be determined for the involved variables before by source code analysis. *

[PATCH 2/9] um/drivers/vector_user: Less checks in user_init_raw_fds() after error detection

From: Markus Elfring Date: Sun, 11 Mar 2018 11:40:14 +0100 Up to two checks could be repeated by the user_init_raw_fds() function during error handling even if the relevant properties can be determined for the involved variables before by source code analysis. * Adjust jump targets so that an

[PATCH 1/9] um/drivers/vector_user: Delete unnecessary code in user_init_raw_fds()

From: Markus Elfring Date: Sun, 11 Mar 2018 11:36:18 +0100 * One condition check could never be reached with a non-null pointer at the end of this function. Thus remove the corresponding statement. * Delete an initialisation for the local variable "result"

[PATCH 1/9] um/drivers/vector_user: Delete unnecessary code in user_init_raw_fds()

From: Markus Elfring Date: Sun, 11 Mar 2018 11:36:18 +0100 * One condition check could never be reached with a non-null pointer at the end of this function. Thus remove the corresponding statement. * Delete an initialisation for the local variable "result" which became unnecessary with this

[PATCH 0/9] UML vector network driver: Adjustments for three function implementations

From: Markus Elfring Date: Sun, 11 Mar 2018 16:06:16 +0100 Some update suggestions were taken into account from static source code analysis. Markus Elfring (9): Delete unnecessary code in user_init_raw_fds() Less checks in user_init_raw_fds() after error

[PATCH 0/9] UML vector network driver: Adjustments for three function implementations

From: Markus Elfring Date: Sun, 11 Mar 2018 16:06:16 +0100 Some update suggestions were taken into account from static source code analysis. Markus Elfring (9): Delete unnecessary code in user_init_raw_fds() Less checks in user_init_raw_fds() after error detection Adjust an error message

[PATCH] powerpc: Use common error handling code in setup_new_fdt()

From: Markus Elfring Date: Sun, 11 Mar 2018 09:03:42 +0100 Add a jump target so that a bit of exception handling can be better reused at the end of this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring

[PATCH] powerpc: Use common error handling code in setup_new_fdt()

From: Markus Elfring Date: Sun, 11 Mar 2018 09:03:42 +0100 Add a jump target so that a bit of exception handling can be better reused at the end of this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

  1   2   3   4   5   6   7   8   9   10   >