* Source code review around jump label usage @ 2015-12-11 12:08 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-11 12:08 UTC (permalink / raw) To: LKML; +Cc: kernel-janitors, Julia Lawall, Derek M. Jones Hello, I have tried another specific analysis out on the source files of "Linux next-20151211" with help of the software "Coccinelle 1.0.4". I have taken a more detailed look on the use of the goto statement and corresponding jump labels. Can statistics like the following support software evolution and further constructive considerations? ╔═════════════════════════════════════════╤═══════════╗ ║ target │ incidence ║ ╠═════════════════════════════════════════╪═══════════╣ ║ out │ 9782 ║ ║ done │ 1344 ║ ║ exit │ 950 ║ ║ out_unlock │ 538 ║ ║ unlock │ 509 ║ ║ bail │ 486 ║ ║ error │ 418 ║ ║ retry │ 414 ║ ║ err │ 400 ║ ║ end │ 332 ║ ║ … │ … ║ ║ abts_pending │ 1 ║ ║ abts_err │ 1 ║ ║ absolute_address │ 1 ║ ║ abort2 │ 1 ║ ║ abort_fail │ 1 ║ ║ abort_end │ 1 ║ ║ abituguru_probe_error │ 1 ║ ║ abituguru_detect_no_pwms_exit │ 1 ║ ║ abituguru_detect_bank1_sensor_type_exit │ 1 ║ ╚═════════════════════════════════════════╧═══════════╝ How often are different jump targets used within function implementations? (Functions without jump labels were not searched for this analysis approach.) ╔═════════╤═══════════╗ ║ counter │ incidence ║ ╠═════════╪═══════════╣ ║ 1 │ 18442 ║ ║ 2 │ 2002 ║ ║ 3 │ 356 ║ ║ 4 │ 106 ║ ║ 5 │ 31 ║ ║ 6 │ 7 ║ ║ 7 │ 2 ║ ║ 8 │ 3 ║ ╚═════════╧═══════════╝ How does the text length distribution look like for the used jump targets? ╔════════╤═══════════╗ ║ length │ incidence ║ ╠════════╪═══════════╣ ║ 1 │ 2 ║ ║ 2 │ 29 ║ ║ 3 │ 10640 ║ ║ 4 │ 3564 ║ ║ 5 │ 1714 ║ ║ 6 │ 1162 ║ ║ 7 │ 1245 ║ ║ 8 │ 881 ║ ║ 9 │ 787 ║ ║ 10 │ 1252 ║ ║ … │ … ║ ║ 35 │ 4 ║ ║ 36 │ 1 ║ ║ 37 │ 2 ║ ║ 38 │ 1 ║ ║ 39 │ 1 ║ ╚════════╧═══════════╝ How often are jump targets called within specific function implementations? ╔══════════════════════════╤═════════════════════════════════════════╤══════╤══════════════════════╤═════════╗ ║ function │ source file │ line │ go to │ counter ║ ╠══════════════════════════╪═════════════════════════════════════════╪══════╪══════════════════════╪═════════╣ ║ do_ipv6_setsockopt │ net/ipv6/ipv6_sockglue.c │ 140 │ e_inval │ 52 ║ ║ dvb_register │ drivers/media/pci/cx88/cx88-dvb.c │ 1005 │ frontend_detach │ 43 ║ ║ dvb_init │ drivers/media/pci/saa7134/saa7134-dvb.c │ 1210 │ detach_frontend │ 40 ║ ║ gdbstub_single_step │ arch/mn10300/kernel/gdb-stub.c │ 491 │ fault │ 38 ║ ║ uinput_ioctl_handler │ drivers/input/misc/uinput.c │ 701 │ out │ 32 ║ ║ … │ … │ … │ … │ … ║ ║ kvm_vm_compat_ioctl │ virt/kvm/kvm_main.c │ 2916 │ out │ 1 ║ ║ kvm_vm_ioctl │ virt/kvm/kvm_main.c │ 2742 │ out_free_irq_routing │ 1 ║ ║ kvm_vm_ioctl_create_vcpu │ virt/kvm/kvm_main.c │ 2257 │ vcpu_destroy │ 1 ║ ╚══════════════════════════╧═════════════════════════════════════════╧══════╧══════════════════════╧═════════╝ Do any of these numbers indicate update candidates which correspond to the "one error jump label bug" symptom that is mentioned in the Linux coding style documentation? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Source code review around jump label usage @ 2015-12-11 12:08 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-11 12:08 UTC (permalink / raw) To: LKML; +Cc: kernel-janitors, Julia Lawall, Derek M. Jones Hello, I have tried another specific analysis out on the source files of "Linux next-20151211" with help of the software "Coccinelle 1.0.4". I have taken a more detailed look on the use of the goto statement and corresponding jump labels. Can statistics like the following support software evolution and further constructive considerations? ╔═════════════════════════════════════════╤═══════════╗ ║ target │ incidence ║ ╠═════════════════════════════════════════╪═══════════╣ ║ out │ 9782 ║ ║ done │ 1344 ║ ║ exit │ 950 ║ ║ out_unlock │ 538 ║ ║ unlock │ 509 ║ ║ bail │ 486 ║ ║ error │ 418 ║ ║ retry │ 414 ║ ║ err │ 400 ║ ║ end │ 332 ║ ║ … │ … ║ ║ abts_pending │ 1 ║ ║ abts_err │ 1 ║ ║ absolute_address │ 1 ║ ║ abort2 │ 1 ║ ║ abort_fail │ 1 ║ ║ abort_end │ 1 ║ ║ abituguru_probe_error │ 1 ║ ║ abituguru_detect_no_pwms_exit │ 1 ║ ║ abituguru_detect_bank1_sensor_type_exit │ 1 ║ ╚═════════════════════════════════════════╧═══════════╝ How often are different jump targets used within function implementations? (Functions without jump labels were not searched for this analysis approach.) ╔═════════╤═══════════╗ ║ counter │ incidence ║ ╠═════════╪═══════════╣ ║ 1 │ 18442 ║ ║ 2 │ 2002 ║ ║ 3 │ 356 ║ ║ 4 │ 106 ║ ║ 5 │ 31 ║ ║ 6 │ 7 ║ ║ 7 │ 2 ║ ║ 8 │ 3 ║ ╚═════════╧═══════════╝ How does the text length distribution look like for the used jump targets? ╔════════╤═══════════╗ ║ length │ incidence ║ ╠════════╪═══════════╣ ║ 1 │ 2 ║ ║ 2 │ 29 ║ ║ 3 │ 10640 ║ ║ 4 │ 3564 ║ ║ 5 │ 1714 ║ ║ 6 │ 1162 ║ ║ 7 │ 1245 ║ ║ 8 │ 881 ║ ║ 9 │ 787 ║ ║ 10 │ 1252 ║ ║ … │ … ║ ║ 35 │ 4 ║ ║ 36 │ 1 ║ ║ 37 │ 2 ║ ║ 38 │ 1 ║ ║ 39 │ 1 ║ ╚════════╧═══════════╝ How often are jump targets called within specific function implementations? ╔══════════════════════════╤═════════════════════════════════════════╤══════╤══════════════════════╤═════════╗ ║ function │ source file │ line │ go to │ counter ║ ╠══════════════════════════╪═════════════════════════════════════════╪══════╪══════════════════════╪═════════╣ ║ do_ipv6_setsockopt │ net/ipv6/ipv6_sockglue.c │ 140 │ e_inval │ 52 ║ ║ dvb_register │ drivers/media/pci/cx88/cx88-dvb.c │ 1005 │ frontend_detach │ 43 ║ ║ dvb_init │ drivers/media/pci/saa7134/saa7134-dvb.c │ 1210 │ detach_frontend │ 40 ║ ║ gdbstub_single_step │ arch/mn10300/kernel/gdb-stub.c │ 491 │ fault │ 38 ║ ║ uinput_ioctl_handler │ drivers/input/misc/uinput.c │ 701 │ out │ 32 ║ ║ … │ … │ … │ … │ … ║ ║ kvm_vm_compat_ioctl │ virt/kvm/kvm_main.c │ 2916 │ out │ 1 ║ ║ kvm_vm_ioctl │ virt/kvm/kvm_main.c │ 2742 │ out_free_irq_routing │ 1 ║ ║ kvm_vm_ioctl_create_vcpu │ virt/kvm/kvm_main.c │ 2257 │ vcpu_destroy │ 1 ║ ╚══════════════════════════╧═════════════════════════════════════════╧══════╧══════════════════════╧═════════╝ Do any of these numbers indicate update candidates which correspond to the "one error jump label bug" symptom that is mentioned in the Linux coding style documentation? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: Source code review around jump label usage 2015-12-11 12:08 ` SF Markus Elfring @ 2015-12-11 12:14 ` Julia Lawall -1 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2015-12-11 12:14 UTC (permalink / raw) To: SF Markus Elfring; +Cc: LKML, kernel-janitors, Derek M. Jones > Do any of these numbers indicate update candidates which correspond to the > "one error jump label bug" symptom that is mentioned in the Linux coding > style documentation? I don't think that numbers could indicate that. The point of that is a single label followed by a bunch of ifs, or by calls to functions that perform tests on input validity. That is, it is the content of the code that causes the problem, not its size. Dan also discourages the use of labels like out, that don't indicate anything about anything, or kmalloc_err, which don't indicate anything about what happens at the label target. julia ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: Source code review around jump label usage @ 2015-12-11 12:14 ` Julia Lawall 0 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2015-12-11 12:14 UTC (permalink / raw) To: SF Markus Elfring; +Cc: LKML, kernel-janitors, Derek M. Jones > Do any of these numbers indicate update candidates which correspond to the > "one error jump label bug" symptom that is mentioned in the Linux coding > style documentation? I don't think that numbers could indicate that. The point of that is a single label followed by a bunch of ifs, or by calls to functions that perform tests on input validity. That is, it is the content of the code that causes the problem, not its size. Dan also discourages the use of labels like out, that don't indicate anything about anything, or kmalloc_err, which don't indicate anything about what happens at the label target. julia ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: Source code review around jump label usage 2015-12-11 12:08 ` SF Markus Elfring @ 2015-12-11 12:48 ` Dan Carpenter -1 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2015-12-11 12:48 UTC (permalink / raw) To: SF Markus Elfring; +Cc: LKML, kernel-janitors, Julia Lawall, Derek M. Jones I hate out labels but a lot of people like them and they're not prohibited by kernel style. I only complain about them when they introduce bugs. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: Source code review around jump label usage @ 2015-12-11 12:48 ` Dan Carpenter 0 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2015-12-11 12:48 UTC (permalink / raw) To: SF Markus Elfring; +Cc: LKML, kernel-janitors, Julia Lawall, Derek M. Jones I hate out labels but a lot of people like them and they're not prohibited by kernel style. I only complain about them when they introduce bugs. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: Source code review around jump label usage 2015-12-11 12:08 ` SF Markus Elfring ` (2 preceding siblings ...) (?) @ 2015-12-11 18:00 ` Christophe JAILLET -1 siblings, 0 replies; 3089+ messages in thread From: Christophe JAILLET @ 2015-12-11 18:00 UTC (permalink / raw) To: linux-kernel; +Cc: kernel-janitors Le 11/12/2015 13:08, SF Markus Elfring a écrit : > How does the text length distribution look like for the used jump targets? > > ╔════════╤═══════════╗ > ║ length │ incidence ║ > ╠════════╪═══════════╣ > ║ 1 │ 2 ║ > ║ 2 │ 29 ║ > ║ 3 │ 10640 ║ > ║ 4 │ 3564 ║ > ║ 5 │ 1714 ║ > ║ 6 │ 1162 ║ > ║ 7 │ 1245 ║ > ║ 8 │ 881 ║ > ║ 9 │ 787 ║ > ║ 10 │ 1252 ║ > ║ … │ … ║ > ║ 35 │ 4 ║ > ║ 36 │ 1 ║ > ║ 37 │ 2 ║ > ║ 38 │ 1 ║ > ║ 39 │ 1 ║ > ╚════════╧═══════════╝ > Maybe having a look at the 1 or 2 chars long labels would make sense. They are likely to be too short for being of any use. IMHO, too long labels may also reduce readability. Best regards, CJ ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/2] block: Fine-tuning for two function implementations 2015-12-11 12:08 ` SF Markus Elfring @ 2015-12-11 18:19 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-11 18:19 UTC (permalink / raw) To: LKML, Minchan Kim, Nitin Gupta, Sergey Senozhatsky Cc: kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 11 Dec 2015 19:12:34 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (2): zram: Less checks in zram_bvec_write() after error detection z2ram: Delete a jump label in z2_init() drivers/block/z2ram.c | 4 +--- drivers/block/zram/zram_drv.c | 26 +++++++++++++------------- 2 files changed, 14 insertions(+), 16 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/2] block: Fine-tuning for two function implementations @ 2015-12-11 18:19 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-11 18:19 UTC (permalink / raw) To: LKML, Minchan Kim, Nitin Gupta, Sergey Senozhatsky Cc: kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 11 Dec 2015 19:12:34 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (2): zram: Less checks in zram_bvec_write() after error detection z2ram: Delete a jump label in z2_init() drivers/block/z2ram.c | 4 +--- drivers/block/zram/zram_drv.c | 26 +++++++++++++------------- 2 files changed, 14 insertions(+), 16 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 1/2] zram: Less checks in zram_bvec_write() after error detection 2015-12-11 18:19 ` SF Markus Elfring @ 2015-12-11 18:24 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-11 18:24 UTC (permalink / raw) To: LKML, Minchan Kim, Nitin Gupta, Sergey Senozhatsky Cc: kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 11 Dec 2015 18:20:59 +0100 This issue was detected by using the Coccinelle software. A few checks could be repeated by the zram_bvec_write() function at two places even if the passed variables contained a null pointer. * This implementation detail could be improved by adjustments for jump targets according to the Linux coding style convention. * Let us return directly if a memory allocation failed. * Drop unnecessary initialisations for the variables "uncmem" and "zstrm" then. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/block/zram/zram_drv.c | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c index 47915d7..69d7fcd 100644 --- a/drivers/block/zram/zram_drv.c +++ b/drivers/block/zram/zram_drv.c @@ -652,9 +652,9 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index, size_t clen; unsigned long handle; struct page *page; - unsigned char *user_mem, *cmem, *src, *uncmem = NULL; + unsigned char *user_mem, *cmem, *src, *uncmem; struct zram_meta *meta = zram->meta; - struct zcomp_strm *zstrm = NULL; + struct zcomp_strm *zstrm; unsigned long alloced_pages; page = bvec->bv_page; @@ -664,13 +664,11 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index, * before to write the changes. */ uncmem = kmalloc(PAGE_SIZE, GFP_NOIO); - if (!uncmem) { - ret = -ENOMEM; - goto out; - } + if (!uncmem) + return -ENOMEM; ret = zram_decompress_page(zram, uncmem, index); if (ret) - goto out; + goto free_uncmem; } zstrm = zcomp_strm_find(zram->comp); @@ -696,7 +694,7 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index, atomic64_inc(&zram->stats.zero_pages); ret = 0; - goto out; + goto check_strm; } ret = zcomp_compress(zram->comp, zstrm, uncmem, &clen); @@ -708,7 +706,7 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index, if (unlikely(ret)) { pr_err("Compression failed! err=%d\n", ret); - goto out; + goto check_strm; } src = zstrm->buffer; if (unlikely(clen > max_zpage_size)) { @@ -722,7 +720,7 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index, pr_err("Error allocating memory for compressed page: %u, size=%zu\n", index, clen); ret = -ENOMEM; - goto out; + goto check_strm; } alloced_pages = zs_get_total_pages(meta->mem_pool); @@ -731,7 +729,7 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index, if (zram->limit_pages && alloced_pages > zram->limit_pages) { zs_free(meta->mem_pool, handle); ret = -ENOMEM; - goto out; + goto check_strm; } cmem = zs_map_object(meta->mem_pool, handle, ZS_MM_WO); @@ -762,11 +760,13 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index, /* Update stats */ atomic64_add(clen, &zram->stats.compr_data_size); atomic64_inc(&zram->stats.pages_stored); -out: +check_strm: if (zstrm) zcomp_strm_release(zram->comp, zstrm); - if (is_partial_io(bvec)) + if (is_partial_io(bvec)) { +free_uncmem: kfree(uncmem); + } return ret; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 1/2] zram: Less checks in zram_bvec_write() after error detection @ 2015-12-11 18:24 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-11 18:24 UTC (permalink / raw) To: LKML, Minchan Kim, Nitin Gupta, Sergey Senozhatsky Cc: kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 11 Dec 2015 18:20:59 +0100 This issue was detected by using the Coccinelle software. A few checks could be repeated by the zram_bvec_write() function at two places even if the passed variables contained a null pointer. * This implementation detail could be improved by adjustments for jump targets according to the Linux coding style convention. * Let us return directly if a memory allocation failed. * Drop unnecessary initialisations for the variables "uncmem" and "zstrm" then. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/block/zram/zram_drv.c | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c index 47915d7..69d7fcd 100644 --- a/drivers/block/zram/zram_drv.c +++ b/drivers/block/zram/zram_drv.c @@ -652,9 +652,9 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index, size_t clen; unsigned long handle; struct page *page; - unsigned char *user_mem, *cmem, *src, *uncmem = NULL; + unsigned char *user_mem, *cmem, *src, *uncmem; struct zram_meta *meta = zram->meta; - struct zcomp_strm *zstrm = NULL; + struct zcomp_strm *zstrm; unsigned long alloced_pages; page = bvec->bv_page; @@ -664,13 +664,11 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index, * before to write the changes. */ uncmem = kmalloc(PAGE_SIZE, GFP_NOIO); - if (!uncmem) { - ret = -ENOMEM; - goto out; - } + if (!uncmem) + return -ENOMEM; ret = zram_decompress_page(zram, uncmem, index); if (ret) - goto out; + goto free_uncmem; } zstrm = zcomp_strm_find(zram->comp); @@ -696,7 +694,7 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index, atomic64_inc(&zram->stats.zero_pages); ret = 0; - goto out; + goto check_strm; } ret = zcomp_compress(zram->comp, zstrm, uncmem, &clen); @@ -708,7 +706,7 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index, if (unlikely(ret)) { pr_err("Compression failed! err=%d\n", ret); - goto out; + goto check_strm; } src = zstrm->buffer; if (unlikely(clen > max_zpage_size)) { @@ -722,7 +720,7 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index, pr_err("Error allocating memory for compressed page: %u, size=%zu\n", index, clen); ret = -ENOMEM; - goto out; + goto check_strm; } alloced_pages = zs_get_total_pages(meta->mem_pool); @@ -731,7 +729,7 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index, if (zram->limit_pages && alloced_pages > zram->limit_pages) { zs_free(meta->mem_pool, handle); ret = -ENOMEM; - goto out; + goto check_strm; } cmem = zs_map_object(meta->mem_pool, handle, ZS_MM_WO); @@ -762,11 +760,13 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index, /* Update stats */ atomic64_add(clen, &zram->stats.compr_data_size); atomic64_inc(&zram->stats.pages_stored); -out: +check_strm: if (zstrm) zcomp_strm_release(zram->comp, zstrm); - if (is_partial_io(bvec)) + if (is_partial_io(bvec)) { +free_uncmem: kfree(uncmem); + } return ret; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/2] zram: Less checks in zram_bvec_write() after error detection 2015-12-11 18:24 ` SF Markus Elfring @ 2015-12-14 0:27 ` Sergey Senozhatsky -1 siblings, 0 replies; 3089+ messages in thread From: Sergey Senozhatsky @ 2015-12-14 0:27 UTC (permalink / raw) To: SF Markus Elfring Cc: LKML, Minchan Kim, Nitin Gupta, Sergey Senozhatsky, kernel-janitors, Julia Lawall On (12/11/15 19:24), SF Markus Elfring wrote: [..] > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c > index 47915d7..69d7fcd 100644 > --- a/drivers/block/zram/zram_drv.c > +++ b/drivers/block/zram/zram_drv.c > @@ -652,9 +652,9 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index, > size_t clen; > unsigned long handle; > struct page *page; > - unsigned char *user_mem, *cmem, *src, *uncmem = NULL; > + unsigned char *user_mem, *cmem, *src, *uncmem; > struct zram_meta *meta = zram->meta; > - struct zcomp_strm *zstrm = NULL; > + struct zcomp_strm *zstrm; > unsigned long alloced_pages; > > page = bvec->bv_page; > @@ -664,13 +664,11 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index, > * before to write the changes. > */ > uncmem = kmalloc(PAGE_SIZE, GFP_NOIO); > - if (!uncmem) { > - ret = -ENOMEM; > - goto out; > - } > + if (!uncmem) > + return -ENOMEM; ok. > ret = zram_decompress_page(zram, uncmem, index); > if (ret) > - goto out; > + goto free_uncmem; here and later, I don't want to split `out' label. you still need to do both 'if zstrm' and 'if is_partial_io' checks anyway, what's the gain? the more labels we have the trickier it may get. > } > > zstrm = zcomp_strm_find(zram->comp); > @@ -696,7 +694,7 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index, > > atomic64_inc(&zram->stats.zero_pages); > ret = 0; > - goto out; > + goto check_strm; > } > > ret = zcomp_compress(zram->comp, zstrm, uncmem, &clen); > @@ -708,7 +706,7 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index, > > if (unlikely(ret)) { > pr_err("Compression failed! err=%d\n", ret); > - goto out; > + goto check_strm; > } > src = zstrm->buffer; > if (unlikely(clen > max_zpage_size)) { > @@ -722,7 +720,7 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index, > pr_err("Error allocating memory for compressed page: %u, size=%zu\n", > index, clen); > ret = -ENOMEM; > - goto out; > + goto check_strm; > } > > alloced_pages = zs_get_total_pages(meta->mem_pool); > @@ -731,7 +729,7 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index, > if (zram->limit_pages && alloced_pages > zram->limit_pages) { > zs_free(meta->mem_pool, handle); > ret = -ENOMEM; > - goto out; > + goto check_strm; > } > > cmem = zs_map_object(meta->mem_pool, handle, ZS_MM_WO); > @@ -762,11 +760,13 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index, > /* Update stats */ > atomic64_add(clen, &zram->stats.compr_data_size); > atomic64_inc(&zram->stats.pages_stored); > -out: > +check_strm: > if (zstrm) > zcomp_strm_release(zram->comp, zstrm); > - if (is_partial_io(bvec)) > + if (is_partial_io(bvec)) { > +free_uncmem: > kfree(uncmem); > + } a label inside of `if'? no. keep it the way it is please. > return ret; > } -ss ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/2] zram: Less checks in zram_bvec_write() after error detection @ 2015-12-14 0:27 ` Sergey Senozhatsky 0 siblings, 0 replies; 3089+ messages in thread From: Sergey Senozhatsky @ 2015-12-14 0:27 UTC (permalink / raw) To: SF Markus Elfring Cc: LKML, Minchan Kim, Nitin Gupta, Sergey Senozhatsky, kernel-janitors, Julia Lawall On (12/11/15 19:24), SF Markus Elfring wrote: [..] > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c > index 47915d7..69d7fcd 100644 > --- a/drivers/block/zram/zram_drv.c > +++ b/drivers/block/zram/zram_drv.c > @@ -652,9 +652,9 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index, > size_t clen; > unsigned long handle; > struct page *page; > - unsigned char *user_mem, *cmem, *src, *uncmem = NULL; > + unsigned char *user_mem, *cmem, *src, *uncmem; > struct zram_meta *meta = zram->meta; > - struct zcomp_strm *zstrm = NULL; > + struct zcomp_strm *zstrm; > unsigned long alloced_pages; > > page = bvec->bv_page; > @@ -664,13 +664,11 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index, > * before to write the changes. > */ > uncmem = kmalloc(PAGE_SIZE, GFP_NOIO); > - if (!uncmem) { > - ret = -ENOMEM; > - goto out; > - } > + if (!uncmem) > + return -ENOMEM; ok. > ret = zram_decompress_page(zram, uncmem, index); > if (ret) > - goto out; > + goto free_uncmem; here and later, I don't want to split `out' label. you still need to do both 'if zstrm' and 'if is_partial_io' checks anyway, what's the gain? the more labels we have the trickier it may get. > } > > zstrm = zcomp_strm_find(zram->comp); > @@ -696,7 +694,7 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index, > > atomic64_inc(&zram->stats.zero_pages); > ret = 0; > - goto out; > + goto check_strm; > } > > ret = zcomp_compress(zram->comp, zstrm, uncmem, &clen); > @@ -708,7 +706,7 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index, > > if (unlikely(ret)) { > pr_err("Compression failed! err=%d\n", ret); > - goto out; > + goto check_strm; > } > src = zstrm->buffer; > if (unlikely(clen > max_zpage_size)) { > @@ -722,7 +720,7 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index, > pr_err("Error allocating memory for compressed page: %u, size=%zu\n", > index, clen); > ret = -ENOMEM; > - goto out; > + goto check_strm; > } > > alloced_pages = zs_get_total_pages(meta->mem_pool); > @@ -731,7 +729,7 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index, > if (zram->limit_pages && alloced_pages > zram->limit_pages) { > zs_free(meta->mem_pool, handle); > ret = -ENOMEM; > - goto out; > + goto check_strm; > } > > cmem = zs_map_object(meta->mem_pool, handle, ZS_MM_WO); > @@ -762,11 +760,13 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index, > /* Update stats */ > atomic64_add(clen, &zram->stats.compr_data_size); > atomic64_inc(&zram->stats.pages_stored); > -out: > +check_strm: > if (zstrm) > zcomp_strm_release(zram->comp, zstrm); > - if (is_partial_io(bvec)) > + if (is_partial_io(bvec)) { > +free_uncmem: > kfree(uncmem); > + } a label inside of `if'? no. keep it the way it is please. > return ret; > } -ss ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/2] zram: Less checks in zram_bvec_write() after error detection 2015-12-14 0:27 ` Sergey Senozhatsky @ 2015-12-14 6:58 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-14 6:58 UTC (permalink / raw) To: Sergey Senozhatsky Cc: LKML, Minchan Kim, Nitin Gupta, kernel-janitors, Julia Lawall >> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c >> index 47915d7..69d7fcd 100644 >> --- a/drivers/block/zram/zram_drv.c >> +++ b/drivers/block/zram/zram_drv.c >> @@ -652,9 +652,9 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index, >> size_t clen; >> unsigned long handle; >> struct page *page; >> - unsigned char *user_mem, *cmem, *src, *uncmem = NULL; >> + unsigned char *user_mem, *cmem, *src, *uncmem; >> struct zram_meta *meta = zram->meta; >> - struct zcomp_strm *zstrm = NULL; >> + struct zcomp_strm *zstrm; >> unsigned long alloced_pages; >> >> page = bvec->bv_page; >> @@ -664,13 +664,11 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index, >> * before to write the changes. >> */ >> uncmem = kmalloc(PAGE_SIZE, GFP_NOIO); >> - if (!uncmem) { >> - ret = -ENOMEM; >> - goto out; >> - } >> + if (!uncmem) >> + return -ENOMEM; > > ok. Thanks for your terse acknowledgement. >> ret = zram_decompress_page(zram, uncmem, index); >> if (ret) >> - goto out; >> + goto free_uncmem; > > here and later, I don't want to split `out' label. I guess that corresponding software design concerns can evolve a bit. > you still need to do both 'if zstrm' and 'if is_partial_io' checks anyway, what's the gain? How are the chances to reduce the number of dispensable sanity checks? > the more labels we have the trickier it may get. I hope that more unique jump labels can make the involved exception handling also clearer. >> @@ -762,11 +760,13 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index, >> /* Update stats */ >> atomic64_add(clen, &zram->stats.compr_data_size); >> atomic64_inc(&zram->stats.pages_stored); >> -out: >> +check_strm: >> if (zstrm) >> zcomp_strm_release(zram->comp, zstrm); >> - if (is_partial_io(bvec)) >> + if (is_partial_io(bvec)) { >> +free_uncmem: >> kfree(uncmem); >> + } > > a label inside of `if'? no. Do any more software developers find such an use case interesting? > keep it the way it is please. I suggest to make the affected exception handling a bit more efficient. Such source code fine-tuning has got a few special consequences. Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/2] zram: Less checks in zram_bvec_write() after error detection @ 2015-12-14 6:58 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-14 6:58 UTC (permalink / raw) To: Sergey Senozhatsky Cc: LKML, Minchan Kim, Nitin Gupta, kernel-janitors, Julia Lawall >> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c >> index 47915d7..69d7fcd 100644 >> --- a/drivers/block/zram/zram_drv.c >> +++ b/drivers/block/zram/zram_drv.c >> @@ -652,9 +652,9 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index, >> size_t clen; >> unsigned long handle; >> struct page *page; >> - unsigned char *user_mem, *cmem, *src, *uncmem = NULL; >> + unsigned char *user_mem, *cmem, *src, *uncmem; >> struct zram_meta *meta = zram->meta; >> - struct zcomp_strm *zstrm = NULL; >> + struct zcomp_strm *zstrm; >> unsigned long alloced_pages; >> >> page = bvec->bv_page; >> @@ -664,13 +664,11 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index, >> * before to write the changes. >> */ >> uncmem = kmalloc(PAGE_SIZE, GFP_NOIO); >> - if (!uncmem) { >> - ret = -ENOMEM; >> - goto out; >> - } >> + if (!uncmem) >> + return -ENOMEM; > > ok. Thanks for your terse acknowledgement. >> ret = zram_decompress_page(zram, uncmem, index); >> if (ret) >> - goto out; >> + goto free_uncmem; > > here and later, I don't want to split `out' label. I guess that corresponding software design concerns can evolve a bit. > you still need to do both 'if zstrm' and 'if is_partial_io' checks anyway, what's the gain? How are the chances to reduce the number of dispensable sanity checks? > the more labels we have the trickier it may get. I hope that more unique jump labels can make the involved exception handling also clearer. >> @@ -762,11 +760,13 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index, >> /* Update stats */ >> atomic64_add(clen, &zram->stats.compr_data_size); >> atomic64_inc(&zram->stats.pages_stored); >> -out: >> +check_strm: >> if (zstrm) >> zcomp_strm_release(zram->comp, zstrm); >> - if (is_partial_io(bvec)) >> + if (is_partial_io(bvec)) { >> +free_uncmem: >> kfree(uncmem); >> + } > > a label inside of `if'? no. Do any more software developers find such an use case interesting? > keep it the way it is please. I suggest to make the affected exception handling a bit more efficient. Such source code fine-tuning has got a few special consequences. Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/2] zram: Less checks in zram_bvec_write() after error detection 2015-12-14 6:58 ` SF Markus Elfring @ 2015-12-14 7:17 ` Julia Lawall -1 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2015-12-14 7:17 UTC (permalink / raw) To: SF Markus Elfring Cc: Sergey Senozhatsky, LKML, Minchan Kim, Nitin Gupta, kernel-janitors > I suggest to make the affected exception handling a bit more efficient. > Such source code fine-tuning has got a few special consequences. Exception handling is by definition exceptional, and thus its efficiency is rarely important. What is important is that it should be correct, and ideally clearly correct, so that someone can check its correctness easily. Optimizations, if they have any effect at all, typically make the correctness less obvious. julia ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/2] zram: Less checks in zram_bvec_write() after error detection @ 2015-12-14 7:17 ` Julia Lawall 0 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2015-12-14 7:17 UTC (permalink / raw) To: SF Markus Elfring Cc: Sergey Senozhatsky, LKML, Minchan Kim, Nitin Gupta, kernel-janitors > I suggest to make the affected exception handling a bit more efficient. > Such source code fine-tuning has got a few special consequences. Exception handling is by definition exceptional, and thus its efficiency is rarely important. What is important is that it should be correct, and ideally clearly correct, so that someone can check its correctness easily. Optimizations, if they have any effect at all, typically make the correctness less obvious. julia ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/2] zram: Less checks in zram_bvec_write() after error detection 2015-12-14 6:58 ` SF Markus Elfring @ 2015-12-14 10:03 ` Sergey Senozhatsky -1 siblings, 0 replies; 3089+ messages in thread From: Sergey Senozhatsky @ 2015-12-14 10:03 UTC (permalink / raw) To: SF Markus Elfring Cc: Sergey Senozhatsky, LKML, Minchan Kim, Nitin Gupta, kernel-janitors, Julia Lawall, Andrew Morton On (12/14/15 07:58), SF Markus Elfring wrote: [..] > > keep it the way it is please. > > I suggest to make the affected exception handling a bit more efficient. > Such source code fine-tuning has got a few special consequences. by 'more efficient' you mean saving cpu cycles on 'bvec->bv_len != PAGE_SIZE' comparison in exception/error path? ... check_strm: if (zstrm) zcomp_strm_release(zram->comp, zstrm); if (is_partial_io(bvec)) { free_uncmem: kfree(uncmem); } ... no. -ss ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/2] zram: Less checks in zram_bvec_write() after error detection @ 2015-12-14 10:03 ` Sergey Senozhatsky 0 siblings, 0 replies; 3089+ messages in thread From: Sergey Senozhatsky @ 2015-12-14 10:03 UTC (permalink / raw) To: SF Markus Elfring Cc: Sergey Senozhatsky, LKML, Minchan Kim, Nitin Gupta, kernel-janitors, Julia Lawall, Andrew Morton On (12/14/15 07:58), SF Markus Elfring wrote: [..] > > keep it the way it is please. > > I suggest to make the affected exception handling a bit more efficient. > Such source code fine-tuning has got a few special consequences. by 'more efficient' you mean saving cpu cycles on 'bvec->bv_len != PAGE_SIZE' comparison in exception/error path? ... check_strm: if (zstrm) zcomp_strm_release(zram->comp, zstrm); if (is_partial_io(bvec)) { free_uncmem: kfree(uncmem); } ... no. -ss ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/2] zram: Less checks in zram_bvec_write() after error detection 2015-12-14 10:03 ` Sergey Senozhatsky @ 2015-12-14 14:03 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-14 14:03 UTC (permalink / raw) To: Sergey Senozhatsky Cc: LKML, Minchan Kim, Nitin Gupta, kernel-janitors, Julia Lawall, Andrew Morton >> I suggest to make the affected exception handling a bit more efficient. >> Such source code fine-tuning has got a few special consequences. > > by 'more efficient' you mean saving cpu cycles on 'bvec->bv_len != PAGE_SIZE' > comparison in exception/error path? Yes … > ... > check_strm: > if (zstrm) > zcomp_strm_release(zram->comp, zstrm); > if (is_partial_io(bvec)) { > free_uncmem: > kfree(uncmem); > } > ... I propose to jump over two sanity checks. > no. Thanks for your feedback. Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/2] zram: Less checks in zram_bvec_write() after error detection @ 2015-12-14 14:03 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-14 14:03 UTC (permalink / raw) To: Sergey Senozhatsky Cc: LKML, Minchan Kim, Nitin Gupta, kernel-janitors, Julia Lawall, Andrew Morton >> I suggest to make the affected exception handling a bit more efficient. >> Such source code fine-tuning has got a few special consequences. > > by 'more efficient' you mean saving cpu cycles on 'bvec->bv_len != PAGE_SIZE' > comparison in exception/error path? Yes … > ... > check_strm: > if (zstrm) > zcomp_strm_release(zram->comp, zstrm); > if (is_partial_io(bvec)) { > free_uncmem: > kfree(uncmem); > } > ... I propose to jump over two sanity checks. > no. Thanks for your feedback. Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 2/2] z2ram: Delete a jump label in z2_init() 2015-12-11 18:19 ` SF Markus Elfring @ 2015-12-11 18:26 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-11 18:26 UTC (permalink / raw) To: LKML, Minchan Kim, Nitin Gupta, Sergey Senozhatsky Cc: kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 11 Dec 2015 18:48:14 +0100 This issue was detected by using the Coccinelle software. * Let us return directly if a call of the function "register_blkdev" failed. * Remove the jump label "err" then. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/block/z2ram.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/block/z2ram.c b/drivers/block/z2ram.c index 968f9e5..b07581d 100644 --- a/drivers/block/z2ram.c +++ b/drivers/block/z2ram.c @@ -345,9 +345,8 @@ z2_init(void) if (!MACH_IS_AMIGA) return -ENODEV; - ret = -EBUSY; if (register_blkdev(Z2RAM_MAJOR, DEVICE_NAME)) - goto err; + return -EBUSY; ret = -ENOMEM; z2ram_gendisk = alloc_disk(1); @@ -374,7 +373,6 @@ out_queue: put_disk(z2ram_gendisk); out_disk: unregister_blkdev(Z2RAM_MAJOR, DEVICE_NAME); -err: return ret; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 2/2] z2ram: Delete a jump label in z2_init() @ 2015-12-11 18:26 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-11 18:26 UTC (permalink / raw) To: LKML, Minchan Kim, Nitin Gupta, Sergey Senozhatsky Cc: kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 11 Dec 2015 18:48:14 +0100 This issue was detected by using the Coccinelle software. * Let us return directly if a call of the function "register_blkdev" failed. * Remove the jump label "err" then. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/block/z2ram.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/block/z2ram.c b/drivers/block/z2ram.c index 968f9e5..b07581d 100644 --- a/drivers/block/z2ram.c +++ b/drivers/block/z2ram.c @@ -345,9 +345,8 @@ z2_init(void) if (!MACH_IS_AMIGA) return -ENODEV; - ret = -EBUSY; if (register_blkdev(Z2RAM_MAJOR, DEVICE_NAME)) - goto err; + return -EBUSY; ret = -ENOMEM; z2ram_gendisk = alloc_disk(1); @@ -374,7 +373,6 @@ out_queue: put_disk(z2ram_gendisk); out_disk: unregister_blkdev(Z2RAM_MAJOR, DEVICE_NAME); -err: return ret; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] z2ram: Delete a jump label in z2_init() 2015-12-11 18:26 ` SF Markus Elfring @ 2015-12-14 0:36 ` Sergey Senozhatsky -1 siblings, 0 replies; 3089+ messages in thread From: Sergey Senozhatsky @ 2015-12-14 0:36 UTC (permalink / raw) To: SF Markus Elfring Cc: LKML, Minchan Kim, Nitin Gupta, Sergey Senozhatsky, kernel-janitors, Julia Lawall, Andrew Morton, Jens Axboe, Geert Uytterhoeven Cc Jens, Andrew, Geert On (12/11/15 19:26), SF Markus Elfring wrote: > > This issue was detected by using the Coccinelle software. > > * Let us return directly if a call of the function "register_blkdev" failed. > > * Remove the jump label "err" then. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/block/z2ram.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/block/z2ram.c b/drivers/block/z2ram.c > index 968f9e5..b07581d 100644 > --- a/drivers/block/z2ram.c > +++ b/drivers/block/z2ram.c > @@ -345,9 +345,8 @@ z2_init(void) > if (!MACH_IS_AMIGA) > return -ENODEV; > > - ret = -EBUSY; > if (register_blkdev(Z2RAM_MAJOR, DEVICE_NAME)) > - goto err; > + return -EBUSY; > > ret = -ENOMEM; > z2ram_gendisk = alloc_disk(1); > @@ -374,7 +373,6 @@ out_queue: > put_disk(z2ram_gendisk); > out_disk: > unregister_blkdev(Z2RAM_MAJOR, DEVICE_NAME); > -err: > return ret; > } z2ram and zram are different drivers, but the change looks ok to me. z2ram can be improved in many ways, so my question is - do people still use it? -ss ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] z2ram: Delete a jump label in z2_init() @ 2015-12-14 0:36 ` Sergey Senozhatsky 0 siblings, 0 replies; 3089+ messages in thread From: Sergey Senozhatsky @ 2015-12-14 0:36 UTC (permalink / raw) To: SF Markus Elfring Cc: LKML, Minchan Kim, Nitin Gupta, Sergey Senozhatsky, kernel-janitors, Julia Lawall, Andrew Morton, Jens Axboe, Geert Uytterhoeven Cc Jens, Andrew, Geert On (12/11/15 19:26), SF Markus Elfring wrote: > > This issue was detected by using the Coccinelle software. > > * Let us return directly if a call of the function "register_blkdev" failed. > > * Remove the jump label "err" then. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/block/z2ram.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/block/z2ram.c b/drivers/block/z2ram.c > index 968f9e5..b07581d 100644 > --- a/drivers/block/z2ram.c > +++ b/drivers/block/z2ram.c > @@ -345,9 +345,8 @@ z2_init(void) > if (!MACH_IS_AMIGA) > return -ENODEV; > > - ret = -EBUSY; > if (register_blkdev(Z2RAM_MAJOR, DEVICE_NAME)) > - goto err; > + return -EBUSY; > > ret = -ENOMEM; > z2ram_gendisk = alloc_disk(1); > @@ -374,7 +373,6 @@ out_queue: > put_disk(z2ram_gendisk); > out_disk: > unregister_blkdev(Z2RAM_MAJOR, DEVICE_NAME); > -err: > return ret; > } z2ram and zram are different drivers, but the change looks ok to me. z2ram can be improved in many ways, so my question is - do people still use it? -ss ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] z2ram: Delete a jump label in z2_init() 2015-12-14 0:36 ` Sergey Senozhatsky @ 2015-12-14 9:10 ` Geert Uytterhoeven -1 siblings, 0 replies; 3089+ messages in thread From: Geert Uytterhoeven @ 2015-12-14 9:10 UTC (permalink / raw) To: Sergey Senozhatsky Cc: SF Markus Elfring, LKML, Minchan Kim, Nitin Gupta, kernel-janitors, Julia Lawall, Andrew Morton, Jens Axboe, Linux/m68k On Mon, Dec 14, 2015 at 1:36 AM, Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> wrote: > Cc Jens, Andrew, Geert > > On (12/11/15 19:26), SF Markus Elfring wrote: >> >> This issue was detected by using the Coccinelle software. >> >> * Let us return directly if a call of the function "register_blkdev" failed. >> >> * Remove the jump label "err" then. >> >> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> >> --- >> drivers/block/z2ram.c | 4 +--- >> 1 file changed, 1 insertion(+), 3 deletions(-) >> >> diff --git a/drivers/block/z2ram.c b/drivers/block/z2ram.c >> index 968f9e5..b07581d 100644 >> --- a/drivers/block/z2ram.c >> +++ b/drivers/block/z2ram.c >> @@ -345,9 +345,8 @@ z2_init(void) >> if (!MACH_IS_AMIGA) >> return -ENODEV; >> >> - ret = -EBUSY; >> if (register_blkdev(Z2RAM_MAJOR, DEVICE_NAME)) >> - goto err; >> + return -EBUSY; >> >> ret = -ENOMEM; >> z2ram_gendisk = alloc_disk(1); >> @@ -374,7 +373,6 @@ out_queue: >> put_disk(z2ram_gendisk); >> out_disk: >> unregister_blkdev(Z2RAM_MAJOR, DEVICE_NAME); >> -err: >> return ret; >> } > > z2ram and zram are different drivers, but the change looks > ok to me. > > z2ram can be improved in many ways, so my question is - do > people still use it? I think it's still used. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] z2ram: Delete a jump label in z2_init() @ 2015-12-14 9:10 ` Geert Uytterhoeven 0 siblings, 0 replies; 3089+ messages in thread From: Geert Uytterhoeven @ 2015-12-14 9:10 UTC (permalink / raw) To: Sergey Senozhatsky Cc: SF Markus Elfring, LKML, Minchan Kim, Nitin Gupta, kernel-janitors, Julia Lawall, Andrew Morton, Jens Axboe, Linux/m68k On Mon, Dec 14, 2015 at 1:36 AM, Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> wrote: > Cc Jens, Andrew, Geert > > On (12/11/15 19:26), SF Markus Elfring wrote: >> >> This issue was detected by using the Coccinelle software. >> >> * Let us return directly if a call of the function "register_blkdev" failed. >> >> * Remove the jump label "err" then. >> >> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> >> --- >> drivers/block/z2ram.c | 4 +--- >> 1 file changed, 1 insertion(+), 3 deletions(-) >> >> diff --git a/drivers/block/z2ram.c b/drivers/block/z2ram.c >> index 968f9e5..b07581d 100644 >> --- a/drivers/block/z2ram.c >> +++ b/drivers/block/z2ram.c >> @@ -345,9 +345,8 @@ z2_init(void) >> if (!MACH_IS_AMIGA) >> return -ENODEV; >> >> - ret = -EBUSY; >> if (register_blkdev(Z2RAM_MAJOR, DEVICE_NAME)) >> - goto err; >> + return -EBUSY; >> >> ret = -ENOMEM; >> z2ram_gendisk = alloc_disk(1); >> @@ -374,7 +373,6 @@ out_queue: >> put_disk(z2ram_gendisk); >> out_disk: >> unregister_blkdev(Z2RAM_MAJOR, DEVICE_NAME); >> -err: >> return ret; >> } > > z2ram and zram are different drivers, but the change looks > ok to me. > > z2ram can be improved in many ways, so my question is - do > people still use it? I think it's still used. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH] uinput: Rename a jump label in uinput_ioctl_handler() 2015-12-11 12:08 ` SF Markus Elfring @ 2015-12-12 9:16 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-12 9:16 UTC (permalink / raw) To: LKML, linux-input, Dmitry Torokhov; +Cc: kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 12 Dec 2015 10:06:00 +0100 This issue was detected by using the Coccinelle software. Choose a jump label according to the current Linux coding style convention. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/input/misc/uinput.c | 66 ++++++++++++++++++++++----------------------- 1 file changed, 33 insertions(+), 33 deletions(-) diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c index 5adbced..466f62d 100644 --- a/drivers/input/misc/uinput.c +++ b/drivers/input/misc/uinput.c @@ -717,7 +717,7 @@ static long uinput_ioctl_handler(struct file *file, unsigned int cmd, if (!udev->dev) { retval = uinput_allocate_device(udev); if (retval) - goto out; + goto unlock; } switch (cmd) { @@ -725,82 +725,82 @@ static long uinput_ioctl_handler(struct file *file, unsigned int cmd, if (put_user(UINPUT_VERSION, (unsigned int __user *)p)) retval = -EFAULT; - goto out; + goto unlock; case UI_DEV_CREATE: retval = uinput_create_device(udev); - goto out; + goto unlock; case UI_DEV_DESTROY: uinput_destroy_device(udev); - goto out; + goto unlock; case UI_SET_EVBIT: retval = uinput_set_bit(arg, evbit, EV_MAX); - goto out; + goto unlock; case UI_SET_KEYBIT: retval = uinput_set_bit(arg, keybit, KEY_MAX); - goto out; + goto unlock; case UI_SET_RELBIT: retval = uinput_set_bit(arg, relbit, REL_MAX); - goto out; + goto unlock; case UI_SET_ABSBIT: retval = uinput_set_bit(arg, absbit, ABS_MAX); - goto out; + goto unlock; case UI_SET_MSCBIT: retval = uinput_set_bit(arg, mscbit, MSC_MAX); - goto out; + goto unlock; case UI_SET_LEDBIT: retval = uinput_set_bit(arg, ledbit, LED_MAX); - goto out; + goto unlock; case UI_SET_SNDBIT: retval = uinput_set_bit(arg, sndbit, SND_MAX); - goto out; + goto unlock; case UI_SET_FFBIT: retval = uinput_set_bit(arg, ffbit, FF_MAX); - goto out; + goto unlock; case UI_SET_SWBIT: retval = uinput_set_bit(arg, swbit, SW_MAX); - goto out; + goto unlock; case UI_SET_PROPBIT: retval = uinput_set_bit(arg, propbit, INPUT_PROP_MAX); - goto out; + goto unlock; case UI_SET_PHYS: if (udev->state == UIST_CREATED) { retval = -EINVAL; - goto out; + goto unlock; } phys = strndup_user(p, 1024); if (IS_ERR(phys)) { retval = PTR_ERR(phys); - goto out; + goto unlock; } kfree(udev->dev->phys); udev->dev->phys = phys; - goto out; + goto unlock; case UI_BEGIN_FF_UPLOAD: retval = uinput_ff_upload_from_user(p, &ff_up); if (retval) - goto out; + goto unlock; req = uinput_request_find(udev, ff_up.request_id); if (!req || req->code != UI_FF_UPLOAD || !req->u.upload.effect) { retval = -EINVAL; - goto out; + goto unlock; } ff_up.retval = 0; @@ -811,60 +811,60 @@ static long uinput_ioctl_handler(struct file *file, unsigned int cmd, memset(&ff_up.old, 0, sizeof(struct ff_effect)); retval = uinput_ff_upload_to_user(p, &ff_up); - goto out; + goto unlock; case UI_BEGIN_FF_ERASE: if (copy_from_user(&ff_erase, p, sizeof(ff_erase))) { retval = -EFAULT; - goto out; + goto unlock; } req = uinput_request_find(udev, ff_erase.request_id); if (!req || req->code != UI_FF_ERASE) { retval = -EINVAL; - goto out; + goto unlock; } ff_erase.retval = 0; ff_erase.effect_id = req->u.effect_id; if (copy_to_user(p, &ff_erase, sizeof(ff_erase))) { retval = -EFAULT; - goto out; + goto unlock; } - goto out; + goto unlock; case UI_END_FF_UPLOAD: retval = uinput_ff_upload_from_user(p, &ff_up); if (retval) - goto out; + goto unlock; req = uinput_request_find(udev, ff_up.request_id); if (!req || req->code != UI_FF_UPLOAD || !req->u.upload.effect) { retval = -EINVAL; - goto out; + goto unlock; } req->retval = ff_up.retval; uinput_request_done(udev, req); - goto out; + goto unlock; case UI_END_FF_ERASE: if (copy_from_user(&ff_erase, p, sizeof(ff_erase))) { retval = -EFAULT; - goto out; + goto unlock; } req = uinput_request_find(udev, ff_erase.request_id); if (!req || req->code != UI_FF_ERASE) { retval = -EINVAL; - goto out; + goto unlock; } req->retval = ff_erase.retval; uinput_request_done(udev, req); - goto out; + goto unlock; } size = _IOC_SIZE(cmd); @@ -874,15 +874,15 @@ static long uinput_ioctl_handler(struct file *file, unsigned int cmd, case UI_GET_SYSNAME(0): if (udev->state != UIST_CREATED) { retval = -ENOENT; - goto out; + goto unlock; } name = dev_name(&udev->dev->dev); retval = uinput_str_to_user(p, name, size); - goto out; + goto unlock; } retval = -EINVAL; - out: + unlock: mutex_unlock(&udev->mutex); return retval; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH] uinput: Rename a jump label in uinput_ioctl_handler() @ 2015-12-12 9:16 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-12 9:16 UTC (permalink / raw) To: LKML, linux-input, Dmitry Torokhov; +Cc: kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 12 Dec 2015 10:06:00 +0100 This issue was detected by using the Coccinelle software. Choose a jump label according to the current Linux coding style convention. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/input/misc/uinput.c | 66 ++++++++++++++++++++++----------------------- 1 file changed, 33 insertions(+), 33 deletions(-) diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c index 5adbced..466f62d 100644 --- a/drivers/input/misc/uinput.c +++ b/drivers/input/misc/uinput.c @@ -717,7 +717,7 @@ static long uinput_ioctl_handler(struct file *file, unsigned int cmd, if (!udev->dev) { retval = uinput_allocate_device(udev); if (retval) - goto out; + goto unlock; } switch (cmd) { @@ -725,82 +725,82 @@ static long uinput_ioctl_handler(struct file *file, unsigned int cmd, if (put_user(UINPUT_VERSION, (unsigned int __user *)p)) retval = -EFAULT; - goto out; + goto unlock; case UI_DEV_CREATE: retval = uinput_create_device(udev); - goto out; + goto unlock; case UI_DEV_DESTROY: uinput_destroy_device(udev); - goto out; + goto unlock; case UI_SET_EVBIT: retval = uinput_set_bit(arg, evbit, EV_MAX); - goto out; + goto unlock; case UI_SET_KEYBIT: retval = uinput_set_bit(arg, keybit, KEY_MAX); - goto out; + goto unlock; case UI_SET_RELBIT: retval = uinput_set_bit(arg, relbit, REL_MAX); - goto out; + goto unlock; case UI_SET_ABSBIT: retval = uinput_set_bit(arg, absbit, ABS_MAX); - goto out; + goto unlock; case UI_SET_MSCBIT: retval = uinput_set_bit(arg, mscbit, MSC_MAX); - goto out; + goto unlock; case UI_SET_LEDBIT: retval = uinput_set_bit(arg, ledbit, LED_MAX); - goto out; + goto unlock; case UI_SET_SNDBIT: retval = uinput_set_bit(arg, sndbit, SND_MAX); - goto out; + goto unlock; case UI_SET_FFBIT: retval = uinput_set_bit(arg, ffbit, FF_MAX); - goto out; + goto unlock; case UI_SET_SWBIT: retval = uinput_set_bit(arg, swbit, SW_MAX); - goto out; + goto unlock; case UI_SET_PROPBIT: retval = uinput_set_bit(arg, propbit, INPUT_PROP_MAX); - goto out; + goto unlock; case UI_SET_PHYS: if (udev->state = UIST_CREATED) { retval = -EINVAL; - goto out; + goto unlock; } phys = strndup_user(p, 1024); if (IS_ERR(phys)) { retval = PTR_ERR(phys); - goto out; + goto unlock; } kfree(udev->dev->phys); udev->dev->phys = phys; - goto out; + goto unlock; case UI_BEGIN_FF_UPLOAD: retval = uinput_ff_upload_from_user(p, &ff_up); if (retval) - goto out; + goto unlock; req = uinput_request_find(udev, ff_up.request_id); if (!req || req->code != UI_FF_UPLOAD || !req->u.upload.effect) { retval = -EINVAL; - goto out; + goto unlock; } ff_up.retval = 0; @@ -811,60 +811,60 @@ static long uinput_ioctl_handler(struct file *file, unsigned int cmd, memset(&ff_up.old, 0, sizeof(struct ff_effect)); retval = uinput_ff_upload_to_user(p, &ff_up); - goto out; + goto unlock; case UI_BEGIN_FF_ERASE: if (copy_from_user(&ff_erase, p, sizeof(ff_erase))) { retval = -EFAULT; - goto out; + goto unlock; } req = uinput_request_find(udev, ff_erase.request_id); if (!req || req->code != UI_FF_ERASE) { retval = -EINVAL; - goto out; + goto unlock; } ff_erase.retval = 0; ff_erase.effect_id = req->u.effect_id; if (copy_to_user(p, &ff_erase, sizeof(ff_erase))) { retval = -EFAULT; - goto out; + goto unlock; } - goto out; + goto unlock; case UI_END_FF_UPLOAD: retval = uinput_ff_upload_from_user(p, &ff_up); if (retval) - goto out; + goto unlock; req = uinput_request_find(udev, ff_up.request_id); if (!req || req->code != UI_FF_UPLOAD || !req->u.upload.effect) { retval = -EINVAL; - goto out; + goto unlock; } req->retval = ff_up.retval; uinput_request_done(udev, req); - goto out; + goto unlock; case UI_END_FF_ERASE: if (copy_from_user(&ff_erase, p, sizeof(ff_erase))) { retval = -EFAULT; - goto out; + goto unlock; } req = uinput_request_find(udev, ff_erase.request_id); if (!req || req->code != UI_FF_ERASE) { retval = -EINVAL; - goto out; + goto unlock; } req->retval = ff_erase.retval; uinput_request_done(udev, req); - goto out; + goto unlock; } size = _IOC_SIZE(cmd); @@ -874,15 +874,15 @@ static long uinput_ioctl_handler(struct file *file, unsigned int cmd, case UI_GET_SYSNAME(0): if (udev->state != UIST_CREATED) { retval = -ENOENT; - goto out; + goto unlock; } name = dev_name(&udev->dev->dev); retval = uinput_str_to_user(p, name, size); - goto out; + goto unlock; } retval = -EINVAL; - out: + unlock: mutex_unlock(&udev->mutex); return retval; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH] uinput: Rename a jump label in uinput_ioctl_handler() 2015-12-12 9:16 ` SF Markus Elfring @ 2015-12-12 22:23 ` Dmitry Torokhov -1 siblings, 0 replies; 3089+ messages in thread From: Dmitry Torokhov @ 2015-12-12 22:23 UTC (permalink / raw) To: SF Markus Elfring; +Cc: LKML, linux-input, kernel-janitors, Julia Lawall Hi Markus, On Sat, Dec 12, 2015 at 10:16:34AM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sat, 12 Dec 2015 10:06:00 +0100 > > This issue was detected by using the Coccinelle software. > > Choose a jump label according to the current Linux coding style convention. While I am mildly curious where you found this Coccinelle script complaining about label names I find the current name is perfectly fine. Thanks. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/input/misc/uinput.c | 66 ++++++++++++++++++++++----------------------- > 1 file changed, 33 insertions(+), 33 deletions(-) > > diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c > index 5adbced..466f62d 100644 > --- a/drivers/input/misc/uinput.c > +++ b/drivers/input/misc/uinput.c > @@ -717,7 +717,7 @@ static long uinput_ioctl_handler(struct file *file, unsigned int cmd, > if (!udev->dev) { > retval = uinput_allocate_device(udev); > if (retval) > - goto out; > + goto unlock; > } > > switch (cmd) { > @@ -725,82 +725,82 @@ static long uinput_ioctl_handler(struct file *file, unsigned int cmd, > if (put_user(UINPUT_VERSION, > (unsigned int __user *)p)) > retval = -EFAULT; > - goto out; > + goto unlock; > > case UI_DEV_CREATE: > retval = uinput_create_device(udev); > - goto out; > + goto unlock; > > case UI_DEV_DESTROY: > uinput_destroy_device(udev); > - goto out; > + goto unlock; > > case UI_SET_EVBIT: > retval = uinput_set_bit(arg, evbit, EV_MAX); > - goto out; > + goto unlock; > > case UI_SET_KEYBIT: > retval = uinput_set_bit(arg, keybit, KEY_MAX); > - goto out; > + goto unlock; > > case UI_SET_RELBIT: > retval = uinput_set_bit(arg, relbit, REL_MAX); > - goto out; > + goto unlock; > > case UI_SET_ABSBIT: > retval = uinput_set_bit(arg, absbit, ABS_MAX); > - goto out; > + goto unlock; > > case UI_SET_MSCBIT: > retval = uinput_set_bit(arg, mscbit, MSC_MAX); > - goto out; > + goto unlock; > > case UI_SET_LEDBIT: > retval = uinput_set_bit(arg, ledbit, LED_MAX); > - goto out; > + goto unlock; > > case UI_SET_SNDBIT: > retval = uinput_set_bit(arg, sndbit, SND_MAX); > - goto out; > + goto unlock; > > case UI_SET_FFBIT: > retval = uinput_set_bit(arg, ffbit, FF_MAX); > - goto out; > + goto unlock; > > case UI_SET_SWBIT: > retval = uinput_set_bit(arg, swbit, SW_MAX); > - goto out; > + goto unlock; > > case UI_SET_PROPBIT: > retval = uinput_set_bit(arg, propbit, INPUT_PROP_MAX); > - goto out; > + goto unlock; > > case UI_SET_PHYS: > if (udev->state == UIST_CREATED) { > retval = -EINVAL; > - goto out; > + goto unlock; > } > > phys = strndup_user(p, 1024); > if (IS_ERR(phys)) { > retval = PTR_ERR(phys); > - goto out; > + goto unlock; > } > > kfree(udev->dev->phys); > udev->dev->phys = phys; > - goto out; > + goto unlock; > > case UI_BEGIN_FF_UPLOAD: > retval = uinput_ff_upload_from_user(p, &ff_up); > if (retval) > - goto out; > + goto unlock; > > req = uinput_request_find(udev, ff_up.request_id); > if (!req || req->code != UI_FF_UPLOAD || > !req->u.upload.effect) { > retval = -EINVAL; > - goto out; > + goto unlock; > } > > ff_up.retval = 0; > @@ -811,60 +811,60 @@ static long uinput_ioctl_handler(struct file *file, unsigned int cmd, > memset(&ff_up.old, 0, sizeof(struct ff_effect)); > > retval = uinput_ff_upload_to_user(p, &ff_up); > - goto out; > + goto unlock; > > case UI_BEGIN_FF_ERASE: > if (copy_from_user(&ff_erase, p, sizeof(ff_erase))) { > retval = -EFAULT; > - goto out; > + goto unlock; > } > > req = uinput_request_find(udev, ff_erase.request_id); > if (!req || req->code != UI_FF_ERASE) { > retval = -EINVAL; > - goto out; > + goto unlock; > } > > ff_erase.retval = 0; > ff_erase.effect_id = req->u.effect_id; > if (copy_to_user(p, &ff_erase, sizeof(ff_erase))) { > retval = -EFAULT; > - goto out; > + goto unlock; > } > > - goto out; > + goto unlock; > > case UI_END_FF_UPLOAD: > retval = uinput_ff_upload_from_user(p, &ff_up); > if (retval) > - goto out; > + goto unlock; > > req = uinput_request_find(udev, ff_up.request_id); > if (!req || req->code != UI_FF_UPLOAD || > !req->u.upload.effect) { > retval = -EINVAL; > - goto out; > + goto unlock; > } > > req->retval = ff_up.retval; > uinput_request_done(udev, req); > - goto out; > + goto unlock; > > case UI_END_FF_ERASE: > if (copy_from_user(&ff_erase, p, sizeof(ff_erase))) { > retval = -EFAULT; > - goto out; > + goto unlock; > } > > req = uinput_request_find(udev, ff_erase.request_id); > if (!req || req->code != UI_FF_ERASE) { > retval = -EINVAL; > - goto out; > + goto unlock; > } > > req->retval = ff_erase.retval; > uinput_request_done(udev, req); > - goto out; > + goto unlock; > } > > size = _IOC_SIZE(cmd); > @@ -874,15 +874,15 @@ static long uinput_ioctl_handler(struct file *file, unsigned int cmd, > case UI_GET_SYSNAME(0): > if (udev->state != UIST_CREATED) { > retval = -ENOENT; > - goto out; > + goto unlock; > } > name = dev_name(&udev->dev->dev); > retval = uinput_str_to_user(p, name, size); > - goto out; > + goto unlock; > } > > retval = -EINVAL; > - out: > + unlock: > mutex_unlock(&udev->mutex); > return retval; > } > -- > 2.6.3 > -- Dmitry ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] uinput: Rename a jump label in uinput_ioctl_handler() @ 2015-12-12 22:23 ` Dmitry Torokhov 0 siblings, 0 replies; 3089+ messages in thread From: Dmitry Torokhov @ 2015-12-12 22:23 UTC (permalink / raw) To: SF Markus Elfring; +Cc: LKML, linux-input, kernel-janitors, Julia Lawall Hi Markus, On Sat, Dec 12, 2015 at 10:16:34AM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sat, 12 Dec 2015 10:06:00 +0100 > > This issue was detected by using the Coccinelle software. > > Choose a jump label according to the current Linux coding style convention. While I am mildly curious where you found this Coccinelle script complaining about label names I find the current name is perfectly fine. Thanks. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/input/misc/uinput.c | 66 ++++++++++++++++++++++----------------------- > 1 file changed, 33 insertions(+), 33 deletions(-) > > diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c > index 5adbced..466f62d 100644 > --- a/drivers/input/misc/uinput.c > +++ b/drivers/input/misc/uinput.c > @@ -717,7 +717,7 @@ static long uinput_ioctl_handler(struct file *file, unsigned int cmd, > if (!udev->dev) { > retval = uinput_allocate_device(udev); > if (retval) > - goto out; > + goto unlock; > } > > switch (cmd) { > @@ -725,82 +725,82 @@ static long uinput_ioctl_handler(struct file *file, unsigned int cmd, > if (put_user(UINPUT_VERSION, > (unsigned int __user *)p)) > retval = -EFAULT; > - goto out; > + goto unlock; > > case UI_DEV_CREATE: > retval = uinput_create_device(udev); > - goto out; > + goto unlock; > > case UI_DEV_DESTROY: > uinput_destroy_device(udev); > - goto out; > + goto unlock; > > case UI_SET_EVBIT: > retval = uinput_set_bit(arg, evbit, EV_MAX); > - goto out; > + goto unlock; > > case UI_SET_KEYBIT: > retval = uinput_set_bit(arg, keybit, KEY_MAX); > - goto out; > + goto unlock; > > case UI_SET_RELBIT: > retval = uinput_set_bit(arg, relbit, REL_MAX); > - goto out; > + goto unlock; > > case UI_SET_ABSBIT: > retval = uinput_set_bit(arg, absbit, ABS_MAX); > - goto out; > + goto unlock; > > case UI_SET_MSCBIT: > retval = uinput_set_bit(arg, mscbit, MSC_MAX); > - goto out; > + goto unlock; > > case UI_SET_LEDBIT: > retval = uinput_set_bit(arg, ledbit, LED_MAX); > - goto out; > + goto unlock; > > case UI_SET_SNDBIT: > retval = uinput_set_bit(arg, sndbit, SND_MAX); > - goto out; > + goto unlock; > > case UI_SET_FFBIT: > retval = uinput_set_bit(arg, ffbit, FF_MAX); > - goto out; > + goto unlock; > > case UI_SET_SWBIT: > retval = uinput_set_bit(arg, swbit, SW_MAX); > - goto out; > + goto unlock; > > case UI_SET_PROPBIT: > retval = uinput_set_bit(arg, propbit, INPUT_PROP_MAX); > - goto out; > + goto unlock; > > case UI_SET_PHYS: > if (udev->state = UIST_CREATED) { > retval = -EINVAL; > - goto out; > + goto unlock; > } > > phys = strndup_user(p, 1024); > if (IS_ERR(phys)) { > retval = PTR_ERR(phys); > - goto out; > + goto unlock; > } > > kfree(udev->dev->phys); > udev->dev->phys = phys; > - goto out; > + goto unlock; > > case UI_BEGIN_FF_UPLOAD: > retval = uinput_ff_upload_from_user(p, &ff_up); > if (retval) > - goto out; > + goto unlock; > > req = uinput_request_find(udev, ff_up.request_id); > if (!req || req->code != UI_FF_UPLOAD || > !req->u.upload.effect) { > retval = -EINVAL; > - goto out; > + goto unlock; > } > > ff_up.retval = 0; > @@ -811,60 +811,60 @@ static long uinput_ioctl_handler(struct file *file, unsigned int cmd, > memset(&ff_up.old, 0, sizeof(struct ff_effect)); > > retval = uinput_ff_upload_to_user(p, &ff_up); > - goto out; > + goto unlock; > > case UI_BEGIN_FF_ERASE: > if (copy_from_user(&ff_erase, p, sizeof(ff_erase))) { > retval = -EFAULT; > - goto out; > + goto unlock; > } > > req = uinput_request_find(udev, ff_erase.request_id); > if (!req || req->code != UI_FF_ERASE) { > retval = -EINVAL; > - goto out; > + goto unlock; > } > > ff_erase.retval = 0; > ff_erase.effect_id = req->u.effect_id; > if (copy_to_user(p, &ff_erase, sizeof(ff_erase))) { > retval = -EFAULT; > - goto out; > + goto unlock; > } > > - goto out; > + goto unlock; > > case UI_END_FF_UPLOAD: > retval = uinput_ff_upload_from_user(p, &ff_up); > if (retval) > - goto out; > + goto unlock; > > req = uinput_request_find(udev, ff_up.request_id); > if (!req || req->code != UI_FF_UPLOAD || > !req->u.upload.effect) { > retval = -EINVAL; > - goto out; > + goto unlock; > } > > req->retval = ff_up.retval; > uinput_request_done(udev, req); > - goto out; > + goto unlock; > > case UI_END_FF_ERASE: > if (copy_from_user(&ff_erase, p, sizeof(ff_erase))) { > retval = -EFAULT; > - goto out; > + goto unlock; > } > > req = uinput_request_find(udev, ff_erase.request_id); > if (!req || req->code != UI_FF_ERASE) { > retval = -EINVAL; > - goto out; > + goto unlock; > } > > req->retval = ff_erase.retval; > uinput_request_done(udev, req); > - goto out; > + goto unlock; > } > > size = _IOC_SIZE(cmd); > @@ -874,15 +874,15 @@ static long uinput_ioctl_handler(struct file *file, unsigned int cmd, > case UI_GET_SYSNAME(0): > if (udev->state != UIST_CREATED) { > retval = -ENOENT; > - goto out; > + goto unlock; > } > name = dev_name(&udev->dev->dev); > retval = uinput_str_to_user(p, name, size); > - goto out; > + goto unlock; > } > > retval = -EINVAL; > - out: > + unlock: > mutex_unlock(&udev->mutex); > return retval; > } > -- > 2.6.3 > -- Dmitry ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/7] iSCSI-target: Fine-tuning for three function implementations 2015-12-11 12:08 ` SF Markus Elfring @ 2015-12-12 14:30 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-12 14:30 UTC (permalink / raw) To: linux-scsi, target-devel, Nicholas A. Bellinger Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 12 Dec 2015 15:25:20 +0100 Some update suggestions were taken into account from static source code analysis. Markus Elfring (7): Use a variable initialisation in iscsi_set_default_param() directly Less checks in iscsi_set_default_param() after error detection Delete an unnecessary variable initialisation in iscsi_create_default_params() Make a variable initialisation a bit more obvious in iscsi_create_default_params() Rename a jump label in iscsi_create_default_params() Delete unnecessary variable initialisations in iscsi_check_valuelist_for_support() Make two variable initialisations a bit more obvious in iscsi_check_valuelist_for_support() drivers/target/iscsi/iscsi_target_parameters.c | 100 ++++++++++++------------- 1 file changed, 47 insertions(+), 53 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/7] iSCSI-target: Fine-tuning for three function implementations @ 2015-12-12 14:30 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-12 14:30 UTC (permalink / raw) To: linux-scsi, target-devel, Nicholas A. Bellinger Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 12 Dec 2015 15:25:20 +0100 Some update suggestions were taken into account from static source code analysis. Markus Elfring (7): Use a variable initialisation in iscsi_set_default_param() directly Less checks in iscsi_set_default_param() after error detection Delete an unnecessary variable initialisation in iscsi_create_default_params() Make a variable initialisation a bit more obvious in iscsi_create_default_params() Rename a jump label in iscsi_create_default_params() Delete unnecessary variable initialisations in iscsi_check_valuelist_for_support() Make two variable initialisations a bit more obvious in iscsi_check_valuelist_for_support() drivers/target/iscsi/iscsi_target_parameters.c | 100 ++++++++++++------------- 1 file changed, 47 insertions(+), 53 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 1/7] iscsi-target: Use a variable initialisation in iscsi_set_default_param() directly 2015-12-12 14:30 ` SF Markus Elfring @ 2015-12-12 14:34 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-12 14:34 UTC (permalink / raw) To: linux-scsi, target-devel, Nicholas A. Bellinger Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 12 Dec 2015 11:36:02 +0100 Omit the unnecessary setting to a null pointer for the variable "param" at the beginning of the function "iscsi_set_default_param" because it can be directly initialized with the return value from the function "kzalloc". Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/target/iscsi/iscsi_target_parameters.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/target/iscsi/iscsi_target_parameters.c b/drivers/target/iscsi/iscsi_target_parameters.c index 3a1f9a7..0a8bd3f 100644 --- a/drivers/target/iscsi/iscsi_target_parameters.c +++ b/drivers/target/iscsi/iscsi_target_parameters.c @@ -127,9 +127,8 @@ static struct iscsi_param *iscsi_set_default_param(struct iscsi_param_list *para char *name, char *value, u8 phase, u8 scope, u8 sender, u16 type_range, u8 use) { - struct iscsi_param *param = NULL; + struct iscsi_param *param = kzalloc(sizeof(*param), GFP_KERNEL); - param = kzalloc(sizeof(struct iscsi_param), GFP_KERNEL); if (!param) { pr_err("Unable to allocate memory for parameter.\n"); goto out; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 1/7] iscsi-target: Use a variable initialisation in iscsi_set_default_param() directly @ 2015-12-12 14:34 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-12 14:34 UTC (permalink / raw) To: linux-scsi, target-devel, Nicholas A. Bellinger Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 12 Dec 2015 11:36:02 +0100 Omit the unnecessary setting to a null pointer for the variable "param" at the beginning of the function "iscsi_set_default_param" because it can be directly initialized with the return value from the function "kzalloc". Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/target/iscsi/iscsi_target_parameters.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/target/iscsi/iscsi_target_parameters.c b/drivers/target/iscsi/iscsi_target_parameters.c index 3a1f9a7..0a8bd3f 100644 --- a/drivers/target/iscsi/iscsi_target_parameters.c +++ b/drivers/target/iscsi/iscsi_target_parameters.c @@ -127,9 +127,8 @@ static struct iscsi_param *iscsi_set_default_param(struct iscsi_param_list *para char *name, char *value, u8 phase, u8 scope, u8 sender, u16 type_range, u8 use) { - struct iscsi_param *param = NULL; + struct iscsi_param *param = kzalloc(sizeof(*param), GFP_KERNEL); - param = kzalloc(sizeof(struct iscsi_param), GFP_KERNEL); if (!param) { pr_err("Unable to allocate memory for parameter.\n"); goto out; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/7] iscsi-target: Use a variable initialisation in iscsi_set_default_param() directly 2015-12-12 14:34 ` SF Markus Elfring @ 2015-12-12 19:49 ` Dan Carpenter -1 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2015-12-12 19:49 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-scsi, target-devel, Nicholas A. Bellinger, LKML, kernel-janitors, Julia Lawall On Sat, Dec 12, 2015 at 03:34:50PM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sat, 12 Dec 2015 11:36:02 +0100 > > Omit the unnecessary setting to a null pointer for the variable "param" > at the beginning of the function "iscsi_set_default_param" > because it can be directly initialized with the return value > from the function "kzalloc". > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/target/iscsi/iscsi_target_parameters.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/target/iscsi/iscsi_target_parameters.c b/drivers/target/iscsi/iscsi_target_parameters.c > index 3a1f9a7..0a8bd3f 100644 > --- a/drivers/target/iscsi/iscsi_target_parameters.c > +++ b/drivers/target/iscsi/iscsi_target_parameters.c > @@ -127,9 +127,8 @@ static struct iscsi_param *iscsi_set_default_param(struct iscsi_param_list *para > char *name, char *value, u8 phase, u8 scope, u8 sender, > u16 type_range, u8 use) > { > - struct iscsi_param *param = NULL; > + struct iscsi_param *param = kzalloc(sizeof(*param), GFP_KERNEL); > > - param = kzalloc(sizeof(struct iscsi_param), GFP_KERNEL); > if (!param) { > pr_err("Unable to allocate memory for parameter.\n"); > goto out; It's better to just get rid of the initialization but leave the kzalloc() as-is for two reasons. 1) Initializer code normally contains more bugs per line than other code. I am thinking about dereferencing pointers before checking for NULL or not checking the allocation for failure. 2) It puts a blank line between the allocation and the check for failure. It's like a new paragraph. The allocation and the check should be next to each other. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/7] iscsi-target: Use a variable initialisation in iscsi_set_default_param() directly @ 2015-12-12 19:49 ` Dan Carpenter 0 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2015-12-12 19:49 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-scsi, target-devel, Nicholas A. Bellinger, LKML, kernel-janitors, Julia Lawall On Sat, Dec 12, 2015 at 03:34:50PM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sat, 12 Dec 2015 11:36:02 +0100 > > Omit the unnecessary setting to a null pointer for the variable "param" > at the beginning of the function "iscsi_set_default_param" > because it can be directly initialized with the return value > from the function "kzalloc". > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/target/iscsi/iscsi_target_parameters.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/target/iscsi/iscsi_target_parameters.c b/drivers/target/iscsi/iscsi_target_parameters.c > index 3a1f9a7..0a8bd3f 100644 > --- a/drivers/target/iscsi/iscsi_target_parameters.c > +++ b/drivers/target/iscsi/iscsi_target_parameters.c > @@ -127,9 +127,8 @@ static struct iscsi_param *iscsi_set_default_param(struct iscsi_param_list *para > char *name, char *value, u8 phase, u8 scope, u8 sender, > u16 type_range, u8 use) > { > - struct iscsi_param *param = NULL; > + struct iscsi_param *param = kzalloc(sizeof(*param), GFP_KERNEL); > > - param = kzalloc(sizeof(struct iscsi_param), GFP_KERNEL); > if (!param) { > pr_err("Unable to allocate memory for parameter.\n"); > goto out; It's better to just get rid of the initialization but leave the kzalloc() as-is for two reasons. 1) Initializer code normally contains more bugs per line than other code. I am thinking about dereferencing pointers before checking for NULL or not checking the allocation for failure. 2) It puts a blank line between the allocation and the check for failure. It's like a new paragraph. The allocation and the check should be next to each other. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/7] iscsi-target: Use a variable initialisation in iscsi_set_default_param() directly 2015-12-12 19:49 ` Dan Carpenter @ 2015-12-12 21:22 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-12 21:22 UTC (permalink / raw) To: Dan Carpenter Cc: linux-scsi, target-devel, Nicholas A. Bellinger, LKML, kernel-janitors, Julia Lawall >> @@ -127,9 +127,8 @@ static struct iscsi_param *iscsi_set_default_param(struct iscsi_param_list *para >> char *name, char *value, u8 phase, u8 scope, u8 sender, >> u16 type_range, u8 use) >> { >> - struct iscsi_param *param = NULL; >> + struct iscsi_param *param = kzalloc(sizeof(*param), GFP_KERNEL); >> >> - param = kzalloc(sizeof(struct iscsi_param), GFP_KERNEL); >> if (!param) { >> pr_err("Unable to allocate memory for parameter.\n"); >> goto out; > > It's better to just get rid of the initialization but leave the > kzalloc() as-is for two reasons. > > 1) Initializer code normally contains more bugs per line than other > code. I am thinking about dereferencing pointers before checking > for NULL or not checking the allocation for failure. I can follow your concerns a bit. > 2) It puts a blank line between the allocation and the check for failure. Is there a target conflict between "convenient" variable initialisation in the declaration section and the function outline that seems to be checked by the script "checkpatch.pl" to some degree while corresponding preferences or recommendations are not mentioned in the document "CodingStyle"? > It's like a new paragraph. I do not see the separation in a strict way so far. > The allocation and the check should be next to each other. I find that these actions are still close enough in the discussed use case. Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/7] iscsi-target: Use a variable initialisation in iscsi_set_default_param() directly @ 2015-12-12 21:22 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-12 21:22 UTC (permalink / raw) To: Dan Carpenter Cc: linux-scsi, target-devel, Nicholas A. Bellinger, LKML, kernel-janitors, Julia Lawall >> @@ -127,9 +127,8 @@ static struct iscsi_param *iscsi_set_default_param(struct iscsi_param_list *para >> char *name, char *value, u8 phase, u8 scope, u8 sender, >> u16 type_range, u8 use) >> { >> - struct iscsi_param *param = NULL; >> + struct iscsi_param *param = kzalloc(sizeof(*param), GFP_KERNEL); >> >> - param = kzalloc(sizeof(struct iscsi_param), GFP_KERNEL); >> if (!param) { >> pr_err("Unable to allocate memory for parameter.\n"); >> goto out; > > It's better to just get rid of the initialization but leave the > kzalloc() as-is for two reasons. > > 1) Initializer code normally contains more bugs per line than other > code. I am thinking about dereferencing pointers before checking > for NULL or not checking the allocation for failure. I can follow your concerns a bit. > 2) It puts a blank line between the allocation and the check for failure. Is there a target conflict between "convenient" variable initialisation in the declaration section and the function outline that seems to be checked by the script "checkpatch.pl" to some degree while corresponding preferences or recommendations are not mentioned in the document "CodingStyle"? > It's like a new paragraph. I do not see the separation in a strict way so far. > The allocation and the check should be next to each other. I find that these actions are still close enough in the discussed use case. Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/7] iscsi-target: Use a variable initialisation in iscsi_set_default_param() directly 2015-12-12 19:49 ` Dan Carpenter @ 2015-12-14 8:41 ` Johannes Thumshirn -1 siblings, 0 replies; 3089+ messages in thread From: Johannes Thumshirn @ 2015-12-14 8:41 UTC (permalink / raw) To: Dan Carpenter Cc: SF Markus Elfring, linux-scsi, target-devel, Nicholas A. Bellinger, LKML, kernel-janitors, Julia Lawall On Sat, Dec 12, 2015 at 10:49:40PM +0300, Dan Carpenter wrote: > On Sat, Dec 12, 2015 at 03:34:50PM +0100, SF Markus Elfring wrote: > > From: Markus Elfring <elfring@users.sourceforge.net> > > Date: Sat, 12 Dec 2015 11:36:02 +0100 > > > > Omit the unnecessary setting to a null pointer for the variable "param" > > at the beginning of the function "iscsi_set_default_param" > > because it can be directly initialized with the return value > > from the function "kzalloc". > > > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > > --- > > drivers/target/iscsi/iscsi_target_parameters.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/drivers/target/iscsi/iscsi_target_parameters.c b/drivers/target/iscsi/iscsi_target_parameters.c > > index 3a1f9a7..0a8bd3f 100644 > > --- a/drivers/target/iscsi/iscsi_target_parameters.c > > +++ b/drivers/target/iscsi/iscsi_target_parameters.c > > @@ -127,9 +127,8 @@ static struct iscsi_param *iscsi_set_default_param(struct iscsi_param_list *para > > char *name, char *value, u8 phase, u8 scope, u8 sender, > > u16 type_range, u8 use) > > { > > - struct iscsi_param *param = NULL; > > + struct iscsi_param *param = kzalloc(sizeof(*param), GFP_KERNEL); > > > > - param = kzalloc(sizeof(struct iscsi_param), GFP_KERNEL); > > if (!param) { > > pr_err("Unable to allocate memory for parameter.\n"); > > goto out; > > It's better to just get rid of the initialization but leave the > kzalloc() as-is for two reasons. > > 1) Initializer code normally contains more bugs per line than other > code. I am thinking about dereferencing pointers before checking > for NULL or not checking the allocation for failure. > > 2) It puts a blank line between the allocation and the check for > failure. It's like a new paragraph. The allocation and the check > should be next to each other. I agree with Dan here. Please don't do it. @@ -127,9 +127,8 @@ static struct iscsi_param *iscsi_set_default_param(struct iscsi_param_list *para char *name, char *value, u8 phase, u8 scope, u8 sender, u16 type_range, u8 use) { - struct iscsi_param *param = NULL; + struct iscsi_param *param; param = kzalloc(sizeof(struct iscsi_param), GFP_KERNEL); if (!param) { pr_err("Unable to allocate memory for parameter.\n"); This way it would be _far_ more readable. IMHO one should have a 1 action per line of code style and only assign values in at declaration time if really necessary. But what is the benefit from this? Is it fixing a (hypothetical) bug? I somehow fail to see it. Thanks, Johannes -- Johannes Thumshirn Storage jthumshirn@suse.de +49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/7] iscsi-target: Use a variable initialisation in iscsi_set_default_param() directly @ 2015-12-14 8:41 ` Johannes Thumshirn 0 siblings, 0 replies; 3089+ messages in thread From: Johannes Thumshirn @ 2015-12-14 8:41 UTC (permalink / raw) To: Dan Carpenter Cc: SF Markus Elfring, linux-scsi, target-devel, Nicholas A. Bellinger, LKML, kernel-janitors, Julia Lawall On Sat, Dec 12, 2015 at 10:49:40PM +0300, Dan Carpenter wrote: > On Sat, Dec 12, 2015 at 03:34:50PM +0100, SF Markus Elfring wrote: > > From: Markus Elfring <elfring@users.sourceforge.net> > > Date: Sat, 12 Dec 2015 11:36:02 +0100 > > > > Omit the unnecessary setting to a null pointer for the variable "param" > > at the beginning of the function "iscsi_set_default_param" > > because it can be directly initialized with the return value > > from the function "kzalloc". > > > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > > --- > > drivers/target/iscsi/iscsi_target_parameters.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/drivers/target/iscsi/iscsi_target_parameters.c b/drivers/target/iscsi/iscsi_target_parameters.c > > index 3a1f9a7..0a8bd3f 100644 > > --- a/drivers/target/iscsi/iscsi_target_parameters.c > > +++ b/drivers/target/iscsi/iscsi_target_parameters.c > > @@ -127,9 +127,8 @@ static struct iscsi_param *iscsi_set_default_param(struct iscsi_param_list *para > > char *name, char *value, u8 phase, u8 scope, u8 sender, > > u16 type_range, u8 use) > > { > > - struct iscsi_param *param = NULL; > > + struct iscsi_param *param = kzalloc(sizeof(*param), GFP_KERNEL); > > > > - param = kzalloc(sizeof(struct iscsi_param), GFP_KERNEL); > > if (!param) { > > pr_err("Unable to allocate memory for parameter.\n"); > > goto out; > > It's better to just get rid of the initialization but leave the > kzalloc() as-is for two reasons. > > 1) Initializer code normally contains more bugs per line than other > code. I am thinking about dereferencing pointers before checking > for NULL or not checking the allocation for failure. > > 2) It puts a blank line between the allocation and the check for > failure. It's like a new paragraph. The allocation and the check > should be next to each other. I agree with Dan here. Please don't do it. @@ -127,9 +127,8 @@ static struct iscsi_param *iscsi_set_default_param(struct iscsi_param_list *para char *name, char *value, u8 phase, u8 scope, u8 sender, u16 type_range, u8 use) { - struct iscsi_param *param = NULL; + struct iscsi_param *param; param = kzalloc(sizeof(struct iscsi_param), GFP_KERNEL); if (!param) { pr_err("Unable to allocate memory for parameter.\n"); This way it would be _far_ more readable. IMHO one should have a 1 action per line of code style and only assign values in at declaration time if really necessary. But what is the benefit from this? Is it fixing a (hypothetical) bug? I somehow fail to see it. Thanks, Johannes -- Johannes Thumshirn Storage jthumshirn@suse.de +49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/7] iscsi-target: Use a variable initialisation in iscsi_set_default_param() directly 2015-12-14 8:41 ` Johannes Thumshirn @ 2015-12-14 11:38 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-14 11:38 UTC (permalink / raw) To: Johannes Thumshirn Cc: Dan Carpenter, linux-scsi, target-devel, Nicholas A. Bellinger, LKML, kernel-janitors, Julia Lawall > @@ -127,9 +127,8 @@ static struct iscsi_param *iscsi_set_default_param(struct iscsi_param_list *para > char *name, char *value, u8 phase, u8 scope, u8 sender, > u16 type_range, u8 use) > { > - struct iscsi_param *param = NULL; > + struct iscsi_param *param; > > param = kzalloc(sizeof(struct iscsi_param), GFP_KERNEL); > if (!param) { > pr_err("Unable to allocate memory for parameter.\n"); > > > This way it would be _far_ more readable. I guess that there are some opinions available for this implementation detail. > IMHO one should have a 1 action per line of code style How often do you care for such style issues? > and only assign values in at declaration time if really necessary. Which is or might become the official Linux coding style recommendation for this aspect? > But what is the benefit from this? Is it fixing a (hypothetical) bug? I find the shown null pointer initialisation just needless. Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/7] iscsi-target: Use a variable initialisation in iscsi_set_default_param() directly @ 2015-12-14 11:38 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-14 11:38 UTC (permalink / raw) To: Johannes Thumshirn Cc: Dan Carpenter, linux-scsi, target-devel, Nicholas A. Bellinger, LKML, kernel-janitors, Julia Lawall > @@ -127,9 +127,8 @@ static struct iscsi_param *iscsi_set_default_param(struct iscsi_param_list *para > char *name, char *value, u8 phase, u8 scope, u8 sender, > u16 type_range, u8 use) > { > - struct iscsi_param *param = NULL; > + struct iscsi_param *param; > > param = kzalloc(sizeof(struct iscsi_param), GFP_KERNEL); > if (!param) { > pr_err("Unable to allocate memory for parameter.\n"); > > > This way it would be _far_ more readable. I guess that there are some opinions available for this implementation detail. > IMHO one should have a 1 action per line of code style How often do you care for such style issues? > and only assign values in at declaration time if really necessary. Which is or might become the official Linux coding style recommendation for this aspect? > But what is the benefit from this? Is it fixing a (hypothetical) bug? I find the shown null pointer initialisation just needless. Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 2/7] iscsi-target: Less checks in iscsi_set_default_param() after error detection 2015-12-12 14:30 ` SF Markus Elfring @ 2015-12-12 14:37 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-12 14:37 UTC (permalink / raw) To: linux-scsi, target-devel, Nicholas A. Bellinger Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 12 Dec 2015 12:50:10 +0100 This issue was detected by using the Coccinelle software. A sanity check would be performed by the iscsi_set_default_param() function even if it is known already that the passed variable contained a null pointer. * This implementation detail could be improved by adjustments for jump targets according to the Linux coding style convention. * Let us return directly if a call of the function "kzalloc" failed. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/target/iscsi/iscsi_target_parameters.c | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/drivers/target/iscsi/iscsi_target_parameters.c b/drivers/target/iscsi/iscsi_target_parameters.c index 0a8bd3f..15b2618 100644 --- a/drivers/target/iscsi/iscsi_target_parameters.c +++ b/drivers/target/iscsi/iscsi_target_parameters.c @@ -131,20 +131,20 @@ static struct iscsi_param *iscsi_set_default_param(struct iscsi_param_list *para if (!param) { pr_err("Unable to allocate memory for parameter.\n"); - goto out; + return NULL; } INIT_LIST_HEAD(¶m->p_list); param->name = kstrdup(name, GFP_KERNEL); if (!param->name) { pr_err("Unable to allocate memory for parameter name.\n"); - goto out; + goto free_param; } param->value = kstrdup(value, GFP_KERNEL); if (!param->value) { pr_err("Unable to allocate memory for parameter value.\n"); - goto out; + goto free_name; } param->phase = phase; @@ -182,18 +182,17 @@ static struct iscsi_param *iscsi_set_default_param(struct iscsi_param_list *para default: pr_err("Unknown type_range 0x%02x\n", param->type_range); - goto out; + goto free_value; } list_add_tail(¶m->p_list, ¶m_list->param_list); return param; -out: - if (param) { - kfree(param->value); - kfree(param->name); - kfree(param); - } - +free_value: + kfree(param->value); +free_name: + kfree(param->name); +free_param: + kfree(param); return NULL; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 2/7] iscsi-target: Less checks in iscsi_set_default_param() after error detection @ 2015-12-12 14:37 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-12 14:37 UTC (permalink / raw) To: linux-scsi, target-devel, Nicholas A. Bellinger Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 12 Dec 2015 12:50:10 +0100 This issue was detected by using the Coccinelle software. A sanity check would be performed by the iscsi_set_default_param() function even if it is known already that the passed variable contained a null pointer. * This implementation detail could be improved by adjustments for jump targets according to the Linux coding style convention. * Let us return directly if a call of the function "kzalloc" failed. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/target/iscsi/iscsi_target_parameters.c | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/drivers/target/iscsi/iscsi_target_parameters.c b/drivers/target/iscsi/iscsi_target_parameters.c index 0a8bd3f..15b2618 100644 --- a/drivers/target/iscsi/iscsi_target_parameters.c +++ b/drivers/target/iscsi/iscsi_target_parameters.c @@ -131,20 +131,20 @@ static struct iscsi_param *iscsi_set_default_param(struct iscsi_param_list *para if (!param) { pr_err("Unable to allocate memory for parameter.\n"); - goto out; + return NULL; } INIT_LIST_HEAD(¶m->p_list); param->name = kstrdup(name, GFP_KERNEL); if (!param->name) { pr_err("Unable to allocate memory for parameter name.\n"); - goto out; + goto free_param; } param->value = kstrdup(value, GFP_KERNEL); if (!param->value) { pr_err("Unable to allocate memory for parameter value.\n"); - goto out; + goto free_name; } param->phase = phase; @@ -182,18 +182,17 @@ static struct iscsi_param *iscsi_set_default_param(struct iscsi_param_list *para default: pr_err("Unknown type_range 0x%02x\n", param->type_range); - goto out; + goto free_value; } list_add_tail(¶m->p_list, ¶m_list->param_list); return param; -out: - if (param) { - kfree(param->value); - kfree(param->name); - kfree(param); - } - +free_value: + kfree(param->value); +free_name: + kfree(param->name); +free_param: + kfree(param); return NULL; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 3/7] iscsi-target: Delete an unnecessary variable initialisation in iscsi_create_default_params() 2015-12-12 14:30 ` SF Markus Elfring @ 2015-12-12 14:40 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-12 14:40 UTC (permalink / raw) To: linux-scsi, target-devel, Nicholas A. Bellinger Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 12 Dec 2015 13:20:08 +0100 The variable "param" will eventually be set to an appropriate pointer from a call of the iscsi_set_default_param() function. Thus let us omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/target/iscsi/iscsi_target_parameters.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/target/iscsi/iscsi_target_parameters.c b/drivers/target/iscsi/iscsi_target_parameters.c index 15b2618..e0b173d 100644 --- a/drivers/target/iscsi/iscsi_target_parameters.c +++ b/drivers/target/iscsi/iscsi_target_parameters.c @@ -199,7 +199,7 @@ free_param: /* #warning Add extension keys */ int iscsi_create_default_params(struct iscsi_param_list **param_list_ptr) { - struct iscsi_param *param = NULL; + struct iscsi_param *param; struct iscsi_param_list *pl; pl = kzalloc(sizeof(struct iscsi_param_list), GFP_KERNEL); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 3/7] iscsi-target: Delete an unnecessary variable initialisation in iscsi_create_default_para @ 2015-12-12 14:40 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-12 14:40 UTC (permalink / raw) To: linux-scsi, target-devel, Nicholas A. Bellinger Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 12 Dec 2015 13:20:08 +0100 The variable "param" will eventually be set to an appropriate pointer from a call of the iscsi_set_default_param() function. Thus let us omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/target/iscsi/iscsi_target_parameters.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/target/iscsi/iscsi_target_parameters.c b/drivers/target/iscsi/iscsi_target_parameters.c index 15b2618..e0b173d 100644 --- a/drivers/target/iscsi/iscsi_target_parameters.c +++ b/drivers/target/iscsi/iscsi_target_parameters.c @@ -199,7 +199,7 @@ free_param: /* #warning Add extension keys */ int iscsi_create_default_params(struct iscsi_param_list **param_list_ptr) { - struct iscsi_param *param = NULL; + struct iscsi_param *param; struct iscsi_param_list *pl; pl = kzalloc(sizeof(struct iscsi_param_list), GFP_KERNEL); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 4/7] iscsi-target: Make a variable initialisation a bit more obvious in iscsi_create_default_params() 2015-12-12 14:30 ` SF Markus Elfring @ 2015-12-12 14:41 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-12 14:41 UTC (permalink / raw) To: linux-scsi, target-devel, Nicholas A. Bellinger Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 12 Dec 2015 13:44:06 +0100 The variable "pl" was declared and immediately assigned a return value from a function call in a separate statement. * Let us express the desired variable initialisation directly. * Avoid the repetition of the data type specification for the involved memory allocation according to the Linux coding style convention. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/target/iscsi/iscsi_target_parameters.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/target/iscsi/iscsi_target_parameters.c b/drivers/target/iscsi/iscsi_target_parameters.c index e0b173d..3f3842f 100644 --- a/drivers/target/iscsi/iscsi_target_parameters.c +++ b/drivers/target/iscsi/iscsi_target_parameters.c @@ -200,9 +200,8 @@ free_param: int iscsi_create_default_params(struct iscsi_param_list **param_list_ptr) { struct iscsi_param *param; - struct iscsi_param_list *pl; + struct iscsi_param_list *pl = kzalloc(sizeof(*pl), GFP_KERNEL); - pl = kzalloc(sizeof(struct iscsi_param_list), GFP_KERNEL); if (!pl) { pr_err("Unable to allocate memory for" " struct iscsi_param_list.\n"); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 4/7] iscsi-target: Make a variable initialisation a bit more obvious in iscsi_create_default_ @ 2015-12-12 14:41 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-12 14:41 UTC (permalink / raw) To: linux-scsi, target-devel, Nicholas A. Bellinger Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 12 Dec 2015 13:44:06 +0100 The variable "pl" was declared and immediately assigned a return value from a function call in a separate statement. * Let us express the desired variable initialisation directly. * Avoid the repetition of the data type specification for the involved memory allocation according to the Linux coding style convention. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/target/iscsi/iscsi_target_parameters.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/target/iscsi/iscsi_target_parameters.c b/drivers/target/iscsi/iscsi_target_parameters.c index e0b173d..3f3842f 100644 --- a/drivers/target/iscsi/iscsi_target_parameters.c +++ b/drivers/target/iscsi/iscsi_target_parameters.c @@ -200,9 +200,8 @@ free_param: int iscsi_create_default_params(struct iscsi_param_list **param_list_ptr) { struct iscsi_param *param; - struct iscsi_param_list *pl; + struct iscsi_param_list *pl = kzalloc(sizeof(*pl), GFP_KERNEL); - pl = kzalloc(sizeof(struct iscsi_param_list), GFP_KERNEL); if (!pl) { pr_err("Unable to allocate memory for" " struct iscsi_param_list.\n"); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 4/7] iscsi-target: Make a variable initialisation a bit more obvious in iscsi_create_default_params() 2015-12-12 14:41 ` [PATCH 4/7] iscsi-target: Make a variable initialisation a bit more obvious in iscsi_create_default_ SF Markus Elfring @ 2015-12-12 14:45 ` Julia Lawall -1 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2015-12-12 14:45 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-scsi, target-devel, Nicholas A. Bellinger, LKML, kernel-janitors On Sat, 12 Dec 2015, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sat, 12 Dec 2015 13:44:06 +0100 > > The variable "pl" was declared and immediately assigned a return value > from a function call in a separate statement. > > * Let us express the desired variable initialisation directly. > > * Avoid the repetition of the data type specification for the > involved memory allocation according to the Linux coding > style convention. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/target/iscsi/iscsi_target_parameters.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/target/iscsi/iscsi_target_parameters.c b/drivers/target/iscsi/iscsi_target_parameters.c > index e0b173d..3f3842f 100644 > --- a/drivers/target/iscsi/iscsi_target_parameters.c > +++ b/drivers/target/iscsi/iscsi_target_parameters.c > @@ -200,9 +200,8 @@ free_param: > int iscsi_create_default_params(struct iscsi_param_list **param_list_ptr) > { > struct iscsi_param *param; > - struct iscsi_param_list *pl; > + struct iscsi_param_list *pl = kzalloc(sizeof(*pl), GFP_KERNEL); > > - pl = kzalloc(sizeof(struct iscsi_param_list), GFP_KERNEL); I don't see the benefit of this change, and the pattern assignment -> failure test becomes more obscure. julia > if (!pl) { > pr_err("Unable to allocate memory for" > " struct iscsi_param_list.\n"); > -- > 2.6.3 > > -- > To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 4/7] iscsi-target: Make a variable initialisation a bit more obvious in iscsi_create_defa @ 2015-12-12 14:45 ` Julia Lawall 0 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2015-12-12 14:45 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-scsi, target-devel, Nicholas A. Bellinger, LKML, kernel-janitors On Sat, 12 Dec 2015, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sat, 12 Dec 2015 13:44:06 +0100 > > The variable "pl" was declared and immediately assigned a return value > from a function call in a separate statement. > > * Let us express the desired variable initialisation directly. > > * Avoid the repetition of the data type specification for the > involved memory allocation according to the Linux coding > style convention. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/target/iscsi/iscsi_target_parameters.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/target/iscsi/iscsi_target_parameters.c b/drivers/target/iscsi/iscsi_target_parameters.c > index e0b173d..3f3842f 100644 > --- a/drivers/target/iscsi/iscsi_target_parameters.c > +++ b/drivers/target/iscsi/iscsi_target_parameters.c > @@ -200,9 +200,8 @@ free_param: > int iscsi_create_default_params(struct iscsi_param_list **param_list_ptr) > { > struct iscsi_param *param; > - struct iscsi_param_list *pl; > + struct iscsi_param_list *pl = kzalloc(sizeof(*pl), GFP_KERNEL); > > - pl = kzalloc(sizeof(struct iscsi_param_list), GFP_KERNEL); I don't see the benefit of this change, and the pattern assignment -> failure test becomes more obscure. julia > if (!pl) { > pr_err("Unable to allocate memory for" > " struct iscsi_param_list.\n"); > -- > 2.6.3 > > -- > To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 4/7] iscsi-target: Make a variable initialisation a bit more obvious in iscsi_create_default_params() 2015-12-12 14:45 ` [PATCH 4/7] iscsi-target: Make a variable initialisation a bit more obvious in iscsi_create_defa Julia Lawall @ 2015-12-12 15:02 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-12 15:02 UTC (permalink / raw) To: Julia Lawall Cc: linux-scsi, target-devel, Nicholas A. Bellinger, LKML, kernel-janitors >> @@ -200,9 +200,8 @@ free_param: >> int iscsi_create_default_params(struct iscsi_param_list **param_list_ptr) >> { >> struct iscsi_param *param; >> - struct iscsi_param_list *pl; >> + struct iscsi_param_list *pl = kzalloc(sizeof(*pl), GFP_KERNEL); >> >> - pl = kzalloc(sizeof(struct iscsi_param_list), GFP_KERNEL); > > I don't see the benefit of this change, and the pattern assignment -> > failure test becomes more obscure. Are there any more software developers who prefer to specify such a variable initialisation on a single line? Does the proposed small source code reduction matter for you? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 4/7] iscsi-target: Make a variable initialisation a bit more obvious in iscsi_create_defa @ 2015-12-12 15:02 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-12 15:02 UTC (permalink / raw) To: Julia Lawall Cc: linux-scsi, target-devel, Nicholas A. Bellinger, LKML, kernel-janitors >> @@ -200,9 +200,8 @@ free_param: >> int iscsi_create_default_params(struct iscsi_param_list **param_list_ptr) >> { >> struct iscsi_param *param; >> - struct iscsi_param_list *pl; >> + struct iscsi_param_list *pl = kzalloc(sizeof(*pl), GFP_KERNEL); >> >> - pl = kzalloc(sizeof(struct iscsi_param_list), GFP_KERNEL); > > I don't see the benefit of this change, and the pattern assignment -> > failure test becomes more obscure. Are there any more software developers who prefer to specify such a variable initialisation on a single line? Does the proposed small source code reduction matter for you? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 5/7] iscsi-target: Rename a jump label in iscsi_create_default_params() 2015-12-12 14:30 ` SF Markus Elfring @ 2015-12-12 14:42 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-12 14:42 UTC (permalink / raw) To: linux-scsi, target-devel, Nicholas A. Bellinger Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 12 Dec 2015 14:12:50 +0100 This issue was detected by using the Coccinelle software. Choose a jump label according to the current Linux coding style convention. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/target/iscsi/iscsi_target_parameters.c | 64 +++++++++++++------------- 1 file changed, 32 insertions(+), 32 deletions(-) diff --git a/drivers/target/iscsi/iscsi_target_parameters.c b/drivers/target/iscsi/iscsi_target_parameters.c index 3f3842f..29ecf29 100644 --- a/drivers/target/iscsi/iscsi_target_parameters.c +++ b/drivers/target/iscsi/iscsi_target_parameters.c @@ -225,185 +225,185 @@ int iscsi_create_default_params(struct iscsi_param_list **param_list_ptr) PHASE_SECURITY, SCOPE_CONNECTION_ONLY, SENDER_BOTH, TYPERANGE_AUTH, USE_INITIAL_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, HEADERDIGEST, INITIAL_HEADERDIGEST, PHASE_OPERATIONAL, SCOPE_CONNECTION_ONLY, SENDER_BOTH, TYPERANGE_DIGEST, USE_INITIAL_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, DATADIGEST, INITIAL_DATADIGEST, PHASE_OPERATIONAL, SCOPE_CONNECTION_ONLY, SENDER_BOTH, TYPERANGE_DIGEST, USE_INITIAL_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, MAXCONNECTIONS, INITIAL_MAXCONNECTIONS, PHASE_OPERATIONAL, SCOPE_SESSION_WIDE, SENDER_BOTH, TYPERANGE_1_TO_65535, USE_LEADING_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, SENDTARGETS, INITIAL_SENDTARGETS, PHASE_FFP0, SCOPE_SESSION_WIDE, SENDER_INITIATOR, TYPERANGE_UTF8, 0); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, TARGETNAME, INITIAL_TARGETNAME, PHASE_DECLARATIVE, SCOPE_SESSION_WIDE, SENDER_BOTH, TYPERANGE_ISCSINAME, USE_ALL); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, INITIATORNAME, INITIAL_INITIATORNAME, PHASE_DECLARATIVE, SCOPE_SESSION_WIDE, SENDER_INITIATOR, TYPERANGE_ISCSINAME, USE_INITIAL_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, TARGETALIAS, INITIAL_TARGETALIAS, PHASE_DECLARATIVE, SCOPE_SESSION_WIDE, SENDER_TARGET, TYPERANGE_UTF8, USE_ALL); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, INITIATORALIAS, INITIAL_INITIATORALIAS, PHASE_DECLARATIVE, SCOPE_SESSION_WIDE, SENDER_INITIATOR, TYPERANGE_UTF8, USE_ALL); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, TARGETADDRESS, INITIAL_TARGETADDRESS, PHASE_DECLARATIVE, SCOPE_SESSION_WIDE, SENDER_TARGET, TYPERANGE_TARGETADDRESS, USE_ALL); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, TARGETPORTALGROUPTAG, INITIAL_TARGETPORTALGROUPTAG, PHASE_DECLARATIVE, SCOPE_SESSION_WIDE, SENDER_TARGET, TYPERANGE_0_TO_65535, USE_INITIAL_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, INITIALR2T, INITIAL_INITIALR2T, PHASE_OPERATIONAL, SCOPE_SESSION_WIDE, SENDER_BOTH, TYPERANGE_BOOL_OR, USE_LEADING_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, IMMEDIATEDATA, INITIAL_IMMEDIATEDATA, PHASE_OPERATIONAL, SCOPE_SESSION_WIDE, SENDER_BOTH, TYPERANGE_BOOL_AND, USE_LEADING_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, MAXXMITDATASEGMENTLENGTH, INITIAL_MAXXMITDATASEGMENTLENGTH, PHASE_OPERATIONAL, SCOPE_CONNECTION_ONLY, SENDER_BOTH, TYPERANGE_512_TO_16777215, USE_ALL); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, MAXRECVDATASEGMENTLENGTH, INITIAL_MAXRECVDATASEGMENTLENGTH, PHASE_OPERATIONAL, SCOPE_CONNECTION_ONLY, SENDER_BOTH, TYPERANGE_512_TO_16777215, USE_ALL); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, MAXBURSTLENGTH, INITIAL_MAXBURSTLENGTH, PHASE_OPERATIONAL, SCOPE_SESSION_WIDE, SENDER_BOTH, TYPERANGE_512_TO_16777215, USE_LEADING_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, FIRSTBURSTLENGTH, INITIAL_FIRSTBURSTLENGTH, PHASE_OPERATIONAL, SCOPE_SESSION_WIDE, SENDER_BOTH, TYPERANGE_512_TO_16777215, USE_LEADING_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, DEFAULTTIME2WAIT, INITIAL_DEFAULTTIME2WAIT, PHASE_OPERATIONAL, SCOPE_SESSION_WIDE, SENDER_BOTH, TYPERANGE_0_TO_3600, USE_LEADING_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, DEFAULTTIME2RETAIN, INITIAL_DEFAULTTIME2RETAIN, PHASE_OPERATIONAL, SCOPE_SESSION_WIDE, SENDER_BOTH, TYPERANGE_0_TO_3600, USE_LEADING_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, MAXOUTSTANDINGR2T, INITIAL_MAXOUTSTANDINGR2T, PHASE_OPERATIONAL, SCOPE_SESSION_WIDE, SENDER_BOTH, TYPERANGE_1_TO_65535, USE_LEADING_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, DATAPDUINORDER, INITIAL_DATAPDUINORDER, PHASE_OPERATIONAL, SCOPE_SESSION_WIDE, SENDER_BOTH, TYPERANGE_BOOL_OR, USE_LEADING_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, DATASEQUENCEINORDER, INITIAL_DATASEQUENCEINORDER, PHASE_OPERATIONAL, SCOPE_SESSION_WIDE, SENDER_BOTH, TYPERANGE_BOOL_OR, USE_LEADING_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, ERRORRECOVERYLEVEL, INITIAL_ERRORRECOVERYLEVEL, PHASE_OPERATIONAL, SCOPE_SESSION_WIDE, SENDER_BOTH, TYPERANGE_0_TO_2, USE_LEADING_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, SESSIONTYPE, INITIAL_SESSIONTYPE, PHASE_DECLARATIVE, SCOPE_SESSION_WIDE, SENDER_INITIATOR, TYPERANGE_SESSIONTYPE, USE_LEADING_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, IFMARKER, INITIAL_IFMARKER, PHASE_OPERATIONAL, SCOPE_CONNECTION_ONLY, SENDER_BOTH, TYPERANGE_BOOL_AND, USE_INITIAL_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, OFMARKER, INITIAL_OFMARKER, PHASE_OPERATIONAL, SCOPE_CONNECTION_ONLY, SENDER_BOTH, TYPERANGE_BOOL_AND, USE_INITIAL_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, IFMARKINT, INITIAL_IFMARKINT, PHASE_OPERATIONAL, SCOPE_CONNECTION_ONLY, SENDER_BOTH, TYPERANGE_UTF8, USE_INITIAL_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, OFMARKINT, INITIAL_OFMARKINT, PHASE_OPERATIONAL, SCOPE_CONNECTION_ONLY, SENDER_BOTH, TYPERANGE_UTF8, USE_INITIAL_ONLY); if (!param) - goto out; + goto release_list; /* * Extra parameters for ISER from RFC-5046 @@ -412,25 +412,25 @@ int iscsi_create_default_params(struct iscsi_param_list **param_list_ptr) PHASE_OPERATIONAL, SCOPE_SESSION_WIDE, SENDER_BOTH, TYPERANGE_BOOL_AND, USE_LEADING_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, INITIATORRECVDATASEGMENTLENGTH, INITIAL_INITIATORRECVDATASEGMENTLENGTH, PHASE_OPERATIONAL, SCOPE_CONNECTION_ONLY, SENDER_BOTH, TYPERANGE_512_TO_16777215, USE_ALL); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, TARGETRECVDATASEGMENTLENGTH, INITIAL_TARGETRECVDATASEGMENTLENGTH, PHASE_OPERATIONAL, SCOPE_CONNECTION_ONLY, SENDER_BOTH, TYPERANGE_512_TO_16777215, USE_ALL); if (!param) - goto out; + goto release_list; *param_list_ptr = pl; return 0; -out: +release_list: iscsi_release_param_list(pl); return -1; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 5/7] iscsi-target: Rename a jump label in iscsi_create_default_params() @ 2015-12-12 14:42 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-12 14:42 UTC (permalink / raw) To: linux-scsi, target-devel, Nicholas A. Bellinger Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 12 Dec 2015 14:12:50 +0100 This issue was detected by using the Coccinelle software. Choose a jump label according to the current Linux coding style convention. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/target/iscsi/iscsi_target_parameters.c | 64 +++++++++++++------------- 1 file changed, 32 insertions(+), 32 deletions(-) diff --git a/drivers/target/iscsi/iscsi_target_parameters.c b/drivers/target/iscsi/iscsi_target_parameters.c index 3f3842f..29ecf29 100644 --- a/drivers/target/iscsi/iscsi_target_parameters.c +++ b/drivers/target/iscsi/iscsi_target_parameters.c @@ -225,185 +225,185 @@ int iscsi_create_default_params(struct iscsi_param_list **param_list_ptr) PHASE_SECURITY, SCOPE_CONNECTION_ONLY, SENDER_BOTH, TYPERANGE_AUTH, USE_INITIAL_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, HEADERDIGEST, INITIAL_HEADERDIGEST, PHASE_OPERATIONAL, SCOPE_CONNECTION_ONLY, SENDER_BOTH, TYPERANGE_DIGEST, USE_INITIAL_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, DATADIGEST, INITIAL_DATADIGEST, PHASE_OPERATIONAL, SCOPE_CONNECTION_ONLY, SENDER_BOTH, TYPERANGE_DIGEST, USE_INITIAL_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, MAXCONNECTIONS, INITIAL_MAXCONNECTIONS, PHASE_OPERATIONAL, SCOPE_SESSION_WIDE, SENDER_BOTH, TYPERANGE_1_TO_65535, USE_LEADING_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, SENDTARGETS, INITIAL_SENDTARGETS, PHASE_FFP0, SCOPE_SESSION_WIDE, SENDER_INITIATOR, TYPERANGE_UTF8, 0); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, TARGETNAME, INITIAL_TARGETNAME, PHASE_DECLARATIVE, SCOPE_SESSION_WIDE, SENDER_BOTH, TYPERANGE_ISCSINAME, USE_ALL); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, INITIATORNAME, INITIAL_INITIATORNAME, PHASE_DECLARATIVE, SCOPE_SESSION_WIDE, SENDER_INITIATOR, TYPERANGE_ISCSINAME, USE_INITIAL_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, TARGETALIAS, INITIAL_TARGETALIAS, PHASE_DECLARATIVE, SCOPE_SESSION_WIDE, SENDER_TARGET, TYPERANGE_UTF8, USE_ALL); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, INITIATORALIAS, INITIAL_INITIATORALIAS, PHASE_DECLARATIVE, SCOPE_SESSION_WIDE, SENDER_INITIATOR, TYPERANGE_UTF8, USE_ALL); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, TARGETADDRESS, INITIAL_TARGETADDRESS, PHASE_DECLARATIVE, SCOPE_SESSION_WIDE, SENDER_TARGET, TYPERANGE_TARGETADDRESS, USE_ALL); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, TARGETPORTALGROUPTAG, INITIAL_TARGETPORTALGROUPTAG, PHASE_DECLARATIVE, SCOPE_SESSION_WIDE, SENDER_TARGET, TYPERANGE_0_TO_65535, USE_INITIAL_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, INITIALR2T, INITIAL_INITIALR2T, PHASE_OPERATIONAL, SCOPE_SESSION_WIDE, SENDER_BOTH, TYPERANGE_BOOL_OR, USE_LEADING_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, IMMEDIATEDATA, INITIAL_IMMEDIATEDATA, PHASE_OPERATIONAL, SCOPE_SESSION_WIDE, SENDER_BOTH, TYPERANGE_BOOL_AND, USE_LEADING_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, MAXXMITDATASEGMENTLENGTH, INITIAL_MAXXMITDATASEGMENTLENGTH, PHASE_OPERATIONAL, SCOPE_CONNECTION_ONLY, SENDER_BOTH, TYPERANGE_512_TO_16777215, USE_ALL); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, MAXRECVDATASEGMENTLENGTH, INITIAL_MAXRECVDATASEGMENTLENGTH, PHASE_OPERATIONAL, SCOPE_CONNECTION_ONLY, SENDER_BOTH, TYPERANGE_512_TO_16777215, USE_ALL); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, MAXBURSTLENGTH, INITIAL_MAXBURSTLENGTH, PHASE_OPERATIONAL, SCOPE_SESSION_WIDE, SENDER_BOTH, TYPERANGE_512_TO_16777215, USE_LEADING_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, FIRSTBURSTLENGTH, INITIAL_FIRSTBURSTLENGTH, PHASE_OPERATIONAL, SCOPE_SESSION_WIDE, SENDER_BOTH, TYPERANGE_512_TO_16777215, USE_LEADING_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, DEFAULTTIME2WAIT, INITIAL_DEFAULTTIME2WAIT, PHASE_OPERATIONAL, SCOPE_SESSION_WIDE, SENDER_BOTH, TYPERANGE_0_TO_3600, USE_LEADING_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, DEFAULTTIME2RETAIN, INITIAL_DEFAULTTIME2RETAIN, PHASE_OPERATIONAL, SCOPE_SESSION_WIDE, SENDER_BOTH, TYPERANGE_0_TO_3600, USE_LEADING_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, MAXOUTSTANDINGR2T, INITIAL_MAXOUTSTANDINGR2T, PHASE_OPERATIONAL, SCOPE_SESSION_WIDE, SENDER_BOTH, TYPERANGE_1_TO_65535, USE_LEADING_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, DATAPDUINORDER, INITIAL_DATAPDUINORDER, PHASE_OPERATIONAL, SCOPE_SESSION_WIDE, SENDER_BOTH, TYPERANGE_BOOL_OR, USE_LEADING_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, DATASEQUENCEINORDER, INITIAL_DATASEQUENCEINORDER, PHASE_OPERATIONAL, SCOPE_SESSION_WIDE, SENDER_BOTH, TYPERANGE_BOOL_OR, USE_LEADING_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, ERRORRECOVERYLEVEL, INITIAL_ERRORRECOVERYLEVEL, PHASE_OPERATIONAL, SCOPE_SESSION_WIDE, SENDER_BOTH, TYPERANGE_0_TO_2, USE_LEADING_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, SESSIONTYPE, INITIAL_SESSIONTYPE, PHASE_DECLARATIVE, SCOPE_SESSION_WIDE, SENDER_INITIATOR, TYPERANGE_SESSIONTYPE, USE_LEADING_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, IFMARKER, INITIAL_IFMARKER, PHASE_OPERATIONAL, SCOPE_CONNECTION_ONLY, SENDER_BOTH, TYPERANGE_BOOL_AND, USE_INITIAL_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, OFMARKER, INITIAL_OFMARKER, PHASE_OPERATIONAL, SCOPE_CONNECTION_ONLY, SENDER_BOTH, TYPERANGE_BOOL_AND, USE_INITIAL_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, IFMARKINT, INITIAL_IFMARKINT, PHASE_OPERATIONAL, SCOPE_CONNECTION_ONLY, SENDER_BOTH, TYPERANGE_UTF8, USE_INITIAL_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, OFMARKINT, INITIAL_OFMARKINT, PHASE_OPERATIONAL, SCOPE_CONNECTION_ONLY, SENDER_BOTH, TYPERANGE_UTF8, USE_INITIAL_ONLY); if (!param) - goto out; + goto release_list; /* * Extra parameters for ISER from RFC-5046 @@ -412,25 +412,25 @@ int iscsi_create_default_params(struct iscsi_param_list **param_list_ptr) PHASE_OPERATIONAL, SCOPE_SESSION_WIDE, SENDER_BOTH, TYPERANGE_BOOL_AND, USE_LEADING_ONLY); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, INITIATORRECVDATASEGMENTLENGTH, INITIAL_INITIATORRECVDATASEGMENTLENGTH, PHASE_OPERATIONAL, SCOPE_CONNECTION_ONLY, SENDER_BOTH, TYPERANGE_512_TO_16777215, USE_ALL); if (!param) - goto out; + goto release_list; param = iscsi_set_default_param(pl, TARGETRECVDATASEGMENTLENGTH, INITIAL_TARGETRECVDATASEGMENTLENGTH, PHASE_OPERATIONAL, SCOPE_CONNECTION_ONLY, SENDER_BOTH, TYPERANGE_512_TO_16777215, USE_ALL); if (!param) - goto out; + goto release_list; *param_list_ptr = pl; return 0; -out: +release_list: iscsi_release_param_list(pl); return -1; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 6/7] iscsi-target: Delete unnecessary variable initialisations in iscsi_check_valuelist_for_support() 2015-12-12 14:30 ` SF Markus Elfring @ 2015-12-12 14:43 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-12 14:43 UTC (permalink / raw) To: linux-scsi, target-devel, Nicholas A. Bellinger Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 12 Dec 2015 14:34:26 +0100 The variables "tmp1" and "tmp2" will eventually be set to appropriate pointers from a call of the strchr() function. Thus let us omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/target/iscsi/iscsi_target_parameters.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/target/iscsi/iscsi_target_parameters.c b/drivers/target/iscsi/iscsi_target_parameters.c index 29ecf29..53e3345 100644 --- a/drivers/target/iscsi/iscsi_target_parameters.c +++ b/drivers/target/iscsi/iscsi_target_parameters.c @@ -920,7 +920,7 @@ static char *iscsi_check_valuelist_for_support( struct iscsi_param *param, char *value) { - char *tmp1 = NULL, *tmp2 = NULL; + char *tmp1, *tmp2; char *acceptor_values = NULL, *proposer_values = NULL; acceptor_values = param->value; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 6/7] iscsi-target: Delete unnecessary variable initialisations in iscsi_check_valuelist_for_s @ 2015-12-12 14:43 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-12 14:43 UTC (permalink / raw) To: linux-scsi, target-devel, Nicholas A. Bellinger Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 12 Dec 2015 14:34:26 +0100 The variables "tmp1" and "tmp2" will eventually be set to appropriate pointers from a call of the strchr() function. Thus let us omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/target/iscsi/iscsi_target_parameters.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/target/iscsi/iscsi_target_parameters.c b/drivers/target/iscsi/iscsi_target_parameters.c index 29ecf29..53e3345 100644 --- a/drivers/target/iscsi/iscsi_target_parameters.c +++ b/drivers/target/iscsi/iscsi_target_parameters.c @@ -920,7 +920,7 @@ static char *iscsi_check_valuelist_for_support( struct iscsi_param *param, char *value) { - char *tmp1 = NULL, *tmp2 = NULL; + char *tmp1, *tmp2; char *acceptor_values = NULL, *proposer_values = NULL; acceptor_values = param->value; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 7/7] iscsi-target: Make two variable initialisations a bit more obvious in iscsi_check_valuelist_for_support() 2015-12-12 14:30 ` SF Markus Elfring @ 2015-12-12 14:45 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-12 14:45 UTC (permalink / raw) To: linux-scsi, target-devel, Nicholas A. Bellinger Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 12 Dec 2015 15:04:57 +0100 The variable "acceptor_values" and "proposer_values" were initialized by null pointers and immediately assigned values from input parameters by separate statements. Let us express the desired variable initialisations directly. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/target/iscsi/iscsi_target_parameters.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/target/iscsi/iscsi_target_parameters.c b/drivers/target/iscsi/iscsi_target_parameters.c index 53e3345..fb6fd34 100644 --- a/drivers/target/iscsi/iscsi_target_parameters.c +++ b/drivers/target/iscsi/iscsi_target_parameters.c @@ -921,10 +921,7 @@ static char *iscsi_check_valuelist_for_support( char *value) { char *tmp1, *tmp2; - char *acceptor_values = NULL, *proposer_values = NULL; - - acceptor_values = param->value; - proposer_values = value; + char *acceptor_values = param->value, *proposer_values = value; do { if (!proposer_values) -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 7/7] iscsi-target: Make two variable initialisations a bit more obvious in iscsi_check_valuel @ 2015-12-12 14:45 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-12 14:45 UTC (permalink / raw) To: linux-scsi, target-devel, Nicholas A. Bellinger Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 12 Dec 2015 15:04:57 +0100 The variable "acceptor_values" and "proposer_values" were initialized by null pointers and immediately assigned values from input parameters by separate statements. Let us express the desired variable initialisations directly. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/target/iscsi/iscsi_target_parameters.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/target/iscsi/iscsi_target_parameters.c b/drivers/target/iscsi/iscsi_target_parameters.c index 53e3345..fb6fd34 100644 --- a/drivers/target/iscsi/iscsi_target_parameters.c +++ b/drivers/target/iscsi/iscsi_target_parameters.c @@ -921,10 +921,7 @@ static char *iscsi_check_valuelist_for_support( char *value) { char *tmp1, *tmp2; - char *acceptor_values = NULL, *proposer_values = NULL; - - acceptor_values = param->value; - proposer_values = value; + char *acceptor_values = param->value, *proposer_values = value; do { if (!proposer_values) -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 7/7] iscsi-target: Make two variable initialisations a bit more obvious in iscsi_check_valuelist_for_support() 2015-12-12 14:45 ` [PATCH 7/7] iscsi-target: Make two variable initialisations a bit more obvious in iscsi_check_valuel SF Markus Elfring @ 2015-12-12 17:17 ` walter harms -1 siblings, 0 replies; 3089+ messages in thread From: walter harms @ 2015-12-12 17:17 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-scsi, target-devel, Nicholas A. Bellinger, LKML, kernel-janitors, Julia Lawall Am 12.12.2015 15:45, schrieb SF Markus Elfring: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sat, 12 Dec 2015 15:04:57 +0100 > > The variable "acceptor_values" and "proposer_values" were initialized > by null pointers and immediately assigned values from input parameters > by separate statements. > Let us express the desired variable initialisations directly. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/target/iscsi/iscsi_target_parameters.c | 5 +---- > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/drivers/target/iscsi/iscsi_target_parameters.c b/drivers/target/iscsi/iscsi_target_parameters.c > index 53e3345..fb6fd34 100644 > --- a/drivers/target/iscsi/iscsi_target_parameters.c > +++ b/drivers/target/iscsi/iscsi_target_parameters.c > @@ -921,10 +921,7 @@ static char *iscsi_check_valuelist_for_support( > char *value) > { > char *tmp1, *tmp2; > - char *acceptor_values = NULL, *proposer_values = NULL; > - > - acceptor_values = param->value; > - proposer_values = value; > + char *acceptor_values = param->value, *proposer_values = value; > I do not thing that this is a good idea, i find the first version more readable but you are right the NULL can be removed. just my 2 cents, re, wh > do { > if (!proposer_values) ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 7/7] iscsi-target: Make two variable initialisations a bit more obvious in iscsi_check_va @ 2015-12-12 17:17 ` walter harms 0 siblings, 0 replies; 3089+ messages in thread From: walter harms @ 2015-12-12 17:17 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-scsi, target-devel, Nicholas A. Bellinger, LKML, kernel-janitors, Julia Lawall Am 12.12.2015 15:45, schrieb SF Markus Elfring: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sat, 12 Dec 2015 15:04:57 +0100 > > The variable "acceptor_values" and "proposer_values" were initialized > by null pointers and immediately assigned values from input parameters > by separate statements. > Let us express the desired variable initialisations directly. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/target/iscsi/iscsi_target_parameters.c | 5 +---- > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/drivers/target/iscsi/iscsi_target_parameters.c b/drivers/target/iscsi/iscsi_target_parameters.c > index 53e3345..fb6fd34 100644 > --- a/drivers/target/iscsi/iscsi_target_parameters.c > +++ b/drivers/target/iscsi/iscsi_target_parameters.c > @@ -921,10 +921,7 @@ static char *iscsi_check_valuelist_for_support( > char *value) > { > char *tmp1, *tmp2; > - char *acceptor_values = NULL, *proposer_values = NULL; > - > - acceptor_values = param->value; > - proposer_values = value; > + char *acceptor_values = param->value, *proposer_values = value; > I do not thing that this is a good idea, i find the first version more readable but you are right the NULL can be removed. just my 2 cents, re, wh > do { > if (!proposer_values) ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/7] staging-Lustre: Fine-tuning for some function implementations 2015-12-11 12:08 ` SF Markus Elfring (?) @ 2015-12-13 13:48 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-13 13:48 UTC (permalink / raw) To: Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 13 Dec 2015 14:40:14 +0100 Several update suggestions were taken into account from static source code analysis. Markus Elfring (7): Delete unnecessary goto statements in six functions Rename a jump label for ptlrpc_req_finished() calls Rename a jump label for a kfree(key) call Delete an unnecessary variable initialisation in mgc_process_recover_log() Less checks in mgc_process_recover_log() after error detection A few checks less in mgc_process_recover_log() after error detection Rename a jump label for module_put() calls drivers/staging/lustre/lustre/llite/file.c | 26 ++--- drivers/staging/lustre/lustre/llite/lloop.c | 8 +- drivers/staging/lustre/lustre/llite/namei.c | 13 +-- drivers/staging/lustre/lustre/llite/xattr.c | 20 ++-- drivers/staging/lustre/lustre/mdc/mdc_request.c | 124 ++++++++++----------- drivers/staging/lustre/lustre/mgc/mgc_request.c | 53 ++++----- drivers/staging/lustre/lustre/osc/osc_request.c | 52 ++++----- drivers/staging/lustre/lustre/ptlrpc/llog_client.c | 22 ++-- 8 files changed, 152 insertions(+), 166 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [lustre-devel] [PATCH 0/7] staging-Lustre: Fine-tuning for some function implementations @ 2015-12-13 13:48 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-13 13:48 UTC (permalink / raw) To: lustre-devel From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 13 Dec 2015 14:40:14 +0100 Several update suggestions were taken into account from static source code analysis. Markus Elfring (7): Delete unnecessary goto statements in six functions Rename a jump label for ptlrpc_req_finished() calls Rename a jump label for a kfree(key) call Delete an unnecessary variable initialisation in mgc_process_recover_log() Less checks in mgc_process_recover_log() after error detection A few checks less in mgc_process_recover_log() after error detection Rename a jump label for module_put() calls drivers/staging/lustre/lustre/llite/file.c | 26 ++--- drivers/staging/lustre/lustre/llite/lloop.c | 8 +- drivers/staging/lustre/lustre/llite/namei.c | 13 +-- drivers/staging/lustre/lustre/llite/xattr.c | 20 ++-- drivers/staging/lustre/lustre/mdc/mdc_request.c | 124 ++++++++++----------- drivers/staging/lustre/lustre/mgc/mgc_request.c | 53 ++++----- drivers/staging/lustre/lustre/osc/osc_request.c | 52 ++++----- drivers/staging/lustre/lustre/ptlrpc/llog_client.c | 22 ++-- 8 files changed, 152 insertions(+), 166 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/7] staging-Lustre: Fine-tuning for some function implementations @ 2015-12-13 13:48 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-13 13:48 UTC (permalink / raw) To: Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 13 Dec 2015 14:40:14 +0100 Several update suggestions were taken into account from static source code analysis. Markus Elfring (7): Delete unnecessary goto statements in six functions Rename a jump label for ptlrpc_req_finished() calls Rename a jump label for a kfree(key) call Delete an unnecessary variable initialisation in mgc_process_recover_log() Less checks in mgc_process_recover_log() after error detection A few checks less in mgc_process_recover_log() after error detection Rename a jump label for module_put() calls drivers/staging/lustre/lustre/llite/file.c | 26 ++--- drivers/staging/lustre/lustre/llite/lloop.c | 8 +- drivers/staging/lustre/lustre/llite/namei.c | 13 +-- drivers/staging/lustre/lustre/llite/xattr.c | 20 ++-- drivers/staging/lustre/lustre/mdc/mdc_request.c | 124 ++++++++++----------- drivers/staging/lustre/lustre/mgc/mgc_request.c | 53 ++++----- drivers/staging/lustre/lustre/osc/osc_request.c | 52 ++++----- drivers/staging/lustre/lustre/ptlrpc/llog_client.c | 22 ++-- 8 files changed, 152 insertions(+), 166 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 1/7] staging: lustre: Delete unnecessary goto statements in six functions 2015-12-13 13:48 ` SF Markus Elfring (?) @ 2015-12-13 13:52 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-13 13:52 UTC (permalink / raw) To: Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 13 Dec 2015 09:30:47 +0100 Six goto statements referred to a source code position directly behind them. Thus omit such unnecessary jumps. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/llite/namei.c | 1 - drivers/staging/lustre/lustre/mdc/mdc_request.c | 7 ------- 2 files changed, 8 deletions(-) diff --git a/drivers/staging/lustre/lustre/llite/namei.c b/drivers/staging/lustre/lustre/llite/namei.c index 64db5e8..2113dd4 100644 --- a/drivers/staging/lustre/lustre/llite/namei.c +++ b/drivers/staging/lustre/lustre/llite/namei.c @@ -554,7 +554,6 @@ static struct dentry *ll_lookup_it(struct inode *parent, struct dentry *dentry, retval = NULL; else retval = dentry; - goto out; out: if (req) ptlrpc_req_finished(req); diff --git a/drivers/staging/lustre/lustre/mdc/mdc_request.c b/drivers/staging/lustre/lustre/mdc/mdc_request.c index 294c050..920b1e9 100644 --- a/drivers/staging/lustre/lustre/mdc/mdc_request.c +++ b/drivers/staging/lustre/lustre/mdc/mdc_request.c @@ -1181,7 +1181,6 @@ static int mdc_ioc_hsm_progress(struct obd_export *exp, ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); - goto out; out: ptlrpc_req_finished(req); return rc; @@ -1216,7 +1215,6 @@ static int mdc_ioc_hsm_ct_register(struct obd_import *imp, __u32 archives) ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); - goto out; out: ptlrpc_req_finished(req); return rc; @@ -1282,7 +1280,6 @@ static int mdc_ioc_hsm_ct_unregister(struct obd_import *imp) ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); - goto out; out: ptlrpc_req_finished(req); return rc; @@ -1362,8 +1359,6 @@ static int mdc_ioc_hsm_state_set(struct obd_export *exp, ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); - goto out; - out: ptlrpc_req_finished(req); return rc; @@ -1427,8 +1422,6 @@ static int mdc_ioc_hsm_request(struct obd_export *exp, ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); - goto out; - out: ptlrpc_req_finished(req); return rc; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [lustre-devel] [PATCH 1/7] staging: lustre: Delete unnecessary goto statements in six functions @ 2015-12-13 13:52 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-13 13:52 UTC (permalink / raw) To: lustre-devel From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 13 Dec 2015 09:30:47 +0100 Six goto statements referred to a source code position directly behind them. Thus omit such unnecessary jumps. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/llite/namei.c | 1 - drivers/staging/lustre/lustre/mdc/mdc_request.c | 7 ------- 2 files changed, 8 deletions(-) diff --git a/drivers/staging/lustre/lustre/llite/namei.c b/drivers/staging/lustre/lustre/llite/namei.c index 64db5e8..2113dd4 100644 --- a/drivers/staging/lustre/lustre/llite/namei.c +++ b/drivers/staging/lustre/lustre/llite/namei.c @@ -554,7 +554,6 @@ static struct dentry *ll_lookup_it(struct inode *parent, struct dentry *dentry, retval = NULL; else retval = dentry; - goto out; out: if (req) ptlrpc_req_finished(req); diff --git a/drivers/staging/lustre/lustre/mdc/mdc_request.c b/drivers/staging/lustre/lustre/mdc/mdc_request.c index 294c050..920b1e9 100644 --- a/drivers/staging/lustre/lustre/mdc/mdc_request.c +++ b/drivers/staging/lustre/lustre/mdc/mdc_request.c @@ -1181,7 +1181,6 @@ static int mdc_ioc_hsm_progress(struct obd_export *exp, ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); - goto out; out: ptlrpc_req_finished(req); return rc; @@ -1216,7 +1215,6 @@ static int mdc_ioc_hsm_ct_register(struct obd_import *imp, __u32 archives) ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); - goto out; out: ptlrpc_req_finished(req); return rc; @@ -1282,7 +1280,6 @@ static int mdc_ioc_hsm_ct_unregister(struct obd_import *imp) ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); - goto out; out: ptlrpc_req_finished(req); return rc; @@ -1362,8 +1359,6 @@ static int mdc_ioc_hsm_state_set(struct obd_export *exp, ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); - goto out; - out: ptlrpc_req_finished(req); return rc; @@ -1427,8 +1422,6 @@ static int mdc_ioc_hsm_request(struct obd_export *exp, ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); - goto out; - out: ptlrpc_req_finished(req); return rc; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 1/7] staging: lustre: Delete unnecessary goto statements in six functions @ 2015-12-13 13:52 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-13 13:52 UTC (permalink / raw) To: Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 13 Dec 2015 09:30:47 +0100 Six goto statements referred to a source code position directly behind them. Thus omit such unnecessary jumps. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/llite/namei.c | 1 - drivers/staging/lustre/lustre/mdc/mdc_request.c | 7 ------- 2 files changed, 8 deletions(-) diff --git a/drivers/staging/lustre/lustre/llite/namei.c b/drivers/staging/lustre/lustre/llite/namei.c index 64db5e8..2113dd4 100644 --- a/drivers/staging/lustre/lustre/llite/namei.c +++ b/drivers/staging/lustre/lustre/llite/namei.c @@ -554,7 +554,6 @@ static struct dentry *ll_lookup_it(struct inode *parent, struct dentry *dentry, retval = NULL; else retval = dentry; - goto out; out: if (req) ptlrpc_req_finished(req); diff --git a/drivers/staging/lustre/lustre/mdc/mdc_request.c b/drivers/staging/lustre/lustre/mdc/mdc_request.c index 294c050..920b1e9 100644 --- a/drivers/staging/lustre/lustre/mdc/mdc_request.c +++ b/drivers/staging/lustre/lustre/mdc/mdc_request.c @@ -1181,7 +1181,6 @@ static int mdc_ioc_hsm_progress(struct obd_export *exp, ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); - goto out; out: ptlrpc_req_finished(req); return rc; @@ -1216,7 +1215,6 @@ static int mdc_ioc_hsm_ct_register(struct obd_import *imp, __u32 archives) ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); - goto out; out: ptlrpc_req_finished(req); return rc; @@ -1282,7 +1280,6 @@ static int mdc_ioc_hsm_ct_unregister(struct obd_import *imp) ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); - goto out; out: ptlrpc_req_finished(req); return rc; @@ -1362,8 +1359,6 @@ static int mdc_ioc_hsm_state_set(struct obd_export *exp, ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); - goto out; - out: ptlrpc_req_finished(req); return rc; @@ -1427,8 +1422,6 @@ static int mdc_ioc_hsm_request(struct obd_export *exp, ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); - goto out; - out: ptlrpc_req_finished(req); return rc; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/7] staging: lustre: Delete unnecessary goto statements in six functions 2015-12-13 13:52 ` SF Markus Elfring (?) @ 2015-12-15 14:27 ` Joe Perches -1 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2015-12-15 14:27 UTC (permalink / raw) To: SF Markus Elfring, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel Cc: LKML, kernel-janitors, Julia Lawall On Sun, 2015-12-13 at 14:52 +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 13 Dec 2015 09:30:47 +0100 > > Six goto statements referred to a source code position directly behind them. > Thus omit such unnecessary jumps. I suggest you leave a blank line instead of deleting the goto. > diff --git a/drivers/staging/lustre/lustre/llite/namei.c b/drivers/staging/lustre/lustre/llite/namei.c [] > @@ -554,7 +554,6 @@ static struct dentry *ll_lookup_it(struct inode *parent, struct dentry *dentry, > retval = NULL; > else > retval = dentry; > - goto out; > out: > if (req) > ptlrpc_req_finished(req); etc.,, ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [lustre-devel] [PATCH 1/7] staging: lustre: Delete unnecessary goto statements in six functions @ 2015-12-15 14:27 ` Joe Perches 0 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2015-12-15 14:27 UTC (permalink / raw) To: lustre-devel On Sun, 2015-12-13 at 14:52 +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 13 Dec 2015 09:30:47 +0100 > > Six goto statements referred to a source code position directly behind them. > Thus omit such unnecessary jumps. I suggest you leave a blank line instead of deleting the goto. > diff --git a/drivers/staging/lustre/lustre/llite/namei.c b/drivers/staging/lustre/lustre/llite/namei.c [] > @@ -554,7 +554,6 @@ static struct dentry *ll_lookup_it(struct inode *parent, struct dentry *dentry, > ? retval = NULL; > ? else > ? retval = dentry; > - goto out; > ? out: > ? if (req) > ? ptlrpc_req_finished(req); etc.,, ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/7] staging: lustre: Delete unnecessary goto statements in six functions @ 2015-12-15 14:27 ` Joe Perches 0 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2015-12-15 14:27 UTC (permalink / raw) To: SF Markus Elfring, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel Cc: LKML, kernel-janitors, Julia Lawall On Sun, 2015-12-13 at 14:52 +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 13 Dec 2015 09:30:47 +0100 > > Six goto statements referred to a source code position directly behind them. > Thus omit such unnecessary jumps. I suggest you leave a blank line instead of deleting the goto. > diff --git a/drivers/staging/lustre/lustre/llite/namei.c b/drivers/staging/lustre/lustre/llite/namei.c [] > @@ -554,7 +554,6 @@ static struct dentry *ll_lookup_it(struct inode *parent, struct dentry *dentry, > retval = NULL; > else > retval = dentry; > - goto out; > out: > if (req) > ptlrpc_req_finished(req); etc.,, -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/7] staging: lustre: Delete unnecessary goto statements in six functions 2015-12-15 14:27 ` Joe Perches (?) @ 2015-12-15 14:41 ` Dan Carpenter -1 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2015-12-15 14:41 UTC (permalink / raw) To: Joe Perches Cc: SF Markus Elfring, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel, LKML, kernel-janitors, Julia Lawall On Tue, Dec 15, 2015 at 06:27:56AM -0800, Joe Perches wrote: > On Sun, 2015-12-13 at 14:52 +0100, SF Markus Elfring wrote: > > From: Markus Elfring <elfring@users.sourceforge.net> > > Date: Sun, 13 Dec 2015 09:30:47 +0100 > > > > Six goto statements referred to a source code position directly behind them. > > Thus omit such unnecessary jumps. > > I suggest you leave a blank line instead > of deleting the goto. > What is the point of the little bunny hop? regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [lustre-devel] [PATCH 1/7] staging: lustre: Delete unnecessary goto statements in six functions @ 2015-12-15 14:41 ` Dan Carpenter 0 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2015-12-15 14:41 UTC (permalink / raw) To: lustre-devel On Tue, Dec 15, 2015 at 06:27:56AM -0800, Joe Perches wrote: > On Sun, 2015-12-13 at 14:52 +0100, SF Markus Elfring wrote: > > From: Markus Elfring <elfring@users.sourceforge.net> > > Date: Sun, 13 Dec 2015 09:30:47 +0100 > > > > Six goto statements referred to a source code position directly behind them. > > Thus omit such unnecessary jumps. > > I suggest you leave a blank line instead > of deleting the goto. > What is the point of the little bunny hop? regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/7] staging: lustre: Delete unnecessary goto statements in six functions @ 2015-12-15 14:41 ` Dan Carpenter 0 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2015-12-15 14:41 UTC (permalink / raw) To: Joe Perches Cc: SF Markus Elfring, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel, LKML, kernel-janitors, Julia Lawall On Tue, Dec 15, 2015 at 06:27:56AM -0800, Joe Perches wrote: > On Sun, 2015-12-13 at 14:52 +0100, SF Markus Elfring wrote: > > From: Markus Elfring <elfring@users.sourceforge.net> > > Date: Sun, 13 Dec 2015 09:30:47 +0100 > > > > Six goto statements referred to a source code position directly behind them. > > Thus omit such unnecessary jumps. > > I suggest you leave a blank line instead > of deleting the goto. > What is the point of the little bunny hop? regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/7] staging: lustre: Delete unnecessary goto statements in six functions 2015-12-15 14:41 ` Dan Carpenter (?) @ 2015-12-15 15:02 ` Joe Perches -1 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2015-12-15 15:02 UTC (permalink / raw) To: Dan Carpenter Cc: SF Markus Elfring, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel, LKML, kernel-janitors, Julia Lawall On Tue, 2015-12-15 at 17:41 +0300, Dan Carpenter wrote: > On Tue, Dec 15, 2015 at 06:27:56AM -0800, Joe Perches wrote: > > On Sun, 2015-12-13 at 14:52 +0100, SF Markus Elfring wrote: > > > From: Markus Elfring <elfring@users.sourceforge.net> > > > Date: Sun, 13 Dec 2015 09:30:47 +0100 > > > > > > Six goto statements referred to a source code position directly behind them. > > > Thus omit such unnecessary jumps. > > > > I suggest you leave a blank line instead > > of deleting the goto. > > > > What is the point of the little bunny hop? > > regards, > dan carpenter > -ENOPARSE little bunny hop (though I could have said "just leave a blank line) I think that code blocks are more obvious to read. This is the original code: result = foo(); if (result) goto label; result = bar(); if (result) goto label; result = baz(); if (result) goto label; label: go on... He proposes: result = foo(); if (result) goto label; result = bar(); if (result) goto label; result = baz(); label: go on... I don't find the test->goto label; label: use offensive, but if he does, I think keeping a blank line in place of the test->goto might be better. result = foo(); if (result) goto label; result = bar(); if (result) goto label; result = baz(); label: go on... ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [lustre-devel] [PATCH 1/7] staging: lustre: Delete unnecessary goto statements in six functions @ 2015-12-15 15:02 ` Joe Perches 0 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2015-12-15 15:02 UTC (permalink / raw) To: lustre-devel On Tue, 2015-12-15 at 17:41 +0300, Dan Carpenter wrote: > On Tue, Dec 15, 2015 at 06:27:56AM -0800, Joe Perches wrote: > > On Sun, 2015-12-13 at 14:52 +0100, SF Markus Elfring wrote: > > > From: Markus Elfring <elfring@users.sourceforge.net> > > > Date: Sun, 13 Dec 2015 09:30:47 +0100 > > > > > > Six goto statements referred to a source code position directly behind them. > > > Thus omit such unnecessary jumps. > > > > I suggest you leave a blank line instead > > of deleting the goto. > > > > What is the point of the little bunny hop? > > regards, > dan carpenter > -ENOPARSE little bunny hop (though I could have said "just leave a blank line) I think that code blocks are more obvious to read. This is the original code: result = foo(); if (result) goto label; result = bar(); if (result) goto label; result = baz(); if (result) goto label; label: go on... He proposes: result = foo(); if (result) goto label; result = bar(); if (result) goto label; result = baz(); label: go on... I don't find the test->goto label; label: use offensive, but if he does, I think keeping a blank line in place of the test->goto might be better. result = foo(); if (result) goto label; result = bar(); if (result) goto label; result = baz(); label: go on... ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/7] staging: lustre: Delete unnecessary goto statements in six functions @ 2015-12-15 15:02 ` Joe Perches 0 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2015-12-15 15:02 UTC (permalink / raw) To: Dan Carpenter Cc: SF Markus Elfring, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel, LKML, kernel-janitors, Julia Lawall On Tue, 2015-12-15 at 17:41 +0300, Dan Carpenter wrote: > On Tue, Dec 15, 2015 at 06:27:56AM -0800, Joe Perches wrote: > > On Sun, 2015-12-13 at 14:52 +0100, SF Markus Elfring wrote: > > > From: Markus Elfring <elfring@users.sourceforge.net> > > > Date: Sun, 13 Dec 2015 09:30:47 +0100 > > > > > > Six goto statements referred to a source code position directly behind them. > > > Thus omit such unnecessary jumps. > > > > I suggest you leave a blank line instead > > of deleting the goto. > > > > What is the point of the little bunny hop? > > regards, > dan carpenter > -ENOPARSE little bunny hop (though I could have said "just leave a blank line) I think that code blocks are more obvious to read. This is the original code: result = foo(); if (result) goto label; result = bar(); if (result) goto label; result = baz(); if (result) goto label; label: go on... He proposes: result = foo(); if (result) goto label; result = bar(); if (result) goto label; result = baz(); label: go on... I don't find the test->goto label; label: use offensive, but if he does, I think keeping a blank line in place of the test->goto might be better. result = foo(); if (result) goto label; result = bar(); if (result) goto label; result = baz(); label: go on... ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/7] staging: lustre: Delete unnecessary goto statements in six functions 2015-12-15 15:02 ` Joe Perches (?) @ 2015-12-15 17:48 ` Dan Carpenter -1 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2015-12-15 17:48 UTC (permalink / raw) To: Joe Perches Cc: SF Markus Elfring, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel, LKML, kernel-janitors, Julia Lawall On Tue, Dec 15, 2015 at 07:02:31AM -0800, Joe Perches wrote: > This is the original code: > > result = foo(); > if (result) > goto label; > > result = bar(); > if (result) > goto label; > > result = baz(); > if (result) > goto label; > > label: > go on... > No. There is no test. The original code looks like: result = foo(); if (result) goto out; result = baz(); goto out; out: go on.. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [lustre-devel] [PATCH 1/7] staging: lustre: Delete unnecessary goto statements in six functions @ 2015-12-15 17:48 ` Dan Carpenter 0 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2015-12-15 17:48 UTC (permalink / raw) To: lustre-devel On Tue, Dec 15, 2015 at 07:02:31AM -0800, Joe Perches wrote: > This is the original code: > > result = foo(); > if (result) > goto label; > > result = bar(); > if (result) > goto label; > > result = baz(); > if (result) > goto label; > > label: > go on... > No. There is no test. The original code looks like: result = foo(); if (result) goto out; result = baz(); goto out; out: go on.. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/7] staging: lustre: Delete unnecessary goto statements in six functions @ 2015-12-15 17:48 ` Dan Carpenter 0 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2015-12-15 17:48 UTC (permalink / raw) To: Joe Perches Cc: SF Markus Elfring, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel, LKML, kernel-janitors, Julia Lawall On Tue, Dec 15, 2015 at 07:02:31AM -0800, Joe Perches wrote: > This is the original code: > > result = foo(); > if (result) > goto label; > > result = bar(); > if (result) > goto label; > > result = baz(); > if (result) > goto label; > > label: > go on... > No. There is no test. The original code looks like: result = foo(); if (result) goto out; result = baz(); goto out; out: go on.. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/7] staging: lustre: Delete unnecessary goto statements in six functions 2015-12-15 17:48 ` Dan Carpenter (?) @ 2015-12-15 18:10 ` Joe Perches -1 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2015-12-15 18:10 UTC (permalink / raw) To: Dan Carpenter Cc: SF Markus Elfring, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel, LKML, kernel-janitors, Julia Lawall On Tue, 2015-12-15 at 20:48 +0300, Dan Carpenter wrote: > On Tue, Dec 15, 2015 at 07:02:31AM -0800, Joe Perches wrote: > > This is the original code: > > > > result = foo(); > > if (result) > > goto label; > > > > result = bar(); > > if (result) > > goto label; > > > > result = baz(); > > if (result) > > goto label; > > > > label: > > go on... > > > > No. There is no test. The original code looks like: > > result = foo(); > if (result) > goto out; > result = baz(); > goto out; > out: > go on.. > > regards, > dan carpenter Here is the original code: --------------------- /* Copy hsm_progress struct */ req_hpk = req_capsule_client_get(&req->rq_pill, &RMF_MDS_HSM_PROGRESS); if (req_hpk == NULL) { rc = -EPROTO; goto out; } *req_hpk = *hpk; req_hpk->hpk_errval = lustre_errno_hton(hpk->hpk_errval); ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); goto out; out: ptlrpc_req_finished(req); return rc; } --------------------- I think if the last goto out; is to be removed, then it should be replaced by a blank line. It separates the last operation block from the return. cheers, Joe ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [lustre-devel] [PATCH 1/7] staging: lustre: Delete unnecessary goto statements in six functions @ 2015-12-15 18:10 ` Joe Perches 0 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2015-12-15 18:10 UTC (permalink / raw) To: lustre-devel On Tue, 2015-12-15 at 20:48 +0300, Dan Carpenter wrote: > On Tue, Dec 15, 2015 at 07:02:31AM -0800, Joe Perches wrote: > > This is the original code: > > > > result = foo(); > > if (result) > > goto label; > > > > result = bar(); > > if (result) > > goto label; > > > > result = baz(); > > if (result) > > goto label; > > > > label: > > go on... > > > > No.??There is no test.??The original code looks like: > > result = foo(); > if (result) > goto out; > result = baz(); > goto out; > out: > go on.. > > regards, > dan carpenter Here is the original code: --------------------- /* Copy hsm_progress struct */ req_hpk = req_capsule_client_get(&req->rq_pill, &RMF_MDS_HSM_PROGRESS); if (req_hpk == NULL) { rc = -EPROTO; goto out; } *req_hpk = *hpk; req_hpk->hpk_errval = lustre_errno_hton(hpk->hpk_errval); ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); goto out; out: ptlrpc_req_finished(req); return rc; } --------------------- I think if the last goto out; is to be removed, then it should be replaced by a blank line. It separates the last operation block from the return. cheers, Joe ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/7] staging: lustre: Delete unnecessary goto statements in six functions @ 2015-12-15 18:10 ` Joe Perches 0 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2015-12-15 18:10 UTC (permalink / raw) To: Dan Carpenter Cc: SF Markus Elfring, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel, LKML, kernel-janitors, Julia Lawall On Tue, 2015-12-15 at 20:48 +0300, Dan Carpenter wrote: > On Tue, Dec 15, 2015 at 07:02:31AM -0800, Joe Perches wrote: > > This is the original code: > > > > result = foo(); > > if (result) > > goto label; > > > > result = bar(); > > if (result) > > goto label; > > > > result = baz(); > > if (result) > > goto label; > > > > label: > > go on... > > > > No. There is no test. The original code looks like: > > result = foo(); > if (result) > goto out; > result = baz(); > goto out; > out: > go on.. > > regards, > dan carpenter Here is the original code: --------------------- /* Copy hsm_progress struct */ req_hpk = req_capsule_client_get(&req->rq_pill, &RMF_MDS_HSM_PROGRESS); if (req_hpk = NULL) { rc = -EPROTO; goto out; } *req_hpk = *hpk; req_hpk->hpk_errval = lustre_errno_hton(hpk->hpk_errval); ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); goto out; out: ptlrpc_req_finished(req); return rc; } --------------------- I think if the last goto out; is to be removed, then it should be replaced by a blank line. It separates the last operation block from the return. cheers, Joe -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: staging: lustre: Delete unnecessary goto statements in six functions 2015-12-15 18:10 ` Joe Perches (?) @ 2015-12-15 18:26 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-15 18:26 UTC (permalink / raw) To: Joe Perches Cc: Dan Carpenter, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel, LKML, kernel-janitors, Julia Lawall > rc = mdc_queue_wait(req); > goto out; > out: > ptlrpc_req_finished(req); > return rc; > } > --------------------- > > I think if the last goto out; is to be removed, > then it should be replaced by a blank line. > > It separates the last operation block from the return. Would you like to point a very specific coding style issue out? How often should jump labels preceded with blank lines? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [lustre-devel] staging: lustre: Delete unnecessary goto statements in six functions @ 2015-12-15 18:26 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-15 18:26 UTC (permalink / raw) To: lustre-devel > rc = mdc_queue_wait(req); > goto out; > out: > ptlrpc_req_finished(req); > return rc; > } > --------------------- > > I think if the last goto out; is to be removed, > then it should be replaced by a blank line. > > It separates the last operation block from the return. Would you like to point a very specific coding style issue out? How often should jump labels preceded with blank lines? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: staging: lustre: Delete unnecessary goto statements in six functions @ 2015-12-15 18:26 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-15 18:26 UTC (permalink / raw) To: Joe Perches Cc: Dan Carpenter, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel, LKML, kernel-janitors, Julia Lawall > rc = mdc_queue_wait(req); > goto out; > out: > ptlrpc_req_finished(req); > return rc; > } > --------------------- > > I think if the last goto out; is to be removed, > then it should be replaced by a blank line. > > It separates the last operation block from the return. Would you like to point a very specific coding style issue out? How often should jump labels preceded with blank lines? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: staging: lustre: Delete unnecessary goto statements in six functions 2015-12-15 18:26 ` SF Markus Elfring (?) @ 2015-12-15 18:34 ` Joe Perches -1 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2015-12-15 18:34 UTC (permalink / raw) To: SF Markus Elfring Cc: Dan Carpenter, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel, LKML, kernel-janitors, Julia Lawall On Tue, 2015-12-15 at 19:26 +0100, SF Markus Elfring wrote: > > rc = mdc_queue_wait(req); > > goto out; > > out: > > ptlrpc_req_finished(req); > > return rc; > > } > > --------------------- > > > > I think if the last goto out; is to be removed, > > then it should be replaced by a blank line. > > > > It separates the last operation block from the return. > > Would you like to point a very specific coding style issue out? Other than using vertical separation can help readability? I think there should _not_ be a hardened rule. Style is just a guide. Do what you think appropriate. > How often should jump labels preceded with blank lines? When other nearby blocks are also separated by blank lines. Localized consistency can be useful. Inconsistency can make code harder to follow/predict. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [lustre-devel] staging: lustre: Delete unnecessary goto statements in six functions @ 2015-12-15 18:34 ` Joe Perches 0 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2015-12-15 18:34 UTC (permalink / raw) To: lustre-devel On Tue, 2015-12-15 at 19:26 +0100, SF Markus Elfring wrote: > > rc = mdc_queue_wait(req); > > goto out; > > out: > > ptlrpc_req_finished(req); > > return rc; > > } > > --------------------- > > > > I think if the last goto out; is to be removed, > > then it should be replaced by a blank line. > > > > It separates the last operation block from the return. > > Would you like to point a very specific coding style issue out? Other than using vertical separation can help readability? I think there should _not_ be a hardened rule. Style is just a guide. ?Do what you think appropriate. > How often should jump labels preceded with blank lines? When other nearby blocks are also separated by blank lines. Localized consistency can be useful. Inconsistency can make code harder to follow/predict. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: staging: lustre: Delete unnecessary goto statements in six functions @ 2015-12-15 18:34 ` Joe Perches 0 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2015-12-15 18:34 UTC (permalink / raw) To: SF Markus Elfring Cc: Dan Carpenter, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel, LKML, kernel-janitors, Julia Lawall On Tue, 2015-12-15 at 19:26 +0100, SF Markus Elfring wrote: > > rc = mdc_queue_wait(req); > > goto out; > > out: > > ptlrpc_req_finished(req); > > return rc; > > } > > --------------------- > > > > I think if the last goto out; is to be removed, > > then it should be replaced by a blank line. > > > > It separates the last operation block from the return. > > Would you like to point a very specific coding style issue out? Other than using vertical separation can help readability? I think there should _not_ be a hardened rule. Style is just a guide. Do what you think appropriate. > How often should jump labels preceded with blank lines? When other nearby blocks are also separated by blank lines. Localized consistency can be useful. Inconsistency can make code harder to follow/predict. -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: staging: lustre: Delete unnecessary goto statements in six functions 2015-12-15 18:34 ` Joe Perches (?) @ 2015-12-15 18:49 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-15 18:49 UTC (permalink / raw) To: Joe Perches Cc: Dan Carpenter, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel, LKML, kernel-janitors, Julia Lawall > I think there should _not_ be a hardened rule. I guess that it can become hard to achieve consensus on a precise rule. > Style is just a guide. Generally nice … > Do what you think appropriate. I'm sorry for my evolving understanding. - But I imagine that your feedback can cause further software development troubles if the acceptance for this update suggestion will really depend on the number of blank lines before a jump label. Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [lustre-devel] staging: lustre: Delete unnecessary goto statements in six functions @ 2015-12-15 18:49 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-15 18:49 UTC (permalink / raw) To: lustre-devel > I think there should _not_ be a hardened rule. I guess that it can become hard to achieve consensus on a precise rule. > Style is just a guide. Generally nice ? > Do what you think appropriate. I'm sorry for my evolving understanding. - But I imagine that your feedback can cause further software development troubles if the acceptance for this update suggestion will really depend on the number of blank lines before a jump label. Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: staging: lustre: Delete unnecessary goto statements in six functions @ 2015-12-15 18:49 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-15 18:49 UTC (permalink / raw) To: Joe Perches Cc: Dan Carpenter, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel, LKML, kernel-janitors, Julia Lawall > I think there should _not_ be a hardened rule. I guess that it can become hard to achieve consensus on a precise rule. > Style is just a guide. Generally nice … > Do what you think appropriate. I'm sorry for my evolving understanding. - But I imagine that your feedback can cause further software development troubles if the acceptance for this update suggestion will really depend on the number of blank lines before a jump label. Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: staging: lustre: Delete unnecessary goto statements in six functions 2015-12-15 18:49 ` SF Markus Elfring (?) @ 2015-12-15 18:55 ` Joe Perches -1 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2015-12-15 18:55 UTC (permalink / raw) To: SF Markus Elfring Cc: Dan Carpenter, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel, LKML, kernel-janitors, Julia Lawall On Tue, 2015-12-15 at 19:49 +0100, SF Markus Elfring wrote: > > I think there should _not_ be a hardened rule. > I guess that it can become hard to achieve consensus on a precise rule. Consensus isn't unanimity. > I imagine that your feedback > can cause further software development troubles if the acceptance for > this update suggestion will really depend on the number of blank lines > before a jump label. <shrug> The author of any particular bit of code can do whatever they want. Localized consistency is probably more valuable than global consistency. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [lustre-devel] staging: lustre: Delete unnecessary goto statements in six functions @ 2015-12-15 18:55 ` Joe Perches 0 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2015-12-15 18:55 UTC (permalink / raw) To: lustre-devel On Tue, 2015-12-15 at 19:49 +0100, SF Markus Elfring wrote: > > I think there should _not_ be a hardened rule. > I guess that it can become hard to achieve consensus on a precise rule. Consensus isn't unanimity. > I imagine that your feedback > can cause further software development troubles if the acceptance for > this update suggestion will really depend on the number of blank lines > before a jump label. <shrug> The author of any particular bit of code can do whatever they want. Localized consistency is probably more valuable than global consistency. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: staging: lustre: Delete unnecessary goto statements in six functions @ 2015-12-15 18:55 ` Joe Perches 0 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2015-12-15 18:55 UTC (permalink / raw) To: SF Markus Elfring Cc: Dan Carpenter, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel, LKML, kernel-janitors, Julia Lawall On Tue, 2015-12-15 at 19:49 +0100, SF Markus Elfring wrote: > > I think there should _not_ be a hardened rule. > I guess that it can become hard to achieve consensus on a precise rule. Consensus isn't unanimity. > I imagine that your feedback > can cause further software development troubles if the acceptance for > this update suggestion will really depend on the number of blank lines > before a jump label. <shrug> The author of any particular bit of code can do whatever they want. Localized consistency is probably more valuable than global consistency. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: staging: lustre: Delete unnecessary goto statements in six functions 2015-12-15 15:02 ` Joe Perches (?) @ 2015-12-15 18:02 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-15 18:02 UTC (permalink / raw) To: Joe Perches, Dan Carpenter Cc: Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel, LKML, kernel-janitors, Julia Lawall > This is the original code: Really …? > result = baz(); > if (result) > goto label; > > label: > go on... I do not see such a source code structure at the six places I propose to clean-up. > I don't find the test->goto label; label: use offensive, > but if he does, I think keeping a blank line in place of > the test->goto might be better. I find this an interesting view on source code layout. Are there any more opinions around such implementation details? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [lustre-devel] staging: lustre: Delete unnecessary goto statements in six functions @ 2015-12-15 18:02 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-15 18:02 UTC (permalink / raw) To: lustre-devel > This is the original code: Really ?? > result = baz(); > if (result) > goto label; > > label: > go on... I do not see such a source code structure at the six places I propose to clean-up. > I don't find the test->goto label; label: use offensive, > but if he does, I think keeping a blank line in place of > the test->goto might be better. I find this an interesting view on source code layout. Are there any more opinions around such implementation details? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: staging: lustre: Delete unnecessary goto statements in six functions @ 2015-12-15 18:02 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-15 18:02 UTC (permalink / raw) To: Joe Perches, Dan Carpenter Cc: Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel, LKML, kernel-janitors, Julia Lawall > This is the original code: Really …? > result = baz(); > if (result) > goto label; > > label: > go on... I do not see such a source code structure at the six places I propose to clean-up. > I don't find the test->goto label; label: use offensive, > but if he does, I think keeping a blank line in place of > the test->goto might be better. I find this an interesting view on source code layout. Are there any more opinions around such implementation details? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: staging: lustre: Delete unnecessary goto statements in six functions 2015-12-15 18:02 ` SF Markus Elfring (?) @ 2015-12-15 18:22 ` Joe Perches -1 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2015-12-15 18:22 UTC (permalink / raw) To: SF Markus Elfring, Dan Carpenter Cc: Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel, LKML, kernel-janitors, Julia Lawall On Tue, 2015-12-15 at 19:02 +0100, SF Markus Elfring wrote: > > This is the original code: > Really …? > > result = baz(); > > if (result) > > goto label; > > > > label: > > go on... > > I do not see such a source code structure > at the six places I propose to clean-up. > > > > I don't find the test->goto label; label: use offensive, > > but if he does, I think keeping a blank line in place of > > the test->goto might be better. > > I find this an interesting view on source code layout. > Are there any more opinions around such implementation details? Or to put it another way, use a blank line before the first or only label in an error/out block. I don't find it different then commonly written blocks like: void foo(void) { ...; wind1(); val = func1(...); if (val) { printk(...); goto err_type; } wind2(); val = func2(...); if (val) { printk(...); goto err_type2; } ... return 0; err_type2: unwind2(); err_type: unwind1(); return -ERR; } Yes, you can elide all the blank lines, but using them can help readability. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [lustre-devel] staging: lustre: Delete unnecessary goto statements in six functions @ 2015-12-15 18:22 ` Joe Perches 0 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2015-12-15 18:22 UTC (permalink / raw) To: lustre-devel On Tue, 2015-12-15 at 19:02 +0100, SF Markus Elfring wrote: > > This is the original code: > Really ?? > > result = baz(); > > if (result) > > goto label; > > > > label: > > go on... > > I do not see such a source code structure > at the six places I propose to clean-up. > > > > I don't find the test->goto label; label: use offensive, > > but if he does, I think keeping a blank line in place of > > the test->goto might be better. > > I find this an interesting view on source code layout. > Are there any more opinions around such implementation details? Or to put it another way, use a blank line before the first or only label in an error/out block. I don't find it different then commonly written blocks like: void foo(void) { ...; wind1(); val = func1(...); if (val) { printk(...); goto err_type; } wind2(); val = func2(...); if (val) { printk(...); goto err_type2; } ... return 0; err_type2: unwind2(); err_type: unwind1(); return -ERR; } Yes, you can elide all the blank lines, but using them can help readability. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: staging: lustre: Delete unnecessary goto statements in six functions @ 2015-12-15 18:22 ` Joe Perches 0 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2015-12-15 18:22 UTC (permalink / raw) To: SF Markus Elfring, Dan Carpenter Cc: Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel, LKML, kernel-janitors, Julia Lawall On Tue, 2015-12-15 at 19:02 +0100, SF Markus Elfring wrote: > > This is the original code: > Really …? > > result = baz(); > > if (result) > > goto label; > > > > label: > > go on... > > I do not see such a source code structure > at the six places I propose to clean-up. > > > > I don't find the test->goto label; label: use offensive, > > but if he does, I think keeping a blank line in place of > > the test->goto might be better. > > I find this an interesting view on source code layout. > Are there any more opinions around such implementation details? Or to put it another way, use a blank line before the first or only label in an error/out block. I don't find it different then commonly written blocks like: void foo(void) { ...; wind1(); val = func1(...); if (val) { printk(...); goto err_type; } wind2(); val = func2(...); if (val) { printk(...); goto err_type2; } ... return 0; err_type2: unwind2(); err_type: unwind1(); return -ERR; } Yes, you can elide all the blank lines, but using them can help readability. -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 2/7] staging: lustre: Rename a jump label for ptlrpc_req_finished() calls 2015-12-13 13:48 ` SF Markus Elfring (?) @ 2015-12-13 13:54 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-13 13:54 UTC (permalink / raw) To: Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 13 Dec 2015 10:33:38 +0100 This issue was detected by using the Coccinelle software. Choose a jump label according to the current Linux coding style convention. I suggest to improve this implementation detail by the reuse of a script like the following for the semantic patch language. @rename_jump_label exists@ identifier work; type return_type; @@ return_type work(...) { ... when any goto -out +finish_request ; ... when any -out +finish_request : ptlrpc_req_finished(...); ... when any } Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/llite/file.c | 26 +++++------ drivers/staging/lustre/lustre/llite/namei.c | 12 ++--- drivers/staging/lustre/lustre/llite/xattr.c | 20 ++++---- drivers/staging/lustre/lustre/mdc/mdc_request.c | 54 +++++++++++----------- drivers/staging/lustre/lustre/osc/osc_request.c | 28 +++++------ drivers/staging/lustre/lustre/ptlrpc/llog_client.c | 22 ++++----- 6 files changed, 81 insertions(+), 81 deletions(-) diff --git a/drivers/staging/lustre/lustre/llite/file.c b/drivers/staging/lustre/lustre/llite/file.c index 31cd6b3..b94df54 100644 --- a/drivers/staging/lustre/lustre/llite/file.c +++ b/drivers/staging/lustre/lustre/llite/file.c @@ -427,27 +427,27 @@ static int ll_intent_file_open(struct dentry *dentry, void *lmm, */ if (!it_disposition(itp, DISP_OPEN_OPEN) || it_open_error(DISP_OPEN_OPEN, itp)) - goto out; + goto finish_request; ll_release_openhandle(inode, itp); - goto out; + goto finish_request; } if (it_disposition(itp, DISP_LOOKUP_NEG)) { rc = -ENOENT; - goto out; + goto finish_request; } if (rc != 0 || it_open_error(DISP_OPEN_OPEN, itp)) { rc = rc ? rc : it_open_error(DISP_OPEN_OPEN, itp); CDEBUG(D_VFSTRACE, "lock enqueue: err: %d\n", rc); - goto out; + goto finish_request; } rc = ll_prep_inode(&inode, req, NULL, itp); if (!rc && itp->d.lustre.it_lock_mode) ll_set_lock_data(sbi->ll_md_exp, inode, itp, NULL); -out: +finish_request: ptlrpc_req_finished(req); ll_intent_drop_lock(itp); @@ -2900,13 +2900,13 @@ static int __ll_inode_revalidate(struct dentry *dentry, __u64 ibits) oit.it_create_mode &= ~M_CHECK_STALE; if (rc < 0) { rc = ll_inode_revalidate_fini(inode, rc); - goto out; + goto finish_request; } rc = ll_revalidate_it_finish(req, &oit, inode); if (rc != 0) { ll_intent_release(&oit); - goto out; + goto finish_request; } /* Unlinked? Unhash dentry, so it is not picked up later by @@ -2946,7 +2946,7 @@ static int __ll_inode_revalidate(struct dentry *dentry, __u64 ibits) rc = ll_prep_inode(&inode, req, NULL, NULL); } -out: +finish_request: ptlrpc_req_finished(req); return rc; } @@ -3315,25 +3315,25 @@ static int ll_layout_fetch(struct inode *inode, struct ldlm_lock *lock) body = req_capsule_server_get(&req->rq_pill, &RMF_MDT_BODY); if (body == NULL) { rc = -EPROTO; - goto out; + goto finish_request; } lmmsize = body->eadatasize; if (lmmsize == 0) /* empty layout */ { rc = 0; - goto out; + goto finish_request; } lmm = req_capsule_server_sized_get(&req->rq_pill, &RMF_EADATA, lmmsize); if (lmm == NULL) { rc = -EFAULT; - goto out; + goto finish_request; } lvbdata = libcfs_kvzalloc(lmmsize, GFP_NOFS); if (lvbdata == NULL) { rc = -ENOMEM; - goto out; + goto finish_request; } memcpy(lvbdata, lmm, lmmsize); @@ -3345,7 +3345,7 @@ static int ll_layout_fetch(struct inode *inode, struct ldlm_lock *lock) lock->l_lvb_len = lmmsize; unlock_res_and_lock(lock); -out: +finish_request: ptlrpc_req_finished(req); return rc; } diff --git a/drivers/staging/lustre/lustre/llite/namei.c b/drivers/staging/lustre/lustre/llite/namei.c index 2113dd4..7501f70 100644 --- a/drivers/staging/lustre/lustre/llite/namei.c +++ b/drivers/staging/lustre/lustre/llite/namei.c @@ -686,7 +686,7 @@ static struct inode *ll_create_node(struct inode *dir, struct lookup_intent *it) rc = ll_prep_inode(&inode, request, dir->i_sb, it); if (rc) { inode = ERR_PTR(rc); - goto out; + goto finish_request; } LASSERT(hlist_empty(&inode->i_dentry)); @@ -697,7 +697,7 @@ static struct inode *ll_create_node(struct inode *dir, struct lookup_intent *it) CDEBUG(D_DLMTRACE, "setting l_ast_data to inode %p (%lu/%u)\n", inode, inode->i_ino, inode->i_generation); ll_set_lock_data(sbi->ll_md_exp, inode, it, NULL); - out: + finish_request: ptlrpc_req_finished(request); return inode; } @@ -960,13 +960,13 @@ static int ll_unlink(struct inode *dir, struct dentry *dentry) rc = md_unlink(ll_i2sbi(dir)->ll_md_exp, op_data, &request); ll_finish_md_op_data(op_data); if (rc) - goto out; + goto finish_request; ll_update_times(request, dir); ll_stats_ops_tally(ll_i2sbi(dir), LPROC_LL_UNLINK, 1); rc = ll_objects_destroy(request, dir); - out: + finish_request: ptlrpc_req_finished(request); return rc; } @@ -1059,11 +1059,11 @@ static int ll_link(struct dentry *old_dentry, struct inode *dir, err = md_link(sbi->ll_md_exp, op_data, &request); ll_finish_md_op_data(op_data); if (err) - goto out; + goto finish_request; ll_update_times(request, dir); ll_stats_ops_tally(sbi, LPROC_LL_LINK, 1); -out: +finish_request: ptlrpc_req_finished(request); return err; } diff --git a/drivers/staging/lustre/lustre/llite/xattr.c b/drivers/staging/lustre/lustre/llite/xattr.c index 660b8ac..8d3287c 100644 --- a/drivers/staging/lustre/lustre/llite/xattr.c +++ b/drivers/staging/lustre/lustre/llite/xattr.c @@ -390,19 +390,19 @@ getxattr_nocache: /* only detect the xattr size */ if (size == 0) { rc = body->eadatasize; - goto out; + goto finish_request; } if (size < body->eadatasize) { CERROR("server bug: replied size %u > %u\n", body->eadatasize, (int)size); rc = -ERANGE; - goto out; + goto finish_request; } if (body->eadatasize == 0) { rc = -ENODATA; - goto out; + goto finish_request; } /* do not need swab xattr data */ @@ -410,7 +410,7 @@ getxattr_nocache: body->eadatasize); if (!xdata) { rc = -EFAULT; - goto out; + goto finish_request; } memcpy(buffer, xdata, body->eadatasize); @@ -425,14 +425,14 @@ getxattr_nocache: (posix_acl_xattr_header *)buffer, rc); if (IS_ERR(acl)) { rc = PTR_ERR(acl); - goto out; + goto finish_request; } rc = ee_add(&sbi->ll_et, current_pid(), ll_inode2fid(inode), xattr_type, acl); if (unlikely(rc < 0)) { lustre_ext_acl_xattr_free(acl); - goto out; + goto finish_request; } } #endif @@ -444,7 +444,7 @@ out_xattr: ll_get_fsname(inode->i_sb, NULL, 0), rc); sbi->ll_flags &= ~LL_SBI_USER_XATTR; } -out: +finish_request: ptlrpc_req_finished(req); return rc; } @@ -555,7 +555,7 @@ ssize_t ll_listxattr(struct dentry *dentry, char *buffer, size_t size) rc = ll_getxattr_common(inode, NULL, buffer, size, OBD_MD_FLXATTRLS); if (rc < 0) - goto out; + goto finish_request; if (buffer != NULL) { struct ll_sb_info *sbi = ll_i2sbi(inode); @@ -589,7 +589,7 @@ ssize_t ll_listxattr(struct dentry *dentry, char *buffer, size_t size) if (rc2 < 0) { rc2 = 0; - goto out; + goto finish_request; } else if (S_ISREG(inode->i_mode) || S_ISDIR(inode->i_mode)) { const int prefix_len = sizeof(XATTR_LUSTRE_PREFIX) - 1; const size_t name_len = sizeof("lov") - 1; @@ -608,7 +608,7 @@ ssize_t ll_listxattr(struct dentry *dentry, char *buffer, size_t size) } rc2 = total_len; } -out: +finish_request: ptlrpc_req_finished(request); rc = rc + rc2; diff --git a/drivers/staging/lustre/lustre/mdc/mdc_request.c b/drivers/staging/lustre/lustre/mdc/mdc_request.c index 920b1e9..2a76685 100644 --- a/drivers/staging/lustre/lustre/mdc/mdc_request.c +++ b/drivers/staging/lustre/lustre/mdc/mdc_request.c @@ -92,12 +92,12 @@ static int mdc_getstatus(struct obd_export *exp, struct lu_fid *rootfid) rc = ptlrpc_queue_wait(req); if (rc) - goto out; + goto finish_request; body = req_capsule_server_get(&req->rq_pill, &RMF_MDT_BODY); if (body == NULL) { rc = -EPROTO; - goto out; + goto finish_request; } *rootfid = body->fid1; @@ -105,7 +105,7 @@ static int mdc_getstatus(struct obd_export *exp, struct lu_fid *rootfid) "root fid="DFID", last_committed=%llu\n", PFID(rootfid), lustre_msg_get_last_committed(req->rq_repmsg)); -out: +finish_request: ptlrpc_req_finished(req); return rc; } @@ -1084,17 +1084,17 @@ static int mdc_statfs(const struct lu_env *env, /* check connection error first */ if (imp->imp_connect_error) rc = imp->imp_connect_error; - goto out; + goto finish_request; } msfs = req_capsule_server_get(&req->rq_pill, &RMF_OBD_STATFS); if (msfs == NULL) { rc = -EPROTO; - goto out; + goto finish_request; } *osfs = *msfs; -out: +finish_request: ptlrpc_req_finished(req); output: class_import_put(imp); @@ -1163,7 +1163,7 @@ static int mdc_ioc_hsm_progress(struct obd_export *exp, LUSTRE_MDS_VERSION, MDS_HSM_PROGRESS); if (req == NULL) { rc = -ENOMEM; - goto out; + goto finish_request; } mdc_pack_body(req, NULL, OBD_MD_FLRMTPERM, 0, 0, 0); @@ -1172,7 +1172,7 @@ static int mdc_ioc_hsm_progress(struct obd_export *exp, req_hpk = req_capsule_client_get(&req->rq_pill, &RMF_MDS_HSM_PROGRESS); if (req_hpk == NULL) { rc = -EPROTO; - goto out; + goto finish_request; } *req_hpk = *hpk; @@ -1181,7 +1181,7 @@ static int mdc_ioc_hsm_progress(struct obd_export *exp, ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); -out: +finish_request: ptlrpc_req_finished(req); return rc; } @@ -1197,7 +1197,7 @@ static int mdc_ioc_hsm_ct_register(struct obd_import *imp, __u32 archives) MDS_HSM_CT_REGISTER); if (req == NULL) { rc = -ENOMEM; - goto out; + goto finish_request; } mdc_pack_body(req, NULL, OBD_MD_FLRMTPERM, 0, 0, 0); @@ -1207,7 +1207,7 @@ static int mdc_ioc_hsm_ct_register(struct obd_import *imp, __u32 archives) &RMF_MDS_HSM_ARCHIVE); if (archive_mask == NULL) { rc = -EPROTO; - goto out; + goto finish_request; } *archive_mask = archives; @@ -1215,7 +1215,7 @@ static int mdc_ioc_hsm_ct_register(struct obd_import *imp, __u32 archives) ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); -out: +finish_request: ptlrpc_req_finished(req); return rc; } @@ -1246,18 +1246,18 @@ static int mdc_ioc_hsm_current_action(struct obd_export *exp, rc = mdc_queue_wait(req); if (rc) - goto out; + goto finish_request; req_hca = req_capsule_server_get(&req->rq_pill, &RMF_MDS_HSM_CURRENT_ACTION); if (req_hca == NULL) { rc = -EPROTO; - goto out; + goto finish_request; } *hca = *req_hca; -out: +finish_request: ptlrpc_req_finished(req); return rc; } @@ -1272,7 +1272,7 @@ static int mdc_ioc_hsm_ct_unregister(struct obd_import *imp) MDS_HSM_CT_UNREGISTER); if (req == NULL) { rc = -ENOMEM; - goto out; + goto finish_request; } mdc_pack_body(req, NULL, OBD_MD_FLRMTPERM, 0, 0, 0); @@ -1280,7 +1280,7 @@ static int mdc_ioc_hsm_ct_unregister(struct obd_import *imp) ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); -out: +finish_request: ptlrpc_req_finished(req); return rc; } @@ -1311,17 +1311,17 @@ static int mdc_ioc_hsm_state_get(struct obd_export *exp, rc = mdc_queue_wait(req); if (rc) - goto out; + goto finish_request; req_hus = req_capsule_server_get(&req->rq_pill, &RMF_HSM_USER_STATE); if (req_hus == NULL) { rc = -EPROTO; - goto out; + goto finish_request; } *hus = *req_hus; -out: +finish_request: ptlrpc_req_finished(req); return rc; } @@ -1352,14 +1352,14 @@ static int mdc_ioc_hsm_state_set(struct obd_export *exp, req_hss = req_capsule_client_get(&req->rq_pill, &RMF_HSM_STATE_SET); if (req_hss == NULL) { rc = -EPROTO; - goto out; + goto finish_request; } *req_hss = *hss; ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); -out: +finish_request: ptlrpc_req_finished(req); return rc; } @@ -1377,7 +1377,7 @@ static int mdc_ioc_hsm_request(struct obd_export *exp, req = ptlrpc_request_alloc(imp, &RQF_MDS_HSM_REQUEST); if (req == NULL) { rc = -ENOMEM; - goto out; + goto finish_request; } req_capsule_set_size(&req->rq_pill, &RMF_MDS_HSM_USER_ITEM, RCL_CLIENT, @@ -1398,7 +1398,7 @@ static int mdc_ioc_hsm_request(struct obd_export *exp, req_hr = req_capsule_client_get(&req->rq_pill, &RMF_MDS_HSM_REQUEST); if (req_hr == NULL) { rc = -EPROTO; - goto out; + goto finish_request; } *req_hr = hur->hur_request; @@ -1406,7 +1406,7 @@ static int mdc_ioc_hsm_request(struct obd_export *exp, req_hui = req_capsule_client_get(&req->rq_pill, &RMF_MDS_HSM_USER_ITEM); if (req_hui == NULL) { rc = -EPROTO; - goto out; + goto finish_request; } memcpy(req_hui, hur->hur_user_item, hur->hur_request.hr_itemcount * sizeof(struct hsm_user_item)); @@ -1415,14 +1415,14 @@ static int mdc_ioc_hsm_request(struct obd_export *exp, req_opaque = req_capsule_client_get(&req->rq_pill, &RMF_GENERIC_DATA); if (req_opaque == NULL) { rc = -EPROTO; - goto out; + goto finish_request; } memcpy(req_opaque, hur_data(hur), hur->hur_request.hr_data_len); ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); -out: +finish_request: ptlrpc_req_finished(req); return rc; } diff --git a/drivers/staging/lustre/lustre/osc/osc_request.c b/drivers/staging/lustre/lustre/osc/osc_request.c index d6c1447..3a56fb7 100644 --- a/drivers/staging/lustre/lustre/osc/osc_request.c +++ b/drivers/staging/lustre/lustre/osc/osc_request.c @@ -291,12 +291,12 @@ static int osc_getattr(const struct lu_env *env, struct obd_export *exp, rc = ptlrpc_queue_wait(req); if (rc) - goto out; + goto finish_request; body = req_capsule_server_get(&req->rq_pill, &RMF_OST_BODY); if (body == NULL) { rc = -EPROTO; - goto out; + goto finish_request; } CDEBUG(D_INODE, "mode: %o\n", body->oa.o_mode); @@ -306,7 +306,7 @@ static int osc_getattr(const struct lu_env *env, struct obd_export *exp, oinfo->oi_oa->o_blksize = cli_brw_size(exp->exp_obd); oinfo->oi_oa->o_valid |= OBD_MD_FLBLKSZ; - out: + finish_request: ptlrpc_req_finished(req); return rc; } @@ -336,18 +336,18 @@ static int osc_setattr(const struct lu_env *env, struct obd_export *exp, rc = ptlrpc_queue_wait(req); if (rc) - goto out; + goto finish_request; body = req_capsule_server_get(&req->rq_pill, &RMF_OST_BODY); if (body == NULL) { rc = -EPROTO; - goto out; + goto finish_request; } lustre_get_wire_obdo(&req->rq_import->imp_connect_data, oinfo->oi_oa, &body->oa); -out: +finish_request: ptlrpc_req_finished(req); return rc; } @@ -1276,7 +1276,7 @@ static int osc_brw_prep_request(int cmd, struct client_obd *cli, if (desc == NULL) { rc = -ENOMEM; - goto out; + goto finish_request; } /* NB request now owns desc and will free it when it gets freed */ @@ -1407,7 +1407,7 @@ static int osc_brw_prep_request(int cmd, struct client_obd *cli, *reqp = req; return 0; - out: + finish_request: ptlrpc_req_finished(req); return rc; } @@ -2513,17 +2513,17 @@ static int osc_statfs(const struct lu_env *env, struct obd_export *exp, rc = ptlrpc_queue_wait(req); if (rc) - goto out; + goto finish_request; msfs = req_capsule_server_get(&req->rq_pill, &RMF_OBD_STATFS); if (msfs == NULL) { rc = -EPROTO; - goto out; + goto finish_request; } *osfs = *msfs; - out: + finish_request: ptlrpc_req_finished(req); return rc; } @@ -2718,16 +2718,16 @@ static int osc_get_info(const struct lu_env *env, struct obd_export *exp, ptlrpc_request_set_replen(req); rc = ptlrpc_queue_wait(req); if (rc) - goto out; + goto finish_request; reply = req_capsule_server_get(&req->rq_pill, &RMF_OBD_ID); if (reply == NULL) { rc = -EPROTO; - goto out; + goto finish_request; } *((u64 *)val) = *reply; - out: + finish_request: ptlrpc_req_finished(req); return rc; } else if (KEY_IS(KEY_FIEMAP)) { diff --git a/drivers/staging/lustre/lustre/ptlrpc/llog_client.c b/drivers/staging/lustre/lustre/ptlrpc/llog_client.c index 5122205..150d2ec 100644 --- a/drivers/staging/lustre/lustre/ptlrpc/llog_client.c +++ b/drivers/staging/lustre/lustre/ptlrpc/llog_client.c @@ -176,26 +176,26 @@ static int llog_client_next_block(const struct lu_env *env, ptlrpc_request_set_replen(req); rc = ptlrpc_queue_wait(req); if (rc) - goto out; + goto finish_request; body = req_capsule_server_get(&req->rq_pill, &RMF_LLOGD_BODY); if (body == NULL) { rc = -EFAULT; - goto out; + goto finish_request; } /* The log records are swabbed as they are processed */ ptr = req_capsule_server_get(&req->rq_pill, &RMF_EADATA); if (ptr == NULL) { rc = -EFAULT; - goto out; + goto finish_request; } *cur_idx = body->lgd_saved_index; *cur_offset = body->lgd_cur_offset; memcpy(buf, ptr, len); -out: +finish_request: ptlrpc_req_finished(req); err_exit: LLOG_CLIENT_EXIT(loghandle->lgh_ctxt, imp); @@ -233,22 +233,22 @@ static int llog_client_prev_block(const struct lu_env *env, rc = ptlrpc_queue_wait(req); if (rc) - goto out; + goto finish_request; body = req_capsule_server_get(&req->rq_pill, &RMF_LLOGD_BODY); if (body == NULL) { rc = -EFAULT; - goto out; + goto finish_request; } ptr = req_capsule_server_get(&req->rq_pill, &RMF_EADATA); if (ptr == NULL) { rc = -EFAULT; - goto out; + goto finish_request; } memcpy(buf, ptr, len); -out: +finish_request: ptlrpc_req_finished(req); err_exit: LLOG_CLIENT_EXIT(loghandle->lgh_ctxt, imp); @@ -282,12 +282,12 @@ static int llog_client_read_header(const struct lu_env *env, ptlrpc_request_set_replen(req); rc = ptlrpc_queue_wait(req); if (rc) - goto out; + goto finish_request; hdr = req_capsule_server_get(&req->rq_pill, &RMF_LLOG_LOG_HDR); if (hdr == NULL) { rc = -EFAULT; - goto out; + goto finish_request; } memcpy(handle->lgh_hdr, hdr, sizeof(*hdr)); @@ -305,7 +305,7 @@ static int llog_client_read_header(const struct lu_env *env, CERROR("you may need to re-run lconf --write_conf.\n"); rc = -EIO; } -out: +finish_request: ptlrpc_req_finished(req); err_exit: LLOG_CLIENT_EXIT(handle->lgh_ctxt, imp); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [lustre-devel] [PATCH 2/7] staging: lustre: Rename a jump label for ptlrpc_req_finished() calls @ 2015-12-13 13:54 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-13 13:54 UTC (permalink / raw) To: lustre-devel From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 13 Dec 2015 10:33:38 +0100 This issue was detected by using the Coccinelle software. Choose a jump label according to the current Linux coding style convention. I suggest to improve this implementation detail by the reuse of a script like the following for the semantic patch language. @rename_jump_label exists@ identifier work; type return_type; @@ return_type work(...) { ... when any goto -out +finish_request ; ... when any -out +finish_request : ptlrpc_req_finished(...); ... when any } Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/llite/file.c | 26 +++++------ drivers/staging/lustre/lustre/llite/namei.c | 12 ++--- drivers/staging/lustre/lustre/llite/xattr.c | 20 ++++---- drivers/staging/lustre/lustre/mdc/mdc_request.c | 54 +++++++++++----------- drivers/staging/lustre/lustre/osc/osc_request.c | 28 +++++------ drivers/staging/lustre/lustre/ptlrpc/llog_client.c | 22 ++++----- 6 files changed, 81 insertions(+), 81 deletions(-) diff --git a/drivers/staging/lustre/lustre/llite/file.c b/drivers/staging/lustre/lustre/llite/file.c index 31cd6b3..b94df54 100644 --- a/drivers/staging/lustre/lustre/llite/file.c +++ b/drivers/staging/lustre/lustre/llite/file.c @@ -427,27 +427,27 @@ static int ll_intent_file_open(struct dentry *dentry, void *lmm, */ if (!it_disposition(itp, DISP_OPEN_OPEN) || it_open_error(DISP_OPEN_OPEN, itp)) - goto out; + goto finish_request; ll_release_openhandle(inode, itp); - goto out; + goto finish_request; } if (it_disposition(itp, DISP_LOOKUP_NEG)) { rc = -ENOENT; - goto out; + goto finish_request; } if (rc != 0 || it_open_error(DISP_OPEN_OPEN, itp)) { rc = rc ? rc : it_open_error(DISP_OPEN_OPEN, itp); CDEBUG(D_VFSTRACE, "lock enqueue: err: %d\n", rc); - goto out; + goto finish_request; } rc = ll_prep_inode(&inode, req, NULL, itp); if (!rc && itp->d.lustre.it_lock_mode) ll_set_lock_data(sbi->ll_md_exp, inode, itp, NULL); -out: +finish_request: ptlrpc_req_finished(req); ll_intent_drop_lock(itp); @@ -2900,13 +2900,13 @@ static int __ll_inode_revalidate(struct dentry *dentry, __u64 ibits) oit.it_create_mode &= ~M_CHECK_STALE; if (rc < 0) { rc = ll_inode_revalidate_fini(inode, rc); - goto out; + goto finish_request; } rc = ll_revalidate_it_finish(req, &oit, inode); if (rc != 0) { ll_intent_release(&oit); - goto out; + goto finish_request; } /* Unlinked? Unhash dentry, so it is not picked up later by @@ -2946,7 +2946,7 @@ static int __ll_inode_revalidate(struct dentry *dentry, __u64 ibits) rc = ll_prep_inode(&inode, req, NULL, NULL); } -out: +finish_request: ptlrpc_req_finished(req); return rc; } @@ -3315,25 +3315,25 @@ static int ll_layout_fetch(struct inode *inode, struct ldlm_lock *lock) body = req_capsule_server_get(&req->rq_pill, &RMF_MDT_BODY); if (body == NULL) { rc = -EPROTO; - goto out; + goto finish_request; } lmmsize = body->eadatasize; if (lmmsize == 0) /* empty layout */ { rc = 0; - goto out; + goto finish_request; } lmm = req_capsule_server_sized_get(&req->rq_pill, &RMF_EADATA, lmmsize); if (lmm == NULL) { rc = -EFAULT; - goto out; + goto finish_request; } lvbdata = libcfs_kvzalloc(lmmsize, GFP_NOFS); if (lvbdata == NULL) { rc = -ENOMEM; - goto out; + goto finish_request; } memcpy(lvbdata, lmm, lmmsize); @@ -3345,7 +3345,7 @@ static int ll_layout_fetch(struct inode *inode, struct ldlm_lock *lock) lock->l_lvb_len = lmmsize; unlock_res_and_lock(lock); -out: +finish_request: ptlrpc_req_finished(req); return rc; } diff --git a/drivers/staging/lustre/lustre/llite/namei.c b/drivers/staging/lustre/lustre/llite/namei.c index 2113dd4..7501f70 100644 --- a/drivers/staging/lustre/lustre/llite/namei.c +++ b/drivers/staging/lustre/lustre/llite/namei.c @@ -686,7 +686,7 @@ static struct inode *ll_create_node(struct inode *dir, struct lookup_intent *it) rc = ll_prep_inode(&inode, request, dir->i_sb, it); if (rc) { inode = ERR_PTR(rc); - goto out; + goto finish_request; } LASSERT(hlist_empty(&inode->i_dentry)); @@ -697,7 +697,7 @@ static struct inode *ll_create_node(struct inode *dir, struct lookup_intent *it) CDEBUG(D_DLMTRACE, "setting l_ast_data to inode %p (%lu/%u)\n", inode, inode->i_ino, inode->i_generation); ll_set_lock_data(sbi->ll_md_exp, inode, it, NULL); - out: + finish_request: ptlrpc_req_finished(request); return inode; } @@ -960,13 +960,13 @@ static int ll_unlink(struct inode *dir, struct dentry *dentry) rc = md_unlink(ll_i2sbi(dir)->ll_md_exp, op_data, &request); ll_finish_md_op_data(op_data); if (rc) - goto out; + goto finish_request; ll_update_times(request, dir); ll_stats_ops_tally(ll_i2sbi(dir), LPROC_LL_UNLINK, 1); rc = ll_objects_destroy(request, dir); - out: + finish_request: ptlrpc_req_finished(request); return rc; } @@ -1059,11 +1059,11 @@ static int ll_link(struct dentry *old_dentry, struct inode *dir, err = md_link(sbi->ll_md_exp, op_data, &request); ll_finish_md_op_data(op_data); if (err) - goto out; + goto finish_request; ll_update_times(request, dir); ll_stats_ops_tally(sbi, LPROC_LL_LINK, 1); -out: +finish_request: ptlrpc_req_finished(request); return err; } diff --git a/drivers/staging/lustre/lustre/llite/xattr.c b/drivers/staging/lustre/lustre/llite/xattr.c index 660b8ac..8d3287c 100644 --- a/drivers/staging/lustre/lustre/llite/xattr.c +++ b/drivers/staging/lustre/lustre/llite/xattr.c @@ -390,19 +390,19 @@ getxattr_nocache: /* only detect the xattr size */ if (size == 0) { rc = body->eadatasize; - goto out; + goto finish_request; } if (size < body->eadatasize) { CERROR("server bug: replied size %u > %u\n", body->eadatasize, (int)size); rc = -ERANGE; - goto out; + goto finish_request; } if (body->eadatasize == 0) { rc = -ENODATA; - goto out; + goto finish_request; } /* do not need swab xattr data */ @@ -410,7 +410,7 @@ getxattr_nocache: body->eadatasize); if (!xdata) { rc = -EFAULT; - goto out; + goto finish_request; } memcpy(buffer, xdata, body->eadatasize); @@ -425,14 +425,14 @@ getxattr_nocache: (posix_acl_xattr_header *)buffer, rc); if (IS_ERR(acl)) { rc = PTR_ERR(acl); - goto out; + goto finish_request; } rc = ee_add(&sbi->ll_et, current_pid(), ll_inode2fid(inode), xattr_type, acl); if (unlikely(rc < 0)) { lustre_ext_acl_xattr_free(acl); - goto out; + goto finish_request; } } #endif @@ -444,7 +444,7 @@ out_xattr: ll_get_fsname(inode->i_sb, NULL, 0), rc); sbi->ll_flags &= ~LL_SBI_USER_XATTR; } -out: +finish_request: ptlrpc_req_finished(req); return rc; } @@ -555,7 +555,7 @@ ssize_t ll_listxattr(struct dentry *dentry, char *buffer, size_t size) rc = ll_getxattr_common(inode, NULL, buffer, size, OBD_MD_FLXATTRLS); if (rc < 0) - goto out; + goto finish_request; if (buffer != NULL) { struct ll_sb_info *sbi = ll_i2sbi(inode); @@ -589,7 +589,7 @@ ssize_t ll_listxattr(struct dentry *dentry, char *buffer, size_t size) if (rc2 < 0) { rc2 = 0; - goto out; + goto finish_request; } else if (S_ISREG(inode->i_mode) || S_ISDIR(inode->i_mode)) { const int prefix_len = sizeof(XATTR_LUSTRE_PREFIX) - 1; const size_t name_len = sizeof("lov") - 1; @@ -608,7 +608,7 @@ ssize_t ll_listxattr(struct dentry *dentry, char *buffer, size_t size) } rc2 = total_len; } -out: +finish_request: ptlrpc_req_finished(request); rc = rc + rc2; diff --git a/drivers/staging/lustre/lustre/mdc/mdc_request.c b/drivers/staging/lustre/lustre/mdc/mdc_request.c index 920b1e9..2a76685 100644 --- a/drivers/staging/lustre/lustre/mdc/mdc_request.c +++ b/drivers/staging/lustre/lustre/mdc/mdc_request.c @@ -92,12 +92,12 @@ static int mdc_getstatus(struct obd_export *exp, struct lu_fid *rootfid) rc = ptlrpc_queue_wait(req); if (rc) - goto out; + goto finish_request; body = req_capsule_server_get(&req->rq_pill, &RMF_MDT_BODY); if (body == NULL) { rc = -EPROTO; - goto out; + goto finish_request; } *rootfid = body->fid1; @@ -105,7 +105,7 @@ static int mdc_getstatus(struct obd_export *exp, struct lu_fid *rootfid) "root fid="DFID", last_committed=%llu\n", PFID(rootfid), lustre_msg_get_last_committed(req->rq_repmsg)); -out: +finish_request: ptlrpc_req_finished(req); return rc; } @@ -1084,17 +1084,17 @@ static int mdc_statfs(const struct lu_env *env, /* check connection error first */ if (imp->imp_connect_error) rc = imp->imp_connect_error; - goto out; + goto finish_request; } msfs = req_capsule_server_get(&req->rq_pill, &RMF_OBD_STATFS); if (msfs == NULL) { rc = -EPROTO; - goto out; + goto finish_request; } *osfs = *msfs; -out: +finish_request: ptlrpc_req_finished(req); output: class_import_put(imp); @@ -1163,7 +1163,7 @@ static int mdc_ioc_hsm_progress(struct obd_export *exp, LUSTRE_MDS_VERSION, MDS_HSM_PROGRESS); if (req == NULL) { rc = -ENOMEM; - goto out; + goto finish_request; } mdc_pack_body(req, NULL, OBD_MD_FLRMTPERM, 0, 0, 0); @@ -1172,7 +1172,7 @@ static int mdc_ioc_hsm_progress(struct obd_export *exp, req_hpk = req_capsule_client_get(&req->rq_pill, &RMF_MDS_HSM_PROGRESS); if (req_hpk == NULL) { rc = -EPROTO; - goto out; + goto finish_request; } *req_hpk = *hpk; @@ -1181,7 +1181,7 @@ static int mdc_ioc_hsm_progress(struct obd_export *exp, ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); -out: +finish_request: ptlrpc_req_finished(req); return rc; } @@ -1197,7 +1197,7 @@ static int mdc_ioc_hsm_ct_register(struct obd_import *imp, __u32 archives) MDS_HSM_CT_REGISTER); if (req == NULL) { rc = -ENOMEM; - goto out; + goto finish_request; } mdc_pack_body(req, NULL, OBD_MD_FLRMTPERM, 0, 0, 0); @@ -1207,7 +1207,7 @@ static int mdc_ioc_hsm_ct_register(struct obd_import *imp, __u32 archives) &RMF_MDS_HSM_ARCHIVE); if (archive_mask == NULL) { rc = -EPROTO; - goto out; + goto finish_request; } *archive_mask = archives; @@ -1215,7 +1215,7 @@ static int mdc_ioc_hsm_ct_register(struct obd_import *imp, __u32 archives) ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); -out: +finish_request: ptlrpc_req_finished(req); return rc; } @@ -1246,18 +1246,18 @@ static int mdc_ioc_hsm_current_action(struct obd_export *exp, rc = mdc_queue_wait(req); if (rc) - goto out; + goto finish_request; req_hca = req_capsule_server_get(&req->rq_pill, &RMF_MDS_HSM_CURRENT_ACTION); if (req_hca == NULL) { rc = -EPROTO; - goto out; + goto finish_request; } *hca = *req_hca; -out: +finish_request: ptlrpc_req_finished(req); return rc; } @@ -1272,7 +1272,7 @@ static int mdc_ioc_hsm_ct_unregister(struct obd_import *imp) MDS_HSM_CT_UNREGISTER); if (req == NULL) { rc = -ENOMEM; - goto out; + goto finish_request; } mdc_pack_body(req, NULL, OBD_MD_FLRMTPERM, 0, 0, 0); @@ -1280,7 +1280,7 @@ static int mdc_ioc_hsm_ct_unregister(struct obd_import *imp) ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); -out: +finish_request: ptlrpc_req_finished(req); return rc; } @@ -1311,17 +1311,17 @@ static int mdc_ioc_hsm_state_get(struct obd_export *exp, rc = mdc_queue_wait(req); if (rc) - goto out; + goto finish_request; req_hus = req_capsule_server_get(&req->rq_pill, &RMF_HSM_USER_STATE); if (req_hus == NULL) { rc = -EPROTO; - goto out; + goto finish_request; } *hus = *req_hus; -out: +finish_request: ptlrpc_req_finished(req); return rc; } @@ -1352,14 +1352,14 @@ static int mdc_ioc_hsm_state_set(struct obd_export *exp, req_hss = req_capsule_client_get(&req->rq_pill, &RMF_HSM_STATE_SET); if (req_hss == NULL) { rc = -EPROTO; - goto out; + goto finish_request; } *req_hss = *hss; ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); -out: +finish_request: ptlrpc_req_finished(req); return rc; } @@ -1377,7 +1377,7 @@ static int mdc_ioc_hsm_request(struct obd_export *exp, req = ptlrpc_request_alloc(imp, &RQF_MDS_HSM_REQUEST); if (req == NULL) { rc = -ENOMEM; - goto out; + goto finish_request; } req_capsule_set_size(&req->rq_pill, &RMF_MDS_HSM_USER_ITEM, RCL_CLIENT, @@ -1398,7 +1398,7 @@ static int mdc_ioc_hsm_request(struct obd_export *exp, req_hr = req_capsule_client_get(&req->rq_pill, &RMF_MDS_HSM_REQUEST); if (req_hr == NULL) { rc = -EPROTO; - goto out; + goto finish_request; } *req_hr = hur->hur_request; @@ -1406,7 +1406,7 @@ static int mdc_ioc_hsm_request(struct obd_export *exp, req_hui = req_capsule_client_get(&req->rq_pill, &RMF_MDS_HSM_USER_ITEM); if (req_hui == NULL) { rc = -EPROTO; - goto out; + goto finish_request; } memcpy(req_hui, hur->hur_user_item, hur->hur_request.hr_itemcount * sizeof(struct hsm_user_item)); @@ -1415,14 +1415,14 @@ static int mdc_ioc_hsm_request(struct obd_export *exp, req_opaque = req_capsule_client_get(&req->rq_pill, &RMF_GENERIC_DATA); if (req_opaque == NULL) { rc = -EPROTO; - goto out; + goto finish_request; } memcpy(req_opaque, hur_data(hur), hur->hur_request.hr_data_len); ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); -out: +finish_request: ptlrpc_req_finished(req); return rc; } diff --git a/drivers/staging/lustre/lustre/osc/osc_request.c b/drivers/staging/lustre/lustre/osc/osc_request.c index d6c1447..3a56fb7 100644 --- a/drivers/staging/lustre/lustre/osc/osc_request.c +++ b/drivers/staging/lustre/lustre/osc/osc_request.c @@ -291,12 +291,12 @@ static int osc_getattr(const struct lu_env *env, struct obd_export *exp, rc = ptlrpc_queue_wait(req); if (rc) - goto out; + goto finish_request; body = req_capsule_server_get(&req->rq_pill, &RMF_OST_BODY); if (body == NULL) { rc = -EPROTO; - goto out; + goto finish_request; } CDEBUG(D_INODE, "mode: %o\n", body->oa.o_mode); @@ -306,7 +306,7 @@ static int osc_getattr(const struct lu_env *env, struct obd_export *exp, oinfo->oi_oa->o_blksize = cli_brw_size(exp->exp_obd); oinfo->oi_oa->o_valid |= OBD_MD_FLBLKSZ; - out: + finish_request: ptlrpc_req_finished(req); return rc; } @@ -336,18 +336,18 @@ static int osc_setattr(const struct lu_env *env, struct obd_export *exp, rc = ptlrpc_queue_wait(req); if (rc) - goto out; + goto finish_request; body = req_capsule_server_get(&req->rq_pill, &RMF_OST_BODY); if (body == NULL) { rc = -EPROTO; - goto out; + goto finish_request; } lustre_get_wire_obdo(&req->rq_import->imp_connect_data, oinfo->oi_oa, &body->oa); -out: +finish_request: ptlrpc_req_finished(req); return rc; } @@ -1276,7 +1276,7 @@ static int osc_brw_prep_request(int cmd, struct client_obd *cli, if (desc == NULL) { rc = -ENOMEM; - goto out; + goto finish_request; } /* NB request now owns desc and will free it when it gets freed */ @@ -1407,7 +1407,7 @@ static int osc_brw_prep_request(int cmd, struct client_obd *cli, *reqp = req; return 0; - out: + finish_request: ptlrpc_req_finished(req); return rc; } @@ -2513,17 +2513,17 @@ static int osc_statfs(const struct lu_env *env, struct obd_export *exp, rc = ptlrpc_queue_wait(req); if (rc) - goto out; + goto finish_request; msfs = req_capsule_server_get(&req->rq_pill, &RMF_OBD_STATFS); if (msfs == NULL) { rc = -EPROTO; - goto out; + goto finish_request; } *osfs = *msfs; - out: + finish_request: ptlrpc_req_finished(req); return rc; } @@ -2718,16 +2718,16 @@ static int osc_get_info(const struct lu_env *env, struct obd_export *exp, ptlrpc_request_set_replen(req); rc = ptlrpc_queue_wait(req); if (rc) - goto out; + goto finish_request; reply = req_capsule_server_get(&req->rq_pill, &RMF_OBD_ID); if (reply == NULL) { rc = -EPROTO; - goto out; + goto finish_request; } *((u64 *)val) = *reply; - out: + finish_request: ptlrpc_req_finished(req); return rc; } else if (KEY_IS(KEY_FIEMAP)) { diff --git a/drivers/staging/lustre/lustre/ptlrpc/llog_client.c b/drivers/staging/lustre/lustre/ptlrpc/llog_client.c index 5122205..150d2ec 100644 --- a/drivers/staging/lustre/lustre/ptlrpc/llog_client.c +++ b/drivers/staging/lustre/lustre/ptlrpc/llog_client.c @@ -176,26 +176,26 @@ static int llog_client_next_block(const struct lu_env *env, ptlrpc_request_set_replen(req); rc = ptlrpc_queue_wait(req); if (rc) - goto out; + goto finish_request; body = req_capsule_server_get(&req->rq_pill, &RMF_LLOGD_BODY); if (body == NULL) { rc = -EFAULT; - goto out; + goto finish_request; } /* The log records are swabbed as they are processed */ ptr = req_capsule_server_get(&req->rq_pill, &RMF_EADATA); if (ptr == NULL) { rc = -EFAULT; - goto out; + goto finish_request; } *cur_idx = body->lgd_saved_index; *cur_offset = body->lgd_cur_offset; memcpy(buf, ptr, len); -out: +finish_request: ptlrpc_req_finished(req); err_exit: LLOG_CLIENT_EXIT(loghandle->lgh_ctxt, imp); @@ -233,22 +233,22 @@ static int llog_client_prev_block(const struct lu_env *env, rc = ptlrpc_queue_wait(req); if (rc) - goto out; + goto finish_request; body = req_capsule_server_get(&req->rq_pill, &RMF_LLOGD_BODY); if (body == NULL) { rc = -EFAULT; - goto out; + goto finish_request; } ptr = req_capsule_server_get(&req->rq_pill, &RMF_EADATA); if (ptr == NULL) { rc = -EFAULT; - goto out; + goto finish_request; } memcpy(buf, ptr, len); -out: +finish_request: ptlrpc_req_finished(req); err_exit: LLOG_CLIENT_EXIT(loghandle->lgh_ctxt, imp); @@ -282,12 +282,12 @@ static int llog_client_read_header(const struct lu_env *env, ptlrpc_request_set_replen(req); rc = ptlrpc_queue_wait(req); if (rc) - goto out; + goto finish_request; hdr = req_capsule_server_get(&req->rq_pill, &RMF_LLOG_LOG_HDR); if (hdr == NULL) { rc = -EFAULT; - goto out; + goto finish_request; } memcpy(handle->lgh_hdr, hdr, sizeof(*hdr)); @@ -305,7 +305,7 @@ static int llog_client_read_header(const struct lu_env *env, CERROR("you may need to re-run lconf --write_conf.\n"); rc = -EIO; } -out: +finish_request: ptlrpc_req_finished(req); err_exit: LLOG_CLIENT_EXIT(handle->lgh_ctxt, imp); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 2/7] staging: lustre: Rename a jump label for ptlrpc_req_finished() calls @ 2015-12-13 13:54 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-13 13:54 UTC (permalink / raw) To: Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 13 Dec 2015 10:33:38 +0100 This issue was detected by using the Coccinelle software. Choose a jump label according to the current Linux coding style convention. I suggest to improve this implementation detail by the reuse of a script like the following for the semantic patch language. @rename_jump_label exists@ identifier work; type return_type; @@ return_type work(...) { ... when any goto -out +finish_request ; ... when any -out +finish_request : ptlrpc_req_finished(...); ... when any } Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/llite/file.c | 26 +++++------ drivers/staging/lustre/lustre/llite/namei.c | 12 ++--- drivers/staging/lustre/lustre/llite/xattr.c | 20 ++++---- drivers/staging/lustre/lustre/mdc/mdc_request.c | 54 +++++++++++----------- drivers/staging/lustre/lustre/osc/osc_request.c | 28 +++++------ drivers/staging/lustre/lustre/ptlrpc/llog_client.c | 22 ++++----- 6 files changed, 81 insertions(+), 81 deletions(-) diff --git a/drivers/staging/lustre/lustre/llite/file.c b/drivers/staging/lustre/lustre/llite/file.c index 31cd6b3..b94df54 100644 --- a/drivers/staging/lustre/lustre/llite/file.c +++ b/drivers/staging/lustre/lustre/llite/file.c @@ -427,27 +427,27 @@ static int ll_intent_file_open(struct dentry *dentry, void *lmm, */ if (!it_disposition(itp, DISP_OPEN_OPEN) || it_open_error(DISP_OPEN_OPEN, itp)) - goto out; + goto finish_request; ll_release_openhandle(inode, itp); - goto out; + goto finish_request; } if (it_disposition(itp, DISP_LOOKUP_NEG)) { rc = -ENOENT; - goto out; + goto finish_request; } if (rc != 0 || it_open_error(DISP_OPEN_OPEN, itp)) { rc = rc ? rc : it_open_error(DISP_OPEN_OPEN, itp); CDEBUG(D_VFSTRACE, "lock enqueue: err: %d\n", rc); - goto out; + goto finish_request; } rc = ll_prep_inode(&inode, req, NULL, itp); if (!rc && itp->d.lustre.it_lock_mode) ll_set_lock_data(sbi->ll_md_exp, inode, itp, NULL); -out: +finish_request: ptlrpc_req_finished(req); ll_intent_drop_lock(itp); @@ -2900,13 +2900,13 @@ static int __ll_inode_revalidate(struct dentry *dentry, __u64 ibits) oit.it_create_mode &= ~M_CHECK_STALE; if (rc < 0) { rc = ll_inode_revalidate_fini(inode, rc); - goto out; + goto finish_request; } rc = ll_revalidate_it_finish(req, &oit, inode); if (rc != 0) { ll_intent_release(&oit); - goto out; + goto finish_request; } /* Unlinked? Unhash dentry, so it is not picked up later by @@ -2946,7 +2946,7 @@ static int __ll_inode_revalidate(struct dentry *dentry, __u64 ibits) rc = ll_prep_inode(&inode, req, NULL, NULL); } -out: +finish_request: ptlrpc_req_finished(req); return rc; } @@ -3315,25 +3315,25 @@ static int ll_layout_fetch(struct inode *inode, struct ldlm_lock *lock) body = req_capsule_server_get(&req->rq_pill, &RMF_MDT_BODY); if (body = NULL) { rc = -EPROTO; - goto out; + goto finish_request; } lmmsize = body->eadatasize; if (lmmsize = 0) /* empty layout */ { rc = 0; - goto out; + goto finish_request; } lmm = req_capsule_server_sized_get(&req->rq_pill, &RMF_EADATA, lmmsize); if (lmm = NULL) { rc = -EFAULT; - goto out; + goto finish_request; } lvbdata = libcfs_kvzalloc(lmmsize, GFP_NOFS); if (lvbdata = NULL) { rc = -ENOMEM; - goto out; + goto finish_request; } memcpy(lvbdata, lmm, lmmsize); @@ -3345,7 +3345,7 @@ static int ll_layout_fetch(struct inode *inode, struct ldlm_lock *lock) lock->l_lvb_len = lmmsize; unlock_res_and_lock(lock); -out: +finish_request: ptlrpc_req_finished(req); return rc; } diff --git a/drivers/staging/lustre/lustre/llite/namei.c b/drivers/staging/lustre/lustre/llite/namei.c index 2113dd4..7501f70 100644 --- a/drivers/staging/lustre/lustre/llite/namei.c +++ b/drivers/staging/lustre/lustre/llite/namei.c @@ -686,7 +686,7 @@ static struct inode *ll_create_node(struct inode *dir, struct lookup_intent *it) rc = ll_prep_inode(&inode, request, dir->i_sb, it); if (rc) { inode = ERR_PTR(rc); - goto out; + goto finish_request; } LASSERT(hlist_empty(&inode->i_dentry)); @@ -697,7 +697,7 @@ static struct inode *ll_create_node(struct inode *dir, struct lookup_intent *it) CDEBUG(D_DLMTRACE, "setting l_ast_data to inode %p (%lu/%u)\n", inode, inode->i_ino, inode->i_generation); ll_set_lock_data(sbi->ll_md_exp, inode, it, NULL); - out: + finish_request: ptlrpc_req_finished(request); return inode; } @@ -960,13 +960,13 @@ static int ll_unlink(struct inode *dir, struct dentry *dentry) rc = md_unlink(ll_i2sbi(dir)->ll_md_exp, op_data, &request); ll_finish_md_op_data(op_data); if (rc) - goto out; + goto finish_request; ll_update_times(request, dir); ll_stats_ops_tally(ll_i2sbi(dir), LPROC_LL_UNLINK, 1); rc = ll_objects_destroy(request, dir); - out: + finish_request: ptlrpc_req_finished(request); return rc; } @@ -1059,11 +1059,11 @@ static int ll_link(struct dentry *old_dentry, struct inode *dir, err = md_link(sbi->ll_md_exp, op_data, &request); ll_finish_md_op_data(op_data); if (err) - goto out; + goto finish_request; ll_update_times(request, dir); ll_stats_ops_tally(sbi, LPROC_LL_LINK, 1); -out: +finish_request: ptlrpc_req_finished(request); return err; } diff --git a/drivers/staging/lustre/lustre/llite/xattr.c b/drivers/staging/lustre/lustre/llite/xattr.c index 660b8ac..8d3287c 100644 --- a/drivers/staging/lustre/lustre/llite/xattr.c +++ b/drivers/staging/lustre/lustre/llite/xattr.c @@ -390,19 +390,19 @@ getxattr_nocache: /* only detect the xattr size */ if (size = 0) { rc = body->eadatasize; - goto out; + goto finish_request; } if (size < body->eadatasize) { CERROR("server bug: replied size %u > %u\n", body->eadatasize, (int)size); rc = -ERANGE; - goto out; + goto finish_request; } if (body->eadatasize = 0) { rc = -ENODATA; - goto out; + goto finish_request; } /* do not need swab xattr data */ @@ -410,7 +410,7 @@ getxattr_nocache: body->eadatasize); if (!xdata) { rc = -EFAULT; - goto out; + goto finish_request; } memcpy(buffer, xdata, body->eadatasize); @@ -425,14 +425,14 @@ getxattr_nocache: (posix_acl_xattr_header *)buffer, rc); if (IS_ERR(acl)) { rc = PTR_ERR(acl); - goto out; + goto finish_request; } rc = ee_add(&sbi->ll_et, current_pid(), ll_inode2fid(inode), xattr_type, acl); if (unlikely(rc < 0)) { lustre_ext_acl_xattr_free(acl); - goto out; + goto finish_request; } } #endif @@ -444,7 +444,7 @@ out_xattr: ll_get_fsname(inode->i_sb, NULL, 0), rc); sbi->ll_flags &= ~LL_SBI_USER_XATTR; } -out: +finish_request: ptlrpc_req_finished(req); return rc; } @@ -555,7 +555,7 @@ ssize_t ll_listxattr(struct dentry *dentry, char *buffer, size_t size) rc = ll_getxattr_common(inode, NULL, buffer, size, OBD_MD_FLXATTRLS); if (rc < 0) - goto out; + goto finish_request; if (buffer != NULL) { struct ll_sb_info *sbi = ll_i2sbi(inode); @@ -589,7 +589,7 @@ ssize_t ll_listxattr(struct dentry *dentry, char *buffer, size_t size) if (rc2 < 0) { rc2 = 0; - goto out; + goto finish_request; } else if (S_ISREG(inode->i_mode) || S_ISDIR(inode->i_mode)) { const int prefix_len = sizeof(XATTR_LUSTRE_PREFIX) - 1; const size_t name_len = sizeof("lov") - 1; @@ -608,7 +608,7 @@ ssize_t ll_listxattr(struct dentry *dentry, char *buffer, size_t size) } rc2 = total_len; } -out: +finish_request: ptlrpc_req_finished(request); rc = rc + rc2; diff --git a/drivers/staging/lustre/lustre/mdc/mdc_request.c b/drivers/staging/lustre/lustre/mdc/mdc_request.c index 920b1e9..2a76685 100644 --- a/drivers/staging/lustre/lustre/mdc/mdc_request.c +++ b/drivers/staging/lustre/lustre/mdc/mdc_request.c @@ -92,12 +92,12 @@ static int mdc_getstatus(struct obd_export *exp, struct lu_fid *rootfid) rc = ptlrpc_queue_wait(req); if (rc) - goto out; + goto finish_request; body = req_capsule_server_get(&req->rq_pill, &RMF_MDT_BODY); if (body = NULL) { rc = -EPROTO; - goto out; + goto finish_request; } *rootfid = body->fid1; @@ -105,7 +105,7 @@ static int mdc_getstatus(struct obd_export *exp, struct lu_fid *rootfid) "root fid="DFID", last_committed=%llu\n", PFID(rootfid), lustre_msg_get_last_committed(req->rq_repmsg)); -out: +finish_request: ptlrpc_req_finished(req); return rc; } @@ -1084,17 +1084,17 @@ static int mdc_statfs(const struct lu_env *env, /* check connection error first */ if (imp->imp_connect_error) rc = imp->imp_connect_error; - goto out; + goto finish_request; } msfs = req_capsule_server_get(&req->rq_pill, &RMF_OBD_STATFS); if (msfs = NULL) { rc = -EPROTO; - goto out; + goto finish_request; } *osfs = *msfs; -out: +finish_request: ptlrpc_req_finished(req); output: class_import_put(imp); @@ -1163,7 +1163,7 @@ static int mdc_ioc_hsm_progress(struct obd_export *exp, LUSTRE_MDS_VERSION, MDS_HSM_PROGRESS); if (req = NULL) { rc = -ENOMEM; - goto out; + goto finish_request; } mdc_pack_body(req, NULL, OBD_MD_FLRMTPERM, 0, 0, 0); @@ -1172,7 +1172,7 @@ static int mdc_ioc_hsm_progress(struct obd_export *exp, req_hpk = req_capsule_client_get(&req->rq_pill, &RMF_MDS_HSM_PROGRESS); if (req_hpk = NULL) { rc = -EPROTO; - goto out; + goto finish_request; } *req_hpk = *hpk; @@ -1181,7 +1181,7 @@ static int mdc_ioc_hsm_progress(struct obd_export *exp, ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); -out: +finish_request: ptlrpc_req_finished(req); return rc; } @@ -1197,7 +1197,7 @@ static int mdc_ioc_hsm_ct_register(struct obd_import *imp, __u32 archives) MDS_HSM_CT_REGISTER); if (req = NULL) { rc = -ENOMEM; - goto out; + goto finish_request; } mdc_pack_body(req, NULL, OBD_MD_FLRMTPERM, 0, 0, 0); @@ -1207,7 +1207,7 @@ static int mdc_ioc_hsm_ct_register(struct obd_import *imp, __u32 archives) &RMF_MDS_HSM_ARCHIVE); if (archive_mask = NULL) { rc = -EPROTO; - goto out; + goto finish_request; } *archive_mask = archives; @@ -1215,7 +1215,7 @@ static int mdc_ioc_hsm_ct_register(struct obd_import *imp, __u32 archives) ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); -out: +finish_request: ptlrpc_req_finished(req); return rc; } @@ -1246,18 +1246,18 @@ static int mdc_ioc_hsm_current_action(struct obd_export *exp, rc = mdc_queue_wait(req); if (rc) - goto out; + goto finish_request; req_hca = req_capsule_server_get(&req->rq_pill, &RMF_MDS_HSM_CURRENT_ACTION); if (req_hca = NULL) { rc = -EPROTO; - goto out; + goto finish_request; } *hca = *req_hca; -out: +finish_request: ptlrpc_req_finished(req); return rc; } @@ -1272,7 +1272,7 @@ static int mdc_ioc_hsm_ct_unregister(struct obd_import *imp) MDS_HSM_CT_UNREGISTER); if (req = NULL) { rc = -ENOMEM; - goto out; + goto finish_request; } mdc_pack_body(req, NULL, OBD_MD_FLRMTPERM, 0, 0, 0); @@ -1280,7 +1280,7 @@ static int mdc_ioc_hsm_ct_unregister(struct obd_import *imp) ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); -out: +finish_request: ptlrpc_req_finished(req); return rc; } @@ -1311,17 +1311,17 @@ static int mdc_ioc_hsm_state_get(struct obd_export *exp, rc = mdc_queue_wait(req); if (rc) - goto out; + goto finish_request; req_hus = req_capsule_server_get(&req->rq_pill, &RMF_HSM_USER_STATE); if (req_hus = NULL) { rc = -EPROTO; - goto out; + goto finish_request; } *hus = *req_hus; -out: +finish_request: ptlrpc_req_finished(req); return rc; } @@ -1352,14 +1352,14 @@ static int mdc_ioc_hsm_state_set(struct obd_export *exp, req_hss = req_capsule_client_get(&req->rq_pill, &RMF_HSM_STATE_SET); if (req_hss = NULL) { rc = -EPROTO; - goto out; + goto finish_request; } *req_hss = *hss; ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); -out: +finish_request: ptlrpc_req_finished(req); return rc; } @@ -1377,7 +1377,7 @@ static int mdc_ioc_hsm_request(struct obd_export *exp, req = ptlrpc_request_alloc(imp, &RQF_MDS_HSM_REQUEST); if (req = NULL) { rc = -ENOMEM; - goto out; + goto finish_request; } req_capsule_set_size(&req->rq_pill, &RMF_MDS_HSM_USER_ITEM, RCL_CLIENT, @@ -1398,7 +1398,7 @@ static int mdc_ioc_hsm_request(struct obd_export *exp, req_hr = req_capsule_client_get(&req->rq_pill, &RMF_MDS_HSM_REQUEST); if (req_hr = NULL) { rc = -EPROTO; - goto out; + goto finish_request; } *req_hr = hur->hur_request; @@ -1406,7 +1406,7 @@ static int mdc_ioc_hsm_request(struct obd_export *exp, req_hui = req_capsule_client_get(&req->rq_pill, &RMF_MDS_HSM_USER_ITEM); if (req_hui = NULL) { rc = -EPROTO; - goto out; + goto finish_request; } memcpy(req_hui, hur->hur_user_item, hur->hur_request.hr_itemcount * sizeof(struct hsm_user_item)); @@ -1415,14 +1415,14 @@ static int mdc_ioc_hsm_request(struct obd_export *exp, req_opaque = req_capsule_client_get(&req->rq_pill, &RMF_GENERIC_DATA); if (req_opaque = NULL) { rc = -EPROTO; - goto out; + goto finish_request; } memcpy(req_opaque, hur_data(hur), hur->hur_request.hr_data_len); ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); -out: +finish_request: ptlrpc_req_finished(req); return rc; } diff --git a/drivers/staging/lustre/lustre/osc/osc_request.c b/drivers/staging/lustre/lustre/osc/osc_request.c index d6c1447..3a56fb7 100644 --- a/drivers/staging/lustre/lustre/osc/osc_request.c +++ b/drivers/staging/lustre/lustre/osc/osc_request.c @@ -291,12 +291,12 @@ static int osc_getattr(const struct lu_env *env, struct obd_export *exp, rc = ptlrpc_queue_wait(req); if (rc) - goto out; + goto finish_request; body = req_capsule_server_get(&req->rq_pill, &RMF_OST_BODY); if (body = NULL) { rc = -EPROTO; - goto out; + goto finish_request; } CDEBUG(D_INODE, "mode: %o\n", body->oa.o_mode); @@ -306,7 +306,7 @@ static int osc_getattr(const struct lu_env *env, struct obd_export *exp, oinfo->oi_oa->o_blksize = cli_brw_size(exp->exp_obd); oinfo->oi_oa->o_valid |= OBD_MD_FLBLKSZ; - out: + finish_request: ptlrpc_req_finished(req); return rc; } @@ -336,18 +336,18 @@ static int osc_setattr(const struct lu_env *env, struct obd_export *exp, rc = ptlrpc_queue_wait(req); if (rc) - goto out; + goto finish_request; body = req_capsule_server_get(&req->rq_pill, &RMF_OST_BODY); if (body = NULL) { rc = -EPROTO; - goto out; + goto finish_request; } lustre_get_wire_obdo(&req->rq_import->imp_connect_data, oinfo->oi_oa, &body->oa); -out: +finish_request: ptlrpc_req_finished(req); return rc; } @@ -1276,7 +1276,7 @@ static int osc_brw_prep_request(int cmd, struct client_obd *cli, if (desc = NULL) { rc = -ENOMEM; - goto out; + goto finish_request; } /* NB request now owns desc and will free it when it gets freed */ @@ -1407,7 +1407,7 @@ static int osc_brw_prep_request(int cmd, struct client_obd *cli, *reqp = req; return 0; - out: + finish_request: ptlrpc_req_finished(req); return rc; } @@ -2513,17 +2513,17 @@ static int osc_statfs(const struct lu_env *env, struct obd_export *exp, rc = ptlrpc_queue_wait(req); if (rc) - goto out; + goto finish_request; msfs = req_capsule_server_get(&req->rq_pill, &RMF_OBD_STATFS); if (msfs = NULL) { rc = -EPROTO; - goto out; + goto finish_request; } *osfs = *msfs; - out: + finish_request: ptlrpc_req_finished(req); return rc; } @@ -2718,16 +2718,16 @@ static int osc_get_info(const struct lu_env *env, struct obd_export *exp, ptlrpc_request_set_replen(req); rc = ptlrpc_queue_wait(req); if (rc) - goto out; + goto finish_request; reply = req_capsule_server_get(&req->rq_pill, &RMF_OBD_ID); if (reply = NULL) { rc = -EPROTO; - goto out; + goto finish_request; } *((u64 *)val) = *reply; - out: + finish_request: ptlrpc_req_finished(req); return rc; } else if (KEY_IS(KEY_FIEMAP)) { diff --git a/drivers/staging/lustre/lustre/ptlrpc/llog_client.c b/drivers/staging/lustre/lustre/ptlrpc/llog_client.c index 5122205..150d2ec 100644 --- a/drivers/staging/lustre/lustre/ptlrpc/llog_client.c +++ b/drivers/staging/lustre/lustre/ptlrpc/llog_client.c @@ -176,26 +176,26 @@ static int llog_client_next_block(const struct lu_env *env, ptlrpc_request_set_replen(req); rc = ptlrpc_queue_wait(req); if (rc) - goto out; + goto finish_request; body = req_capsule_server_get(&req->rq_pill, &RMF_LLOGD_BODY); if (body = NULL) { rc = -EFAULT; - goto out; + goto finish_request; } /* The log records are swabbed as they are processed */ ptr = req_capsule_server_get(&req->rq_pill, &RMF_EADATA); if (ptr = NULL) { rc = -EFAULT; - goto out; + goto finish_request; } *cur_idx = body->lgd_saved_index; *cur_offset = body->lgd_cur_offset; memcpy(buf, ptr, len); -out: +finish_request: ptlrpc_req_finished(req); err_exit: LLOG_CLIENT_EXIT(loghandle->lgh_ctxt, imp); @@ -233,22 +233,22 @@ static int llog_client_prev_block(const struct lu_env *env, rc = ptlrpc_queue_wait(req); if (rc) - goto out; + goto finish_request; body = req_capsule_server_get(&req->rq_pill, &RMF_LLOGD_BODY); if (body = NULL) { rc = -EFAULT; - goto out; + goto finish_request; } ptr = req_capsule_server_get(&req->rq_pill, &RMF_EADATA); if (ptr = NULL) { rc = -EFAULT; - goto out; + goto finish_request; } memcpy(buf, ptr, len); -out: +finish_request: ptlrpc_req_finished(req); err_exit: LLOG_CLIENT_EXIT(loghandle->lgh_ctxt, imp); @@ -282,12 +282,12 @@ static int llog_client_read_header(const struct lu_env *env, ptlrpc_request_set_replen(req); rc = ptlrpc_queue_wait(req); if (rc) - goto out; + goto finish_request; hdr = req_capsule_server_get(&req->rq_pill, &RMF_LLOG_LOG_HDR); if (hdr = NULL) { rc = -EFAULT; - goto out; + goto finish_request; } memcpy(handle->lgh_hdr, hdr, sizeof(*hdr)); @@ -305,7 +305,7 @@ static int llog_client_read_header(const struct lu_env *env, CERROR("you may need to re-run lconf --write_conf.\n"); rc = -EIO; } -out: +finish_request: ptlrpc_req_finished(req); err_exit: LLOG_CLIENT_EXIT(handle->lgh_ctxt, imp); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/7] staging: lustre: Rename a jump label for ptlrpc_req_finished() calls 2015-12-13 13:54 ` SF Markus Elfring (?) @ 2015-12-14 6:53 ` Dan Carpenter -1 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2015-12-14 6:53 UTC (permalink / raw) To: SF Markus Elfring Cc: Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel, Julia Lawall, kernel-janitors, LKML Markus, please stop sending these things to rename out labels unless there is a bug. CodingStyle allows out labels. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [lustre-devel] [PATCH 2/7] staging: lustre: Rename a jump label for ptlrpc_req_finished() calls @ 2015-12-14 6:53 ` Dan Carpenter 0 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2015-12-14 6:53 UTC (permalink / raw) To: lustre-devel Markus, please stop sending these things to rename out labels unless there is a bug. CodingStyle allows out labels. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/7] staging: lustre: Rename a jump label for ptlrpc_req_finished() calls @ 2015-12-14 6:53 ` Dan Carpenter 0 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2015-12-14 6:53 UTC (permalink / raw) To: SF Markus Elfring Cc: Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel, Julia Lawall, kernel-janitors, LKML Markus, please stop sending these things to rename out labels unless there is a bug. CodingStyle allows out labels. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/7] staging: lustre: Rename a jump label for ptlrpc_req_finished() calls 2015-12-14 6:53 ` Dan Carpenter (?) @ 2015-12-14 9:08 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-14 9:08 UTC (permalink / raw) To: Dan Carpenter Cc: Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel, Julia Lawall, kernel-janitors, LKML > Markus, please stop sending these things to rename out labels unless > there is a bug. CodingStyle allows out labels. How does this feedback fit to information like the following? "… Chapter 7: … … Choose label names which say what the goto does or why the goto exists. … Avoid using GW-BASIC names … …" Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [lustre-devel] [PATCH 2/7] staging: lustre: Rename a jump label for ptlrpc_req_finished() calls @ 2015-12-14 9:08 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-14 9:08 UTC (permalink / raw) To: lustre-devel > Markus, please stop sending these things to rename out labels unless > there is a bug. CodingStyle allows out labels. How does this feedback fit to information like the following? "? Chapter 7: ? ? Choose label names which say what the goto does or why the goto exists. ? Avoid using GW-BASIC names ? ?" Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/7] staging: lustre: Rename a jump label for ptlrpc_req_finished() calls @ 2015-12-14 9:08 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-14 9:08 UTC (permalink / raw) To: Dan Carpenter Cc: Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel, Julia Lawall, kernel-janitors, LKML > Markus, please stop sending these things to rename out labels unless > there is a bug. CodingStyle allows out labels. How does this feedback fit to information like the following? "… Chapter 7: … … Choose label names which say what the goto does or why the goto exists. … Avoid using GW-BASIC names … …" Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/7] staging: lustre: Rename a jump label for ptlrpc_req_finished() calls 2015-12-14 9:08 ` SF Markus Elfring (?) @ 2015-12-14 9:31 ` Dan Carpenter -1 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2015-12-14 9:31 UTC (permalink / raw) To: SF Markus Elfring Cc: devel, Andreas Dilger, Greg Kroah-Hartman, kernel-janitors, LKML, Oleg Drokin, Julia Lawall, lustre-devel On Mon, Dec 14, 2015 at 10:08:03AM +0100, SF Markus Elfring wrote: > > Markus, please stop sending these things to rename out labels unless > > there is a bug. CodingStyle allows out labels. > > How does this feedback fit to information like the following? > > "… > Chapter 7: … > … > Choose label names which say what the goto does or why the goto exists. A lot of people think "out" says what the goto does and why it exists. I personally don't agree with them but if you look at when I complain about it, it's almost always when it causes a bug. > … Avoid using GW-BASIC names … Those when people just use numbers for their label names instead of words like out1, out2, out4, out5. It's a different thing. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [lustre-devel] [PATCH 2/7] staging: lustre: Rename a jump label for ptlrpc_req_finished() calls @ 2015-12-14 9:31 ` Dan Carpenter 0 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2015-12-14 9:31 UTC (permalink / raw) To: lustre-devel On Mon, Dec 14, 2015 at 10:08:03AM +0100, SF Markus Elfring wrote: > > Markus, please stop sending these things to rename out labels unless > > there is a bug. CodingStyle allows out labels. > > How does this feedback fit to information like the following? > > "? > Chapter 7: ? > ? > Choose label names which say what the goto does or why the goto exists. A lot of people think "out" says what the goto does and why it exists. I personally don't agree with them but if you look at when I complain about it, it's almost always when it causes a bug. > ? Avoid using GW-BASIC names ? Those when people just use numbers for their label names instead of words like out1, out2, out4, out5. It's a different thing. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/7] staging: lustre: Rename a jump label for ptlrpc_req_finished() calls @ 2015-12-14 9:31 ` Dan Carpenter 0 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2015-12-14 9:31 UTC (permalink / raw) To: SF Markus Elfring Cc: devel, Andreas Dilger, Greg Kroah-Hartman, kernel-janitors, LKML, Oleg Drokin, Julia Lawall, lustre-devel On Mon, Dec 14, 2015 at 10:08:03AM +0100, SF Markus Elfring wrote: > > Markus, please stop sending these things to rename out labels unless > > there is a bug. CodingStyle allows out labels. > > How does this feedback fit to information like the following? > > "… > Chapter 7: … > … > Choose label names which say what the goto does or why the goto exists. A lot of people think "out" says what the goto does and why it exists. I personally don't agree with them but if you look at when I complain about it, it's almost always when it causes a bug. > … Avoid using GW-BASIC names … Those when people just use numbers for their label names instead of words like out1, out2, out4, out5. It's a different thing. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: staging: lustre: Rename a jump label for ptlrpc_req_finished() calls 2015-12-14 9:31 ` Dan Carpenter (?) @ 2015-12-14 10:03 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-14 10:03 UTC (permalink / raw) To: Dan Carpenter Cc: devel, Andreas Dilger, Greg Kroah-Hartman, kernel-janitors, LKML, Oleg Drokin, Julia Lawall, lustre-devel >>> Markus, please stop sending these things to rename out labels unless >>> there is a bug. CodingStyle allows out labels. >> >> How does this feedback fit to information like the following? >> >> "… >> Chapter 7: … >> … >> Choose label names which say what the goto does or why the goto exists. > > A lot of people think "out" says what the goto does and why it exists. I have got the impression that this short identifier is only partly appropriate. > I personally don't agree with them I guess that my opinion goes into a similar direction here. > but if you look at when I complain about it, it's almost always > when it causes a bug. I agree that the combination with bug fixing is more appealing than an attempt to improve coding style applications. >> … Avoid using GW-BASIC names … > > Those when people just use numbers for their label names instead of > words like out1, out2, out4, out5. It's a different thing. The difference is not so clear for me as it appears to you. How many software developers can still remember habits around the selection of such identifiers from GW-BASIC times? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [lustre-devel] staging: lustre: Rename a jump label for ptlrpc_req_finished() calls @ 2015-12-14 10:03 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-14 10:03 UTC (permalink / raw) To: lustre-devel >>> Markus, please stop sending these things to rename out labels unless >>> there is a bug. CodingStyle allows out labels. >> >> How does this feedback fit to information like the following? >> >> "? >> Chapter 7: ? >> ? >> Choose label names which say what the goto does or why the goto exists. > > A lot of people think "out" says what the goto does and why it exists. I have got the impression that this short identifier is only partly appropriate. > I personally don't agree with them I guess that my opinion goes into a similar direction here. > but if you look at when I complain about it, it's almost always > when it causes a bug. I agree that the combination with bug fixing is more appealing than an attempt to improve coding style applications. >> ? Avoid using GW-BASIC names ? > > Those when people just use numbers for their label names instead of > words like out1, out2, out4, out5. It's a different thing. The difference is not so clear for me as it appears to you. How many software developers can still remember habits around the selection of such identifiers from GW-BASIC times? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: staging: lustre: Rename a jump label for ptlrpc_req_finished() calls @ 2015-12-14 10:03 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-14 10:03 UTC (permalink / raw) To: Dan Carpenter Cc: devel, Andreas Dilger, Greg Kroah-Hartman, kernel-janitors, LKML, Oleg Drokin, Julia Lawall, lustre-devel >>> Markus, please stop sending these things to rename out labels unless >>> there is a bug. CodingStyle allows out labels. >> >> How does this feedback fit to information like the following? >> >> "… >> Chapter 7: … >> … >> Choose label names which say what the goto does or why the goto exists. > > A lot of people think "out" says what the goto does and why it exists. I have got the impression that this short identifier is only partly appropriate. > I personally don't agree with them I guess that my opinion goes into a similar direction here. > but if you look at when I complain about it, it's almost always > when it causes a bug. I agree that the combination with bug fixing is more appealing than an attempt to improve coding style applications. >> … Avoid using GW-BASIC names … > > Those when people just use numbers for their label names instead of > words like out1, out2, out4, out5. It's a different thing. The difference is not so clear for me as it appears to you. How many software developers can still remember habits around the selection of such identifiers from GW-BASIC times? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 3/7] staging: lustre: Rename a jump label for a kfree(key) call 2015-12-13 13:48 ` SF Markus Elfring (?) @ 2015-12-13 13:55 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-13 13:55 UTC (permalink / raw) To: Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 13 Dec 2015 10:56:35 +0100 This issue was detected by using the Coccinelle software. Choose a jump label according to the current Linux coding style convention. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/mdc/mdc_request.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/staging/lustre/lustre/mdc/mdc_request.c b/drivers/staging/lustre/lustre/mdc/mdc_request.c index 2a76685..2085ba6 100644 --- a/drivers/staging/lustre/lustre/mdc/mdc_request.c +++ b/drivers/staging/lustre/lustre/mdc/mdc_request.c @@ -1125,7 +1125,7 @@ static int mdc_ioc_fid2path(struct obd_export *exp, struct getinfo_fid2path *gf) if (!fid_is_sane(&gf->gf_fid)) { rc = -EINVAL; - goto out; + goto free_key; } /* Val is struct getinfo_fid2path result plus path */ @@ -1133,20 +1133,19 @@ static int mdc_ioc_fid2path(struct obd_export *exp, struct getinfo_fid2path *gf) rc = obd_get_info(NULL, exp, keylen, key, &vallen, gf, NULL); if (rc != 0 && rc != -EREMOTE) - goto out; + goto free_key; if (vallen <= sizeof(*gf)) { rc = -EPROTO; - goto out; + goto free_key; } else if (vallen > sizeof(*gf) + gf->gf_pathlen) { rc = -EOVERFLOW; - goto out; + goto free_key; } CDEBUG(D_IOCTL, "path get "DFID" from %llu #%d\n%s\n", PFID(&gf->gf_fid), gf->gf_recno, gf->gf_linkno, gf->gf_path); - -out: +free_key: kfree(key); return rc; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [lustre-devel] [PATCH 3/7] staging: lustre: Rename a jump label for a kfree(key) call @ 2015-12-13 13:55 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-13 13:55 UTC (permalink / raw) To: lustre-devel From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 13 Dec 2015 10:56:35 +0100 This issue was detected by using the Coccinelle software. Choose a jump label according to the current Linux coding style convention. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/mdc/mdc_request.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/staging/lustre/lustre/mdc/mdc_request.c b/drivers/staging/lustre/lustre/mdc/mdc_request.c index 2a76685..2085ba6 100644 --- a/drivers/staging/lustre/lustre/mdc/mdc_request.c +++ b/drivers/staging/lustre/lustre/mdc/mdc_request.c @@ -1125,7 +1125,7 @@ static int mdc_ioc_fid2path(struct obd_export *exp, struct getinfo_fid2path *gf) if (!fid_is_sane(&gf->gf_fid)) { rc = -EINVAL; - goto out; + goto free_key; } /* Val is struct getinfo_fid2path result plus path */ @@ -1133,20 +1133,19 @@ static int mdc_ioc_fid2path(struct obd_export *exp, struct getinfo_fid2path *gf) rc = obd_get_info(NULL, exp, keylen, key, &vallen, gf, NULL); if (rc != 0 && rc != -EREMOTE) - goto out; + goto free_key; if (vallen <= sizeof(*gf)) { rc = -EPROTO; - goto out; + goto free_key; } else if (vallen > sizeof(*gf) + gf->gf_pathlen) { rc = -EOVERFLOW; - goto out; + goto free_key; } CDEBUG(D_IOCTL, "path get "DFID" from %llu #%d\n%s\n", PFID(&gf->gf_fid), gf->gf_recno, gf->gf_linkno, gf->gf_path); - -out: +free_key: kfree(key); return rc; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 3/7] staging: lustre: Rename a jump label for a kfree(key) call @ 2015-12-13 13:55 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-13 13:55 UTC (permalink / raw) To: Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 13 Dec 2015 10:56:35 +0100 This issue was detected by using the Coccinelle software. Choose a jump label according to the current Linux coding style convention. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/mdc/mdc_request.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/staging/lustre/lustre/mdc/mdc_request.c b/drivers/staging/lustre/lustre/mdc/mdc_request.c index 2a76685..2085ba6 100644 --- a/drivers/staging/lustre/lustre/mdc/mdc_request.c +++ b/drivers/staging/lustre/lustre/mdc/mdc_request.c @@ -1125,7 +1125,7 @@ static int mdc_ioc_fid2path(struct obd_export *exp, struct getinfo_fid2path *gf) if (!fid_is_sane(&gf->gf_fid)) { rc = -EINVAL; - goto out; + goto free_key; } /* Val is struct getinfo_fid2path result plus path */ @@ -1133,20 +1133,19 @@ static int mdc_ioc_fid2path(struct obd_export *exp, struct getinfo_fid2path *gf) rc = obd_get_info(NULL, exp, keylen, key, &vallen, gf, NULL); if (rc != 0 && rc != -EREMOTE) - goto out; + goto free_key; if (vallen <= sizeof(*gf)) { rc = -EPROTO; - goto out; + goto free_key; } else if (vallen > sizeof(*gf) + gf->gf_pathlen) { rc = -EOVERFLOW; - goto out; + goto free_key; } CDEBUG(D_IOCTL, "path get "DFID" from %llu #%d\n%s\n", PFID(&gf->gf_fid), gf->gf_recno, gf->gf_linkno, gf->gf_path); - -out: +free_key: kfree(key); return rc; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 4/7] staging: lustre: Delete an unnecessary variable initialisation in mgc_process_recover_log() 2015-12-13 13:48 ` SF Markus Elfring (?) @ 2015-12-13 13:56 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-13 13:56 UTC (permalink / raw) To: Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 13 Dec 2015 12:00:32 +0100 The variable "mne_swab" will eventually be set to an appropriate value from a call of the ptlrpc_rep_need_swab() function. Thus let us omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/mgc/mgc_request.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c b/drivers/staging/lustre/lustre/mgc/mgc_request.c index 2c48847..da130f4 100644 --- a/drivers/staging/lustre/lustre/mgc/mgc_request.c +++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c @@ -1293,7 +1293,7 @@ static int mgc_process_recover_log(struct obd_device *obd, struct page **pages; int nrpages; bool eof = true; - bool mne_swab = false; + bool mne_swab; int i; int ealen; int rc; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [lustre-devel] [PATCH 4/7] staging: lustre: Delete an unnecessary variable initialisation in mgc_process_recover_log() @ 2015-12-13 13:56 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-13 13:56 UTC (permalink / raw) To: lustre-devel From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 13 Dec 2015 12:00:32 +0100 The variable "mne_swab" will eventually be set to an appropriate value from a call of the ptlrpc_rep_need_swab() function. Thus let us omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/mgc/mgc_request.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c b/drivers/staging/lustre/lustre/mgc/mgc_request.c index 2c48847..da130f4 100644 --- a/drivers/staging/lustre/lustre/mgc/mgc_request.c +++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c @@ -1293,7 +1293,7 @@ static int mgc_process_recover_log(struct obd_device *obd, struct page **pages; int nrpages; bool eof = true; - bool mne_swab = false; + bool mne_swab; int i; int ealen; int rc; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 4/7] staging: lustre: Delete an unnecessary variable initialisation in mgc_process_recover_lo @ 2015-12-13 13:56 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-13 13:56 UTC (permalink / raw) To: Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 13 Dec 2015 12:00:32 +0100 The variable "mne_swab" will eventually be set to an appropriate value from a call of the ptlrpc_rep_need_swab() function. Thus let us omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/mgc/mgc_request.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c b/drivers/staging/lustre/lustre/mgc/mgc_request.c index 2c48847..da130f4 100644 --- a/drivers/staging/lustre/lustre/mgc/mgc_request.c +++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c @@ -1293,7 +1293,7 @@ static int mgc_process_recover_log(struct obd_device *obd, struct page **pages; int nrpages; bool eof = true; - bool mne_swab = false; + bool mne_swab; int i; int ealen; int rc; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 5/7] staging: lustre: Less checks in mgc_process_recover_log() after error detection 2015-12-13 13:48 ` SF Markus Elfring (?) @ 2015-12-13 13:57 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-13 13:57 UTC (permalink / raw) To: Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 13 Dec 2015 12:21:17 +0100 A few checks would be performed by the mgc_process_recover_log() function even if it is known already that the passed variable "pages" contained a null pointer. * Let us return directly if a call of the kcalloc() function failed. * Move assignments for the variables "eof" and "req" behind this memory allocation. * Delete a sanity check then. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/mgc/mgc_request.c | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c b/drivers/staging/lustre/lustre/mgc/mgc_request.c index da130f4..f3b4c30 100644 --- a/drivers/staging/lustre/lustre/mgc/mgc_request.c +++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c @@ -1285,14 +1285,14 @@ static int mgc_apply_recover_logs(struct obd_device *mgc, static int mgc_process_recover_log(struct obd_device *obd, struct config_llog_data *cld) { - struct ptlrpc_request *req = NULL; + struct ptlrpc_request *req; struct config_llog_instance *cfg = &cld->cld_cfg; struct mgs_config_body *body; struct mgs_config_res *res; struct ptlrpc_bulk_desc *desc; struct page **pages; int nrpages; - bool eof = true; + bool eof; bool mne_swab; int i; int ealen; @@ -1309,10 +1309,11 @@ static int mgc_process_recover_log(struct obd_device *obd, nrpages = CONFIG_READ_NRPAGES_INIT; pages = kcalloc(nrpages, sizeof(*pages), GFP_KERNEL); - if (pages == NULL) { - rc = -ENOMEM; - goto out; - } + if (!pages) + return -ENOMEM; + + req = NULL; + eof = true; for (i = 0; i < nrpages; i++) { pages[i] = alloc_page(GFP_KERNEL); @@ -1432,14 +1433,12 @@ out: if (rc == 0 && !eof) goto again; - if (pages) { - for (i = 0; i < nrpages; i++) { - if (pages[i] == NULL) - break; - __free_page(pages[i]); - } - kfree(pages); + for (i = 0; i < nrpages; i++) { + if (pages[i] == NULL) + break; + __free_page(pages[i]); } + kfree(pages); return rc; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [lustre-devel] [PATCH 5/7] staging: lustre: Less checks in mgc_process_recover_log() after error detection @ 2015-12-13 13:57 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-13 13:57 UTC (permalink / raw) To: lustre-devel From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 13 Dec 2015 12:21:17 +0100 A few checks would be performed by the mgc_process_recover_log() function even if it is known already that the passed variable "pages" contained a null pointer. * Let us return directly if a call of the kcalloc() function failed. * Move assignments for the variables "eof" and "req" behind this memory allocation. * Delete a sanity check then. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/mgc/mgc_request.c | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c b/drivers/staging/lustre/lustre/mgc/mgc_request.c index da130f4..f3b4c30 100644 --- a/drivers/staging/lustre/lustre/mgc/mgc_request.c +++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c @@ -1285,14 +1285,14 @@ static int mgc_apply_recover_logs(struct obd_device *mgc, static int mgc_process_recover_log(struct obd_device *obd, struct config_llog_data *cld) { - struct ptlrpc_request *req = NULL; + struct ptlrpc_request *req; struct config_llog_instance *cfg = &cld->cld_cfg; struct mgs_config_body *body; struct mgs_config_res *res; struct ptlrpc_bulk_desc *desc; struct page **pages; int nrpages; - bool eof = true; + bool eof; bool mne_swab; int i; int ealen; @@ -1309,10 +1309,11 @@ static int mgc_process_recover_log(struct obd_device *obd, nrpages = CONFIG_READ_NRPAGES_INIT; pages = kcalloc(nrpages, sizeof(*pages), GFP_KERNEL); - if (pages == NULL) { - rc = -ENOMEM; - goto out; - } + if (!pages) + return -ENOMEM; + + req = NULL; + eof = true; for (i = 0; i < nrpages; i++) { pages[i] = alloc_page(GFP_KERNEL); @@ -1432,14 +1433,12 @@ out: if (rc == 0 && !eof) goto again; - if (pages) { - for (i = 0; i < nrpages; i++) { - if (pages[i] == NULL) - break; - __free_page(pages[i]); - } - kfree(pages); + for (i = 0; i < nrpages; i++) { + if (pages[i] == NULL) + break; + __free_page(pages[i]); } + kfree(pages); return rc; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 5/7] staging: lustre: Less checks in mgc_process_recover_log() after error detection @ 2015-12-13 13:57 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-13 13:57 UTC (permalink / raw) To: Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 13 Dec 2015 12:21:17 +0100 A few checks would be performed by the mgc_process_recover_log() function even if it is known already that the passed variable "pages" contained a null pointer. * Let us return directly if a call of the kcalloc() function failed. * Move assignments for the variables "eof" and "req" behind this memory allocation. * Delete a sanity check then. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/mgc/mgc_request.c | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c b/drivers/staging/lustre/lustre/mgc/mgc_request.c index da130f4..f3b4c30 100644 --- a/drivers/staging/lustre/lustre/mgc/mgc_request.c +++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c @@ -1285,14 +1285,14 @@ static int mgc_apply_recover_logs(struct obd_device *mgc, static int mgc_process_recover_log(struct obd_device *obd, struct config_llog_data *cld) { - struct ptlrpc_request *req = NULL; + struct ptlrpc_request *req; struct config_llog_instance *cfg = &cld->cld_cfg; struct mgs_config_body *body; struct mgs_config_res *res; struct ptlrpc_bulk_desc *desc; struct page **pages; int nrpages; - bool eof = true; + bool eof; bool mne_swab; int i; int ealen; @@ -1309,10 +1309,11 @@ static int mgc_process_recover_log(struct obd_device *obd, nrpages = CONFIG_READ_NRPAGES_INIT; pages = kcalloc(nrpages, sizeof(*pages), GFP_KERNEL); - if (pages = NULL) { - rc = -ENOMEM; - goto out; - } + if (!pages) + return -ENOMEM; + + req = NULL; + eof = true; for (i = 0; i < nrpages; i++) { pages[i] = alloc_page(GFP_KERNEL); @@ -1432,14 +1433,12 @@ out: if (rc = 0 && !eof) goto again; - if (pages) { - for (i = 0; i < nrpages; i++) { - if (pages[i] = NULL) - break; - __free_page(pages[i]); - } - kfree(pages); + for (i = 0; i < nrpages; i++) { + if (pages[i] = NULL) + break; + __free_page(pages[i]); } + kfree(pages); return rc; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 5/7] staging: lustre: Less checks in mgc_process_recover_log() after error detection 2015-12-13 13:57 ` SF Markus Elfring (?) @ 2015-12-14 11:00 ` Dan Carpenter -1 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2015-12-14 11:00 UTC (permalink / raw) To: SF Markus Elfring Cc: Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel, Julia Lawall, kernel-janitors, LKML On Sun, Dec 13, 2015 at 02:57:38PM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 13 Dec 2015 12:21:17 +0100 > > A few checks would be performed by the mgc_process_recover_log() function > even if it is known already that the passed variable "pages" contained > a null pointer. > > * Let us return directly if a call of the kcalloc() function failed. > > * Move assignments for the variables "eof" and "req" behind > this memory allocation. Why? Then in the next patch it moves again. It's like cup shuffle to read these patches sometimes. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [lustre-devel] [PATCH 5/7] staging: lustre: Less checks in mgc_process_recover_log() after error detection @ 2015-12-14 11:00 ` Dan Carpenter 0 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2015-12-14 11:00 UTC (permalink / raw) To: lustre-devel On Sun, Dec 13, 2015 at 02:57:38PM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 13 Dec 2015 12:21:17 +0100 > > A few checks would be performed by the mgc_process_recover_log() function > even if it is known already that the passed variable "pages" contained > a null pointer. > > * Let us return directly if a call of the kcalloc() function failed. > > * Move assignments for the variables "eof" and "req" behind > this memory allocation. Why? Then in the next patch it moves again. It's like cup shuffle to read these patches sometimes. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 5/7] staging: lustre: Less checks in mgc_process_recover_log() after error detection @ 2015-12-14 11:00 ` Dan Carpenter 0 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2015-12-14 11:00 UTC (permalink / raw) To: SF Markus Elfring Cc: Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel, Julia Lawall, kernel-janitors, LKML On Sun, Dec 13, 2015 at 02:57:38PM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 13 Dec 2015 12:21:17 +0100 > > A few checks would be performed by the mgc_process_recover_log() function > even if it is known already that the passed variable "pages" contained > a null pointer. > > * Let us return directly if a call of the kcalloc() function failed. > > * Move assignments for the variables "eof" and "req" behind > this memory allocation. Why? Then in the next patch it moves again. It's like cup shuffle to read these patches sometimes. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 5/7] staging: lustre: Less checks in mgc_process_recover_log() after error detection 2015-12-14 11:00 ` Dan Carpenter (?) @ 2015-12-14 12:04 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-14 12:04 UTC (permalink / raw) To: Dan Carpenter Cc: Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel, Julia Lawall, kernel-janitors, LKML >> A few checks would be performed by the mgc_process_recover_log() function >> even if it is known already that the passed variable "pages" contained >> a null pointer. >> >> * Let us return directly if a call of the kcalloc() function failed. >> >> * Move assignments for the variables "eof" and "req" behind >> this memory allocation. > > Why? The positions of their initialisation depends on the selected exception handling implementation, doesn't it? Can you accept the proposed changes around the affected memory allocations? > Then in the next patch it moves again. This detail is a matter of patch granularity. > It's like cup shuffle to read these patches sometimes. Do you prefer to stash any changes together for a bigger update step? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [lustre-devel] [PATCH 5/7] staging: lustre: Less checks in mgc_process_recover_log() after error detection @ 2015-12-14 12:04 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-14 12:04 UTC (permalink / raw) To: lustre-devel >> A few checks would be performed by the mgc_process_recover_log() function >> even if it is known already that the passed variable "pages" contained >> a null pointer. >> >> * Let us return directly if a call of the kcalloc() function failed. >> >> * Move assignments for the variables "eof" and "req" behind >> this memory allocation. > > Why? The positions of their initialisation depends on the selected exception handling implementation, doesn't it? Can you accept the proposed changes around the affected memory allocations? > Then in the next patch it moves again. This detail is a matter of patch granularity. > It's like cup shuffle to read these patches sometimes. Do you prefer to stash any changes together for a bigger update step? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 5/7] staging: lustre: Less checks in mgc_process_recover_log() after error detection @ 2015-12-14 12:04 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-14 12:04 UTC (permalink / raw) To: Dan Carpenter Cc: Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel, Julia Lawall, kernel-janitors, LKML >> A few checks would be performed by the mgc_process_recover_log() function >> even if it is known already that the passed variable "pages" contained >> a null pointer. >> >> * Let us return directly if a call of the kcalloc() function failed. >> >> * Move assignments for the variables "eof" and "req" behind >> this memory allocation. > > Why? The positions of their initialisation depends on the selected exception handling implementation, doesn't it? Can you accept the proposed changes around the affected memory allocations? > Then in the next patch it moves again. This detail is a matter of patch granularity. > It's like cup shuffle to read these patches sometimes. Do you prefer to stash any changes together for a bigger update step? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 5/7] staging: lustre: Less checks in mgc_process_recover_log() after error detection 2015-12-14 12:04 ` SF Markus Elfring (?) @ 2015-12-14 12:38 ` Dan Carpenter -1 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2015-12-14 12:38 UTC (permalink / raw) To: SF Markus Elfring Cc: devel, Andreas Dilger, Greg Kroah-Hartman, kernel-janitors, LKML, Oleg Drokin, Julia Lawall, lustre-devel On Mon, Dec 14, 2015 at 01:04:14PM +0100, SF Markus Elfring wrote: > >> A few checks would be performed by the mgc_process_recover_log() function > >> even if it is known already that the passed variable "pages" contained > >> a null pointer. > >> > >> * Let us return directly if a call of the kcalloc() function failed. > >> > >> * Move assignments for the variables "eof" and "req" behind > >> this memory allocation. > > > > Why? > > The positions of their initialisation depends on the selected exception > handling implementation, doesn't it? > > Can you accept the proposed changes around the affected memory allocations? > Just leave it as-is if there is no reason. > > > Then in the next patch it moves again. > > This detail is a matter of patch granularity. > > > > It's like cup shuffle to read these patches sometimes. > > Do you prefer to stash any changes together for a bigger update step? Yes. Patches 5 and 6 would be easier to review if they were folded into one patch. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [lustre-devel] [PATCH 5/7] staging: lustre: Less checks in mgc_process_recover_log() after error detection @ 2015-12-14 12:38 ` Dan Carpenter 0 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2015-12-14 12:38 UTC (permalink / raw) To: lustre-devel On Mon, Dec 14, 2015 at 01:04:14PM +0100, SF Markus Elfring wrote: > >> A few checks would be performed by the mgc_process_recover_log() function > >> even if it is known already that the passed variable "pages" contained > >> a null pointer. > >> > >> * Let us return directly if a call of the kcalloc() function failed. > >> > >> * Move assignments for the variables "eof" and "req" behind > >> this memory allocation. > > > > Why? > > The positions of their initialisation depends on the selected exception > handling implementation, doesn't it? > > Can you accept the proposed changes around the affected memory allocations? > Just leave it as-is if there is no reason. > > > Then in the next patch it moves again. > > This detail is a matter of patch granularity. > > > > It's like cup shuffle to read these patches sometimes. > > Do you prefer to stash any changes together for a bigger update step? Yes. Patches 5 and 6 would be easier to review if they were folded into one patch. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 5/7] staging: lustre: Less checks in mgc_process_recover_log() after error detection @ 2015-12-14 12:38 ` Dan Carpenter 0 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2015-12-14 12:38 UTC (permalink / raw) To: SF Markus Elfring Cc: devel, Andreas Dilger, Greg Kroah-Hartman, kernel-janitors, LKML, Oleg Drokin, Julia Lawall, lustre-devel On Mon, Dec 14, 2015 at 01:04:14PM +0100, SF Markus Elfring wrote: > >> A few checks would be performed by the mgc_process_recover_log() function > >> even if it is known already that the passed variable "pages" contained > >> a null pointer. > >> > >> * Let us return directly if a call of the kcalloc() function failed. > >> > >> * Move assignments for the variables "eof" and "req" behind > >> this memory allocation. > > > > Why? > > The positions of their initialisation depends on the selected exception > handling implementation, doesn't it? > > Can you accept the proposed changes around the affected memory allocations? > Just leave it as-is if there is no reason. > > > Then in the next patch it moves again. > > This detail is a matter of patch granularity. > > > > It's like cup shuffle to read these patches sometimes. > > Do you prefer to stash any changes together for a bigger update step? Yes. Patches 5 and 6 would be easier to review if they were folded into one patch. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: staging: lustre: Less checks in mgc_process_recover_log() after error detection 2015-12-14 12:38 ` Dan Carpenter (?) @ 2015-12-14 12:45 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-14 12:45 UTC (permalink / raw) To: Dan Carpenter Cc: devel, Andreas Dilger, Greg Kroah-Hartman, kernel-janitors, LKML, Oleg Drokin, Julia Lawall, lustre-devel >> Can you accept the proposed changes around the affected memory allocations? > > Just leave it as-is if there is no reason. I suggest to make the implementation of the function "mgc_process_recover_log" a bit more efficient. >> Do you prefer to stash any changes together for a bigger update step? > > Yes. Patches 5 and 6 would be easier to review if they were folded into > one patch. I do not like patch squashing for my update suggestions here. Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [lustre-devel] staging: lustre: Less checks in mgc_process_recover_log() after error detection @ 2015-12-14 12:45 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-14 12:45 UTC (permalink / raw) To: lustre-devel >> Can you accept the proposed changes around the affected memory allocations? > > Just leave it as-is if there is no reason. I suggest to make the implementation of the function "mgc_process_recover_log" a bit more efficient. >> Do you prefer to stash any changes together for a bigger update step? > > Yes. Patches 5 and 6 would be easier to review if they were folded into > one patch. I do not like patch squashing for my update suggestions here. Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: staging: lustre: Less checks in mgc_process_recover_log() after error detection @ 2015-12-14 12:45 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-14 12:45 UTC (permalink / raw) To: Dan Carpenter Cc: devel, Andreas Dilger, Greg Kroah-Hartman, kernel-janitors, LKML, Oleg Drokin, Julia Lawall, lustre-devel >> Can you accept the proposed changes around the affected memory allocations? > > Just leave it as-is if there is no reason. I suggest to make the implementation of the function "mgc_process_recover_log" a bit more efficient. >> Do you prefer to stash any changes together for a bigger update step? > > Yes. Patches 5 and 6 would be easier to review if they were folded into > one patch. I do not like patch squashing for my update suggestions here. Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: staging: lustre: Less checks in mgc_process_recover_log() after error detection 2015-12-14 12:45 ` SF Markus Elfring (?) @ 2015-12-14 13:57 ` Dan Carpenter -1 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2015-12-14 13:57 UTC (permalink / raw) To: SF Markus Elfring Cc: devel, Andreas Dilger, Greg Kroah-Hartman, kernel-janitors, LKML, Oleg Drokin, Julia Lawall, lustre-devel On Mon, Dec 14, 2015 at 01:45:11PM +0100, SF Markus Elfring wrote: > >> Do you prefer to stash any changes together for a bigger update step? > > > > Yes. Patches 5 and 6 would be easier to review if they were folded into > > one patch. > > I do not like patch squashing for my update suggestions here. I am a maintainer in drivers/staging. I am telling you what you need to do if you want us to apply your patch. What you do with that information is up to you. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [lustre-devel] staging: lustre: Less checks in mgc_process_recover_log() after error detection @ 2015-12-14 13:57 ` Dan Carpenter 0 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2015-12-14 13:57 UTC (permalink / raw) To: lustre-devel On Mon, Dec 14, 2015 at 01:45:11PM +0100, SF Markus Elfring wrote: > >> Do you prefer to stash any changes together for a bigger update step? > > > > Yes. Patches 5 and 6 would be easier to review if they were folded into > > one patch. > > I do not like patch squashing for my update suggestions here. I am a maintainer in drivers/staging. I am telling you what you need to do if you want us to apply your patch. What you do with that information is up to you. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: staging: lustre: Less checks in mgc_process_recover_log() after error detection @ 2015-12-14 13:57 ` Dan Carpenter 0 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2015-12-14 13:57 UTC (permalink / raw) To: SF Markus Elfring Cc: devel, Andreas Dilger, Greg Kroah-Hartman, kernel-janitors, LKML, Oleg Drokin, Julia Lawall, lustre-devel On Mon, Dec 14, 2015 at 01:45:11PM +0100, SF Markus Elfring wrote: > >> Do you prefer to stash any changes together for a bigger update step? > > > > Yes. Patches 5 and 6 would be easier to review if they were folded into > > one patch. > > I do not like patch squashing for my update suggestions here. I am a maintainer in drivers/staging. I am telling you what you need to do if you want us to apply your patch. What you do with that information is up to you. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: staging: lustre: Less checks in mgc_process_recover_log() after error detection 2015-12-14 13:57 ` Dan Carpenter (?) @ 2015-12-14 17:43 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-14 17:43 UTC (permalink / raw) To: Dan Carpenter Cc: devel, Andreas Dilger, Greg Kroah-Hartman, kernel-janitors, LKML, Oleg Drokin, Julia Lawall, lustre-devel >> I do not like patch squashing for my update suggestions here. > > I am a maintainer in drivers/staging. Thanks for this information. > I am telling you what you need to do if you want us to apply your patch. I am still waiting for a bit more constructive feedback for this patch series. How many days should I wait before I should send adjusted update suggestions for this approach? > What you do with that information is up to you. Our software development dialogue seems to trigger special challenges between us so far. Are you generally willing to change the exception handling for the memory allocations in the function "mgc_process_recover_log" at all? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [lustre-devel] staging: lustre: Less checks in mgc_process_recover_log() after error detection @ 2015-12-14 17:43 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-14 17:43 UTC (permalink / raw) To: lustre-devel >> I do not like patch squashing for my update suggestions here. > > I am a maintainer in drivers/staging. Thanks for this information. > I am telling you what you need to do if you want us to apply your patch. I am still waiting for a bit more constructive feedback for this patch series. How many days should I wait before I should send adjusted update suggestions for this approach? > What you do with that information is up to you. Our software development dialogue seems to trigger special challenges between us so far. Are you generally willing to change the exception handling for the memory allocations in the function "mgc_process_recover_log" at all? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: staging: lustre: Less checks in mgc_process_recover_log() after error detection @ 2015-12-14 17:43 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-14 17:43 UTC (permalink / raw) To: Dan Carpenter Cc: devel, Andreas Dilger, Greg Kroah-Hartman, kernel-janitors, LKML, Oleg Drokin, Julia Lawall, lustre-devel >> I do not like patch squashing for my update suggestions here. > > I am a maintainer in drivers/staging. Thanks for this information. > I am telling you what you need to do if you want us to apply your patch. I am still waiting for a bit more constructive feedback for this patch series. How many days should I wait before I should send adjusted update suggestions for this approach? > What you do with that information is up to you. Our software development dialogue seems to trigger special challenges between us so far. Are you generally willing to change the exception handling for the memory allocations in the function "mgc_process_recover_log" at all? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: staging: lustre: Less checks in mgc_process_recover_log() after error detection 2015-12-14 17:43 ` SF Markus Elfring (?) @ 2015-12-15 11:42 ` Dan Carpenter -1 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2015-12-15 11:42 UTC (permalink / raw) To: SF Markus Elfring Cc: devel, Andreas Dilger, Greg Kroah-Hartman, kernel-janitors, LKML, Oleg Drokin, Julia Lawall, lustre-devel On Mon, Dec 14, 2015 at 06:43:15PM +0100, SF Markus Elfring wrote: > Our software development dialogue seems to trigger special > challenges between us so far. I try very hard to review patches mechanically and not be biased so that after a while people know if their patches will be merged or not without waiting for feedback. In this case, I had asked you not to send patches renaming out labels and then the next day you sent me a string of patches renaming out labels. If you were a lustre dev then I would accept these renames definitely. But I believe that for anyone else, I would ask them what the point of doing these renames is. I do not think I have been unfair to you. There was no element of surprise. Part of the reason we have CodingStyle is so that we can tell people "That's not in CodingStyle, that's just your own opinion so don't redo code just because you have a different opinion from the maintainer." > Are you generally willing to change the exception handling for > the memory allocations in the function "mgc_process_recover_log" > at all? I like the first patch in this series. I do not like the renames. I don't care too much about patches 5 and 6 except that they should be folded together and you should not move "req" and "eof" around. Mostly I wish you would just focus on fixing bugs instead of these sorts of patches. It is a lot of work for me to explain how to redo patches but it is worth it for bugfixes. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [lustre-devel] staging: lustre: Less checks in mgc_process_recover_log() after error detection @ 2015-12-15 11:42 ` Dan Carpenter 0 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2015-12-15 11:42 UTC (permalink / raw) To: lustre-devel On Mon, Dec 14, 2015 at 06:43:15PM +0100, SF Markus Elfring wrote: > Our software development dialogue seems to trigger special > challenges between us so far. I try very hard to review patches mechanically and not be biased so that after a while people know if their patches will be merged or not without waiting for feedback. In this case, I had asked you not to send patches renaming out labels and then the next day you sent me a string of patches renaming out labels. If you were a lustre dev then I would accept these renames definitely. But I believe that for anyone else, I would ask them what the point of doing these renames is. I do not think I have been unfair to you. There was no element of surprise. Part of the reason we have CodingStyle is so that we can tell people "That's not in CodingStyle, that's just your own opinion so don't redo code just because you have a different opinion from the maintainer." > Are you generally willing to change the exception handling for > the memory allocations in the function "mgc_process_recover_log" > at all? I like the first patch in this series. I do not like the renames. I don't care too much about patches 5 and 6 except that they should be folded together and you should not move "req" and "eof" around. Mostly I wish you would just focus on fixing bugs instead of these sorts of patches. It is a lot of work for me to explain how to redo patches but it is worth it for bugfixes. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: staging: lustre: Less checks in mgc_process_recover_log() after error detection @ 2015-12-15 11:42 ` Dan Carpenter 0 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2015-12-15 11:42 UTC (permalink / raw) To: SF Markus Elfring Cc: devel, Andreas Dilger, Greg Kroah-Hartman, kernel-janitors, LKML, Oleg Drokin, Julia Lawall, lustre-devel On Mon, Dec 14, 2015 at 06:43:15PM +0100, SF Markus Elfring wrote: > Our software development dialogue seems to trigger special > challenges between us so far. I try very hard to review patches mechanically and not be biased so that after a while people know if their patches will be merged or not without waiting for feedback. In this case, I had asked you not to send patches renaming out labels and then the next day you sent me a string of patches renaming out labels. If you were a lustre dev then I would accept these renames definitely. But I believe that for anyone else, I would ask them what the point of doing these renames is. I do not think I have been unfair to you. There was no element of surprise. Part of the reason we have CodingStyle is so that we can tell people "That's not in CodingStyle, that's just your own opinion so don't redo code just because you have a different opinion from the maintainer." > Are you generally willing to change the exception handling for > the memory allocations in the function "mgc_process_recover_log" > at all? I like the first patch in this series. I do not like the renames. I don't care too much about patches 5 and 6 except that they should be folded together and you should not move "req" and "eof" around. Mostly I wish you would just focus on fixing bugs instead of these sorts of patches. It is a lot of work for me to explain how to redo patches but it is worth it for bugfixes. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: staging: lustre: Less checks in mgc_process_recover_log() after error detection 2015-12-15 11:42 ` Dan Carpenter (?) @ 2015-12-15 15:00 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-15 15:00 UTC (permalink / raw) To: Dan Carpenter Cc: devel, Andreas Dilger, Greg Kroah-Hartman, kernel-janitors, LKML, Oleg Drokin, Julia Lawall, lustre-devel > If you were a lustre dev then I would accept these renames definitely. I find this information interesting. Would any more contributors like to share their opinion? > I do not think I have been unfair to you. This view is correct in principle. > There was no element of surprise. I am trying to discuss further "special" update suggestions where the topic focus might evolve to new directions. I got the impression that you had some difficulties already with my previous proposals. So I am unsure about the general change acceptance from you alone. You pointed out that you are maintainer for this software area. I was not so aware about this detail while I noticed that you are very active Linux software developer. (You are not mentioned in the file "MAINTAINERS" for example.) > Part of the reason we have CodingStyle is so that we can tell people > "That's not in CodingStyle, that's just your own opinion so don't redo > code just because you have a different opinion from the maintainer." I find this description reasonable. But I see some challenges to improve the coding style specification. I would appreciate if some items can become less ambiguous and imprecise. I assume that a few recommendations from the script "checkpatch.pl" should also be mentioned there. > >> Are you generally willing to change the exception handling for >> the memory allocations in the function "mgc_process_recover_log" >> at all? > I like the first patch in this series. Thanks for a bit of positive feedback. > I do not like the renames. I guess that this design aspect can be clarified a bit more. > I don't care too much about patches 5 and 6 except that they should be > folded together and you should not move "req" and "eof" around. I can understand this concern better than your first response for these update steps. I might send an adjusted patch series a few days later. > Mostly I wish you would just focus on fixing bugs instead of these sorts > of patches. How often are deviations from the coding style also just ordinary bugs? It seems that changes for this area are occasionally not so attractive in comparison to software improvements for components which are more popular. Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [lustre-devel] staging: lustre: Less checks in mgc_process_recover_log() after error detection @ 2015-12-15 15:00 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-15 15:00 UTC (permalink / raw) To: lustre-devel > If you were a lustre dev then I would accept these renames definitely. I find this information interesting. Would any more contributors like to share their opinion? > I do not think I have been unfair to you. This view is correct in principle. > There was no element of surprise. I am trying to discuss further "special" update suggestions where the topic focus might evolve to new directions. I got the impression that you had some difficulties already with my previous proposals. So I am unsure about the general change acceptance from you alone. You pointed out that you are maintainer for this software area. I was not so aware about this detail while I noticed that you are very active Linux software developer. (You are not mentioned in the file "MAINTAINERS" for example.) > Part of the reason we have CodingStyle is so that we can tell people > "That's not in CodingStyle, that's just your own opinion so don't redo > code just because you have a different opinion from the maintainer." I find this description reasonable. But I see some challenges to improve the coding style specification. I would appreciate if some items can become less ambiguous and imprecise. I assume that a few recommendations from the script "checkpatch.pl" should also be mentioned there. > >> Are you generally willing to change the exception handling for >> the memory allocations in the function "mgc_process_recover_log" >> at all? > I like the first patch in this series. Thanks for a bit of positive feedback. > I do not like the renames. I guess that this design aspect can be clarified a bit more. > I don't care too much about patches 5 and 6 except that they should be > folded together and you should not move "req" and "eof" around. I can understand this concern better than your first response for these update steps. I might send an adjusted patch series a few days later. > Mostly I wish you would just focus on fixing bugs instead of these sorts > of patches. How often are deviations from the coding style also just ordinary bugs? It seems that changes for this area are occasionally not so attractive in comparison to software improvements for components which are more popular. Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: staging: lustre: Less checks in mgc_process_recover_log() after error detection @ 2015-12-15 15:00 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-15 15:00 UTC (permalink / raw) To: Dan Carpenter Cc: devel, Andreas Dilger, Greg Kroah-Hartman, kernel-janitors, LKML, Oleg Drokin, Julia Lawall, lustre-devel > If you were a lustre dev then I would accept these renames definitely. I find this information interesting. Would any more contributors like to share their opinion? > I do not think I have been unfair to you. This view is correct in principle. > There was no element of surprise. I am trying to discuss further "special" update suggestions where the topic focus might evolve to new directions. I got the impression that you had some difficulties already with my previous proposals. So I am unsure about the general change acceptance from you alone. You pointed out that you are maintainer for this software area. I was not so aware about this detail while I noticed that you are very active Linux software developer. (You are not mentioned in the file "MAINTAINERS" for example.) > Part of the reason we have CodingStyle is so that we can tell people > "That's not in CodingStyle, that's just your own opinion so don't redo > code just because you have a different opinion from the maintainer." I find this description reasonable. But I see some challenges to improve the coding style specification. I would appreciate if some items can become less ambiguous and imprecise. I assume that a few recommendations from the script "checkpatch.pl" should also be mentioned there. > >> Are you generally willing to change the exception handling for >> the memory allocations in the function "mgc_process_recover_log" >> at all? > I like the first patch in this series. Thanks for a bit of positive feedback. > I do not like the renames. I guess that this design aspect can be clarified a bit more. > I don't care too much about patches 5 and 6 except that they should be > folded together and you should not move "req" and "eof" around. I can understand this concern better than your first response for these update steps. I might send an adjusted patch series a few days later. > Mostly I wish you would just focus on fixing bugs instead of these sorts > of patches. How often are deviations from the coding style also just ordinary bugs? It seems that changes for this area are occasionally not so attractive in comparison to software improvements for components which are more popular. Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 6/7] staging: lustre: A few checks less in mgc_process_recover_log() after error detection 2015-12-13 13:48 ` SF Markus Elfring (?) @ 2015-12-13 13:58 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-13 13:58 UTC (permalink / raw) To: Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 13 Dec 2015 13:03:58 +0100 A few checks would be performed by the mgc_process_recover_log() function even if it was determined that a call of the alloc_page() function failed. * This implementation detail could be improved by adjustments for jump targets according to the Linux coding style convention. * Move the assignment for the variable "eof" behind the memory allocation. * Delete another sanity check then. * The variable "req" will eventually be set to an appropriate pointer from a call of the ptlrpc_request_alloc() function. Thus let us omit the explicit initialisation before. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/mgc/mgc_request.c | 32 +++++++++++-------------- 1 file changed, 14 insertions(+), 18 deletions(-) diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c b/drivers/staging/lustre/lustre/mgc/mgc_request.c index f3b4c30..7048722 100644 --- a/drivers/staging/lustre/lustre/mgc/mgc_request.c +++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c @@ -1312,17 +1312,15 @@ static int mgc_process_recover_log(struct obd_device *obd, if (!pages) return -ENOMEM; - req = NULL; - eof = true; - for (i = 0; i < nrpages; i++) { pages[i] = alloc_page(GFP_KERNEL); if (pages[i] == NULL) { rc = -ENOMEM; - goto out; + goto free_pages; } } + eof = true; again: LASSERT(cld_is_recover(cld)); LASSERT(mutex_is_locked(&cld->cld_lock)); @@ -1330,12 +1328,12 @@ again: &RQF_MGS_CONFIG_READ); if (req == NULL) { rc = -ENOMEM; - goto out; + goto free_pages; } rc = ptlrpc_request_pack(req, LUSTRE_MGS_VERSION, MGS_CONFIG_READ); if (rc) - goto out; + goto finish_request; /* pack request */ body = req_capsule_client_get(&req->rq_pill, &RMF_MGS_CONFIG_BODY); @@ -1344,7 +1342,7 @@ again: if (strlcpy(body->mcb_name, cld->cld_logname, sizeof(body->mcb_name)) >= sizeof(body->mcb_name)) { rc = -E2BIG; - goto out; + goto finish_request; } body->mcb_offset = cfg->cfg_last_idx + 1; body->mcb_type = cld->cld_type; @@ -1356,7 +1354,7 @@ again: MGS_BULK_PORTAL); if (desc == NULL) { rc = -ENOMEM; - goto out; + goto finish_request; } for (i = 0; i < nrpages; i++) @@ -1365,12 +1363,12 @@ again: ptlrpc_request_set_replen(req); rc = ptlrpc_queue_wait(req); if (rc) - goto out; + goto finish_request; res = req_capsule_server_get(&req->rq_pill, &RMF_MGS_CONFIG_RES); if (res->mcr_size < res->mcr_offset) { rc = -EINVAL; - goto out; + goto finish_request; } /* always update the index even though it might have errors with @@ -1384,18 +1382,18 @@ again: ealen = sptlrpc_cli_unwrap_bulk_read(req, req->rq_bulk, 0); if (ealen < 0) { rc = ealen; - goto out; + goto finish_request; } if (ealen > nrpages << PAGE_CACHE_SHIFT) { rc = -EINVAL; - goto out; + goto finish_request; } if (ealen == 0) { /* no logs transferred */ if (!eof) rc = -EINVAL; - goto out; + goto finish_request; } mne_swab = !!ptlrpc_rep_need_swab(req); @@ -1425,14 +1423,12 @@ again: ealen -= PAGE_CACHE_SIZE; } - -out: - if (req) - ptlrpc_req_finished(req); +finish_request: + ptlrpc_req_finished(req); if (rc == 0 && !eof) goto again; - +free_pages: for (i = 0; i < nrpages; i++) { if (pages[i] == NULL) break; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [lustre-devel] [PATCH 6/7] staging: lustre: A few checks less in mgc_process_recover_log() after error detection @ 2015-12-13 13:58 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-13 13:58 UTC (permalink / raw) To: lustre-devel From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 13 Dec 2015 13:03:58 +0100 A few checks would be performed by the mgc_process_recover_log() function even if it was determined that a call of the alloc_page() function failed. * This implementation detail could be improved by adjustments for jump targets according to the Linux coding style convention. * Move the assignment for the variable "eof" behind the memory allocation. * Delete another sanity check then. * The variable "req" will eventually be set to an appropriate pointer from a call of the ptlrpc_request_alloc() function. Thus let us omit the explicit initialisation before. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/mgc/mgc_request.c | 32 +++++++++++-------------- 1 file changed, 14 insertions(+), 18 deletions(-) diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c b/drivers/staging/lustre/lustre/mgc/mgc_request.c index f3b4c30..7048722 100644 --- a/drivers/staging/lustre/lustre/mgc/mgc_request.c +++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c @@ -1312,17 +1312,15 @@ static int mgc_process_recover_log(struct obd_device *obd, if (!pages) return -ENOMEM; - req = NULL; - eof = true; - for (i = 0; i < nrpages; i++) { pages[i] = alloc_page(GFP_KERNEL); if (pages[i] == NULL) { rc = -ENOMEM; - goto out; + goto free_pages; } } + eof = true; again: LASSERT(cld_is_recover(cld)); LASSERT(mutex_is_locked(&cld->cld_lock)); @@ -1330,12 +1328,12 @@ again: &RQF_MGS_CONFIG_READ); if (req == NULL) { rc = -ENOMEM; - goto out; + goto free_pages; } rc = ptlrpc_request_pack(req, LUSTRE_MGS_VERSION, MGS_CONFIG_READ); if (rc) - goto out; + goto finish_request; /* pack request */ body = req_capsule_client_get(&req->rq_pill, &RMF_MGS_CONFIG_BODY); @@ -1344,7 +1342,7 @@ again: if (strlcpy(body->mcb_name, cld->cld_logname, sizeof(body->mcb_name)) >= sizeof(body->mcb_name)) { rc = -E2BIG; - goto out; + goto finish_request; } body->mcb_offset = cfg->cfg_last_idx + 1; body->mcb_type = cld->cld_type; @@ -1356,7 +1354,7 @@ again: MGS_BULK_PORTAL); if (desc == NULL) { rc = -ENOMEM; - goto out; + goto finish_request; } for (i = 0; i < nrpages; i++) @@ -1365,12 +1363,12 @@ again: ptlrpc_request_set_replen(req); rc = ptlrpc_queue_wait(req); if (rc) - goto out; + goto finish_request; res = req_capsule_server_get(&req->rq_pill, &RMF_MGS_CONFIG_RES); if (res->mcr_size < res->mcr_offset) { rc = -EINVAL; - goto out; + goto finish_request; } /* always update the index even though it might have errors with @@ -1384,18 +1382,18 @@ again: ealen = sptlrpc_cli_unwrap_bulk_read(req, req->rq_bulk, 0); if (ealen < 0) { rc = ealen; - goto out; + goto finish_request; } if (ealen > nrpages << PAGE_CACHE_SHIFT) { rc = -EINVAL; - goto out; + goto finish_request; } if (ealen == 0) { /* no logs transferred */ if (!eof) rc = -EINVAL; - goto out; + goto finish_request; } mne_swab = !!ptlrpc_rep_need_swab(req); @@ -1425,14 +1423,12 @@ again: ealen -= PAGE_CACHE_SIZE; } - -out: - if (req) - ptlrpc_req_finished(req); +finish_request: + ptlrpc_req_finished(req); if (rc == 0 && !eof) goto again; - +free_pages: for (i = 0; i < nrpages; i++) { if (pages[i] == NULL) break; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 6/7] staging: lustre: A few checks less in mgc_process_recover_log() after error detection @ 2015-12-13 13:58 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-13 13:58 UTC (permalink / raw) To: Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 13 Dec 2015 13:03:58 +0100 A few checks would be performed by the mgc_process_recover_log() function even if it was determined that a call of the alloc_page() function failed. * This implementation detail could be improved by adjustments for jump targets according to the Linux coding style convention. * Move the assignment for the variable "eof" behind the memory allocation. * Delete another sanity check then. * The variable "req" will eventually be set to an appropriate pointer from a call of the ptlrpc_request_alloc() function. Thus let us omit the explicit initialisation before. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/mgc/mgc_request.c | 32 +++++++++++-------------- 1 file changed, 14 insertions(+), 18 deletions(-) diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c b/drivers/staging/lustre/lustre/mgc/mgc_request.c index f3b4c30..7048722 100644 --- a/drivers/staging/lustre/lustre/mgc/mgc_request.c +++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c @@ -1312,17 +1312,15 @@ static int mgc_process_recover_log(struct obd_device *obd, if (!pages) return -ENOMEM; - req = NULL; - eof = true; - for (i = 0; i < nrpages; i++) { pages[i] = alloc_page(GFP_KERNEL); if (pages[i] = NULL) { rc = -ENOMEM; - goto out; + goto free_pages; } } + eof = true; again: LASSERT(cld_is_recover(cld)); LASSERT(mutex_is_locked(&cld->cld_lock)); @@ -1330,12 +1328,12 @@ again: &RQF_MGS_CONFIG_READ); if (req = NULL) { rc = -ENOMEM; - goto out; + goto free_pages; } rc = ptlrpc_request_pack(req, LUSTRE_MGS_VERSION, MGS_CONFIG_READ); if (rc) - goto out; + goto finish_request; /* pack request */ body = req_capsule_client_get(&req->rq_pill, &RMF_MGS_CONFIG_BODY); @@ -1344,7 +1342,7 @@ again: if (strlcpy(body->mcb_name, cld->cld_logname, sizeof(body->mcb_name)) >= sizeof(body->mcb_name)) { rc = -E2BIG; - goto out; + goto finish_request; } body->mcb_offset = cfg->cfg_last_idx + 1; body->mcb_type = cld->cld_type; @@ -1356,7 +1354,7 @@ again: MGS_BULK_PORTAL); if (desc = NULL) { rc = -ENOMEM; - goto out; + goto finish_request; } for (i = 0; i < nrpages; i++) @@ -1365,12 +1363,12 @@ again: ptlrpc_request_set_replen(req); rc = ptlrpc_queue_wait(req); if (rc) - goto out; + goto finish_request; res = req_capsule_server_get(&req->rq_pill, &RMF_MGS_CONFIG_RES); if (res->mcr_size < res->mcr_offset) { rc = -EINVAL; - goto out; + goto finish_request; } /* always update the index even though it might have errors with @@ -1384,18 +1382,18 @@ again: ealen = sptlrpc_cli_unwrap_bulk_read(req, req->rq_bulk, 0); if (ealen < 0) { rc = ealen; - goto out; + goto finish_request; } if (ealen > nrpages << PAGE_CACHE_SHIFT) { rc = -EINVAL; - goto out; + goto finish_request; } if (ealen = 0) { /* no logs transferred */ if (!eof) rc = -EINVAL; - goto out; + goto finish_request; } mne_swab = !!ptlrpc_rep_need_swab(req); @@ -1425,14 +1423,12 @@ again: ealen -= PAGE_CACHE_SIZE; } - -out: - if (req) - ptlrpc_req_finished(req); +finish_request: + ptlrpc_req_finished(req); if (rc = 0 && !eof) goto again; - +free_pages: for (i = 0; i < nrpages; i++) { if (pages[i] = NULL) break; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 7/7] staging: lustre: Rename a jump label for module_put() calls 2015-12-13 13:48 ` SF Markus Elfring (?) @ 2015-12-13 14:00 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-13 14:00 UTC (permalink / raw) To: Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 13 Dec 2015 14:05:57 +0100 This issue was detected by using the Coccinelle software. Choose a jump label according to the current Linux coding style convention. I suggest to improve this implementation detail by the reuse of a script like the following for the semantic patch language. @rename_jump_label exists@ identifier target != put_module, work; type return_type; @@ return_type work(...) { ... when any goto -target +put_module ; ... when any -target +put_module : module_put(...); ... when any } Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/llite/lloop.c | 8 ++-- drivers/staging/lustre/lustre/mdc/mdc_request.c | 52 ++++++++++++------------- drivers/staging/lustre/lustre/osc/osc_request.c | 24 ++++++------ 3 files changed, 42 insertions(+), 42 deletions(-) diff --git a/drivers/staging/lustre/lustre/llite/lloop.c b/drivers/staging/lustre/lustre/llite/lloop.c index 420d391..ebeef3b 100644 --- a/drivers/staging/lustre/lustre/llite/lloop.c +++ b/drivers/staging/lustre/lustre/llite/lloop.c @@ -484,14 +484,14 @@ static int loop_set_fd(struct lloop_device *lo, struct file *unused, error = -EBUSY; if (lo->lo_state != LLOOP_UNBOUND) - goto out; + goto put_module; mapping = file->f_mapping; inode = mapping->host; error = -EINVAL; if (!S_ISREG(inode->i_mode) || inode->i_sb->s_magic != LL_SUPER_MAGIC) - goto out; + goto put_module; if (!(file->f_mode & FMODE_WRITE)) lo_flags |= LO_FLAGS_READ_ONLY; @@ -500,7 +500,7 @@ static int loop_set_fd(struct lloop_device *lo, struct file *unused, if ((loff_t)(sector_t)size != size) { error = -EFBIG; - goto out; + goto put_module; } /* remove all pages in cache so as dirty pages not to be existent. */ @@ -542,7 +542,7 @@ static int loop_set_fd(struct lloop_device *lo, struct file *unused, down(&lo->lo_sem); return 0; -out: +put_module: /* This is safe: open() is still holding a reference. */ module_put(THIS_MODULE); return error; diff --git a/drivers/staging/lustre/lustre/mdc/mdc_request.c b/drivers/staging/lustre/lustre/mdc/mdc_request.c index 2085ba6..eaeca9a 100644 --- a/drivers/staging/lustre/lustre/mdc/mdc_request.c +++ b/drivers/staging/lustre/lustre/mdc/mdc_request.c @@ -1734,7 +1734,7 @@ static int mdc_iocontrol(unsigned int cmd, struct obd_export *exp, int len, switch (cmd) { case OBD_IOC_CHANGELOG_SEND: rc = mdc_ioc_changelog_send(obd, karg); - goto out; + goto put_module; case OBD_IOC_CHANGELOG_CLEAR: { struct ioc_changelog *icc = karg; struct changelog_setinfo cs = { @@ -1745,47 +1745,47 @@ static int mdc_iocontrol(unsigned int cmd, struct obd_export *exp, int len, rc = obd_set_info_async(NULL, exp, strlen(KEY_CHANGELOG_CLEAR), KEY_CHANGELOG_CLEAR, sizeof(cs), &cs, NULL); - goto out; + goto put_module; } case OBD_IOC_FID2PATH: rc = mdc_ioc_fid2path(exp, karg); - goto out; + goto put_module; case LL_IOC_HSM_CT_START: rc = mdc_ioc_hsm_ct_start(exp, karg); /* ignore if it was already registered on this MDS. */ if (rc == -EEXIST) rc = 0; - goto out; + goto put_module; case LL_IOC_HSM_PROGRESS: rc = mdc_ioc_hsm_progress(exp, karg); - goto out; + goto put_module; case LL_IOC_HSM_STATE_GET: rc = mdc_ioc_hsm_state_get(exp, karg); - goto out; + goto put_module; case LL_IOC_HSM_STATE_SET: rc = mdc_ioc_hsm_state_set(exp, karg); - goto out; + goto put_module; case LL_IOC_HSM_ACTION: rc = mdc_ioc_hsm_current_action(exp, karg); - goto out; + goto put_module; case LL_IOC_HSM_REQUEST: rc = mdc_ioc_hsm_request(exp, karg); - goto out; + goto put_module; case OBD_IOC_CLIENT_RECOVER: rc = ptlrpc_recover_import(imp, data->ioc_inlbuf1, 0); if (rc < 0) - goto out; + goto put_module; rc = 0; - goto out; + goto put_module; case IOC_OSC_SET_ACTIVE: rc = ptlrpc_set_import_active(imp, data->ioc_offset); - goto out; + goto put_module; case OBD_IOC_POLL_QUOTACHECK: rc = mdc_quota_poll_check(exp, (struct if_quotacheck *)karg); - goto out; + goto put_module; case OBD_IOC_PING_TARGET: rc = ptlrpc_obd_ping(obd); - goto out; + goto put_module; /* * Normally IOC_OBD_STATFS, OBD_IOC_QUOTACTL iocontrol are handled by * LMV instead of MDC. But when the cluster is upgraded from 1.8, @@ -1798,7 +1798,7 @@ static int mdc_iocontrol(unsigned int cmd, struct obd_export *exp, int len, if (*((__u32 *) data->ioc_inlbuf2) != 0) { rc = -ENODEV; - goto out; + goto put_module; } /* copy UUID */ @@ -1806,24 +1806,24 @@ static int mdc_iocontrol(unsigned int cmd, struct obd_export *exp, int len, min_t(size_t, data->ioc_plen2, sizeof(struct obd_uuid)))) { rc = -EFAULT; - goto out; + goto put_module; } rc = mdc_statfs(NULL, obd->obd_self_export, &stat_buf, cfs_time_shift_64(-OBD_STATFS_CACHE_SECONDS), 0); if (rc != 0) - goto out; + goto put_module; if (copy_to_user(data->ioc_pbuf1, &stat_buf, min_t(size_t, data->ioc_plen1, sizeof(stat_buf)))) { rc = -EFAULT; - goto out; + goto put_module; } rc = 0; - goto out; + goto put_module; } case OBD_IOC_QUOTACTL: { struct if_quotactl *qctl = karg; @@ -1832,7 +1832,7 @@ static int mdc_iocontrol(unsigned int cmd, struct obd_export *exp, int len, oqctl = kzalloc(sizeof(*oqctl), GFP_NOFS); if (!oqctl) { rc = -ENOMEM; - goto out; + goto put_module; } QCTL_COPY(oqctl, qctl); @@ -1844,26 +1844,26 @@ static int mdc_iocontrol(unsigned int cmd, struct obd_export *exp, int len, } kfree(oqctl); - goto out; + goto put_module; } case LL_IOC_GET_CONNECT_FLAGS: if (copy_to_user(uarg, exp_connect_flags_ptr(exp), sizeof(*exp_connect_flags_ptr(exp)))) { rc = -EFAULT; - goto out; + goto put_module; } rc = 0; - goto out; + goto put_module; case LL_IOC_LOV_SWAP_LAYOUTS: rc = mdc_ioc_swap_layouts(exp, karg); - goto out; + goto put_module; default: CERROR("unrecognised ioctl: cmd = %#x\n", cmd); rc = -ENOTTY; - goto out; + goto put_module; } -out: +put_module: module_put(THIS_MODULE); return rc; diff --git a/drivers/staging/lustre/lustre/osc/osc_request.c b/drivers/staging/lustre/lustre/osc/osc_request.c index 3a56fb7..3ee1ff8 100644 --- a/drivers/staging/lustre/lustre/osc/osc_request.c +++ b/drivers/staging/lustre/lustre/osc/osc_request.c @@ -2611,7 +2611,7 @@ static int osc_iocontrol(unsigned int cmd, struct obd_export *exp, int len, len = 0; if (obd_ioctl_getdata(&buf, &len, uarg)) { err = -EINVAL; - goto out; + goto put_module; } data = (struct obd_ioctl_data *)buf; @@ -2619,13 +2619,13 @@ static int osc_iocontrol(unsigned int cmd, struct obd_export *exp, int len, if (sizeof(*desc) > data->ioc_inllen1) { obd_ioctl_freedata(buf, len); err = -EINVAL; - goto out; + goto put_module; } if (data->ioc_inllen2 < sizeof(uuid)) { obd_ioctl_freedata(buf, len); err = -EINVAL; - goto out; + goto put_module; } desc = (struct lov_desc *)data->ioc_inlbuf1; @@ -2643,39 +2643,39 @@ static int osc_iocontrol(unsigned int cmd, struct obd_export *exp, int len, if (err) err = -EFAULT; obd_ioctl_freedata(buf, len); - goto out; + goto put_module; } case LL_IOC_LOV_SETSTRIPE: err = obd_alloc_memmd(exp, karg); if (err > 0) err = 0; - goto out; + goto put_module; case LL_IOC_LOV_GETSTRIPE: err = osc_getstripe(karg, uarg); - goto out; + goto put_module; case OBD_IOC_CLIENT_RECOVER: err = ptlrpc_recover_import(obd->u.cli.cl_import, data->ioc_inlbuf1, 0); if (err > 0) err = 0; - goto out; + goto put_module; case IOC_OSC_SET_ACTIVE: err = ptlrpc_set_import_active(obd->u.cli.cl_import, data->ioc_offset); - goto out; + goto put_module; case OBD_IOC_POLL_QUOTACHECK: err = osc_quota_poll_check(exp, karg); - goto out; + goto put_module; case OBD_IOC_PING_TARGET: err = ptlrpc_obd_ping(obd); - goto out; + goto put_module; default: CDEBUG(D_INODE, "unrecognised ioctl %#x by %s\n", cmd, current_comm()); err = -ENOTTY; - goto out; + goto put_module; } -out: +put_module: module_put(THIS_MODULE); return err; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [lustre-devel] [PATCH 7/7] staging: lustre: Rename a jump label for module_put() calls @ 2015-12-13 14:00 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-13 14:00 UTC (permalink / raw) To: lustre-devel From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 13 Dec 2015 14:05:57 +0100 This issue was detected by using the Coccinelle software. Choose a jump label according to the current Linux coding style convention. I suggest to improve this implementation detail by the reuse of a script like the following for the semantic patch language. @rename_jump_label exists@ identifier target != put_module, work; type return_type; @@ return_type work(...) { ... when any goto -target +put_module ; ... when any -target +put_module : module_put(...); ... when any } Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/llite/lloop.c | 8 ++-- drivers/staging/lustre/lustre/mdc/mdc_request.c | 52 ++++++++++++------------- drivers/staging/lustre/lustre/osc/osc_request.c | 24 ++++++------ 3 files changed, 42 insertions(+), 42 deletions(-) diff --git a/drivers/staging/lustre/lustre/llite/lloop.c b/drivers/staging/lustre/lustre/llite/lloop.c index 420d391..ebeef3b 100644 --- a/drivers/staging/lustre/lustre/llite/lloop.c +++ b/drivers/staging/lustre/lustre/llite/lloop.c @@ -484,14 +484,14 @@ static int loop_set_fd(struct lloop_device *lo, struct file *unused, error = -EBUSY; if (lo->lo_state != LLOOP_UNBOUND) - goto out; + goto put_module; mapping = file->f_mapping; inode = mapping->host; error = -EINVAL; if (!S_ISREG(inode->i_mode) || inode->i_sb->s_magic != LL_SUPER_MAGIC) - goto out; + goto put_module; if (!(file->f_mode & FMODE_WRITE)) lo_flags |= LO_FLAGS_READ_ONLY; @@ -500,7 +500,7 @@ static int loop_set_fd(struct lloop_device *lo, struct file *unused, if ((loff_t)(sector_t)size != size) { error = -EFBIG; - goto out; + goto put_module; } /* remove all pages in cache so as dirty pages not to be existent. */ @@ -542,7 +542,7 @@ static int loop_set_fd(struct lloop_device *lo, struct file *unused, down(&lo->lo_sem); return 0; -out: +put_module: /* This is safe: open() is still holding a reference. */ module_put(THIS_MODULE); return error; diff --git a/drivers/staging/lustre/lustre/mdc/mdc_request.c b/drivers/staging/lustre/lustre/mdc/mdc_request.c index 2085ba6..eaeca9a 100644 --- a/drivers/staging/lustre/lustre/mdc/mdc_request.c +++ b/drivers/staging/lustre/lustre/mdc/mdc_request.c @@ -1734,7 +1734,7 @@ static int mdc_iocontrol(unsigned int cmd, struct obd_export *exp, int len, switch (cmd) { case OBD_IOC_CHANGELOG_SEND: rc = mdc_ioc_changelog_send(obd, karg); - goto out; + goto put_module; case OBD_IOC_CHANGELOG_CLEAR: { struct ioc_changelog *icc = karg; struct changelog_setinfo cs = { @@ -1745,47 +1745,47 @@ static int mdc_iocontrol(unsigned int cmd, struct obd_export *exp, int len, rc = obd_set_info_async(NULL, exp, strlen(KEY_CHANGELOG_CLEAR), KEY_CHANGELOG_CLEAR, sizeof(cs), &cs, NULL); - goto out; + goto put_module; } case OBD_IOC_FID2PATH: rc = mdc_ioc_fid2path(exp, karg); - goto out; + goto put_module; case LL_IOC_HSM_CT_START: rc = mdc_ioc_hsm_ct_start(exp, karg); /* ignore if it was already registered on this MDS. */ if (rc == -EEXIST) rc = 0; - goto out; + goto put_module; case LL_IOC_HSM_PROGRESS: rc = mdc_ioc_hsm_progress(exp, karg); - goto out; + goto put_module; case LL_IOC_HSM_STATE_GET: rc = mdc_ioc_hsm_state_get(exp, karg); - goto out; + goto put_module; case LL_IOC_HSM_STATE_SET: rc = mdc_ioc_hsm_state_set(exp, karg); - goto out; + goto put_module; case LL_IOC_HSM_ACTION: rc = mdc_ioc_hsm_current_action(exp, karg); - goto out; + goto put_module; case LL_IOC_HSM_REQUEST: rc = mdc_ioc_hsm_request(exp, karg); - goto out; + goto put_module; case OBD_IOC_CLIENT_RECOVER: rc = ptlrpc_recover_import(imp, data->ioc_inlbuf1, 0); if (rc < 0) - goto out; + goto put_module; rc = 0; - goto out; + goto put_module; case IOC_OSC_SET_ACTIVE: rc = ptlrpc_set_import_active(imp, data->ioc_offset); - goto out; + goto put_module; case OBD_IOC_POLL_QUOTACHECK: rc = mdc_quota_poll_check(exp, (struct if_quotacheck *)karg); - goto out; + goto put_module; case OBD_IOC_PING_TARGET: rc = ptlrpc_obd_ping(obd); - goto out; + goto put_module; /* * Normally IOC_OBD_STATFS, OBD_IOC_QUOTACTL iocontrol are handled by * LMV instead of MDC. But when the cluster is upgraded from 1.8, @@ -1798,7 +1798,7 @@ static int mdc_iocontrol(unsigned int cmd, struct obd_export *exp, int len, if (*((__u32 *) data->ioc_inlbuf2) != 0) { rc = -ENODEV; - goto out; + goto put_module; } /* copy UUID */ @@ -1806,24 +1806,24 @@ static int mdc_iocontrol(unsigned int cmd, struct obd_export *exp, int len, min_t(size_t, data->ioc_plen2, sizeof(struct obd_uuid)))) { rc = -EFAULT; - goto out; + goto put_module; } rc = mdc_statfs(NULL, obd->obd_self_export, &stat_buf, cfs_time_shift_64(-OBD_STATFS_CACHE_SECONDS), 0); if (rc != 0) - goto out; + goto put_module; if (copy_to_user(data->ioc_pbuf1, &stat_buf, min_t(size_t, data->ioc_plen1, sizeof(stat_buf)))) { rc = -EFAULT; - goto out; + goto put_module; } rc = 0; - goto out; + goto put_module; } case OBD_IOC_QUOTACTL: { struct if_quotactl *qctl = karg; @@ -1832,7 +1832,7 @@ static int mdc_iocontrol(unsigned int cmd, struct obd_export *exp, int len, oqctl = kzalloc(sizeof(*oqctl), GFP_NOFS); if (!oqctl) { rc = -ENOMEM; - goto out; + goto put_module; } QCTL_COPY(oqctl, qctl); @@ -1844,26 +1844,26 @@ static int mdc_iocontrol(unsigned int cmd, struct obd_export *exp, int len, } kfree(oqctl); - goto out; + goto put_module; } case LL_IOC_GET_CONNECT_FLAGS: if (copy_to_user(uarg, exp_connect_flags_ptr(exp), sizeof(*exp_connect_flags_ptr(exp)))) { rc = -EFAULT; - goto out; + goto put_module; } rc = 0; - goto out; + goto put_module; case LL_IOC_LOV_SWAP_LAYOUTS: rc = mdc_ioc_swap_layouts(exp, karg); - goto out; + goto put_module; default: CERROR("unrecognised ioctl: cmd = %#x\n", cmd); rc = -ENOTTY; - goto out; + goto put_module; } -out: +put_module: module_put(THIS_MODULE); return rc; diff --git a/drivers/staging/lustre/lustre/osc/osc_request.c b/drivers/staging/lustre/lustre/osc/osc_request.c index 3a56fb7..3ee1ff8 100644 --- a/drivers/staging/lustre/lustre/osc/osc_request.c +++ b/drivers/staging/lustre/lustre/osc/osc_request.c @@ -2611,7 +2611,7 @@ static int osc_iocontrol(unsigned int cmd, struct obd_export *exp, int len, len = 0; if (obd_ioctl_getdata(&buf, &len, uarg)) { err = -EINVAL; - goto out; + goto put_module; } data = (struct obd_ioctl_data *)buf; @@ -2619,13 +2619,13 @@ static int osc_iocontrol(unsigned int cmd, struct obd_export *exp, int len, if (sizeof(*desc) > data->ioc_inllen1) { obd_ioctl_freedata(buf, len); err = -EINVAL; - goto out; + goto put_module; } if (data->ioc_inllen2 < sizeof(uuid)) { obd_ioctl_freedata(buf, len); err = -EINVAL; - goto out; + goto put_module; } desc = (struct lov_desc *)data->ioc_inlbuf1; @@ -2643,39 +2643,39 @@ static int osc_iocontrol(unsigned int cmd, struct obd_export *exp, int len, if (err) err = -EFAULT; obd_ioctl_freedata(buf, len); - goto out; + goto put_module; } case LL_IOC_LOV_SETSTRIPE: err = obd_alloc_memmd(exp, karg); if (err > 0) err = 0; - goto out; + goto put_module; case LL_IOC_LOV_GETSTRIPE: err = osc_getstripe(karg, uarg); - goto out; + goto put_module; case OBD_IOC_CLIENT_RECOVER: err = ptlrpc_recover_import(obd->u.cli.cl_import, data->ioc_inlbuf1, 0); if (err > 0) err = 0; - goto out; + goto put_module; case IOC_OSC_SET_ACTIVE: err = ptlrpc_set_import_active(obd->u.cli.cl_import, data->ioc_offset); - goto out; + goto put_module; case OBD_IOC_POLL_QUOTACHECK: err = osc_quota_poll_check(exp, karg); - goto out; + goto put_module; case OBD_IOC_PING_TARGET: err = ptlrpc_obd_ping(obd); - goto out; + goto put_module; default: CDEBUG(D_INODE, "unrecognised ioctl %#x by %s\n", cmd, current_comm()); err = -ENOTTY; - goto out; + goto put_module; } -out: +put_module: module_put(THIS_MODULE); return err; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 7/7] staging: lustre: Rename a jump label for module_put() calls @ 2015-12-13 14:00 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-13 14:00 UTC (permalink / raw) To: Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin, lustre-devel, devel Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 13 Dec 2015 14:05:57 +0100 This issue was detected by using the Coccinelle software. Choose a jump label according to the current Linux coding style convention. I suggest to improve this implementation detail by the reuse of a script like the following for the semantic patch language. @rename_jump_label exists@ identifier target != put_module, work; type return_type; @@ return_type work(...) { ... when any goto -target +put_module ; ... when any -target +put_module : module_put(...); ... when any } Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/llite/lloop.c | 8 ++-- drivers/staging/lustre/lustre/mdc/mdc_request.c | 52 ++++++++++++------------- drivers/staging/lustre/lustre/osc/osc_request.c | 24 ++++++------ 3 files changed, 42 insertions(+), 42 deletions(-) diff --git a/drivers/staging/lustre/lustre/llite/lloop.c b/drivers/staging/lustre/lustre/llite/lloop.c index 420d391..ebeef3b 100644 --- a/drivers/staging/lustre/lustre/llite/lloop.c +++ b/drivers/staging/lustre/lustre/llite/lloop.c @@ -484,14 +484,14 @@ static int loop_set_fd(struct lloop_device *lo, struct file *unused, error = -EBUSY; if (lo->lo_state != LLOOP_UNBOUND) - goto out; + goto put_module; mapping = file->f_mapping; inode = mapping->host; error = -EINVAL; if (!S_ISREG(inode->i_mode) || inode->i_sb->s_magic != LL_SUPER_MAGIC) - goto out; + goto put_module; if (!(file->f_mode & FMODE_WRITE)) lo_flags |= LO_FLAGS_READ_ONLY; @@ -500,7 +500,7 @@ static int loop_set_fd(struct lloop_device *lo, struct file *unused, if ((loff_t)(sector_t)size != size) { error = -EFBIG; - goto out; + goto put_module; } /* remove all pages in cache so as dirty pages not to be existent. */ @@ -542,7 +542,7 @@ static int loop_set_fd(struct lloop_device *lo, struct file *unused, down(&lo->lo_sem); return 0; -out: +put_module: /* This is safe: open() is still holding a reference. */ module_put(THIS_MODULE); return error; diff --git a/drivers/staging/lustre/lustre/mdc/mdc_request.c b/drivers/staging/lustre/lustre/mdc/mdc_request.c index 2085ba6..eaeca9a 100644 --- a/drivers/staging/lustre/lustre/mdc/mdc_request.c +++ b/drivers/staging/lustre/lustre/mdc/mdc_request.c @@ -1734,7 +1734,7 @@ static int mdc_iocontrol(unsigned int cmd, struct obd_export *exp, int len, switch (cmd) { case OBD_IOC_CHANGELOG_SEND: rc = mdc_ioc_changelog_send(obd, karg); - goto out; + goto put_module; case OBD_IOC_CHANGELOG_CLEAR: { struct ioc_changelog *icc = karg; struct changelog_setinfo cs = { @@ -1745,47 +1745,47 @@ static int mdc_iocontrol(unsigned int cmd, struct obd_export *exp, int len, rc = obd_set_info_async(NULL, exp, strlen(KEY_CHANGELOG_CLEAR), KEY_CHANGELOG_CLEAR, sizeof(cs), &cs, NULL); - goto out; + goto put_module; } case OBD_IOC_FID2PATH: rc = mdc_ioc_fid2path(exp, karg); - goto out; + goto put_module; case LL_IOC_HSM_CT_START: rc = mdc_ioc_hsm_ct_start(exp, karg); /* ignore if it was already registered on this MDS. */ if (rc = -EEXIST) rc = 0; - goto out; + goto put_module; case LL_IOC_HSM_PROGRESS: rc = mdc_ioc_hsm_progress(exp, karg); - goto out; + goto put_module; case LL_IOC_HSM_STATE_GET: rc = mdc_ioc_hsm_state_get(exp, karg); - goto out; + goto put_module; case LL_IOC_HSM_STATE_SET: rc = mdc_ioc_hsm_state_set(exp, karg); - goto out; + goto put_module; case LL_IOC_HSM_ACTION: rc = mdc_ioc_hsm_current_action(exp, karg); - goto out; + goto put_module; case LL_IOC_HSM_REQUEST: rc = mdc_ioc_hsm_request(exp, karg); - goto out; + goto put_module; case OBD_IOC_CLIENT_RECOVER: rc = ptlrpc_recover_import(imp, data->ioc_inlbuf1, 0); if (rc < 0) - goto out; + goto put_module; rc = 0; - goto out; + goto put_module; case IOC_OSC_SET_ACTIVE: rc = ptlrpc_set_import_active(imp, data->ioc_offset); - goto out; + goto put_module; case OBD_IOC_POLL_QUOTACHECK: rc = mdc_quota_poll_check(exp, (struct if_quotacheck *)karg); - goto out; + goto put_module; case OBD_IOC_PING_TARGET: rc = ptlrpc_obd_ping(obd); - goto out; + goto put_module; /* * Normally IOC_OBD_STATFS, OBD_IOC_QUOTACTL iocontrol are handled by * LMV instead of MDC. But when the cluster is upgraded from 1.8, @@ -1798,7 +1798,7 @@ static int mdc_iocontrol(unsigned int cmd, struct obd_export *exp, int len, if (*((__u32 *) data->ioc_inlbuf2) != 0) { rc = -ENODEV; - goto out; + goto put_module; } /* copy UUID */ @@ -1806,24 +1806,24 @@ static int mdc_iocontrol(unsigned int cmd, struct obd_export *exp, int len, min_t(size_t, data->ioc_plen2, sizeof(struct obd_uuid)))) { rc = -EFAULT; - goto out; + goto put_module; } rc = mdc_statfs(NULL, obd->obd_self_export, &stat_buf, cfs_time_shift_64(-OBD_STATFS_CACHE_SECONDS), 0); if (rc != 0) - goto out; + goto put_module; if (copy_to_user(data->ioc_pbuf1, &stat_buf, min_t(size_t, data->ioc_plen1, sizeof(stat_buf)))) { rc = -EFAULT; - goto out; + goto put_module; } rc = 0; - goto out; + goto put_module; } case OBD_IOC_QUOTACTL: { struct if_quotactl *qctl = karg; @@ -1832,7 +1832,7 @@ static int mdc_iocontrol(unsigned int cmd, struct obd_export *exp, int len, oqctl = kzalloc(sizeof(*oqctl), GFP_NOFS); if (!oqctl) { rc = -ENOMEM; - goto out; + goto put_module; } QCTL_COPY(oqctl, qctl); @@ -1844,26 +1844,26 @@ static int mdc_iocontrol(unsigned int cmd, struct obd_export *exp, int len, } kfree(oqctl); - goto out; + goto put_module; } case LL_IOC_GET_CONNECT_FLAGS: if (copy_to_user(uarg, exp_connect_flags_ptr(exp), sizeof(*exp_connect_flags_ptr(exp)))) { rc = -EFAULT; - goto out; + goto put_module; } rc = 0; - goto out; + goto put_module; case LL_IOC_LOV_SWAP_LAYOUTS: rc = mdc_ioc_swap_layouts(exp, karg); - goto out; + goto put_module; default: CERROR("unrecognised ioctl: cmd = %#x\n", cmd); rc = -ENOTTY; - goto out; + goto put_module; } -out: +put_module: module_put(THIS_MODULE); return rc; diff --git a/drivers/staging/lustre/lustre/osc/osc_request.c b/drivers/staging/lustre/lustre/osc/osc_request.c index 3a56fb7..3ee1ff8 100644 --- a/drivers/staging/lustre/lustre/osc/osc_request.c +++ b/drivers/staging/lustre/lustre/osc/osc_request.c @@ -2611,7 +2611,7 @@ static int osc_iocontrol(unsigned int cmd, struct obd_export *exp, int len, len = 0; if (obd_ioctl_getdata(&buf, &len, uarg)) { err = -EINVAL; - goto out; + goto put_module; } data = (struct obd_ioctl_data *)buf; @@ -2619,13 +2619,13 @@ static int osc_iocontrol(unsigned int cmd, struct obd_export *exp, int len, if (sizeof(*desc) > data->ioc_inllen1) { obd_ioctl_freedata(buf, len); err = -EINVAL; - goto out; + goto put_module; } if (data->ioc_inllen2 < sizeof(uuid)) { obd_ioctl_freedata(buf, len); err = -EINVAL; - goto out; + goto put_module; } desc = (struct lov_desc *)data->ioc_inlbuf1; @@ -2643,39 +2643,39 @@ static int osc_iocontrol(unsigned int cmd, struct obd_export *exp, int len, if (err) err = -EFAULT; obd_ioctl_freedata(buf, len); - goto out; + goto put_module; } case LL_IOC_LOV_SETSTRIPE: err = obd_alloc_memmd(exp, karg); if (err > 0) err = 0; - goto out; + goto put_module; case LL_IOC_LOV_GETSTRIPE: err = osc_getstripe(karg, uarg); - goto out; + goto put_module; case OBD_IOC_CLIENT_RECOVER: err = ptlrpc_recover_import(obd->u.cli.cl_import, data->ioc_inlbuf1, 0); if (err > 0) err = 0; - goto out; + goto put_module; case IOC_OSC_SET_ACTIVE: err = ptlrpc_set_import_active(obd->u.cli.cl_import, data->ioc_offset); - goto out; + goto put_module; case OBD_IOC_POLL_QUOTACHECK: err = osc_quota_poll_check(exp, karg); - goto out; + goto put_module; case OBD_IOC_PING_TARGET: err = ptlrpc_obd_ping(obd); - goto out; + goto put_module; default: CDEBUG(D_INODE, "unrecognised ioctl %#x by %s\n", cmd, current_comm()); err = -ENOTTY; - goto out; + goto put_module; } -out: +put_module: module_put(THIS_MODULE); return err; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH v2 0/4] staging-Lustre: Fine-tuning for some function implementations 2015-12-13 13:48 ` SF Markus Elfring @ 2015-12-21 19:05 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-21 19:05 UTC (permalink / raw) To: lustre-devel, devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Mon, 21 Dec 2015 20:00:02 +0100 Several update suggestions were taken into account from static source code analysis. Markus Elfring (4): Delete unnecessary goto statements in six functions Delete an unnecessary variable initialisation in mgc_process_recover_log() Less checks in mgc_process_recover_log() after error detection Fix a jump label position in osc_get_info() drivers/staging/lustre/lustre/llite/namei.c | 1 - drivers/staging/lustre/lustre/mdc/mdc_request.c | 7 ---- drivers/staging/lustre/lustre/mgc/mgc_request.c | 53 +++++++++++-------------- drivers/staging/lustre/lustre/osc/osc_request.c | 2 +- 4 files changed, 25 insertions(+), 38 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH v2 0/4] staging-Lustre: Fine-tuning for some function implementations @ 2015-12-21 19:05 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-21 19:05 UTC (permalink / raw) To: lustre-devel, devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Mon, 21 Dec 2015 20:00:02 +0100 Several update suggestions were taken into account from static source code analysis. Markus Elfring (4): Delete unnecessary goto statements in six functions Delete an unnecessary variable initialisation in mgc_process_recover_log() Less checks in mgc_process_recover_log() after error detection Fix a jump label position in osc_get_info() drivers/staging/lustre/lustre/llite/namei.c | 1 - drivers/staging/lustre/lustre/mdc/mdc_request.c | 7 ---- drivers/staging/lustre/lustre/mgc/mgc_request.c | 53 +++++++++++-------------- drivers/staging/lustre/lustre/osc/osc_request.c | 2 +- 4 files changed, 25 insertions(+), 38 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH v2 1/4] staging: lustre: Delete unnecessary goto statements in six functions 2015-12-21 19:05 ` SF Markus Elfring @ 2015-12-21 19:09 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-21 19:09 UTC (permalink / raw) To: lustre-devel, devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Mon, 21 Dec 2015 18:15:45 +0100 Six goto statements referred to a source code position directly behind them. Thus omit such unnecessary jumps. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/llite/namei.c | 1 - drivers/staging/lustre/lustre/mdc/mdc_request.c | 7 ------- 2 files changed, 8 deletions(-) diff --git a/drivers/staging/lustre/lustre/llite/namei.c b/drivers/staging/lustre/lustre/llite/namei.c index 64db5e8..2113dd4 100644 --- a/drivers/staging/lustre/lustre/llite/namei.c +++ b/drivers/staging/lustre/lustre/llite/namei.c @@ -554,7 +554,6 @@ static struct dentry *ll_lookup_it(struct inode *parent, struct dentry *dentry, retval = NULL; else retval = dentry; - goto out; out: if (req) ptlrpc_req_finished(req); diff --git a/drivers/staging/lustre/lustre/mdc/mdc_request.c b/drivers/staging/lustre/lustre/mdc/mdc_request.c index 294c050..920b1e9 100644 --- a/drivers/staging/lustre/lustre/mdc/mdc_request.c +++ b/drivers/staging/lustre/lustre/mdc/mdc_request.c @@ -1181,7 +1181,6 @@ static int mdc_ioc_hsm_progress(struct obd_export *exp, ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); - goto out; out: ptlrpc_req_finished(req); return rc; @@ -1216,7 +1215,6 @@ static int mdc_ioc_hsm_ct_register(struct obd_import *imp, __u32 archives) ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); - goto out; out: ptlrpc_req_finished(req); return rc; @@ -1282,7 +1280,6 @@ static int mdc_ioc_hsm_ct_unregister(struct obd_import *imp) ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); - goto out; out: ptlrpc_req_finished(req); return rc; @@ -1362,8 +1359,6 @@ static int mdc_ioc_hsm_state_set(struct obd_export *exp, ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); - goto out; - out: ptlrpc_req_finished(req); return rc; @@ -1427,8 +1422,6 @@ static int mdc_ioc_hsm_request(struct obd_export *exp, ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); - goto out; - out: ptlrpc_req_finished(req); return rc; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH v2 1/4] staging: lustre: Delete unnecessary goto statements in six functions @ 2015-12-21 19:09 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-21 19:09 UTC (permalink / raw) To: lustre-devel, devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Mon, 21 Dec 2015 18:15:45 +0100 Six goto statements referred to a source code position directly behind them. Thus omit such unnecessary jumps. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/llite/namei.c | 1 - drivers/staging/lustre/lustre/mdc/mdc_request.c | 7 ------- 2 files changed, 8 deletions(-) diff --git a/drivers/staging/lustre/lustre/llite/namei.c b/drivers/staging/lustre/lustre/llite/namei.c index 64db5e8..2113dd4 100644 --- a/drivers/staging/lustre/lustre/llite/namei.c +++ b/drivers/staging/lustre/lustre/llite/namei.c @@ -554,7 +554,6 @@ static struct dentry *ll_lookup_it(struct inode *parent, struct dentry *dentry, retval = NULL; else retval = dentry; - goto out; out: if (req) ptlrpc_req_finished(req); diff --git a/drivers/staging/lustre/lustre/mdc/mdc_request.c b/drivers/staging/lustre/lustre/mdc/mdc_request.c index 294c050..920b1e9 100644 --- a/drivers/staging/lustre/lustre/mdc/mdc_request.c +++ b/drivers/staging/lustre/lustre/mdc/mdc_request.c @@ -1181,7 +1181,6 @@ static int mdc_ioc_hsm_progress(struct obd_export *exp, ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); - goto out; out: ptlrpc_req_finished(req); return rc; @@ -1216,7 +1215,6 @@ static int mdc_ioc_hsm_ct_register(struct obd_import *imp, __u32 archives) ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); - goto out; out: ptlrpc_req_finished(req); return rc; @@ -1282,7 +1280,6 @@ static int mdc_ioc_hsm_ct_unregister(struct obd_import *imp) ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); - goto out; out: ptlrpc_req_finished(req); return rc; @@ -1362,8 +1359,6 @@ static int mdc_ioc_hsm_state_set(struct obd_export *exp, ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); - goto out; - out: ptlrpc_req_finished(req); return rc; @@ -1427,8 +1422,6 @@ static int mdc_ioc_hsm_request(struct obd_export *exp, ptlrpc_request_set_replen(req); rc = mdc_queue_wait(req); - goto out; - out: ptlrpc_req_finished(req); return rc; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH v2 2/4] staging: lustre: Delete an unnecessary variable initialisation in mgc_process_recover_log() 2015-12-21 19:05 ` SF Markus Elfring @ 2015-12-21 19:10 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-21 19:10 UTC (permalink / raw) To: lustre-devel, devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Mon, 21 Dec 2015 18:24:45 +0100 The variable "mne_swab" will eventually be set to an appropriate value from a call of the ptlrpc_rep_need_swab() function. Thus let us omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/mgc/mgc_request.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c b/drivers/staging/lustre/lustre/mgc/mgc_request.c index 2c48847..da130f4 100644 --- a/drivers/staging/lustre/lustre/mgc/mgc_request.c +++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c @@ -1293,7 +1293,7 @@ static int mgc_process_recover_log(struct obd_device *obd, struct page **pages; int nrpages; bool eof = true; - bool mne_swab = false; + bool mne_swab; int i; int ealen; int rc; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH v2 2/4] staging: lustre: Delete an unnecessary variable initialisation in mgc_process_recover @ 2015-12-21 19:10 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-21 19:10 UTC (permalink / raw) To: lustre-devel, devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Mon, 21 Dec 2015 18:24:45 +0100 The variable "mne_swab" will eventually be set to an appropriate value from a call of the ptlrpc_rep_need_swab() function. Thus let us omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/mgc/mgc_request.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c b/drivers/staging/lustre/lustre/mgc/mgc_request.c index 2c48847..da130f4 100644 --- a/drivers/staging/lustre/lustre/mgc/mgc_request.c +++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c @@ -1293,7 +1293,7 @@ static int mgc_process_recover_log(struct obd_device *obd, struct page **pages; int nrpages; bool eof = true; - bool mne_swab = false; + bool mne_swab; int i; int ealen; int rc; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH v2 3/4] staging: lustre: Less checks in mgc_process_recover_log() after error detection 2015-12-21 19:05 ` SF Markus Elfring @ 2015-12-21 19:12 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-21 19:12 UTC (permalink / raw) To: lustre-devel, devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Mon, 21 Dec 2015 18:58:51 +0100 A few checks would be performed by the mgc_process_recover_log() function even though it was determined that the passed variable "pages" contained a null pointer or a call of the alloc_page() function failed. 1. Let us return directly if a call of the kcalloc() function failed. 2. Corresponding implementation details could be improved by adjustments for jump targets according to the Linux coding style convention. 3. Delete sanity checks then. 4. Move an assignment for the variable "eof" behind memory allocations. 5. The variable "req" will eventually be set to an appropriate pointer from a call of the ptlrpc_request_alloc() function. Thus let us omit the explicit initialisation before. 6. Apply a recommendation from the script "checkpatch.pl". Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/mgc/mgc_request.c | 51 +++++++++++-------------- 1 file changed, 23 insertions(+), 28 deletions(-) diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c b/drivers/staging/lustre/lustre/mgc/mgc_request.c index da130f4..5f581df 100644 --- a/drivers/staging/lustre/lustre/mgc/mgc_request.c +++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c @@ -1285,14 +1285,14 @@ static int mgc_apply_recover_logs(struct obd_device *mgc, static int mgc_process_recover_log(struct obd_device *obd, struct config_llog_data *cld) { - struct ptlrpc_request *req = NULL; + struct ptlrpc_request *req; struct config_llog_instance *cfg = &cld->cld_cfg; struct mgs_config_body *body; struct mgs_config_res *res; struct ptlrpc_bulk_desc *desc; struct page **pages; int nrpages; - bool eof = true; + bool eof; bool mne_swab; int i; int ealen; @@ -1309,19 +1309,18 @@ static int mgc_process_recover_log(struct obd_device *obd, nrpages = CONFIG_READ_NRPAGES_INIT; pages = kcalloc(nrpages, sizeof(*pages), GFP_KERNEL); - if (pages == NULL) { - rc = -ENOMEM; - goto out; - } + if (!pages) + return -ENOMEM; for (i = 0; i < nrpages; i++) { pages[i] = alloc_page(GFP_KERNEL); if (pages[i] == NULL) { rc = -ENOMEM; - goto out; + goto free_pages; } } + eof = true; again: LASSERT(cld_is_recover(cld)); LASSERT(mutex_is_locked(&cld->cld_lock)); @@ -1329,12 +1328,12 @@ again: &RQF_MGS_CONFIG_READ); if (req == NULL) { rc = -ENOMEM; - goto out; + goto free_pages; } rc = ptlrpc_request_pack(req, LUSTRE_MGS_VERSION, MGS_CONFIG_READ); if (rc) - goto out; + goto finish_request; /* pack request */ body = req_capsule_client_get(&req->rq_pill, &RMF_MGS_CONFIG_BODY); @@ -1343,7 +1342,7 @@ again: if (strlcpy(body->mcb_name, cld->cld_logname, sizeof(body->mcb_name)) >= sizeof(body->mcb_name)) { rc = -E2BIG; - goto out; + goto finish_request; } body->mcb_offset = cfg->cfg_last_idx + 1; body->mcb_type = cld->cld_type; @@ -1355,7 +1354,7 @@ again: MGS_BULK_PORTAL); if (desc == NULL) { rc = -ENOMEM; - goto out; + goto finish_request; } for (i = 0; i < nrpages; i++) @@ -1364,12 +1363,12 @@ again: ptlrpc_request_set_replen(req); rc = ptlrpc_queue_wait(req); if (rc) - goto out; + goto finish_request; res = req_capsule_server_get(&req->rq_pill, &RMF_MGS_CONFIG_RES); if (res->mcr_size < res->mcr_offset) { rc = -EINVAL; - goto out; + goto finish_request; } /* always update the index even though it might have errors with @@ -1383,18 +1382,18 @@ again: ealen = sptlrpc_cli_unwrap_bulk_read(req, req->rq_bulk, 0); if (ealen < 0) { rc = ealen; - goto out; + goto finish_request; } if (ealen > nrpages << PAGE_CACHE_SHIFT) { rc = -EINVAL; - goto out; + goto finish_request; } if (ealen == 0) { /* no logs transferred */ if (!eof) rc = -EINVAL; - goto out; + goto finish_request; } mne_swab = !!ptlrpc_rep_need_swab(req); @@ -1424,22 +1423,18 @@ again: ealen -= PAGE_CACHE_SIZE; } - -out: - if (req) - ptlrpc_req_finished(req); +finish_request: + ptlrpc_req_finished(req); if (rc == 0 && !eof) goto again; - - if (pages) { - for (i = 0; i < nrpages; i++) { - if (pages[i] == NULL) - break; - __free_page(pages[i]); - } - kfree(pages); +free_pages: + for (i = 0; i < nrpages; i++) { + if (!(pages[i])) + break; + __free_page(pages[i]); } + kfree(pages); return rc; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH v2 3/4] staging: lustre: Less checks in mgc_process_recover_log() after error detection @ 2015-12-21 19:12 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-21 19:12 UTC (permalink / raw) To: lustre-devel, devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Mon, 21 Dec 2015 18:58:51 +0100 A few checks would be performed by the mgc_process_recover_log() function even though it was determined that the passed variable "pages" contained a null pointer or a call of the alloc_page() function failed. 1. Let us return directly if a call of the kcalloc() function failed. 2. Corresponding implementation details could be improved by adjustments for jump targets according to the Linux coding style convention. 3. Delete sanity checks then. 4. Move an assignment for the variable "eof" behind memory allocations. 5. The variable "req" will eventually be set to an appropriate pointer from a call of the ptlrpc_request_alloc() function. Thus let us omit the explicit initialisation before. 6. Apply a recommendation from the script "checkpatch.pl". Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/mgc/mgc_request.c | 51 +++++++++++-------------- 1 file changed, 23 insertions(+), 28 deletions(-) diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c b/drivers/staging/lustre/lustre/mgc/mgc_request.c index da130f4..5f581df 100644 --- a/drivers/staging/lustre/lustre/mgc/mgc_request.c +++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c @@ -1285,14 +1285,14 @@ static int mgc_apply_recover_logs(struct obd_device *mgc, static int mgc_process_recover_log(struct obd_device *obd, struct config_llog_data *cld) { - struct ptlrpc_request *req = NULL; + struct ptlrpc_request *req; struct config_llog_instance *cfg = &cld->cld_cfg; struct mgs_config_body *body; struct mgs_config_res *res; struct ptlrpc_bulk_desc *desc; struct page **pages; int nrpages; - bool eof = true; + bool eof; bool mne_swab; int i; int ealen; @@ -1309,19 +1309,18 @@ static int mgc_process_recover_log(struct obd_device *obd, nrpages = CONFIG_READ_NRPAGES_INIT; pages = kcalloc(nrpages, sizeof(*pages), GFP_KERNEL); - if (pages = NULL) { - rc = -ENOMEM; - goto out; - } + if (!pages) + return -ENOMEM; for (i = 0; i < nrpages; i++) { pages[i] = alloc_page(GFP_KERNEL); if (pages[i] = NULL) { rc = -ENOMEM; - goto out; + goto free_pages; } } + eof = true; again: LASSERT(cld_is_recover(cld)); LASSERT(mutex_is_locked(&cld->cld_lock)); @@ -1329,12 +1328,12 @@ again: &RQF_MGS_CONFIG_READ); if (req = NULL) { rc = -ENOMEM; - goto out; + goto free_pages; } rc = ptlrpc_request_pack(req, LUSTRE_MGS_VERSION, MGS_CONFIG_READ); if (rc) - goto out; + goto finish_request; /* pack request */ body = req_capsule_client_get(&req->rq_pill, &RMF_MGS_CONFIG_BODY); @@ -1343,7 +1342,7 @@ again: if (strlcpy(body->mcb_name, cld->cld_logname, sizeof(body->mcb_name)) >= sizeof(body->mcb_name)) { rc = -E2BIG; - goto out; + goto finish_request; } body->mcb_offset = cfg->cfg_last_idx + 1; body->mcb_type = cld->cld_type; @@ -1355,7 +1354,7 @@ again: MGS_BULK_PORTAL); if (desc = NULL) { rc = -ENOMEM; - goto out; + goto finish_request; } for (i = 0; i < nrpages; i++) @@ -1364,12 +1363,12 @@ again: ptlrpc_request_set_replen(req); rc = ptlrpc_queue_wait(req); if (rc) - goto out; + goto finish_request; res = req_capsule_server_get(&req->rq_pill, &RMF_MGS_CONFIG_RES); if (res->mcr_size < res->mcr_offset) { rc = -EINVAL; - goto out; + goto finish_request; } /* always update the index even though it might have errors with @@ -1383,18 +1382,18 @@ again: ealen = sptlrpc_cli_unwrap_bulk_read(req, req->rq_bulk, 0); if (ealen < 0) { rc = ealen; - goto out; + goto finish_request; } if (ealen > nrpages << PAGE_CACHE_SHIFT) { rc = -EINVAL; - goto out; + goto finish_request; } if (ealen = 0) { /* no logs transferred */ if (!eof) rc = -EINVAL; - goto out; + goto finish_request; } mne_swab = !!ptlrpc_rep_need_swab(req); @@ -1424,22 +1423,18 @@ again: ealen -= PAGE_CACHE_SIZE; } - -out: - if (req) - ptlrpc_req_finished(req); +finish_request: + ptlrpc_req_finished(req); if (rc = 0 && !eof) goto again; - - if (pages) { - for (i = 0; i < nrpages; i++) { - if (pages[i] = NULL) - break; - __free_page(pages[i]); - } - kfree(pages); +free_pages: + for (i = 0; i < nrpages; i++) { + if (!(pages[i])) + break; + __free_page(pages[i]); } + kfree(pages); return rc; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH v2 3/4] staging: lustre: Less checks in mgc_process_recover_log() after error detection 2015-12-21 19:12 ` SF Markus Elfring @ 2015-12-21 23:48 ` Greg Kroah-Hartman -1 siblings, 0 replies; 3089+ messages in thread From: Greg Kroah-Hartman @ 2015-12-21 23:48 UTC (permalink / raw) To: SF Markus Elfring Cc: lustre-devel, devel, Andreas Dilger, Oleg Drokin, LKML, kernel-janitors, Julia Lawall On Mon, Dec 21, 2015 at 08:12:12PM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Mon, 21 Dec 2015 18:58:51 +0100 > > A few checks would be performed by the mgc_process_recover_log() function > even though it was determined that the passed variable "pages" contained > a null pointer or a call of the alloc_page() function failed. > > 1. Let us return directly if a call of the kcalloc() function failed. > > 2. Corresponding implementation details could be improved by adjustments > for jump targets according to the Linux coding style convention. > > 3. Delete sanity checks then. > > 4. Move an assignment for the variable "eof" behind memory allocations. > > 5. The variable "req" will eventually be set to an appropriate pointer > from a call of the ptlrpc_request_alloc() function. > Thus let us omit the explicit initialisation before. > > 6. Apply a recommendation from the script "checkpatch.pl". That's 6 different things, shouldn't this be 6 different patches? please redo. thanks, greg k-h ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH v2 3/4] staging: lustre: Less checks in mgc_process_recover_log() after error detection @ 2015-12-21 23:48 ` Greg Kroah-Hartman 0 siblings, 0 replies; 3089+ messages in thread From: Greg Kroah-Hartman @ 2015-12-21 23:48 UTC (permalink / raw) To: SF Markus Elfring Cc: lustre-devel, devel, Andreas Dilger, Oleg Drokin, LKML, kernel-janitors, Julia Lawall On Mon, Dec 21, 2015 at 08:12:12PM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Mon, 21 Dec 2015 18:58:51 +0100 > > A few checks would be performed by the mgc_process_recover_log() function > even though it was determined that the passed variable "pages" contained > a null pointer or a call of the alloc_page() function failed. > > 1. Let us return directly if a call of the kcalloc() function failed. > > 2. Corresponding implementation details could be improved by adjustments > for jump targets according to the Linux coding style convention. > > 3. Delete sanity checks then. > > 4. Move an assignment for the variable "eof" behind memory allocations. > > 5. The variable "req" will eventually be set to an appropriate pointer > from a call of the ptlrpc_request_alloc() function. > Thus let us omit the explicit initialisation before. > > 6. Apply a recommendation from the script "checkpatch.pl". That's 6 different things, shouldn't this be 6 different patches? please redo. thanks, greg k-h ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH v2 3/4] staging: lustre: Less checks in mgc_process_recover_log() after error detection 2015-12-21 23:48 ` Greg Kroah-Hartman @ 2015-12-22 7:15 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-22 7:15 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: lustre-devel, devel, Andreas Dilger, Oleg Drokin, LKML, kernel-janitors, Julia Lawall, Dan Carpenter >> 6. Apply a recommendation from the script "checkpatch.pl". > > That's 6 different things, shouldn't this be 6 different patches? > > please redo. Dan Carpenter requested to squash the previous update steps 5 and 6 into a single patch for better source code review. Now I see further software development challenges to increase the patch granularity even more as you suggest. Which route would Lustre developers like to follow? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH v2 3/4] staging: lustre: Less checks in mgc_process_recover_log() after error detection @ 2015-12-22 7:15 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-22 7:15 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: lustre-devel, devel, Andreas Dilger, Oleg Drokin, LKML, kernel-janitors, Julia Lawall, Dan Carpenter >> 6. Apply a recommendation from the script "checkpatch.pl". > > That's 6 different things, shouldn't this be 6 different patches? > > please redo. Dan Carpenter requested to squash the previous update steps 5 and 6 into a single patch for better source code review. Now I see further software development challenges to increase the patch granularity even more as you suggest. Which route would Lustre developers like to follow? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH v2 3/4] staging: lustre: Less checks in mgc_process_recover_log() after error detection 2015-12-21 23:48 ` Greg Kroah-Hartman @ 2015-12-22 8:00 ` Dan Carpenter -1 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2015-12-22 8:00 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: SF Markus Elfring, devel, Andreas Dilger, kernel-janitors, LKML, Oleg Drokin, Julia Lawall, lustre-devel On Mon, Dec 21, 2015 at 03:48:57PM -0800, Greg Kroah-Hartman wrote: > > That's 6 different things, shouldn't this be 6 different patches? > Not really. The patch could be described as just "change from using one exit label to using several." Markus has sent a number of these patches and I am CC'd on them because of kernel-janitors, it's really painful to review when he breaks them up into tiny patches where he changes one label at a time. It's like trying to put coleslaw back together into a head of cabbage. > On Mon, Dec 21, 2015 at 08:12:12PM +0100, SF Markus Elfring wrote: > > From: Markus Elfring <elfring@users.sourceforge.net> > > Date: Mon, 21 Dec 2015 18:58:51 +0100 > > > > A few checks would be performed by the mgc_process_recover_log() function > > even though it was determined that the passed variable "pages" contained > > a null pointer or a call of the alloc_page() function failed. > > > > 1. Let us return directly if a call of the kcalloc() function failed. > > > > 2. Corresponding implementation details could be improved by adjustments > > for jump targets according to the Linux coding style convention. > > > > 3. Delete sanity checks then. These are not sanity checks, of course. They were required because of a common exit path. > > > > 4. Move an assignment for the variable "eof" behind memory allocations. I had asked Markus not to do this. It is unrelated. > > > > 5. The variable "req" will eventually be set to an appropriate pointer > > from a call of the ptlrpc_request_alloc() function. > > Thus let us omit the explicit initialisation before. Now that we use multiple labels it isn't necessary to initialize "req". > > > > 6. Apply a recommendation from the script "checkpatch.pl". This is where he changed pages[i] == NULL to !(pages[i]). It's not strictly related but it's minor and he was changing those lines anyway. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH v2 3/4] staging: lustre: Less checks in mgc_process_recover_log() after error detection @ 2015-12-22 8:00 ` Dan Carpenter 0 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2015-12-22 8:00 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: SF Markus Elfring, devel, Andreas Dilger, kernel-janitors, LKML, Oleg Drokin, Julia Lawall, lustre-devel On Mon, Dec 21, 2015 at 03:48:57PM -0800, Greg Kroah-Hartman wrote: > > That's 6 different things, shouldn't this be 6 different patches? > Not really. The patch could be described as just "change from using one exit label to using several." Markus has sent a number of these patches and I am CC'd on them because of kernel-janitors, it's really painful to review when he breaks them up into tiny patches where he changes one label at a time. It's like trying to put coleslaw back together into a head of cabbage. > On Mon, Dec 21, 2015 at 08:12:12PM +0100, SF Markus Elfring wrote: > > From: Markus Elfring <elfring@users.sourceforge.net> > > Date: Mon, 21 Dec 2015 18:58:51 +0100 > > > > A few checks would be performed by the mgc_process_recover_log() function > > even though it was determined that the passed variable "pages" contained > > a null pointer or a call of the alloc_page() function failed. > > > > 1. Let us return directly if a call of the kcalloc() function failed. > > > > 2. Corresponding implementation details could be improved by adjustments > > for jump targets according to the Linux coding style convention. > > > > 3. Delete sanity checks then. These are not sanity checks, of course. They were required because of a common exit path. > > > > 4. Move an assignment for the variable "eof" behind memory allocations. I had asked Markus not to do this. It is unrelated. > > > > 5. The variable "req" will eventually be set to an appropriate pointer > > from a call of the ptlrpc_request_alloc() function. > > Thus let us omit the explicit initialisation before. Now that we use multiple labels it isn't necessary to initialize "req". > > > > 6. Apply a recommendation from the script "checkpatch.pl". This is where he changed pages[i] = NULL to !(pages[i]). It's not strictly related but it's minor and he was changing those lines anyway. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 00/12] staging-Lustre: Fine-tuning for seven function implementations 2015-12-21 23:48 ` Greg Kroah-Hartman (?) @ 2016-07-26 18:54 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-26 18:54 UTC (permalink / raw) To: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall, Bhumika Goyal From: Markus Elfring <elfring@users.sourceforge.net> Further update suggestions were taken into account after a patch was applied from static source code analysis. Markus Elfring (12): ldlm: Delete unnecessary checks before the function call "kset_unregister" Delete unnecessary checks before the function call "kobject_put" One function call less in class_register_type() after error detection Split a condition check in class_register_type() Optimize error handling in class_register_type() Return directly after a failed kcalloc() in mgc_process_recover_log() Less checks after a failed alloc_page() in mgc_process_recover_log() Less checks after a failed ptlrpc_request_alloc() inmgc_process_recover_log() Delete a check for the variable "req" in mgc_process_recover_log() Rename jump labels in mgc_process_recover_log() Move an assignment for the variable "eof" in mgc_process_recover_log() Delete an unnecessary variable initialisation in mgc_process_recover_log() drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c | 10 ++--- drivers/staging/lustre/lustre/lmv/lmv_obd.c | 5 +-- drivers/staging/lustre/lustre/lov/lov_obd.c | 4 +- drivers/staging/lustre/lustre/mgc/mgc_request.c | 50 ++++++++++++------------- drivers/staging/lustre/lustre/obdclass/genops.c | 41 ++++++++++++-------- 5 files changed, 54 insertions(+), 56 deletions(-) -- 2.9.2 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [lustre-devel] [PATCH 00/12] staging-Lustre: Fine-tuning for seven function implementations @ 2016-07-26 18:54 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-26 18:54 UTC (permalink / raw) To: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall, Bhumika Goyal From: Markus Elfring <elfring@users.sourceforge.net> Further update suggestions were taken into account after a patch was applied from static source code analysis. Markus Elfring (12): ldlm: Delete unnecessary checks before the function call "kset_unregister" Delete unnecessary checks before the function call "kobject_put" One function call less in class_register_type() after error detection Split a condition check in class_register_type() Optimize error handling in class_register_type() Return directly after a failed kcalloc() in mgc_process_recover_log() Less checks after a failed alloc_page() in mgc_process_recover_log() Less checks after a failed ptlrpc_request_alloc() inmgc_process_recover_log() Delete a check for the variable "req" in mgc_process_recover_log() Rename jump labels in mgc_process_recover_log() Move an assignment for the variable "eof" in mgc_process_recover_log() Delete an unnecessary variable initialisation in mgc_process_recover_log() drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c | 10 ++--- drivers/staging/lustre/lustre/lmv/lmv_obd.c | 5 +-- drivers/staging/lustre/lustre/lov/lov_obd.c | 4 +- drivers/staging/lustre/lustre/mgc/mgc_request.c | 50 ++++++++++++------------- drivers/staging/lustre/lustre/obdclass/genops.c | 41 ++++++++++++-------- 5 files changed, 54 insertions(+), 56 deletions(-) -- 2.9.2 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 00/12] staging-Lustre: Fine-tuning for seven function implementations @ 2016-07-26 18:54 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-26 18:54 UTC (permalink / raw) To: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall, Bhumika Goyal From: Markus Elfring <elfring@users.sourceforge.net> Further update suggestions were taken into account after a patch was applied from static source code analysis. Markus Elfring (12): ldlm: Delete unnecessary checks before the function call "kset_unregister" Delete unnecessary checks before the function call "kobject_put" One function call less in class_register_type() after error detection Split a condition check in class_register_type() Optimize error handling in class_register_type() Return directly after a failed kcalloc() in mgc_process_recover_log() Less checks after a failed alloc_page() in mgc_process_recover_log() Less checks after a failed ptlrpc_request_alloc() inmgc_process_recover_log() Delete a check for the variable "req" in mgc_process_recover_log() Rename jump labels in mgc_process_recover_log() Move an assignment for the variable "eof" in mgc_process_recover_log() Delete an unnecessary variable initialisation in mgc_process_recover_log() drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c | 10 ++--- drivers/staging/lustre/lustre/lmv/lmv_obd.c | 5 +-- drivers/staging/lustre/lustre/lov/lov_obd.c | 4 +- drivers/staging/lustre/lustre/mgc/mgc_request.c | 50 ++++++++++++------------- drivers/staging/lustre/lustre/obdclass/genops.c | 41 ++++++++++++-------- 5 files changed, 54 insertions(+), 56 deletions(-) -- 2.9.2 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 01/12] staging/lustre/ldlm: Delete unnecessary checks before the function call "kset_unregister" 2016-07-26 18:54 ` SF Markus Elfring (?) @ 2016-07-26 18:56 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-26 18:56 UTC (permalink / raw) To: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall, Bhumika Goyal From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 26 Jul 2016 11:33:43 +0200 The kset_unregister() function tests whether its argument is NULL and then returns immediately. Thus the test around the calls is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c b/drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c index 821939f..2c1c2fc 100644 --- a/drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c +++ b/drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c @@ -1067,10 +1067,8 @@ static int ldlm_cleanup(void) if (ldlm_state->ldlm_cb_service) ptlrpc_unregister_service(ldlm_state->ldlm_cb_service); - if (ldlm_ns_kset) - kset_unregister(ldlm_ns_kset); - if (ldlm_svc_kset) - kset_unregister(ldlm_svc_kset); + kset_unregister(ldlm_ns_kset); + kset_unregister(ldlm_svc_kset); if (ldlm_kobj) kobject_put(ldlm_kobj); -- 2.9.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [lustre-devel] [PATCH 01/12] staging/lustre/ldlm: Delete unnecessary checks before the function call "kset_unregister" @ 2016-07-26 18:56 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-26 18:56 UTC (permalink / raw) To: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall, Bhumika Goyal From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 26 Jul 2016 11:33:43 +0200 The kset_unregister() function tests whether its argument is NULL and then returns immediately. Thus the test around the calls is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c b/drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c index 821939f..2c1c2fc 100644 --- a/drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c +++ b/drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c @@ -1067,10 +1067,8 @@ static int ldlm_cleanup(void) if (ldlm_state->ldlm_cb_service) ptlrpc_unregister_service(ldlm_state->ldlm_cb_service); - if (ldlm_ns_kset) - kset_unregister(ldlm_ns_kset); - if (ldlm_svc_kset) - kset_unregister(ldlm_svc_kset); + kset_unregister(ldlm_ns_kset); + kset_unregister(ldlm_svc_kset); if (ldlm_kobj) kobject_put(ldlm_kobj); -- 2.9.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 01/12] staging/lustre/ldlm: Delete unnecessary checks before the function call "kset_unregist @ 2016-07-26 18:56 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-26 18:56 UTC (permalink / raw) To: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall, Bhumika Goyal From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 26 Jul 2016 11:33:43 +0200 The kset_unregister() function tests whether its argument is NULL and then returns immediately. Thus the test around the calls is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c b/drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c index 821939f..2c1c2fc 100644 --- a/drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c +++ b/drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c @@ -1067,10 +1067,8 @@ static int ldlm_cleanup(void) if (ldlm_state->ldlm_cb_service) ptlrpc_unregister_service(ldlm_state->ldlm_cb_service); - if (ldlm_ns_kset) - kset_unregister(ldlm_ns_kset); - if (ldlm_svc_kset) - kset_unregister(ldlm_svc_kset); + kset_unregister(ldlm_ns_kset); + kset_unregister(ldlm_svc_kset); if (ldlm_kobj) kobject_put(ldlm_kobj); -- 2.9.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 02/12] staging: lustre: Delete unnecessary checks before the function call "kobject_put" 2016-07-26 18:54 ` SF Markus Elfring (?) @ 2016-07-26 19:00 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-26 19:00 UTC (permalink / raw) To: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall, Bhumika Goyal From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 26 Jul 2016 13:00:32 +0200 The kobject_put() function tests whether its argument is NULL and then returns immediately. Thus the test around the calls is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c | 4 +--- drivers/staging/lustre/lustre/lmv/lmv_obd.c | 5 ++--- drivers/staging/lustre/lustre/lov/lov_obd.c | 4 +--- drivers/staging/lustre/lustre/obdclass/genops.c | 6 ++---- 4 files changed, 6 insertions(+), 13 deletions(-) diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c b/drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c index 2c1c2fc..52c5dd4 100644 --- a/drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c +++ b/drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c @@ -1069,9 +1069,7 @@ static int ldlm_cleanup(void) kset_unregister(ldlm_ns_kset); kset_unregister(ldlm_svc_kset); - if (ldlm_kobj) - kobject_put(ldlm_kobj); - + kobject_put(ldlm_kobj); ldlm_debugfs_cleanup(); kfree(ldlm_state); diff --git a/drivers/staging/lustre/lustre/lmv/lmv_obd.c b/drivers/staging/lustre/lustre/lmv/lmv_obd.c index 0e1588a..8c2e5b3 100644 --- a/drivers/staging/lustre/lustre/lmv/lmv_obd.c +++ b/drivers/staging/lustre/lustre/lmv/lmv_obd.c @@ -238,7 +238,7 @@ static int lmv_connect(const struct lu_env *env, if (data && data->ocd_connect_flags & OBD_CONNECT_REAL) rc = lmv_check_connect(obd); - if (rc && lmv->lmv_tgts_kobj) + if (rc) kobject_put(lmv->lmv_tgts_kobj); return rc; @@ -648,8 +648,7 @@ static int lmv_disconnect(struct obd_export *exp) lmv_disconnect_mdc(obd, lmv->tgts[i]); } - if (lmv->lmv_tgts_kobj) - kobject_put(lmv->lmv_tgts_kobj); + kobject_put(lmv->lmv_tgts_kobj); out_local: /* diff --git a/drivers/staging/lustre/lustre/lov/lov_obd.c b/drivers/staging/lustre/lustre/lov/lov_obd.c index 9b92d55..df701f7 100644 --- a/drivers/staging/lustre/lustre/lov/lov_obd.c +++ b/drivers/staging/lustre/lustre/lov/lov_obd.c @@ -106,9 +106,7 @@ static void lov_putref(struct obd_device *obd) __lov_del_obd(obd, tgt); } - if (lov->lov_tgts_kobj) - kobject_put(lov->lov_tgts_kobj); - + kobject_put(lov->lov_tgts_kobj); } else { mutex_unlock(&lov->lov_lock); } diff --git a/drivers/staging/lustre/lustre/obdclass/genops.c b/drivers/staging/lustre/lustre/obdclass/genops.c index 99c2da6..1b5aa9b 100644 --- a/drivers/staging/lustre/lustre/obdclass/genops.c +++ b/drivers/staging/lustre/lustre/obdclass/genops.c @@ -203,8 +203,7 @@ int class_register_type(struct obd_ops *dt_ops, struct md_ops *md_ops, return 0; failed: - if (type->typ_kobj) - kobject_put(type->typ_kobj); + kobject_put(type->typ_kobj); kfree(type->typ_name); kfree(type->typ_md_ops); kfree(type->typ_dt_ops); @@ -231,8 +230,7 @@ int class_unregister_type(const char *name) return -EBUSY; } - if (type->typ_kobj) - kobject_put(type->typ_kobj); + kobject_put(type->typ_kobj); if (!IS_ERR_OR_NULL(type->typ_debugfs_entry)) ldebugfs_remove(&type->typ_debugfs_entry); -- 2.9.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [lustre-devel] [PATCH 02/12] staging: lustre: Delete unnecessary checks before the function call "kobject_put" @ 2016-07-26 19:00 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-26 19:00 UTC (permalink / raw) To: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall, Bhumika Goyal From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 26 Jul 2016 13:00:32 +0200 The kobject_put() function tests whether its argument is NULL and then returns immediately. Thus the test around the calls is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c | 4 +--- drivers/staging/lustre/lustre/lmv/lmv_obd.c | 5 ++--- drivers/staging/lustre/lustre/lov/lov_obd.c | 4 +--- drivers/staging/lustre/lustre/obdclass/genops.c | 6 ++---- 4 files changed, 6 insertions(+), 13 deletions(-) diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c b/drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c index 2c1c2fc..52c5dd4 100644 --- a/drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c +++ b/drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c @@ -1069,9 +1069,7 @@ static int ldlm_cleanup(void) kset_unregister(ldlm_ns_kset); kset_unregister(ldlm_svc_kset); - if (ldlm_kobj) - kobject_put(ldlm_kobj); - + kobject_put(ldlm_kobj); ldlm_debugfs_cleanup(); kfree(ldlm_state); diff --git a/drivers/staging/lustre/lustre/lmv/lmv_obd.c b/drivers/staging/lustre/lustre/lmv/lmv_obd.c index 0e1588a..8c2e5b3 100644 --- a/drivers/staging/lustre/lustre/lmv/lmv_obd.c +++ b/drivers/staging/lustre/lustre/lmv/lmv_obd.c @@ -238,7 +238,7 @@ static int lmv_connect(const struct lu_env *env, if (data && data->ocd_connect_flags & OBD_CONNECT_REAL) rc = lmv_check_connect(obd); - if (rc && lmv->lmv_tgts_kobj) + if (rc) kobject_put(lmv->lmv_tgts_kobj); return rc; @@ -648,8 +648,7 @@ static int lmv_disconnect(struct obd_export *exp) lmv_disconnect_mdc(obd, lmv->tgts[i]); } - if (lmv->lmv_tgts_kobj) - kobject_put(lmv->lmv_tgts_kobj); + kobject_put(lmv->lmv_tgts_kobj); out_local: /* diff --git a/drivers/staging/lustre/lustre/lov/lov_obd.c b/drivers/staging/lustre/lustre/lov/lov_obd.c index 9b92d55..df701f7 100644 --- a/drivers/staging/lustre/lustre/lov/lov_obd.c +++ b/drivers/staging/lustre/lustre/lov/lov_obd.c @@ -106,9 +106,7 @@ static void lov_putref(struct obd_device *obd) __lov_del_obd(obd, tgt); } - if (lov->lov_tgts_kobj) - kobject_put(lov->lov_tgts_kobj); - + kobject_put(lov->lov_tgts_kobj); } else { mutex_unlock(&lov->lov_lock); } diff --git a/drivers/staging/lustre/lustre/obdclass/genops.c b/drivers/staging/lustre/lustre/obdclass/genops.c index 99c2da6..1b5aa9b 100644 --- a/drivers/staging/lustre/lustre/obdclass/genops.c +++ b/drivers/staging/lustre/lustre/obdclass/genops.c @@ -203,8 +203,7 @@ int class_register_type(struct obd_ops *dt_ops, struct md_ops *md_ops, return 0; failed: - if (type->typ_kobj) - kobject_put(type->typ_kobj); + kobject_put(type->typ_kobj); kfree(type->typ_name); kfree(type->typ_md_ops); kfree(type->typ_dt_ops); @@ -231,8 +230,7 @@ int class_unregister_type(const char *name) return -EBUSY; } - if (type->typ_kobj) - kobject_put(type->typ_kobj); + kobject_put(type->typ_kobj); if (!IS_ERR_OR_NULL(type->typ_debugfs_entry)) ldebugfs_remove(&type->typ_debugfs_entry); -- 2.9.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 02/12] staging: lustre: Delete unnecessary checks before the function call "kobject_put" @ 2016-07-26 19:00 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-26 19:00 UTC (permalink / raw) To: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall, Bhumika Goyal From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 26 Jul 2016 13:00:32 +0200 The kobject_put() function tests whether its argument is NULL and then returns immediately. Thus the test around the calls is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c | 4 +--- drivers/staging/lustre/lustre/lmv/lmv_obd.c | 5 ++--- drivers/staging/lustre/lustre/lov/lov_obd.c | 4 +--- drivers/staging/lustre/lustre/obdclass/genops.c | 6 ++---- 4 files changed, 6 insertions(+), 13 deletions(-) diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c b/drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c index 2c1c2fc..52c5dd4 100644 --- a/drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c +++ b/drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c @@ -1069,9 +1069,7 @@ static int ldlm_cleanup(void) kset_unregister(ldlm_ns_kset); kset_unregister(ldlm_svc_kset); - if (ldlm_kobj) - kobject_put(ldlm_kobj); - + kobject_put(ldlm_kobj); ldlm_debugfs_cleanup(); kfree(ldlm_state); diff --git a/drivers/staging/lustre/lustre/lmv/lmv_obd.c b/drivers/staging/lustre/lustre/lmv/lmv_obd.c index 0e1588a..8c2e5b3 100644 --- a/drivers/staging/lustre/lustre/lmv/lmv_obd.c +++ b/drivers/staging/lustre/lustre/lmv/lmv_obd.c @@ -238,7 +238,7 @@ static int lmv_connect(const struct lu_env *env, if (data && data->ocd_connect_flags & OBD_CONNECT_REAL) rc = lmv_check_connect(obd); - if (rc && lmv->lmv_tgts_kobj) + if (rc) kobject_put(lmv->lmv_tgts_kobj); return rc; @@ -648,8 +648,7 @@ static int lmv_disconnect(struct obd_export *exp) lmv_disconnect_mdc(obd, lmv->tgts[i]); } - if (lmv->lmv_tgts_kobj) - kobject_put(lmv->lmv_tgts_kobj); + kobject_put(lmv->lmv_tgts_kobj); out_local: /* diff --git a/drivers/staging/lustre/lustre/lov/lov_obd.c b/drivers/staging/lustre/lustre/lov/lov_obd.c index 9b92d55..df701f7 100644 --- a/drivers/staging/lustre/lustre/lov/lov_obd.c +++ b/drivers/staging/lustre/lustre/lov/lov_obd.c @@ -106,9 +106,7 @@ static void lov_putref(struct obd_device *obd) __lov_del_obd(obd, tgt); } - if (lov->lov_tgts_kobj) - kobject_put(lov->lov_tgts_kobj); - + kobject_put(lov->lov_tgts_kobj); } else { mutex_unlock(&lov->lov_lock); } diff --git a/drivers/staging/lustre/lustre/obdclass/genops.c b/drivers/staging/lustre/lustre/obdclass/genops.c index 99c2da6..1b5aa9b 100644 --- a/drivers/staging/lustre/lustre/obdclass/genops.c +++ b/drivers/staging/lustre/lustre/obdclass/genops.c @@ -203,8 +203,7 @@ int class_register_type(struct obd_ops *dt_ops, struct md_ops *md_ops, return 0; failed: - if (type->typ_kobj) - kobject_put(type->typ_kobj); + kobject_put(type->typ_kobj); kfree(type->typ_name); kfree(type->typ_md_ops); kfree(type->typ_dt_ops); @@ -231,8 +230,7 @@ int class_unregister_type(const char *name) return -EBUSY; } - if (type->typ_kobj) - kobject_put(type->typ_kobj); + kobject_put(type->typ_kobj); if (!IS_ERR_OR_NULL(type->typ_debugfs_entry)) ldebugfs_remove(&type->typ_debugfs_entry); -- 2.9.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 03/12] staging: lustre: One function call less in class_register_type() after error detection 2016-07-26 18:54 ` SF Markus Elfring (?) @ 2016-07-26 19:02 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-26 19:02 UTC (permalink / raw) To: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall, Bhumika Goyal From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 26 Jul 2016 13:40:47 +0200 The kobject_put() function was called in a few cases by the class_register_type() function during error handling even if the passed data structure element did not contain a pointer for a valid data item. Adjust jump targets according to the Linux coding style convention. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/obdclass/genops.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/staging/lustre/lustre/obdclass/genops.c b/drivers/staging/lustre/lustre/obdclass/genops.c index 1b5aa9b..10dd145 100644 --- a/drivers/staging/lustre/lustre/obdclass/genops.c +++ b/drivers/staging/lustre/lustre/obdclass/genops.c @@ -164,7 +164,7 @@ int class_register_type(struct obd_ops *dt_ops, struct md_ops *md_ops, if (!type->typ_dt_ops || !type->typ_md_ops || !type->typ_name) - goto failed; + goto free_name; *(type->typ_dt_ops) = *dt_ops; /* md_ops is optional */ @@ -180,20 +180,20 @@ int class_register_type(struct obd_ops *dt_ops, struct md_ops *md_ops, rc = type->typ_debugfs_entry ? PTR_ERR(type->typ_debugfs_entry) : -ENOMEM; type->typ_debugfs_entry = NULL; - goto failed; + goto free_name; } type->typ_kobj = kobject_create_and_add(type->typ_name, lustre_kobj); if (!type->typ_kobj) { rc = -ENOMEM; - goto failed; + goto free_name; } if (ldt) { type->typ_lu = ldt; rc = lu_device_type_init(ldt); if (rc != 0) - goto failed; + goto put_object; } spin_lock(&obd_types_lock); @@ -201,9 +201,9 @@ int class_register_type(struct obd_ops *dt_ops, struct md_ops *md_ops, spin_unlock(&obd_types_lock); return 0; - - failed: +put_object: kobject_put(type->typ_kobj); +free_name: kfree(type->typ_name); kfree(type->typ_md_ops); kfree(type->typ_dt_ops); -- 2.9.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [lustre-devel] [PATCH 03/12] staging: lustre: One function call less in class_register_type() after error detection @ 2016-07-26 19:02 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-26 19:02 UTC (permalink / raw) To: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall, Bhumika Goyal From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 26 Jul 2016 13:40:47 +0200 The kobject_put() function was called in a few cases by the class_register_type() function during error handling even if the passed data structure element did not contain a pointer for a valid data item. Adjust jump targets according to the Linux coding style convention. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/obdclass/genops.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/staging/lustre/lustre/obdclass/genops.c b/drivers/staging/lustre/lustre/obdclass/genops.c index 1b5aa9b..10dd145 100644 --- a/drivers/staging/lustre/lustre/obdclass/genops.c +++ b/drivers/staging/lustre/lustre/obdclass/genops.c @@ -164,7 +164,7 @@ int class_register_type(struct obd_ops *dt_ops, struct md_ops *md_ops, if (!type->typ_dt_ops || !type->typ_md_ops || !type->typ_name) - goto failed; + goto free_name; *(type->typ_dt_ops) = *dt_ops; /* md_ops is optional */ @@ -180,20 +180,20 @@ int class_register_type(struct obd_ops *dt_ops, struct md_ops *md_ops, rc = type->typ_debugfs_entry ? PTR_ERR(type->typ_debugfs_entry) : -ENOMEM; type->typ_debugfs_entry = NULL; - goto failed; + goto free_name; } type->typ_kobj = kobject_create_and_add(type->typ_name, lustre_kobj); if (!type->typ_kobj) { rc = -ENOMEM; - goto failed; + goto free_name; } if (ldt) { type->typ_lu = ldt; rc = lu_device_type_init(ldt); if (rc != 0) - goto failed; + goto put_object; } spin_lock(&obd_types_lock); @@ -201,9 +201,9 @@ int class_register_type(struct obd_ops *dt_ops, struct md_ops *md_ops, spin_unlock(&obd_types_lock); return 0; - - failed: +put_object: kobject_put(type->typ_kobj); +free_name: kfree(type->typ_name); kfree(type->typ_md_ops); kfree(type->typ_dt_ops); -- 2.9.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 03/12] staging: lustre: One function call less in class_register_type() after error detection @ 2016-07-26 19:02 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-26 19:02 UTC (permalink / raw) To: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall, Bhumika Goyal From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 26 Jul 2016 13:40:47 +0200 The kobject_put() function was called in a few cases by the class_register_type() function during error handling even if the passed data structure element did not contain a pointer for a valid data item. Adjust jump targets according to the Linux coding style convention. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/obdclass/genops.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/staging/lustre/lustre/obdclass/genops.c b/drivers/staging/lustre/lustre/obdclass/genops.c index 1b5aa9b..10dd145 100644 --- a/drivers/staging/lustre/lustre/obdclass/genops.c +++ b/drivers/staging/lustre/lustre/obdclass/genops.c @@ -164,7 +164,7 @@ int class_register_type(struct obd_ops *dt_ops, struct md_ops *md_ops, if (!type->typ_dt_ops || !type->typ_md_ops || !type->typ_name) - goto failed; + goto free_name; *(type->typ_dt_ops) = *dt_ops; /* md_ops is optional */ @@ -180,20 +180,20 @@ int class_register_type(struct obd_ops *dt_ops, struct md_ops *md_ops, rc = type->typ_debugfs_entry ? PTR_ERR(type->typ_debugfs_entry) : -ENOMEM; type->typ_debugfs_entry = NULL; - goto failed; + goto free_name; } type->typ_kobj = kobject_create_and_add(type->typ_name, lustre_kobj); if (!type->typ_kobj) { rc = -ENOMEM; - goto failed; + goto free_name; } if (ldt) { type->typ_lu = ldt; rc = lu_device_type_init(ldt); if (rc != 0) - goto failed; + goto put_object; } spin_lock(&obd_types_lock); @@ -201,9 +201,9 @@ int class_register_type(struct obd_ops *dt_ops, struct md_ops *md_ops, spin_unlock(&obd_types_lock); return 0; - - failed: +put_object: kobject_put(type->typ_kobj); +free_name: kfree(type->typ_name); kfree(type->typ_md_ops); kfree(type->typ_dt_ops); -- 2.9.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 03/12] staging: lustre: One function call less in class_register_type() after error detection 2016-07-26 19:02 ` SF Markus Elfring (?) @ 2016-07-26 19:08 ` Oleg Drokin -1 siblings, 0 replies; 3089+ messages in thread From: Oleg Drokin @ 2016-07-26 19:08 UTC (permalink / raw) To: SF Markus Elfring Cc: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, LKML, kernel-janitors, Julia Lawall, Bhumika Goyal On Jul 26, 2016, at 3:02 PM, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Tue, 26 Jul 2016 13:40:47 +0200 > > The kobject_put() function was called in a few cases by the > class_register_type() function during error handling even if the passed > data structure element did not contain a pointer for a valid data item. But kobject_put() already checks for NULL, right? you just submitted another batch about that in other area. > Adjust jump targets according to the Linux coding style convention. Not that I am totally against this patch, but when we do not need the extra checks, a single jump target is ok too in my mind (extra benefit - there's not going to be any chance of a mistake to where to jump to). And when we have a single jump target, there's no supersmart naming like free_this_and_that_and_that_other_thing_too. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/staging/lustre/lustre/obdclass/genops.c | 12 ++++++------ > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/drivers/staging/lustre/lustre/obdclass/genops.c b/drivers/staging/lustre/lustre/obdclass/genops.c > index 1b5aa9b..10dd145 100644 > --- a/drivers/staging/lustre/lustre/obdclass/genops.c > +++ b/drivers/staging/lustre/lustre/obdclass/genops.c > @@ -164,7 +164,7 @@ int class_register_type(struct obd_ops *dt_ops, struct md_ops *md_ops, > if (!type->typ_dt_ops || > !type->typ_md_ops || > !type->typ_name) > - goto failed; > + goto free_name; > > *(type->typ_dt_ops) = *dt_ops; > /* md_ops is optional */ > @@ -180,20 +180,20 @@ int class_register_type(struct obd_ops *dt_ops, struct md_ops *md_ops, > rc = type->typ_debugfs_entry ? PTR_ERR(type->typ_debugfs_entry) > : -ENOMEM; > type->typ_debugfs_entry = NULL; > - goto failed; > + goto free_name; > } > > type->typ_kobj = kobject_create_and_add(type->typ_name, lustre_kobj); > if (!type->typ_kobj) { > rc = -ENOMEM; > - goto failed; > + goto free_name; > } > > if (ldt) { > type->typ_lu = ldt; > rc = lu_device_type_init(ldt); > if (rc != 0) > - goto failed; > + goto put_object; > } > > spin_lock(&obd_types_lock); > @@ -201,9 +201,9 @@ int class_register_type(struct obd_ops *dt_ops, struct md_ops *md_ops, > spin_unlock(&obd_types_lock); > > return 0; > - > - failed: > +put_object: > kobject_put(type->typ_kobj); > +free_name: > kfree(type->typ_name); > kfree(type->typ_md_ops); > kfree(type->typ_dt_ops); > -- > 2.9.2 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [lustre-devel] [PATCH 03/12] staging: lustre: One function call less in class_register_type() after error detection @ 2016-07-26 19:08 ` Oleg Drokin 0 siblings, 0 replies; 3089+ messages in thread From: Oleg Drokin @ 2016-07-26 19:08 UTC (permalink / raw) To: SF Markus Elfring Cc: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, LKML, kernel-janitors, Julia Lawall, Bhumika Goyal On Jul 26, 2016, at 3:02 PM, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Tue, 26 Jul 2016 13:40:47 +0200 > > The kobject_put() function was called in a few cases by the > class_register_type() function during error handling even if the passed > data structure element did not contain a pointer for a valid data item. But kobject_put() already checks for NULL, right? you just submitted another batch about that in other area. > Adjust jump targets according to the Linux coding style convention. Not that I am totally against this patch, but when we do not need the extra checks, a single jump target is ok too in my mind (extra benefit - there's not going to be any chance of a mistake to where to jump to). And when we have a single jump target, there's no supersmart naming like free_this_and_that_and_that_other_thing_too. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/staging/lustre/lustre/obdclass/genops.c | 12 ++++++------ > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/drivers/staging/lustre/lustre/obdclass/genops.c b/drivers/staging/lustre/lustre/obdclass/genops.c > index 1b5aa9b..10dd145 100644 > --- a/drivers/staging/lustre/lustre/obdclass/genops.c > +++ b/drivers/staging/lustre/lustre/obdclass/genops.c > @@ -164,7 +164,7 @@ int class_register_type(struct obd_ops *dt_ops, struct md_ops *md_ops, > if (!type->typ_dt_ops || > !type->typ_md_ops || > !type->typ_name) > - goto failed; > + goto free_name; > > *(type->typ_dt_ops) = *dt_ops; > /* md_ops is optional */ > @@ -180,20 +180,20 @@ int class_register_type(struct obd_ops *dt_ops, struct md_ops *md_ops, > rc = type->typ_debugfs_entry ? PTR_ERR(type->typ_debugfs_entry) > : -ENOMEM; > type->typ_debugfs_entry = NULL; > - goto failed; > + goto free_name; > } > > type->typ_kobj = kobject_create_and_add(type->typ_name, lustre_kobj); > if (!type->typ_kobj) { > rc = -ENOMEM; > - goto failed; > + goto free_name; > } > > if (ldt) { > type->typ_lu = ldt; > rc = lu_device_type_init(ldt); > if (rc != 0) > - goto failed; > + goto put_object; > } > > spin_lock(&obd_types_lock); > @@ -201,9 +201,9 @@ int class_register_type(struct obd_ops *dt_ops, struct md_ops *md_ops, > spin_unlock(&obd_types_lock); > > return 0; > - > - failed: > +put_object: > kobject_put(type->typ_kobj); > +free_name: > kfree(type->typ_name); > kfree(type->typ_md_ops); > kfree(type->typ_dt_ops); > -- > 2.9.2 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 03/12] staging: lustre: One function call less in class_register_type() after error detec @ 2016-07-26 19:08 ` Oleg Drokin 0 siblings, 0 replies; 3089+ messages in thread From: Oleg Drokin @ 2016-07-26 19:08 UTC (permalink / raw) To: SF Markus Elfring Cc: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, LKML, kernel-janitors, Julia Lawall, Bhumika Goyal On Jul 26, 2016, at 3:02 PM, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Tue, 26 Jul 2016 13:40:47 +0200 > > The kobject_put() function was called in a few cases by the > class_register_type() function during error handling even if the passed > data structure element did not contain a pointer for a valid data item. But kobject_put() already checks for NULL, right? you just submitted another batch about that in other area. > Adjust jump targets according to the Linux coding style convention. Not that I am totally against this patch, but when we do not need the extra checks, a single jump target is ok too in my mind (extra benefit - there's not going to be any chance of a mistake to where to jump to). And when we have a single jump target, there's no supersmart naming like free_this_and_that_and_that_other_thing_too. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/staging/lustre/lustre/obdclass/genops.c | 12 ++++++------ > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/drivers/staging/lustre/lustre/obdclass/genops.c b/drivers/staging/lustre/lustre/obdclass/genops.c > index 1b5aa9b..10dd145 100644 > --- a/drivers/staging/lustre/lustre/obdclass/genops.c > +++ b/drivers/staging/lustre/lustre/obdclass/genops.c > @@ -164,7 +164,7 @@ int class_register_type(struct obd_ops *dt_ops, struct md_ops *md_ops, > if (!type->typ_dt_ops || > !type->typ_md_ops || > !type->typ_name) > - goto failed; > + goto free_name; > > *(type->typ_dt_ops) = *dt_ops; > /* md_ops is optional */ > @@ -180,20 +180,20 @@ int class_register_type(struct obd_ops *dt_ops, struct md_ops *md_ops, > rc = type->typ_debugfs_entry ? PTR_ERR(type->typ_debugfs_entry) > : -ENOMEM; > type->typ_debugfs_entry = NULL; > - goto failed; > + goto free_name; > } > > type->typ_kobj = kobject_create_and_add(type->typ_name, lustre_kobj); > if (!type->typ_kobj) { > rc = -ENOMEM; > - goto failed; > + goto free_name; > } > > if (ldt) { > type->typ_lu = ldt; > rc = lu_device_type_init(ldt); > if (rc != 0) > - goto failed; > + goto put_object; > } > > spin_lock(&obd_types_lock); > @@ -201,9 +201,9 @@ int class_register_type(struct obd_ops *dt_ops, struct md_ops *md_ops, > spin_unlock(&obd_types_lock); > > return 0; > - > - failed: > +put_object: > kobject_put(type->typ_kobj); > +free_name: > kfree(type->typ_name); > kfree(type->typ_md_ops); > kfree(type->typ_dt_ops); > -- > 2.9.2 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 04/12] staging: lustre: Split a condition check in class_register_type() 2016-07-26 18:54 ` SF Markus Elfring (?) @ 2016-07-26 19:04 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-26 19:04 UTC (permalink / raw) To: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall, Bhumika Goyal From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 26 Jul 2016 14:10:55 +0200 The kfree() function was called in up to three cases by the class_register_type() function during error handling even if the passed data structure element contained a null pointer. * Split a condition check for memory allocation failures. * Improve this implementation detail by the introduction of a few jump labels. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/obdclass/genops.c | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-) diff --git a/drivers/staging/lustre/lustre/obdclass/genops.c b/drivers/staging/lustre/lustre/obdclass/genops.c index 10dd145..fd5e61f 100644 --- a/drivers/staging/lustre/lustre/obdclass/genops.c +++ b/drivers/staging/lustre/lustre/obdclass/genops.c @@ -158,13 +158,22 @@ int class_register_type(struct obd_ops *dt_ops, struct md_ops *md_ops, return rc; type->typ_dt_ops = kzalloc(sizeof(*type->typ_dt_ops), GFP_NOFS); + if (!type->typ_dt_ops) { + rc = -ENOMEM; + goto free_type; + } + type->typ_md_ops = kzalloc(sizeof(*type->typ_md_ops), GFP_NOFS); - type->typ_name = kzalloc(strlen(name) + 1, GFP_NOFS); + if (!type->typ_dt_ops) { + rc = -ENOMEM; + goto free_dt_ops; + } - if (!type->typ_dt_ops || - !type->typ_md_ops || - !type->typ_name) - goto free_name; + type->typ_name = kzalloc(strlen(name) + 1, GFP_NOFS); + if (!type->typ_name) { + rc = -ENOMEM; + goto free_md_ops; + } *(type->typ_dt_ops) = *dt_ops; /* md_ops is optional */ @@ -205,8 +214,11 @@ put_object: kobject_put(type->typ_kobj); free_name: kfree(type->typ_name); +free_md_ops: kfree(type->typ_md_ops); +free_dt_ops: kfree(type->typ_dt_ops); +free_type: kfree(type); return rc; } -- 2.9.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [lustre-devel] [PATCH 04/12] staging: lustre: Split a condition check in class_register_type() @ 2016-07-26 19:04 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-26 19:04 UTC (permalink / raw) To: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall, Bhumika Goyal From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 26 Jul 2016 14:10:55 +0200 The kfree() function was called in up to three cases by the class_register_type() function during error handling even if the passed data structure element contained a null pointer. * Split a condition check for memory allocation failures. * Improve this implementation detail by the introduction of a few jump labels. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/obdclass/genops.c | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-) diff --git a/drivers/staging/lustre/lustre/obdclass/genops.c b/drivers/staging/lustre/lustre/obdclass/genops.c index 10dd145..fd5e61f 100644 --- a/drivers/staging/lustre/lustre/obdclass/genops.c +++ b/drivers/staging/lustre/lustre/obdclass/genops.c @@ -158,13 +158,22 @@ int class_register_type(struct obd_ops *dt_ops, struct md_ops *md_ops, return rc; type->typ_dt_ops = kzalloc(sizeof(*type->typ_dt_ops), GFP_NOFS); + if (!type->typ_dt_ops) { + rc = -ENOMEM; + goto free_type; + } + type->typ_md_ops = kzalloc(sizeof(*type->typ_md_ops), GFP_NOFS); - type->typ_name = kzalloc(strlen(name) + 1, GFP_NOFS); + if (!type->typ_dt_ops) { + rc = -ENOMEM; + goto free_dt_ops; + } - if (!type->typ_dt_ops || - !type->typ_md_ops || - !type->typ_name) - goto free_name; + type->typ_name = kzalloc(strlen(name) + 1, GFP_NOFS); + if (!type->typ_name) { + rc = -ENOMEM; + goto free_md_ops; + } *(type->typ_dt_ops) = *dt_ops; /* md_ops is optional */ @@ -205,8 +214,11 @@ put_object: kobject_put(type->typ_kobj); free_name: kfree(type->typ_name); +free_md_ops: kfree(type->typ_md_ops); +free_dt_ops: kfree(type->typ_dt_ops); +free_type: kfree(type); return rc; } -- 2.9.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 04/12] staging: lustre: Split a condition check in class_register_type() @ 2016-07-26 19:04 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-26 19:04 UTC (permalink / raw) To: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall, Bhumika Goyal From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 26 Jul 2016 14:10:55 +0200 The kfree() function was called in up to three cases by the class_register_type() function during error handling even if the passed data structure element contained a null pointer. * Split a condition check for memory allocation failures. * Improve this implementation detail by the introduction of a few jump labels. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/obdclass/genops.c | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-) diff --git a/drivers/staging/lustre/lustre/obdclass/genops.c b/drivers/staging/lustre/lustre/obdclass/genops.c index 10dd145..fd5e61f 100644 --- a/drivers/staging/lustre/lustre/obdclass/genops.c +++ b/drivers/staging/lustre/lustre/obdclass/genops.c @@ -158,13 +158,22 @@ int class_register_type(struct obd_ops *dt_ops, struct md_ops *md_ops, return rc; type->typ_dt_ops = kzalloc(sizeof(*type->typ_dt_ops), GFP_NOFS); + if (!type->typ_dt_ops) { + rc = -ENOMEM; + goto free_type; + } + type->typ_md_ops = kzalloc(sizeof(*type->typ_md_ops), GFP_NOFS); - type->typ_name = kzalloc(strlen(name) + 1, GFP_NOFS); + if (!type->typ_dt_ops) { + rc = -ENOMEM; + goto free_dt_ops; + } - if (!type->typ_dt_ops || - !type->typ_md_ops || - !type->typ_name) - goto free_name; + type->typ_name = kzalloc(strlen(name) + 1, GFP_NOFS); + if (!type->typ_name) { + rc = -ENOMEM; + goto free_md_ops; + } *(type->typ_dt_ops) = *dt_ops; /* md_ops is optional */ @@ -205,8 +214,11 @@ put_object: kobject_put(type->typ_kobj); free_name: kfree(type->typ_name); +free_md_ops: kfree(type->typ_md_ops); +free_dt_ops: kfree(type->typ_dt_ops); +free_type: kfree(type); return rc; } -- 2.9.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 05/12] staging: lustre: Optimize error handling in class_register_type() 2016-07-26 18:54 ` SF Markus Elfring (?) @ 2016-07-26 19:05 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-26 19:05 UTC (permalink / raw) To: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall, Bhumika Goyal From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 26 Jul 2016 14:23:23 +0200 Return a constant error code without storing it in the local variable "rc" after a failed memory allocation at the beginning of this function. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/obdclass/genops.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/staging/lustre/lustre/obdclass/genops.c b/drivers/staging/lustre/lustre/obdclass/genops.c index fd5e61f..4752091 100644 --- a/drivers/staging/lustre/lustre/obdclass/genops.c +++ b/drivers/staging/lustre/lustre/obdclass/genops.c @@ -152,10 +152,9 @@ int class_register_type(struct obd_ops *dt_ops, struct md_ops *md_ops, return -EEXIST; } - rc = -ENOMEM; type = kzalloc(sizeof(*type), GFP_NOFS); if (!type) - return rc; + return -ENOMEM; type->typ_dt_ops = kzalloc(sizeof(*type->typ_dt_ops), GFP_NOFS); if (!type->typ_dt_ops) { -- 2.9.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [lustre-devel] [PATCH 05/12] staging: lustre: Optimize error handling in class_register_type() @ 2016-07-26 19:05 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-26 19:05 UTC (permalink / raw) To: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall, Bhumika Goyal From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 26 Jul 2016 14:23:23 +0200 Return a constant error code without storing it in the local variable "rc" after a failed memory allocation at the beginning of this function. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/obdclass/genops.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/staging/lustre/lustre/obdclass/genops.c b/drivers/staging/lustre/lustre/obdclass/genops.c index fd5e61f..4752091 100644 --- a/drivers/staging/lustre/lustre/obdclass/genops.c +++ b/drivers/staging/lustre/lustre/obdclass/genops.c @@ -152,10 +152,9 @@ int class_register_type(struct obd_ops *dt_ops, struct md_ops *md_ops, return -EEXIST; } - rc = -ENOMEM; type = kzalloc(sizeof(*type), GFP_NOFS); if (!type) - return rc; + return -ENOMEM; type->typ_dt_ops = kzalloc(sizeof(*type->typ_dt_ops), GFP_NOFS); if (!type->typ_dt_ops) { -- 2.9.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 05/12] staging: lustre: Optimize error handling in class_register_type() @ 2016-07-26 19:05 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-26 19:05 UTC (permalink / raw) To: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall, Bhumika Goyal From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 26 Jul 2016 14:23:23 +0200 Return a constant error code without storing it in the local variable "rc" after a failed memory allocation at the beginning of this function. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/obdclass/genops.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/staging/lustre/lustre/obdclass/genops.c b/drivers/staging/lustre/lustre/obdclass/genops.c index fd5e61f..4752091 100644 --- a/drivers/staging/lustre/lustre/obdclass/genops.c +++ b/drivers/staging/lustre/lustre/obdclass/genops.c @@ -152,10 +152,9 @@ int class_register_type(struct obd_ops *dt_ops, struct md_ops *md_ops, return -EEXIST; } - rc = -ENOMEM; type = kzalloc(sizeof(*type), GFP_NOFS); if (!type) - return rc; + return -ENOMEM; type->typ_dt_ops = kzalloc(sizeof(*type->typ_dt_ops), GFP_NOFS); if (!type->typ_dt_ops) { -- 2.9.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 05/12] staging: lustre: Optimize error handling in class_register_type() 2016-07-26 19:05 ` SF Markus Elfring (?) @ 2016-07-26 19:11 ` Oleg Drokin -1 siblings, 0 replies; 3089+ messages in thread From: Oleg Drokin @ 2016-07-26 19:11 UTC (permalink / raw) To: SF Markus Elfring Cc: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, LKML, kernel-janitors, Julia Lawall, Bhumika Goyal On Jul 26, 2016, at 3:05 PM, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Tue, 26 Jul 2016 14:23:23 +0200 > > Return a constant error code without storing it in the local variable "rc" > after a failed memory allocation at the beginning of this function. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/staging/lustre/lustre/obdclass/genops.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/staging/lustre/lustre/obdclass/genops.c b/drivers/staging/lustre/lustre/obdclass/genops.c > index fd5e61f..4752091 100644 > --- a/drivers/staging/lustre/lustre/obdclass/genops.c > +++ b/drivers/staging/lustre/lustre/obdclass/genops.c > @@ -152,10 +152,9 @@ int class_register_type(struct obd_ops *dt_ops, struct md_ops *md_ops, > return -EEXIST; > } > > - rc = -ENOMEM; NAK. when you do this, the next statement below breaks: > type = kzalloc(sizeof(*type), GFP_NOFS); > if (!type) > - return rc; > + return -ENOMEM; > > type->typ_dt_ops = kzalloc(sizeof(*type->typ_dt_ops), GFP_NOFS); > if (!type->typ_dt_ops) { … goto failed; failed: … return rc; So we are now returning an unitialized rc, did you get a gcc warning about it when compiling? ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [lustre-devel] [PATCH 05/12] staging: lustre: Optimize error handling in class_register_type() @ 2016-07-26 19:11 ` Oleg Drokin 0 siblings, 0 replies; 3089+ messages in thread From: Oleg Drokin @ 2016-07-26 19:11 UTC (permalink / raw) To: SF Markus Elfring Cc: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, LKML, kernel-janitors, Julia Lawall, Bhumika Goyal On Jul 26, 2016, at 3:05 PM, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Tue, 26 Jul 2016 14:23:23 +0200 > > Return a constant error code without storing it in the local variable "rc" > after a failed memory allocation at the beginning of this function. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/staging/lustre/lustre/obdclass/genops.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/staging/lustre/lustre/obdclass/genops.c b/drivers/staging/lustre/lustre/obdclass/genops.c > index fd5e61f..4752091 100644 > --- a/drivers/staging/lustre/lustre/obdclass/genops.c > +++ b/drivers/staging/lustre/lustre/obdclass/genops.c > @@ -152,10 +152,9 @@ int class_register_type(struct obd_ops *dt_ops, struct md_ops *md_ops, > return -EEXIST; > } > > - rc = -ENOMEM; NAK. when you do this, the next statement below breaks: > type = kzalloc(sizeof(*type), GFP_NOFS); > if (!type) > - return rc; > + return -ENOMEM; > > type->typ_dt_ops = kzalloc(sizeof(*type->typ_dt_ops), GFP_NOFS); > if (!type->typ_dt_ops) { ? goto failed; failed: ? return rc; So we are now returning an unitialized rc, did you get a gcc warning about it when compiling? ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 05/12] staging: lustre: Optimize error handling in class_register_type() @ 2016-07-26 19:11 ` Oleg Drokin 0 siblings, 0 replies; 3089+ messages in thread From: Oleg Drokin @ 2016-07-26 19:11 UTC (permalink / raw) To: SF Markus Elfring Cc: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, LKML, kernel-janitors, Julia Lawall, Bhumika Goyal On Jul 26, 2016, at 3:05 PM, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Tue, 26 Jul 2016 14:23:23 +0200 > > Return a constant error code without storing it in the local variable "rc" > after a failed memory allocation at the beginning of this function. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/staging/lustre/lustre/obdclass/genops.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/staging/lustre/lustre/obdclass/genops.c b/drivers/staging/lustre/lustre/obdclass/genops.c > index fd5e61f..4752091 100644 > --- a/drivers/staging/lustre/lustre/obdclass/genops.c > +++ b/drivers/staging/lustre/lustre/obdclass/genops.c > @@ -152,10 +152,9 @@ int class_register_type(struct obd_ops *dt_ops, struct md_ops *md_ops, > return -EEXIST; > } > > - rc = -ENOMEM; NAK. when you do this, the next statement below breaks: > type = kzalloc(sizeof(*type), GFP_NOFS); > if (!type) > - return rc; > + return -ENOMEM; > > type->typ_dt_ops = kzalloc(sizeof(*type->typ_dt_ops), GFP_NOFS); > if (!type->typ_dt_ops) { … goto failed; failed: … return rc; So we are now returning an unitialized rc, did you get a gcc warning about it when compiling?-- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 06/12] staging: lustre: Return directly after a failed kcalloc() in mgc_process_recover_log() 2016-07-26 18:54 ` SF Markus Elfring (?) @ 2016-07-26 19:07 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-26 19:07 UTC (permalink / raw) To: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall, Bhumika Goyal From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 26 Jul 2016 16:32:31 +0200 Return directly after a memory allocation failed at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/mgc/mgc_request.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c b/drivers/staging/lustre/lustre/mgc/mgc_request.c index 9d0bd47..d716bb2 100644 --- a/drivers/staging/lustre/lustre/mgc/mgc_request.c +++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c @@ -1339,10 +1339,8 @@ static int mgc_process_recover_log(struct obd_device *obd, nrpages = CONFIG_READ_NRPAGES_INIT; pages = kcalloc(nrpages, sizeof(*pages), GFP_KERNEL); - if (!pages) { - rc = -ENOMEM; - goto out; - } + if (!pages) + return -ENOMEM; for (i = 0; i < nrpages; i++) { pages[i] = alloc_page(GFP_KERNEL); -- 2.9.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [lustre-devel] [PATCH 06/12] staging: lustre: Return directly after a failed kcalloc() in mgc_process_recover_log() @ 2016-07-26 19:07 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-26 19:07 UTC (permalink / raw) To: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall, Bhumika Goyal From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 26 Jul 2016 16:32:31 +0200 Return directly after a memory allocation failed at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/mgc/mgc_request.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c b/drivers/staging/lustre/lustre/mgc/mgc_request.c index 9d0bd47..d716bb2 100644 --- a/drivers/staging/lustre/lustre/mgc/mgc_request.c +++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c @@ -1339,10 +1339,8 @@ static int mgc_process_recover_log(struct obd_device *obd, nrpages = CONFIG_READ_NRPAGES_INIT; pages = kcalloc(nrpages, sizeof(*pages), GFP_KERNEL); - if (!pages) { - rc = -ENOMEM; - goto out; - } + if (!pages) + return -ENOMEM; for (i = 0; i < nrpages; i++) { pages[i] = alloc_page(GFP_KERNEL); -- 2.9.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 06/12] staging: lustre: Return directly after a failed kcalloc() in mgc_process_recover_log() @ 2016-07-26 19:07 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-26 19:07 UTC (permalink / raw) To: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall, Bhumika Goyal From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 26 Jul 2016 16:32:31 +0200 Return directly after a memory allocation failed at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/mgc/mgc_request.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c b/drivers/staging/lustre/lustre/mgc/mgc_request.c index 9d0bd47..d716bb2 100644 --- a/drivers/staging/lustre/lustre/mgc/mgc_request.c +++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c @@ -1339,10 +1339,8 @@ static int mgc_process_recover_log(struct obd_device *obd, nrpages = CONFIG_READ_NRPAGES_INIT; pages = kcalloc(nrpages, sizeof(*pages), GFP_KERNEL); - if (!pages) { - rc = -ENOMEM; - goto out; - } + if (!pages) + return -ENOMEM; for (i = 0; i < nrpages; i++) { pages[i] = alloc_page(GFP_KERNEL); -- 2.9.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 07/12] staging: lustre: Less checks after a failed alloc_page() in mgc_process_recover_log() 2016-07-26 18:54 ` SF Markus Elfring (?) @ 2016-07-26 19:08 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-26 19:08 UTC (permalink / raw) To: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall, Bhumika Goyal From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 26 Jul 2016 17:12:51 +0200 Release memory directly after a page allocation failed at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/mgc/mgc_request.c | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c b/drivers/staging/lustre/lustre/mgc/mgc_request.c index d716bb2..b064bd3 100644 --- a/drivers/staging/lustre/lustre/mgc/mgc_request.c +++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c @@ -1346,7 +1346,7 @@ static int mgc_process_recover_log(struct obd_device *obd, pages[i] = alloc_page(GFP_KERNEL); if (!pages[i]) { rc = -ENOMEM; - goto out; + goto free_pages; } } @@ -1461,14 +1461,13 @@ out: if (rc == 0 && !eof) goto again; - if (pages) { - for (i = 0; i < nrpages; i++) { - if (!pages[i]) - break; - __free_page(pages[i]); - } - kfree(pages); +free_pages: + for (i = 0; i < nrpages; i++) { + if (!pages[i]) + break; + __free_page(pages[i]); } + kfree(pages); return rc; } -- 2.9.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [lustre-devel] [PATCH 07/12] staging: lustre: Less checks after a failed alloc_page() in mgc_process_recover_log() @ 2016-07-26 19:08 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-26 19:08 UTC (permalink / raw) To: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall, Bhumika Goyal From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 26 Jul 2016 17:12:51 +0200 Release memory directly after a page allocation failed at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/mgc/mgc_request.c | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c b/drivers/staging/lustre/lustre/mgc/mgc_request.c index d716bb2..b064bd3 100644 --- a/drivers/staging/lustre/lustre/mgc/mgc_request.c +++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c @@ -1346,7 +1346,7 @@ static int mgc_process_recover_log(struct obd_device *obd, pages[i] = alloc_page(GFP_KERNEL); if (!pages[i]) { rc = -ENOMEM; - goto out; + goto free_pages; } } @@ -1461,14 +1461,13 @@ out: if (rc == 0 && !eof) goto again; - if (pages) { - for (i = 0; i < nrpages; i++) { - if (!pages[i]) - break; - __free_page(pages[i]); - } - kfree(pages); +free_pages: + for (i = 0; i < nrpages; i++) { + if (!pages[i]) + break; + __free_page(pages[i]); } + kfree(pages); return rc; } -- 2.9.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 07/12] staging: lustre: Less checks after a failed alloc_page() in mgc_process_recover_log() @ 2016-07-26 19:08 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-26 19:08 UTC (permalink / raw) To: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall, Bhumika Goyal From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 26 Jul 2016 17:12:51 +0200 Release memory directly after a page allocation failed at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/mgc/mgc_request.c | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c b/drivers/staging/lustre/lustre/mgc/mgc_request.c index d716bb2..b064bd3 100644 --- a/drivers/staging/lustre/lustre/mgc/mgc_request.c +++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c @@ -1346,7 +1346,7 @@ static int mgc_process_recover_log(struct obd_device *obd, pages[i] = alloc_page(GFP_KERNEL); if (!pages[i]) { rc = -ENOMEM; - goto out; + goto free_pages; } } @@ -1461,14 +1461,13 @@ out: if (rc = 0 && !eof) goto again; - if (pages) { - for (i = 0; i < nrpages; i++) { - if (!pages[i]) - break; - __free_page(pages[i]); - } - kfree(pages); +free_pages: + for (i = 0; i < nrpages; i++) { + if (!pages[i]) + break; + __free_page(pages[i]); } + kfree(pages); return rc; } -- 2.9.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 08/12] staging: lustre: Less checks after a failed ptlrpc_request_alloc() in mgc_process_recover_log() 2016-07-26 18:54 ` SF Markus Elfring (?) @ 2016-07-26 19:09 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-26 19:09 UTC (permalink / raw) To: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall, Bhumika Goyal From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 26 Jul 2016 17:54:24 +0200 Release memory directly after a call of the function "ptlrpc_request_alloc" failed. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/mgc/mgc_request.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c b/drivers/staging/lustre/lustre/mgc/mgc_request.c index b064bd3..f65bb45 100644 --- a/drivers/staging/lustre/lustre/mgc/mgc_request.c +++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c @@ -1357,7 +1357,7 @@ again: &RQF_MGS_CONFIG_READ); if (!req) { rc = -ENOMEM; - goto out; + goto free_pages; } rc = ptlrpc_request_pack(req, LUSTRE_MGS_VERSION, MGS_CONFIG_READ); -- 2.9.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [lustre-devel] [PATCH 08/12] staging: lustre: Less checks after a failed ptlrpc_request_alloc() in mgc_process_recover_log() @ 2016-07-26 19:09 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-26 19:09 UTC (permalink / raw) To: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall, Bhumika Goyal From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 26 Jul 2016 17:54:24 +0200 Release memory directly after a call of the function "ptlrpc_request_alloc" failed. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/mgc/mgc_request.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c b/drivers/staging/lustre/lustre/mgc/mgc_request.c index b064bd3..f65bb45 100644 --- a/drivers/staging/lustre/lustre/mgc/mgc_request.c +++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c @@ -1357,7 +1357,7 @@ again: &RQF_MGS_CONFIG_READ); if (!req) { rc = -ENOMEM; - goto out; + goto free_pages; } rc = ptlrpc_request_pack(req, LUSTRE_MGS_VERSION, MGS_CONFIG_READ); -- 2.9.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 08/12] staging: lustre: Less checks after a failed ptlrpc_request_alloc() in mgc_process_reco @ 2016-07-26 19:09 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-26 19:09 UTC (permalink / raw) To: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall, Bhumika Goyal From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 26 Jul 2016 17:54:24 +0200 Release memory directly after a call of the function "ptlrpc_request_alloc" failed. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/mgc/mgc_request.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c b/drivers/staging/lustre/lustre/mgc/mgc_request.c index b064bd3..f65bb45 100644 --- a/drivers/staging/lustre/lustre/mgc/mgc_request.c +++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c @@ -1357,7 +1357,7 @@ again: &RQF_MGS_CONFIG_READ); if (!req) { rc = -ENOMEM; - goto out; + goto free_pages; } rc = ptlrpc_request_pack(req, LUSTRE_MGS_VERSION, MGS_CONFIG_READ); -- 2.9.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 09/12] staging: lustre: Delete a check for the variable "req" in mgc_process_recover_log() 2016-07-26 18:54 ` SF Markus Elfring (?) @ 2016-07-26 19:10 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-26 19:10 UTC (permalink / raw) To: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall, Bhumika Goyal From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 26 Jul 2016 17:56:49 +0200 Delete a check for the local variable "req" which became unnecessary with the previous update step. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/mgc/mgc_request.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c b/drivers/staging/lustre/lustre/mgc/mgc_request.c index f65bb45..2207af7 100644 --- a/drivers/staging/lustre/lustre/mgc/mgc_request.c +++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c @@ -1455,8 +1455,7 @@ again: } out: - if (req) - ptlrpc_req_finished(req); + ptlrpc_req_finished(req); if (rc == 0 && !eof) goto again; -- 2.9.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [lustre-devel] [PATCH 09/12] staging: lustre: Delete a check for the variable "req" in mgc_process_recover_log() @ 2016-07-26 19:10 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-26 19:10 UTC (permalink / raw) To: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall, Bhumika Goyal From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 26 Jul 2016 17:56:49 +0200 Delete a check for the local variable "req" which became unnecessary with the previous update step. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/mgc/mgc_request.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c b/drivers/staging/lustre/lustre/mgc/mgc_request.c index f65bb45..2207af7 100644 --- a/drivers/staging/lustre/lustre/mgc/mgc_request.c +++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c @@ -1455,8 +1455,7 @@ again: } out: - if (req) - ptlrpc_req_finished(req); + ptlrpc_req_finished(req); if (rc == 0 && !eof) goto again; -- 2.9.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 09/12] staging: lustre: Delete a check for the variable "req" in mgc_process_recover_log() @ 2016-07-26 19:10 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-26 19:10 UTC (permalink / raw) To: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall, Bhumika Goyal From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 26 Jul 2016 17:56:49 +0200 Delete a check for the local variable "req" which became unnecessary with the previous update step. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/mgc/mgc_request.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c b/drivers/staging/lustre/lustre/mgc/mgc_request.c index f65bb45..2207af7 100644 --- a/drivers/staging/lustre/lustre/mgc/mgc_request.c +++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c @@ -1455,8 +1455,7 @@ again: } out: - if (req) - ptlrpc_req_finished(req); + ptlrpc_req_finished(req); if (rc = 0 && !eof) goto again; -- 2.9.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 10/12] staging: lustre: Rename jump labels in mgc_process_recover_log() 2016-07-26 18:54 ` SF Markus Elfring (?) @ 2016-07-26 19:12 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-26 19:12 UTC (permalink / raw) To: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall, Bhumika Goyal From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 26 Jul 2016 19:29:11 +0200 Adjust jump targets according to the Linux coding style convention. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/mgc/mgc_request.c | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c b/drivers/staging/lustre/lustre/mgc/mgc_request.c index 2207af7..ff60b9b 100644 --- a/drivers/staging/lustre/lustre/mgc/mgc_request.c +++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c @@ -1362,7 +1362,7 @@ again: rc = ptlrpc_request_pack(req, LUSTRE_MGS_VERSION, MGS_CONFIG_READ); if (rc) - goto out; + goto finish_request; /* pack request */ body = req_capsule_client_get(&req->rq_pill, &RMF_MGS_CONFIG_BODY); @@ -1370,7 +1370,7 @@ again: if (strlcpy(body->mcb_name, cld->cld_logname, sizeof(body->mcb_name)) >= sizeof(body->mcb_name)) { rc = -E2BIG; - goto out; + goto finish_request; } body->mcb_offset = cfg->cfg_last_idx + 1; body->mcb_type = cld->cld_type; @@ -1382,7 +1382,7 @@ again: MGS_BULK_PORTAL); if (!desc) { rc = -ENOMEM; - goto out; + goto finish_request; } for (i = 0; i < nrpages; i++) @@ -1391,12 +1391,12 @@ again: ptlrpc_request_set_replen(req); rc = ptlrpc_queue_wait(req); if (rc) - goto out; + goto finish_request; res = req_capsule_server_get(&req->rq_pill, &RMF_MGS_CONFIG_RES); if (res->mcr_size < res->mcr_offset) { rc = -EINVAL; - goto out; + goto finish_request; } /* always update the index even though it might have errors with @@ -1411,18 +1411,18 @@ again: ealen = sptlrpc_cli_unwrap_bulk_read(req, req->rq_bulk, 0); if (ealen < 0) { rc = ealen; - goto out; + goto finish_request; } if (ealen > nrpages << PAGE_SHIFT) { rc = -EINVAL; - goto out; + goto finish_request; } if (ealen == 0) { /* no logs transferred */ if (!eof) rc = -EINVAL; - goto out; + goto finish_request; } mne_swab = !!ptlrpc_rep_need_swab(req); @@ -1453,8 +1453,7 @@ again: ealen -= PAGE_SIZE; } - -out: +finish_request: ptlrpc_req_finished(req); if (rc == 0 && !eof) -- 2.9.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [lustre-devel] [PATCH 10/12] staging: lustre: Rename jump labels in mgc_process_recover_log() @ 2016-07-26 19:12 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-26 19:12 UTC (permalink / raw) To: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall, Bhumika Goyal From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 26 Jul 2016 19:29:11 +0200 Adjust jump targets according to the Linux coding style convention. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/mgc/mgc_request.c | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c b/drivers/staging/lustre/lustre/mgc/mgc_request.c index 2207af7..ff60b9b 100644 --- a/drivers/staging/lustre/lustre/mgc/mgc_request.c +++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c @@ -1362,7 +1362,7 @@ again: rc = ptlrpc_request_pack(req, LUSTRE_MGS_VERSION, MGS_CONFIG_READ); if (rc) - goto out; + goto finish_request; /* pack request */ body = req_capsule_client_get(&req->rq_pill, &RMF_MGS_CONFIG_BODY); @@ -1370,7 +1370,7 @@ again: if (strlcpy(body->mcb_name, cld->cld_logname, sizeof(body->mcb_name)) >= sizeof(body->mcb_name)) { rc = -E2BIG; - goto out; + goto finish_request; } body->mcb_offset = cfg->cfg_last_idx + 1; body->mcb_type = cld->cld_type; @@ -1382,7 +1382,7 @@ again: MGS_BULK_PORTAL); if (!desc) { rc = -ENOMEM; - goto out; + goto finish_request; } for (i = 0; i < nrpages; i++) @@ -1391,12 +1391,12 @@ again: ptlrpc_request_set_replen(req); rc = ptlrpc_queue_wait(req); if (rc) - goto out; + goto finish_request; res = req_capsule_server_get(&req->rq_pill, &RMF_MGS_CONFIG_RES); if (res->mcr_size < res->mcr_offset) { rc = -EINVAL; - goto out; + goto finish_request; } /* always update the index even though it might have errors with @@ -1411,18 +1411,18 @@ again: ealen = sptlrpc_cli_unwrap_bulk_read(req, req->rq_bulk, 0); if (ealen < 0) { rc = ealen; - goto out; + goto finish_request; } if (ealen > nrpages << PAGE_SHIFT) { rc = -EINVAL; - goto out; + goto finish_request; } if (ealen == 0) { /* no logs transferred */ if (!eof) rc = -EINVAL; - goto out; + goto finish_request; } mne_swab = !!ptlrpc_rep_need_swab(req); @@ -1453,8 +1453,7 @@ again: ealen -= PAGE_SIZE; } - -out: +finish_request: ptlrpc_req_finished(req); if (rc == 0 && !eof) -- 2.9.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 10/12] staging: lustre: Rename jump labels in mgc_process_recover_log() @ 2016-07-26 19:12 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-26 19:12 UTC (permalink / raw) To: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall, Bhumika Goyal From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 26 Jul 2016 19:29:11 +0200 Adjust jump targets according to the Linux coding style convention. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/mgc/mgc_request.c | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c b/drivers/staging/lustre/lustre/mgc/mgc_request.c index 2207af7..ff60b9b 100644 --- a/drivers/staging/lustre/lustre/mgc/mgc_request.c +++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c @@ -1362,7 +1362,7 @@ again: rc = ptlrpc_request_pack(req, LUSTRE_MGS_VERSION, MGS_CONFIG_READ); if (rc) - goto out; + goto finish_request; /* pack request */ body = req_capsule_client_get(&req->rq_pill, &RMF_MGS_CONFIG_BODY); @@ -1370,7 +1370,7 @@ again: if (strlcpy(body->mcb_name, cld->cld_logname, sizeof(body->mcb_name)) >= sizeof(body->mcb_name)) { rc = -E2BIG; - goto out; + goto finish_request; } body->mcb_offset = cfg->cfg_last_idx + 1; body->mcb_type = cld->cld_type; @@ -1382,7 +1382,7 @@ again: MGS_BULK_PORTAL); if (!desc) { rc = -ENOMEM; - goto out; + goto finish_request; } for (i = 0; i < nrpages; i++) @@ -1391,12 +1391,12 @@ again: ptlrpc_request_set_replen(req); rc = ptlrpc_queue_wait(req); if (rc) - goto out; + goto finish_request; res = req_capsule_server_get(&req->rq_pill, &RMF_MGS_CONFIG_RES); if (res->mcr_size < res->mcr_offset) { rc = -EINVAL; - goto out; + goto finish_request; } /* always update the index even though it might have errors with @@ -1411,18 +1411,18 @@ again: ealen = sptlrpc_cli_unwrap_bulk_read(req, req->rq_bulk, 0); if (ealen < 0) { rc = ealen; - goto out; + goto finish_request; } if (ealen > nrpages << PAGE_SHIFT) { rc = -EINVAL; - goto out; + goto finish_request; } if (ealen = 0) { /* no logs transferred */ if (!eof) rc = -EINVAL; - goto out; + goto finish_request; } mne_swab = !!ptlrpc_rep_need_swab(req); @@ -1453,8 +1453,7 @@ again: ealen -= PAGE_SIZE; } - -out: +finish_request: ptlrpc_req_finished(req); if (rc = 0 && !eof) -- 2.9.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 11/12] staging: lustre: Move an assignment for the variable "eof" in mgc_process_recover_log() 2016-07-26 18:54 ` SF Markus Elfring (?) @ 2016-07-26 19:13 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-26 19:13 UTC (permalink / raw) To: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall, Bhumika Goyal From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 26 Jul 2016 19:40:28 +0200 Move the assignment for the local variable "eof" behind the source code for memory allocations by this function. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/mgc/mgc_request.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c b/drivers/staging/lustre/lustre/mgc/mgc_request.c index ff60b9b..8f5db79 100644 --- a/drivers/staging/lustre/lustre/mgc/mgc_request.c +++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c @@ -1322,7 +1322,7 @@ static int mgc_process_recover_log(struct obd_device *obd, struct ptlrpc_bulk_desc *desc; struct page **pages; int nrpages; - bool eof = true; + bool eof; bool mne_swab; int i; int ealen; @@ -1350,6 +1350,7 @@ static int mgc_process_recover_log(struct obd_device *obd, } } + eof = true; again: LASSERT(cld_is_recover(cld)); LASSERT(mutex_is_locked(&cld->cld_lock)); -- 2.9.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [lustre-devel] [PATCH 11/12] staging: lustre: Move an assignment for the variable "eof" in mgc_process_recover_log() @ 2016-07-26 19:13 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-26 19:13 UTC (permalink / raw) To: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall, Bhumika Goyal From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 26 Jul 2016 19:40:28 +0200 Move the assignment for the local variable "eof" behind the source code for memory allocations by this function. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/mgc/mgc_request.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c b/drivers/staging/lustre/lustre/mgc/mgc_request.c index ff60b9b..8f5db79 100644 --- a/drivers/staging/lustre/lustre/mgc/mgc_request.c +++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c @@ -1322,7 +1322,7 @@ static int mgc_process_recover_log(struct obd_device *obd, struct ptlrpc_bulk_desc *desc; struct page **pages; int nrpages; - bool eof = true; + bool eof; bool mne_swab; int i; int ealen; @@ -1350,6 +1350,7 @@ static int mgc_process_recover_log(struct obd_device *obd, } } + eof = true; again: LASSERT(cld_is_recover(cld)); LASSERT(mutex_is_locked(&cld->cld_lock)); -- 2.9.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 11/12] staging: lustre: Move an assignment for the variable "eof" in mgc_process_recover_log( @ 2016-07-26 19:13 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-26 19:13 UTC (permalink / raw) To: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall, Bhumika Goyal From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 26 Jul 2016 19:40:28 +0200 Move the assignment for the local variable "eof" behind the source code for memory allocations by this function. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/mgc/mgc_request.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c b/drivers/staging/lustre/lustre/mgc/mgc_request.c index ff60b9b..8f5db79 100644 --- a/drivers/staging/lustre/lustre/mgc/mgc_request.c +++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c @@ -1322,7 +1322,7 @@ static int mgc_process_recover_log(struct obd_device *obd, struct ptlrpc_bulk_desc *desc; struct page **pages; int nrpages; - bool eof = true; + bool eof; bool mne_swab; int i; int ealen; @@ -1350,6 +1350,7 @@ static int mgc_process_recover_log(struct obd_device *obd, } } + eof = true; again: LASSERT(cld_is_recover(cld)); LASSERT(mutex_is_locked(&cld->cld_lock)); -- 2.9.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 12/12] staging: lustre: Delete an unnecessary variable initialisation in mgc_process_recover_log() 2016-07-26 18:54 ` SF Markus Elfring ` (12 preceding siblings ...) (?) @ 2016-07-26 19:14 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-26 19:14 UTC (permalink / raw) To: devel, lustre-devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall, Bhumika Goyal From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 26 Jul 2016 19:50:40 +0200 The variable "req" will eventually be set to an appropriate pointer from a call of the ptlrpc_request_alloc() function. Thus omit the explicit initialisation which became unnecessary with a previous update step. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/mgc/mgc_request.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c b/drivers/staging/lustre/lustre/mgc/mgc_request.c index 8f5db79..6e8368e 100644 --- a/drivers/staging/lustre/lustre/mgc/mgc_request.c +++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c @@ -1315,7 +1315,7 @@ static int mgc_apply_recover_logs(struct obd_device *mgc, static int mgc_process_recover_log(struct obd_device *obd, struct config_llog_data *cld) { - struct ptlrpc_request *req = NULL; + struct ptlrpc_request *req; struct config_llog_instance *cfg = &cld->cld_cfg; struct mgs_config_body *body; struct mgs_config_res *res; -- 2.9.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH v2 4/4] staging: lustre: Fix a jump label position in osc_get_info() 2015-12-21 19:05 ` SF Markus Elfring @ 2015-12-21 19:13 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-21 19:13 UTC (permalink / raw) To: lustre-devel, devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Mon, 21 Dec 2015 19:30:42 +0100 The script "checkpatch.pl" pointed out that labels should not be indented. Thus delete a horizontal tab before the jump label "out" in the function "osc_get_info". Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/osc/osc_request.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/lustre/lustre/osc/osc_request.c b/drivers/staging/lustre/lustre/osc/osc_request.c index d6c1447..85ab180 100644 --- a/drivers/staging/lustre/lustre/osc/osc_request.c +++ b/drivers/staging/lustre/lustre/osc/osc_request.c @@ -2727,7 +2727,7 @@ static int osc_get_info(const struct lu_env *env, struct obd_export *exp, } *((u64 *)val) = *reply; - out: +out: ptlrpc_req_finished(req); return rc; } else if (KEY_IS(KEY_FIEMAP)) { -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH v2 4/4] staging: lustre: Fix a jump label position in osc_get_info() @ 2015-12-21 19:13 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-21 19:13 UTC (permalink / raw) To: lustre-devel, devel, Andreas Dilger, Greg Kroah-Hartman, Oleg Drokin Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Mon, 21 Dec 2015 19:30:42 +0100 The script "checkpatch.pl" pointed out that labels should not be indented. Thus delete a horizontal tab before the jump label "out" in the function "osc_get_info". Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/lustre/lustre/osc/osc_request.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/lustre/lustre/osc/osc_request.c b/drivers/staging/lustre/lustre/osc/osc_request.c index d6c1447..85ab180 100644 --- a/drivers/staging/lustre/lustre/osc/osc_request.c +++ b/drivers/staging/lustre/lustre/osc/osc_request.c @@ -2727,7 +2727,7 @@ static int osc_get_info(const struct lu_env *env, struct obd_export *exp, } *((u64 *)val) = *reply; - out: +out: ptlrpc_req_finished(req); return rc; } else if (KEY_IS(KEY_FIEMAP)) { -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [POWERPC] bootwrapper: One check less in fsl_get_immr() after error detection 2015-12-11 12:08 ` SF Markus Elfring @ 2015-12-14 22:10 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-14 22:10 UTC (permalink / raw) To: Benjamin Herrenschmidt, Michael Ellerman, Paul Mackerras, linuxppc-dev Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Mon, 14 Dec 2015 23:01:32 +0100 A status check was performed by the fsl_get_immr() function even if it was known already that a system setting did not fit to the expectations. This implementation detail could be improved by an adjustment for a jump label according to the Linux coding style convention. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- arch/powerpc/boot/fsl-soc.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/powerpc/boot/fsl-soc.c b/arch/powerpc/boot/fsl-soc.c index b835ed6..ff1dae3 100644 --- a/arch/powerpc/boot/fsl-soc.c +++ b/arch/powerpc/boot/fsl-soc.c @@ -34,24 +34,24 @@ u32 *fsl_get_immr(void) naddr = 2; if (naddr != 1 && naddr != 2) - goto err; + goto report_failure; size = getprop(soc, "ranges", prop_buf, MAX_PROP_LEN); if (size < 12) - goto err; + goto report_failure; if (prop_buf[0] != 0) - goto err; + goto report_failure; if (naddr == 2 && prop_buf[1] != 0) - goto err; + goto report_failure; if (!dt_xlate_addr(soc, prop_buf + naddr, 8, &ret)) ret = 0; } -err: - if (!ret) + if (!ret) { +report_failure: printf("fsl_get_immr: Failed to find immr base\r\n"); - + } return (u32 *)ret; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [POWERPC] bootwrapper: One check less in fsl_get_immr() after error detection @ 2015-12-14 22:10 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-14 22:10 UTC (permalink / raw) To: Benjamin Herrenschmidt, Michael Ellerman, Paul Mackerras, linuxppc-dev Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Mon, 14 Dec 2015 23:01:32 +0100 A status check was performed by the fsl_get_immr() function even if it was known already that a system setting did not fit to the expectations. This implementation detail could be improved by an adjustment for a jump label according to the Linux coding style convention. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- arch/powerpc/boot/fsl-soc.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/powerpc/boot/fsl-soc.c b/arch/powerpc/boot/fsl-soc.c index b835ed6..ff1dae3 100644 --- a/arch/powerpc/boot/fsl-soc.c +++ b/arch/powerpc/boot/fsl-soc.c @@ -34,24 +34,24 @@ u32 *fsl_get_immr(void) naddr = 2; if (naddr != 1 && naddr != 2) - goto err; + goto report_failure; size = getprop(soc, "ranges", prop_buf, MAX_PROP_LEN); if (size < 12) - goto err; + goto report_failure; if (prop_buf[0] != 0) - goto err; + goto report_failure; if (naddr = 2 && prop_buf[1] != 0) - goto err; + goto report_failure; if (!dt_xlate_addr(soc, prop_buf + naddr, 8, &ret)) ret = 0; } -err: - if (!ret) + if (!ret) { +report_failure: printf("fsl_get_immr: Failed to find immr base\r\n"); - + } return (u32 *)ret; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [POWERPC] bootwrapper: One check less in fsl_get_immr() after error detection 2015-12-14 22:10 ` SF Markus Elfring @ 2015-12-14 22:20 ` Scott Wood -1 siblings, 0 replies; 3089+ messages in thread From: Scott Wood @ 2015-12-14 22:20 UTC (permalink / raw) To: SF Markus Elfring, Benjamin Herrenschmidt, Michael Ellerman, Paul Mackerras, linuxppc-dev Cc: LKML, kernel-janitors, Julia Lawall On Mon, 2015-12-14 at 23:10 +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Mon, 14 Dec 2015 23:01:32 +0100 > > A status check was performed by the fsl_get_immr() function even if it > was known already that a system setting did not fit to the expectations. > > This implementation detail could be improved by an adjustment for > a jump label according to the Linux coding style convention. What is the actual problem you're trying to solve? Cluttering the code to micro-optimize an error path is not an improvement. -Scott ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [POWERPC] bootwrapper: One check less in fsl_get_immr() after error detection @ 2015-12-14 22:20 ` Scott Wood 0 siblings, 0 replies; 3089+ messages in thread From: Scott Wood @ 2015-12-14 22:20 UTC (permalink / raw) To: SF Markus Elfring, Benjamin Herrenschmidt, Michael Ellerman, Paul Mackerras, linuxppc-dev Cc: LKML, kernel-janitors, Julia Lawall On Mon, 2015-12-14 at 23:10 +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Mon, 14 Dec 2015 23:01:32 +0100 > > A status check was performed by the fsl_get_immr() function even if it > was known already that a system setting did not fit to the expectations. > > This implementation detail could be improved by an adjustment for > a jump label according to the Linux coding style convention. What is the actual problem you're trying to solve? Cluttering the code to micro-optimize an error path is not an improvement. -Scott ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH] block-LDM: One function call less in ldm_validate_tocblocks() after error detection 2015-12-11 12:08 ` SF Markus Elfring @ 2015-12-23 9:43 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-23 9:43 UTC (permalink / raw) To: linux-ntfs-dev, linux-block, Jens Axboe, Richard Russon Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 22 Dec 2015 22:32:07 +0100 This issue was detected by using the Coccinelle software. Let us return directly if a memory allocation failed. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- block/partitions/ldm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/block/partitions/ldm.c b/block/partitions/ldm.c index e507cfb..a50385c 100644 --- a/block/partitions/ldm.c +++ b/block/partitions/ldm.c @@ -433,7 +433,7 @@ static bool ldm_validate_tocblocks(struct parsed_partitions *state, tb[1] = kmalloc(sizeof(*tb[1]) * 3, GFP_KERNEL); if (!tb[1]) { ldm_crit("Out of memory."); - goto err; + return false; } tb[2] = (struct tocblock*)((u8*)tb[1] + sizeof(*tb[1])); tb[3] = (struct tocblock*)((u8*)tb[2] + sizeof(*tb[2])); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH] block-LDM: One function call less in ldm_validate_tocblocks() after error detection @ 2015-12-23 9:43 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-23 9:43 UTC (permalink / raw) To: linux-ntfs-dev, linux-block, Jens Axboe, Richard Russon Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 22 Dec 2015 22:32:07 +0100 This issue was detected by using the Coccinelle software. Let us return directly if a memory allocation failed. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- block/partitions/ldm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/block/partitions/ldm.c b/block/partitions/ldm.c index e507cfb..a50385c 100644 --- a/block/partitions/ldm.c +++ b/block/partitions/ldm.c @@ -433,7 +433,7 @@ static bool ldm_validate_tocblocks(struct parsed_partitions *state, tb[1] = kmalloc(sizeof(*tb[1]) * 3, GFP_KERNEL); if (!tb[1]) { ldm_crit("Out of memory."); - goto err; + return false; } tb[2] = (struct tocblock*)((u8*)tb[1] + sizeof(*tb[1])); tb[3] = (struct tocblock*)((u8*)tb[2] + sizeof(*tb[2])); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH] block-LDM: One function call less in ldm_validate_tocblocks() after error detection 2015-12-23 9:43 ` SF Markus Elfring @ 2015-12-23 10:41 ` Julia Lawall -1 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2015-12-23 10:41 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-ntfs-dev, linux-block, Jens Axboe, Richard Russon, LKML, kernel-janitors On Wed, 23 Dec 2015, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Tue, 22 Dec 2015 22:32:07 +0100 > > This issue was detected by using the Coccinelle software. > > Let us return directly if a memory allocation failed. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > block/partitions/ldm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/block/partitions/ldm.c b/block/partitions/ldm.c > index e507cfb..a50385c 100644 > --- a/block/partitions/ldm.c > +++ b/block/partitions/ldm.c > @@ -433,7 +433,7 @@ static bool ldm_validate_tocblocks(struct parsed_partitions *state, > tb[1] = kmalloc(sizeof(*tb[1]) * 3, GFP_KERNEL); > if (!tb[1]) { > ldm_crit("Out of memory."); > - goto err; > + return false; The ldm_crit, which is just a printk, is also not necessary, because kmalloc already generates backtrace information on failure. So you could clean up the whole thing at once. julia > } > tb[2] = (struct tocblock*)((u8*)tb[1] + sizeof(*tb[1])); > tb[3] = (struct tocblock*)((u8*)tb[2] + sizeof(*tb[2])); > -- > 2.6.3 > > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] block-LDM: One function call less in ldm_validate_tocblocks() after error detection @ 2015-12-23 10:41 ` Julia Lawall 0 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2015-12-23 10:41 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-ntfs-dev, linux-block, Jens Axboe, Richard Russon, LKML, kernel-janitors On Wed, 23 Dec 2015, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Tue, 22 Dec 2015 22:32:07 +0100 > > This issue was detected by using the Coccinelle software. > > Let us return directly if a memory allocation failed. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > block/partitions/ldm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/block/partitions/ldm.c b/block/partitions/ldm.c > index e507cfb..a50385c 100644 > --- a/block/partitions/ldm.c > +++ b/block/partitions/ldm.c > @@ -433,7 +433,7 @@ static bool ldm_validate_tocblocks(struct parsed_partitions *state, > tb[1] = kmalloc(sizeof(*tb[1]) * 3, GFP_KERNEL); > if (!tb[1]) { > ldm_crit("Out of memory."); > - goto err; > + return false; The ldm_crit, which is just a printk, is also not necessary, because kmalloc already generates backtrace information on failure. So you could clean up the whole thing at once. julia > } > tb[2] = (struct tocblock*)((u8*)tb[1] + sizeof(*tb[1])); > tb[3] = (struct tocblock*)((u8*)tb[2] + sizeof(*tb[2])); > -- > 2.6.3 > > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/5] block-LDM: Improvements for exception handling 2015-12-23 10:41 ` Julia Lawall @ 2015-12-23 18:02 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-23 18:02 UTC (permalink / raw) To: linux-ntfs-dev, linux-block, Jens Axboe, Richard Russon Cc: Julia Lawall, LKML, kernel-janitors From: Markus Elfring <elfring@users.sourceforge.net> Date: Wed, 23 Dec 2015 17:32:12 +0100 Several update suggestions were taken into account from static source code analysis. Markus Elfring (5): One function call less in ldm_validate_tocblocks() after error detection Delete extra log messages for memory allocation failures One function call less in ldm_partition() after error detection Less function calls in ldm_validate_privheads() after error detection Fine-tuning for the source code formatting block/partitions/ldm.c | 455 +++++++++++++++++++++++++------------------------ 1 file changed, 236 insertions(+), 219 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/5] block-LDM: Improvements for exception handling @ 2015-12-23 18:02 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-23 18:02 UTC (permalink / raw) To: linux-ntfs-dev, linux-block, Jens Axboe, Richard Russon Cc: Julia Lawall, LKML, kernel-janitors From: Markus Elfring <elfring@users.sourceforge.net> Date: Wed, 23 Dec 2015 17:32:12 +0100 Several update suggestions were taken into account from static source code analysis. Markus Elfring (5): One function call less in ldm_validate_tocblocks() after error detection Delete extra log messages for memory allocation failures One function call less in ldm_partition() after error detection Less function calls in ldm_validate_privheads() after error detection Fine-tuning for the source code formatting block/partitions/ldm.c | 455 +++++++++++++++++++++++++------------------------ 1 file changed, 236 insertions(+), 219 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 1/5] block-LDM: One function call less in ldm_validate_tocblocks() after error detection 2015-12-23 18:02 ` SF Markus Elfring @ 2015-12-23 18:06 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-23 18:06 UTC (permalink / raw) To: linux-ntfs-dev, linux-block, Jens Axboe, Richard Russon Cc: Julia Lawall, LKML, kernel-janitors From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 22 Dec 2015 22:32:07 +0100 This issue was detected by using the Coccinelle software. Let us return directly if a memory allocation failed. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- block/partitions/ldm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/block/partitions/ldm.c b/block/partitions/ldm.c index e507cfb..a50385c 100644 --- a/block/partitions/ldm.c +++ b/block/partitions/ldm.c @@ -433,7 +433,7 @@ static bool ldm_validate_tocblocks(struct parsed_partitions *state, tb[1] = kmalloc(sizeof(*tb[1]) * 3, GFP_KERNEL); if (!tb[1]) { ldm_crit("Out of memory."); - goto err; + return false; } tb[2] = (struct tocblock*)((u8*)tb[1] + sizeof(*tb[1])); tb[3] = (struct tocblock*)((u8*)tb[2] + sizeof(*tb[2])); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 1/5] block-LDM: One function call less in ldm_validate_tocblocks() after error detection @ 2015-12-23 18:06 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-23 18:06 UTC (permalink / raw) To: linux-ntfs-dev, linux-block, Jens Axboe, Richard Russon Cc: Julia Lawall, LKML, kernel-janitors From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 22 Dec 2015 22:32:07 +0100 This issue was detected by using the Coccinelle software. Let us return directly if a memory allocation failed. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- block/partitions/ldm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/block/partitions/ldm.c b/block/partitions/ldm.c index e507cfb..a50385c 100644 --- a/block/partitions/ldm.c +++ b/block/partitions/ldm.c @@ -433,7 +433,7 @@ static bool ldm_validate_tocblocks(struct parsed_partitions *state, tb[1] = kmalloc(sizeof(*tb[1]) * 3, GFP_KERNEL); if (!tb[1]) { ldm_crit("Out of memory."); - goto err; + return false; } tb[2] = (struct tocblock*)((u8*)tb[1] + sizeof(*tb[1])); tb[3] = (struct tocblock*)((u8*)tb[2] + sizeof(*tb[2])); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 2/5] block-LDM: Delete extra log messages for memory allocation failures 2015-12-23 18:02 ` SF Markus Elfring @ 2015-12-23 18:09 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-23 18:09 UTC (permalink / raw) To: linux-ntfs-dev, linux-block, Jens Axboe, Richard Russon Cc: Julia Lawall, LKML, kernel-janitors From: Markus Elfring <elfring@users.sourceforge.net> Date: Wed, 23 Dec 2015 13:21:01 +0100 A failed call of the kmalloc() function can generate appropriate information about insufficient memory already. Thus remove unnecessary log messages for such failures. Suggested-by: Julia Lawall <julia.lawall@lip6.fr> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- block/partitions/ldm.c | 20 +++++--------------- 1 file changed, 5 insertions(+), 15 deletions(-) diff --git a/block/partitions/ldm.c b/block/partitions/ldm.c index a50385c..856658a 100644 --- a/block/partitions/ldm.c +++ b/block/partitions/ldm.c @@ -343,10 +343,8 @@ static bool ldm_validate_privheads(struct parsed_partitions *state, ph[1] = kmalloc (sizeof (*ph[1]), GFP_KERNEL); ph[2] = kmalloc (sizeof (*ph[2]), GFP_KERNEL); - if (!ph[1] || !ph[2]) { - ldm_crit ("Out of memory."); + if (!ph[1] || !ph[2]) goto out; - } /* off[1 & 2] are relative to ph[0]->config_start */ ph[0]->config_start = 0; @@ -431,10 +429,8 @@ static bool ldm_validate_tocblocks(struct parsed_partitions *state, ph = &ldb->ph; tb[0] = &ldb->toc; tb[1] = kmalloc(sizeof(*tb[1]) * 3, GFP_KERNEL); - if (!tb[1]) { - ldm_crit("Out of memory."); + if (!tb[1]) return false; - } tb[2] = (struct tocblock*)((u8*)tb[1] + sizeof(*tb[1])); tb[3] = (struct tocblock*)((u8*)tb[2] + sizeof(*tb[2])); /* @@ -1239,10 +1235,8 @@ static bool ldm_ldmdb_add (u8 *data, int len, struct ldmdb *ldb) BUG_ON (!data || !ldb); vb = kmalloc (sizeof (*vb), GFP_KERNEL); - if (!vb) { - ldm_crit ("Out of memory."); + if (!vb) return false; - } if (!ldm_parse_vblk (data, len, vb)) { kfree(vb); @@ -1325,10 +1319,8 @@ static bool ldm_frag_add (const u8 *data, int size, struct list_head *frags) } f = kmalloc (sizeof (*f) + size*num, GFP_KERNEL); - if (!f) { - ldm_crit ("Out of memory."); + if (!f) return false; - } f->group = group; f->num = num; @@ -1519,10 +1511,8 @@ int ldm_partition(struct parsed_partitions *state) return 0; ldb = kmalloc (sizeof (*ldb), GFP_KERNEL); - if (!ldb) { - ldm_crit ("Out of memory."); + if (!ldb) goto out; - } /* Parse and check privheads. */ if (!ldm_validate_privheads(state, &ldb->ph)) -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 2/5] block-LDM: Delete extra log messages for memory allocation failures @ 2015-12-23 18:09 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-23 18:09 UTC (permalink / raw) To: linux-ntfs-dev, linux-block, Jens Axboe, Richard Russon Cc: Julia Lawall, LKML, kernel-janitors From: Markus Elfring <elfring@users.sourceforge.net> Date: Wed, 23 Dec 2015 13:21:01 +0100 A failed call of the kmalloc() function can generate appropriate information about insufficient memory already. Thus remove unnecessary log messages for such failures. Suggested-by: Julia Lawall <julia.lawall@lip6.fr> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- block/partitions/ldm.c | 20 +++++--------------- 1 file changed, 5 insertions(+), 15 deletions(-) diff --git a/block/partitions/ldm.c b/block/partitions/ldm.c index a50385c..856658a 100644 --- a/block/partitions/ldm.c +++ b/block/partitions/ldm.c @@ -343,10 +343,8 @@ static bool ldm_validate_privheads(struct parsed_partitions *state, ph[1] = kmalloc (sizeof (*ph[1]), GFP_KERNEL); ph[2] = kmalloc (sizeof (*ph[2]), GFP_KERNEL); - if (!ph[1] || !ph[2]) { - ldm_crit ("Out of memory."); + if (!ph[1] || !ph[2]) goto out; - } /* off[1 & 2] are relative to ph[0]->config_start */ ph[0]->config_start = 0; @@ -431,10 +429,8 @@ static bool ldm_validate_tocblocks(struct parsed_partitions *state, ph = &ldb->ph; tb[0] = &ldb->toc; tb[1] = kmalloc(sizeof(*tb[1]) * 3, GFP_KERNEL); - if (!tb[1]) { - ldm_crit("Out of memory."); + if (!tb[1]) return false; - } tb[2] = (struct tocblock*)((u8*)tb[1] + sizeof(*tb[1])); tb[3] = (struct tocblock*)((u8*)tb[2] + sizeof(*tb[2])); /* @@ -1239,10 +1235,8 @@ static bool ldm_ldmdb_add (u8 *data, int len, struct ldmdb *ldb) BUG_ON (!data || !ldb); vb = kmalloc (sizeof (*vb), GFP_KERNEL); - if (!vb) { - ldm_crit ("Out of memory."); + if (!vb) return false; - } if (!ldm_parse_vblk (data, len, vb)) { kfree(vb); @@ -1325,10 +1319,8 @@ static bool ldm_frag_add (const u8 *data, int size, struct list_head *frags) } f = kmalloc (sizeof (*f) + size*num, GFP_KERNEL); - if (!f) { - ldm_crit ("Out of memory."); + if (!f) return false; - } f->group = group; f->num = num; @@ -1519,10 +1511,8 @@ int ldm_partition(struct parsed_partitions *state) return 0; ldb = kmalloc (sizeof (*ldb), GFP_KERNEL); - if (!ldb) { - ldm_crit ("Out of memory."); + if (!ldb) goto out; - } /* Parse and check privheads. */ if (!ldm_validate_privheads(state, &ldb->ph)) -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 3/5] block-LDM: One function call less in ldm_partition() after error detection 2015-12-23 18:02 ` SF Markus Elfring @ 2015-12-23 18:10 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-23 18:10 UTC (permalink / raw) To: linux-ntfs-dev, linux-block, Jens Axboe, Richard Russon Cc: Julia Lawall, LKML, kernel-janitors From: Markus Elfring <elfring@users.sourceforge.net> Date: Wed, 23 Dec 2015 13:32:51 +0100 Let us return directly if a memory allocation failed. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- block/partitions/ldm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/block/partitions/ldm.c b/block/partitions/ldm.c index 856658a..3118d24 100644 --- a/block/partitions/ldm.c +++ b/block/partitions/ldm.c @@ -1512,7 +1512,7 @@ int ldm_partition(struct parsed_partitions *state) ldb = kmalloc (sizeof (*ldb), GFP_KERNEL); if (!ldb) - goto out; + return -1; /* Parse and check privheads. */ if (!ldm_validate_privheads(state, &ldb->ph)) -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 3/5] block-LDM: One function call less in ldm_partition() after error detection @ 2015-12-23 18:10 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-23 18:10 UTC (permalink / raw) To: linux-ntfs-dev, linux-block, Jens Axboe, Richard Russon Cc: Julia Lawall, LKML, kernel-janitors From: Markus Elfring <elfring@users.sourceforge.net> Date: Wed, 23 Dec 2015 13:32:51 +0100 Let us return directly if a memory allocation failed. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- block/partitions/ldm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/block/partitions/ldm.c b/block/partitions/ldm.c index 856658a..3118d24 100644 --- a/block/partitions/ldm.c +++ b/block/partitions/ldm.c @@ -1512,7 +1512,7 @@ int ldm_partition(struct parsed_partitions *state) ldb = kmalloc (sizeof (*ldb), GFP_KERNEL); if (!ldb) - goto out; + return -1; /* Parse and check privheads. */ if (!ldm_validate_privheads(state, &ldb->ph)) -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 4/5] block-LDM: Less function calls in ldm_validate_privheads() after error detection 2015-12-23 18:02 ` SF Markus Elfring @ 2015-12-23 18:12 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-23 18:12 UTC (permalink / raw) To: linux-ntfs-dev, linux-block, Jens Axboe, Richard Russon Cc: Julia Lawall, LKML, kernel-janitors From: Markus Elfring <elfring@users.sourceforge.net> Date: Wed, 23 Dec 2015 14:31:01 +0100 The kfree() function was called by the ldm_validate_privheads() function during error handling even if the passed variable "ph" contained a null pointer. * Corresponding implementation details could be improved by adjustments for jump targets according to the Linux coding style convention. * The variable "result" will eventually be set to an appropriate value. Thus let us omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- block/partitions/ldm.c | 30 ++++++++++++++++++------------ 1 file changed, 18 insertions(+), 12 deletions(-) diff --git a/block/partitions/ldm.c b/block/partitions/ldm.c index 3118d24..6fc9150 100644 --- a/block/partitions/ldm.c +++ b/block/partitions/ldm.c @@ -335,16 +335,20 @@ static bool ldm_validate_privheads(struct parsed_partitions *state, struct privhead *ph[3] = { ph1 }; Sector sect; u8 *data; - bool result = false; + bool result; long num_sects; int i; BUG_ON (!state || !ph1); ph[1] = kmalloc (sizeof (*ph[1]), GFP_KERNEL); + if (!ph[1]) + return false; ph[2] = kmalloc (sizeof (*ph[2]), GFP_KERNEL); - if (!ph[1] || !ph[2]) - goto out; + if (!ph[2]) { + result = false; + goto free_a_head; + } /* off[1 & 2] are relative to ph[0]->config_start */ ph[0]->config_start = 0; @@ -355,14 +359,15 @@ static bool ldm_validate_privheads(struct parsed_partitions *state, §); if (!data) { ldm_crit ("Disk read failed."); - goto out; + result = false; + goto free_another_head; } result = ldm_parse_privhead (data, ph[i]); put_dev_sector (sect); if (!result) { ldm_error ("Cannot find PRIVHEAD %d.", i+1); /* Log again */ if (i < 2) - goto out; /* Already logged */ + goto free_another_head; /* Already logged */ else break; /* FIXME ignore for now, 3rd PH can fail on odd-sized disks */ } @@ -373,30 +378,31 @@ static bool ldm_validate_privheads(struct parsed_partitions *state, if ((ph[0]->config_start > num_sects) || ((ph[0]->config_start + ph[0]->config_size) > num_sects)) { ldm_crit ("Database extends beyond the end of the disk."); - goto out; + goto free_another_head; } if ((ph[0]->logical_disk_start > ph[0]->config_start) || ((ph[0]->logical_disk_start + ph[0]->logical_disk_size) > ph[0]->config_start)) { ldm_crit ("Disk and database overlap."); - goto out; + goto free_another_head; } if (!ldm_compare_privheads (ph[0], ph[1])) { ldm_crit ("Primary and backup PRIVHEADs don't match."); - goto out; + goto free_another_head; } /* FIXME ignore this for now if (!ldm_compare_privheads (ph[0], ph[2])) { ldm_crit ("Primary and backup PRIVHEADs don't match."); - goto out; + goto free_another_head; }*/ ldm_debug ("Validated PRIVHEADs successfully."); result = true; -out: - kfree (ph[1]); - kfree (ph[2]); +free_another_head: + kfree(ph[2]); +free_a_head: + kfree(ph[1]); return result; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 4/5] block-LDM: Less function calls in ldm_validate_privheads() after error detection @ 2015-12-23 18:12 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-23 18:12 UTC (permalink / raw) To: linux-ntfs-dev, linux-block, Jens Axboe, Richard Russon Cc: Julia Lawall, LKML, kernel-janitors From: Markus Elfring <elfring@users.sourceforge.net> Date: Wed, 23 Dec 2015 14:31:01 +0100 The kfree() function was called by the ldm_validate_privheads() function during error handling even if the passed variable "ph" contained a null pointer. * Corresponding implementation details could be improved by adjustments for jump targets according to the Linux coding style convention. * The variable "result" will eventually be set to an appropriate value. Thus let us omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- block/partitions/ldm.c | 30 ++++++++++++++++++------------ 1 file changed, 18 insertions(+), 12 deletions(-) diff --git a/block/partitions/ldm.c b/block/partitions/ldm.c index 3118d24..6fc9150 100644 --- a/block/partitions/ldm.c +++ b/block/partitions/ldm.c @@ -335,16 +335,20 @@ static bool ldm_validate_privheads(struct parsed_partitions *state, struct privhead *ph[3] = { ph1 }; Sector sect; u8 *data; - bool result = false; + bool result; long num_sects; int i; BUG_ON (!state || !ph1); ph[1] = kmalloc (sizeof (*ph[1]), GFP_KERNEL); + if (!ph[1]) + return false; ph[2] = kmalloc (sizeof (*ph[2]), GFP_KERNEL); - if (!ph[1] || !ph[2]) - goto out; + if (!ph[2]) { + result = false; + goto free_a_head; + } /* off[1 & 2] are relative to ph[0]->config_start */ ph[0]->config_start = 0; @@ -355,14 +359,15 @@ static bool ldm_validate_privheads(struct parsed_partitions *state, §); if (!data) { ldm_crit ("Disk read failed."); - goto out; + result = false; + goto free_another_head; } result = ldm_parse_privhead (data, ph[i]); put_dev_sector (sect); if (!result) { ldm_error ("Cannot find PRIVHEAD %d.", i+1); /* Log again */ if (i < 2) - goto out; /* Already logged */ + goto free_another_head; /* Already logged */ else break; /* FIXME ignore for now, 3rd PH can fail on odd-sized disks */ } @@ -373,30 +378,31 @@ static bool ldm_validate_privheads(struct parsed_partitions *state, if ((ph[0]->config_start > num_sects) || ((ph[0]->config_start + ph[0]->config_size) > num_sects)) { ldm_crit ("Database extends beyond the end of the disk."); - goto out; + goto free_another_head; } if ((ph[0]->logical_disk_start > ph[0]->config_start) || ((ph[0]->logical_disk_start + ph[0]->logical_disk_size) > ph[0]->config_start)) { ldm_crit ("Disk and database overlap."); - goto out; + goto free_another_head; } if (!ldm_compare_privheads (ph[0], ph[1])) { ldm_crit ("Primary and backup PRIVHEADs don't match."); - goto out; + goto free_another_head; } /* FIXME ignore this for now if (!ldm_compare_privheads (ph[0], ph[2])) { ldm_crit ("Primary and backup PRIVHEADs don't match."); - goto out; + goto free_another_head; }*/ ldm_debug ("Validated PRIVHEADs successfully."); result = true; -out: - kfree (ph[1]); - kfree (ph[2]); +free_another_head: + kfree(ph[2]); +free_a_head: + kfree(ph[1]); return result; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 5/5] block-LDM: Fine-tuning for the source code formatting 2015-12-23 18:02 ` SF Markus Elfring @ 2015-12-23 18:13 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-23 18:13 UTC (permalink / raw) To: linux-ntfs-dev, linux-block, Jens Axboe, Richard Russon Cc: Julia Lawall, LKML, kernel-janitors From: Markus Elfring <elfring@users.sourceforge.net> Date: Wed, 23 Dec 2015 17:23:25 +0100 1. Remove some space characters and add a few according to the Linux coding style convention. 2. Reformat a bit of source code also for one switch statement. 3. Apply a few more recommendations from the script "checkpatch.pl". Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- block/partitions/ldm.c | 405 ++++++++++++++++++++++++++----------------------- 1 file changed, 213 insertions(+), 192 deletions(-) diff --git a/block/partitions/ldm.c b/block/partitions/ldm.c index 6fc9150..3ebe033 100644 --- a/block/partitions/ldm.c +++ b/block/partitions/ldm.c @@ -42,12 +42,12 @@ #ifndef CONFIG_LDM_DEBUG #define ldm_debug(...) do {} while (0) #else -#define ldm_debug(f, a...) _ldm_printk (KERN_DEBUG, __func__, f, ##a) +#define ldm_debug(f, a...) _ldm_printk(KERN_DEBUG, __func__, f, ##a) #endif -#define ldm_crit(f, a...) _ldm_printk (KERN_CRIT, __func__, f, ##a) -#define ldm_error(f, a...) _ldm_printk (KERN_ERR, __func__, f, ##a) -#define ldm_info(f, a...) _ldm_printk (KERN_INFO, __func__, f, ##a) +#define ldm_crit(f, a...) _ldm_printk(KERN_CRIT, __func__, f, ##a) +#define ldm_error(f, a...) _ldm_printk(KERN_ERR, __func__, f, ##a) +#define ldm_info(f, a...) _ldm_printk(KERN_INFO, __func__, f, ##a) static __printf(3, 4) void _ldm_printk(const char *level, const char *function, const char *fmt, ...) @@ -55,7 +55,7 @@ void _ldm_printk(const char *level, const char *function, const char *fmt, ...) struct va_format vaf; va_list args; - va_start (args, fmt); + va_start(args, fmt); vaf.fmt = fmt; vaf.va = &args; @@ -74,7 +74,7 @@ void _ldm_printk(const char *level, const char *function, const char *fmt, ...) * Return: 0-255 Success, the byte was parsed correctly * -1 Error, an invalid character was supplied */ -static int ldm_parse_hexbyte (const u8 *src) +static int ldm_parse_hexbyte(const u8 *src) { unsigned int x; /* For correct wrapping */ int h; @@ -102,7 +102,7 @@ static int ldm_parse_hexbyte (const u8 *src) * Return: 'true' @dest contains binary GUID * 'false' @dest contents are undefined */ -static bool ldm_parse_guid (const u8 *src, u8 *dest) +static bool ldm_parse_guid(const u8 *src, u8 *dest) { static const int size[] = { 4, 2, 2, 2, 6 }; int i, j, v; @@ -112,10 +112,11 @@ static bool ldm_parse_guid (const u8 *src, u8 *dest) return false; for (j = 0; j < 5; j++, src++) - for (i = 0; i < size[j]; i++, src+=2, *dest++ = v) - if ((v = ldm_parse_hexbyte (src)) < 0) + for (i = 0; i < size[j]; i++, src += 2, *dest++ = v) { + v = ldm_parse_hexbyte(src); + if (v < 0) return false; - + } return true; } @@ -189,36 +190,36 @@ static bool ldm_parse_privhead(const u8 *data, struct privhead *ph) * Return: 'true' @toc contains the TOCBLOCK data * 'false' @toc contents are undefined */ -static bool ldm_parse_tocblock (const u8 *data, struct tocblock *toc) +static bool ldm_parse_tocblock(const u8 *data, struct tocblock *toc) { - BUG_ON (!data || !toc); + BUG_ON(!data || !toc); if (MAGIC_TOCBLOCK != get_unaligned_be64(data)) { - ldm_crit ("Cannot find TOCBLOCK, database may be corrupt."); + ldm_crit("Cannot find TOCBLOCK, database may be corrupt."); return false; } - strncpy (toc->bitmap1_name, data + 0x24, sizeof (toc->bitmap1_name)); + strncpy(toc->bitmap1_name, data + 0x24, sizeof(toc->bitmap1_name)); toc->bitmap1_name[sizeof (toc->bitmap1_name) - 1] = 0; toc->bitmap1_start = get_unaligned_be64(data + 0x2E); toc->bitmap1_size = get_unaligned_be64(data + 0x36); - if (strncmp (toc->bitmap1_name, TOC_BITMAP1, - sizeof (toc->bitmap1_name)) != 0) { - ldm_crit ("TOCBLOCK's first bitmap is '%s', should be '%s'.", + if (strncmp(toc->bitmap1_name, TOC_BITMAP1, + sizeof(toc->bitmap1_name)) != 0) { + ldm_crit("TOCBLOCK's first bitmap is '%s', should be '%s'.", TOC_BITMAP1, toc->bitmap1_name); return false; } - strncpy (toc->bitmap2_name, data + 0x46, sizeof (toc->bitmap2_name)); - toc->bitmap2_name[sizeof (toc->bitmap2_name) - 1] = 0; + strncpy(toc->bitmap2_name, data + 0x46, sizeof(toc->bitmap2_name)); + toc->bitmap2_name[sizeof(toc->bitmap2_name) - 1] = 0; toc->bitmap2_start = get_unaligned_be64(data + 0x50); toc->bitmap2_size = get_unaligned_be64(data + 0x58); - if (strncmp (toc->bitmap2_name, TOC_BITMAP2, - sizeof (toc->bitmap2_name)) != 0) { - ldm_crit ("TOCBLOCK's second bitmap is '%s', should be '%s'.", + if (strncmp(toc->bitmap2_name, TOC_BITMAP2, + sizeof(toc->bitmap2_name)) != 0) { + ldm_crit("TOCBLOCK's second bitmap is '%s', should be '%s'.", TOC_BITMAP2, toc->bitmap2_name); return false; } - ldm_debug ("Parsed TOCBLOCK successfully."); + ldm_debug("Parsed TOCBLOCK successfully."); return true; } @@ -235,33 +236,33 @@ static bool ldm_parse_tocblock (const u8 *data, struct tocblock *toc) * Return: 'true' @vm contains VMDB info * 'false' @vm contents are undefined */ -static bool ldm_parse_vmdb (const u8 *data, struct vmdb *vm) +static bool ldm_parse_vmdb(const u8 *data, struct vmdb *vm) { - BUG_ON (!data || !vm); + BUG_ON(!data || !vm); if (MAGIC_VMDB != get_unaligned_be32(data)) { - ldm_crit ("Cannot find the VMDB, database may be corrupt."); + ldm_crit("Cannot find the VMDB, database may be corrupt."); return false; } vm->ver_major = get_unaligned_be16(data + 0x12); vm->ver_minor = get_unaligned_be16(data + 0x14); if ((vm->ver_major != 4) || (vm->ver_minor != 10)) { - ldm_error ("Expected VMDB version %d.%d, got %d.%d. " + ldm_error("Expected VMDB version %d.%d, got %d.%d. " "Aborting.", 4, 10, vm->ver_major, vm->ver_minor); return false; } vm->vblk_size = get_unaligned_be32(data + 0x08); if (vm->vblk_size == 0) { - ldm_error ("Illegal VBLK size"); + ldm_error("Illegal VBLK size"); return false; } vm->vblk_offset = get_unaligned_be32(data + 0x0C); vm->last_vblk_seq = get_unaligned_be32(data + 0x04); - ldm_debug ("Parsed VMDB successfully."); + ldm_debug("Parsed VMDB successfully."); return true; } @@ -275,10 +276,10 @@ static bool ldm_parse_vmdb (const u8 *data, struct vmdb *vm) * Return: 'true' Identical * 'false' Different */ -static bool ldm_compare_privheads (const struct privhead *ph1, +static bool ldm_compare_privheads(const struct privhead *ph1, const struct privhead *ph2) { - BUG_ON (!ph1 || !ph2); + BUG_ON(!ph1 || !ph2); return ((ph1->ver_major == ph2->ver_major) && (ph1->ver_minor == ph2->ver_minor) && @@ -286,7 +287,7 @@ static bool ldm_compare_privheads (const struct privhead *ph1, (ph1->logical_disk_size == ph2->logical_disk_size) && (ph1->config_start == ph2->config_start) && (ph1->config_size == ph2->config_size) && - !memcmp (ph1->disk_id, ph2->disk_id, GUID_SIZE)); + !memcmp(ph1->disk_id, ph2->disk_id, GUID_SIZE)); } /** @@ -299,19 +300,19 @@ static bool ldm_compare_privheads (const struct privhead *ph1, * Return: 'true' Identical * 'false' Different */ -static bool ldm_compare_tocblocks (const struct tocblock *toc1, +static bool ldm_compare_tocblocks(const struct tocblock *toc1, const struct tocblock *toc2) { - BUG_ON (!toc1 || !toc2); + BUG_ON(!toc1 || !toc2); return ((toc1->bitmap1_start == toc2->bitmap1_start) && (toc1->bitmap1_size == toc2->bitmap1_size) && (toc1->bitmap2_start == toc2->bitmap2_start) && (toc1->bitmap2_size == toc2->bitmap2_size) && - !strncmp (toc1->bitmap1_name, toc2->bitmap1_name, - sizeof (toc1->bitmap1_name)) && - !strncmp (toc1->bitmap2_name, toc2->bitmap2_name, - sizeof (toc1->bitmap2_name))); + !strncmp(toc1->bitmap1_name, toc2->bitmap1_name, + sizeof(toc1->bitmap1_name)) && + !strncmp(toc1->bitmap2_name, toc2->bitmap2_name, + sizeof(toc1->bitmap2_name))); } /** @@ -339,12 +340,12 @@ static bool ldm_validate_privheads(struct parsed_partitions *state, long num_sects; int i; - BUG_ON (!state || !ph1); + BUG_ON(!state || !ph1); - ph[1] = kmalloc (sizeof (*ph[1]), GFP_KERNEL); + ph[1] = kmalloc(sizeof(*ph[1]), GFP_KERNEL); if (!ph[1]) return false; - ph[2] = kmalloc (sizeof (*ph[2]), GFP_KERNEL); + ph[2] = kmalloc(sizeof(*ph[2]), GFP_KERNEL); if (!ph[2]) { result = false; goto free_a_head; @@ -358,18 +359,23 @@ static bool ldm_validate_privheads(struct parsed_partitions *state, data = read_part_sector(state, ph[0]->config_start + off[i], §); if (!data) { - ldm_crit ("Disk read failed."); + ldm_crit("Disk read failed."); result = false; goto free_another_head; } - result = ldm_parse_privhead (data, ph[i]); + result = ldm_parse_privhead(data, ph[i]); put_dev_sector (sect); if (!result) { - ldm_error ("Cannot find PRIVHEAD %d.", i+1); /* Log again */ + /* Log again */ + ldm_error("Cannot find PRIVHEAD %d.", i + 1); if (i < 2) goto free_another_head; /* Already logged */ else - break; /* FIXME ignore for now, 3rd PH can fail on odd-sized disks */ + /* + * FIXME: ignore for now, + * 3rd PH can fail on odd-sized disks + */ + break; } } @@ -377,19 +383,19 @@ static bool ldm_validate_privheads(struct parsed_partitions *state, if ((ph[0]->config_start > num_sects) || ((ph[0]->config_start + ph[0]->config_size) > num_sects)) { - ldm_crit ("Database extends beyond the end of the disk."); + ldm_crit("Database extends beyond the end of the disk."); goto free_another_head; } if ((ph[0]->logical_disk_start > ph[0]->config_start) || ((ph[0]->logical_disk_start + ph[0]->logical_disk_size) > ph[0]->config_start)) { - ldm_crit ("Disk and database overlap."); + ldm_crit("Disk and database overlap."); goto free_another_head; } - if (!ldm_compare_privheads (ph[0], ph[1])) { - ldm_crit ("Primary and backup PRIVHEADs don't match."); + if (!ldm_compare_privheads(ph[0], ph[1])) { + ldm_crit("Primary and backup PRIVHEADs don't match."); goto free_another_head; } /* FIXME ignore this for now @@ -397,7 +403,7 @@ static bool ldm_validate_privheads(struct parsed_partitions *state, ldm_crit ("Primary and backup PRIVHEADs don't match."); goto free_another_head; }*/ - ldm_debug ("Validated PRIVHEADs successfully."); + ldm_debug("Validated PRIVHEADs successfully."); result = true; free_another_head: kfree(ph[2]); @@ -501,42 +507,42 @@ static bool ldm_validate_vmdb(struct parsed_partitions *state, struct vmdb *vm; struct tocblock *toc; - BUG_ON (!state || !ldb); + BUG_ON(!state || !ldb); vm = &ldb->vm; toc = &ldb->toc; data = read_part_sector(state, base + OFF_VMDB, §); if (!data) { - ldm_crit ("Disk read failed."); + ldm_crit("Disk read failed."); return false; } - if (!ldm_parse_vmdb (data, vm)) + if (!ldm_parse_vmdb(data, vm)) goto out; /* Already logged */ /* Are there uncommitted transactions? */ if (get_unaligned_be16(data + 0x10) != 0x01) { - ldm_crit ("Database is not in a consistent state. Aborting."); + ldm_crit("Database is not in a consistent state. Aborting."); goto out; } if (vm->vblk_offset != 512) - ldm_info ("VBLKs start at offset 0x%04x.", vm->vblk_offset); + ldm_info("VBLKs start at offset 0x%04x.", vm->vblk_offset); /* * The last_vblkd_seq can be before the end of the vmdb, just make sure * it is not out of bounds. */ if ((vm->vblk_size * vm->last_vblk_seq) > (toc->bitmap1_size << 9)) { - ldm_crit ("VMDB exceeds allowed size specified by TOCBLOCK. " + ldm_crit("VMDB exceeds allowed size specified by TOCBLOCK. " "Database is corrupt. Aborting."); goto out; } result = true; out: - put_dev_sector (sect); + put_dev_sector(sect); return result; } @@ -569,11 +575,11 @@ static bool ldm_validate_partition_table(struct parsed_partitions *state) data = read_part_sector(state, 0, §); if (!data) { - ldm_info ("Disk read failed."); + ldm_info("Disk read failed."); return false; } - if (*(__le16*) (data + 0x01FE) != cpu_to_le16 (MSDOS_LABEL_MAGIC)) + if (*(__le16 *) (data + 0x01FE) != cpu_to_le16(MSDOS_LABEL_MAGIC)) goto out; p = (struct partition*)(data + 0x01BE); @@ -584,10 +590,10 @@ static bool ldm_validate_partition_table(struct parsed_partitions *state) } if (result) - ldm_debug ("Found W2K dynamic disk partition type."); + ldm_debug("Found W2K dynamic disk partition type."); out: - put_dev_sector (sect); + put_dev_sector(sect); return result; } @@ -603,15 +609,16 @@ out: * Return: Pointer, A matching vblk was found * NULL, No match, or an error */ -static struct vblk * ldm_get_disk_objid (const struct ldmdb *ldb) +static struct vblk *ldm_get_disk_objid(const struct ldmdb *ldb) { struct list_head *item; - BUG_ON (!ldb); + BUG_ON(!ldb); - list_for_each (item, &ldb->v_disk) { - struct vblk *v = list_entry (item, struct vblk, list); - if (!memcmp (v->vblk.disk.disk_id, ldb->ph.disk_id, GUID_SIZE)) + list_for_each(item, &ldb->v_disk) { + struct vblk *v = list_entry(item, struct vblk, list); + + if (!memcmp(v->vblk.disk.disk_id, ldb->ph.disk_id, GUID_SIZE)) return v; } @@ -635,7 +642,7 @@ static struct vblk * ldm_get_disk_objid (const struct ldmdb *ldb) * Return: 'true' Partition created * 'false' Error, probably a range checking problem */ -static bool ldm_create_data_partitions (struct parsed_partitions *pp, +static bool ldm_create_data_partitions(struct parsed_partitions *pp, const struct ldmdb *ldb) { struct list_head *item; @@ -644,25 +651,25 @@ static bool ldm_create_data_partitions (struct parsed_partitions *pp, struct vblk_part *part; int part_num = 1; - BUG_ON (!pp || !ldb); + BUG_ON(!pp || !ldb); - disk = ldm_get_disk_objid (ldb); + disk = ldm_get_disk_objid(ldb); if (!disk) { - ldm_crit ("Can't find the ID of this disk in the database."); + ldm_crit("Can't find the ID of this disk in the database."); return false; } strlcat(pp->pp_buf, " [LDM]", PAGE_SIZE); /* Create the data partitions */ - list_for_each (item, &ldb->v_part) { - vb = list_entry (item, struct vblk, list); + list_for_each(item, &ldb->v_part) { + vb = list_entry(item, struct vblk, list); part = &vb->vblk.part; if (part->disk_id != disk->obj_id) continue; - put_partition (pp, part_num, ldb->ph.logical_disk_start + + put_partition(pp, part_num, ldb->ph.logical_disk_start + part->start, part->size); part_num++; } @@ -722,12 +729,12 @@ static int ldm_relative(const u8 *buffer, int buflen, int base, int offset) * Return: n A number * 0 Zero, or an error occurred */ -static u64 ldm_get_vnum (const u8 *block) +static u64 ldm_get_vnum(const u8 *block) { u64 tmp = 0; u8 length; - BUG_ON (!block); + BUG_ON(!block); length = *block++; @@ -735,7 +742,7 @@ static u64 ldm_get_vnum (const u8 *block) while (length--) tmp = (tmp << 8) | *block++; else - ldm_error ("Illegal length %d.", length); + ldm_error("Illegal length %d.", length); return tmp; } @@ -757,18 +764,18 @@ static u64 ldm_get_vnum (const u8 *block) * n, String length in characters (excluding NULL) * buflen-1, String was truncated. */ -static int ldm_get_vstr (const u8 *block, u8 *buffer, int buflen) +static int ldm_get_vstr(const u8 *block, u8 *buffer, int buflen) { int length; - BUG_ON (!block || !buffer); + BUG_ON(!block || !buffer); length = block[0]; if (length >= buflen) { - ldm_error ("Truncating string %d -> %d.", length, buflen); + ldm_error("Truncating string %d -> %d.", length, buflen); length = buflen - 1; } - memcpy (buffer, block + 1, length); + memcpy(buffer, block + 1, length); buffer[length] = 0; return length; } @@ -785,22 +792,22 @@ static int ldm_get_vstr (const u8 *block, u8 *buffer, int buflen) * Return: 'true' @vb contains a Component VBLK * 'false' @vb contents are not defined */ -static bool ldm_parse_cmp3 (const u8 *buffer, int buflen, struct vblk *vb) +static bool ldm_parse_cmp3(const u8 *buffer, int buflen, struct vblk *vb) { int r_objid, r_name, r_vstate, r_child, r_parent, r_stripe, r_cols, len; struct vblk_comp *comp; - BUG_ON (!buffer || !vb); + BUG_ON(!buffer || !vb); - r_objid = ldm_relative (buffer, buflen, 0x18, 0); - r_name = ldm_relative (buffer, buflen, 0x18, r_objid); - r_vstate = ldm_relative (buffer, buflen, 0x18, r_name); - r_child = ldm_relative (buffer, buflen, 0x1D, r_vstate); - r_parent = ldm_relative (buffer, buflen, 0x2D, r_child); + r_objid = ldm_relative(buffer, buflen, 0x18, 0); + r_name = ldm_relative(buffer, buflen, 0x18, r_objid); + r_vstate = ldm_relative(buffer, buflen, 0x18, r_name); + r_child = ldm_relative(buffer, buflen, 0x1D, r_vstate); + r_parent = ldm_relative(buffer, buflen, 0x2D, r_child); if (buffer[0x12] & VBLK_FLAG_COMP_STRIPE) { - r_stripe = ldm_relative (buffer, buflen, 0x2E, r_parent); - r_cols = ldm_relative (buffer, buflen, 0x2E, r_stripe); + r_stripe = ldm_relative(buffer, buflen, 0x2E, r_parent); + r_cols = ldm_relative(buffer, buflen, 0x2E, r_stripe); len = r_cols; } else { r_stripe = 0; @@ -815,12 +822,12 @@ static bool ldm_parse_cmp3 (const u8 *buffer, int buflen, struct vblk *vb) return false; comp = &vb->vblk.comp; - ldm_get_vstr (buffer + 0x18 + r_name, comp->state, - sizeof (comp->state)); + ldm_get_vstr(buffer + 0x18 + r_name, comp->state, + sizeof(comp->state)); comp->type = buffer[0x18 + r_vstate]; - comp->children = ldm_get_vnum (buffer + 0x1D + r_vstate); - comp->parent_id = ldm_get_vnum (buffer + 0x2D + r_child); - comp->chunksize = r_stripe ? ldm_get_vnum (buffer+r_parent+0x2E) : 0; + comp->children = ldm_get_vnum(buffer + 0x1D + r_vstate); + comp->parent_id = ldm_get_vnum(buffer + 0x2D + r_child); + comp->chunksize = r_stripe ? ldm_get_vnum(buffer + r_parent + 0x2E) : 0; return true; } @@ -836,20 +843,20 @@ static bool ldm_parse_cmp3 (const u8 *buffer, int buflen, struct vblk *vb) * Return: 'true' @vb contains a Disk Group VBLK * 'false' @vb contents are not defined */ -static int ldm_parse_dgr3 (const u8 *buffer, int buflen, struct vblk *vb) +static int ldm_parse_dgr3(const u8 *buffer, int buflen, struct vblk *vb) { int r_objid, r_name, r_diskid, r_id1, r_id2, len; struct vblk_dgrp *dgrp; - BUG_ON (!buffer || !vb); + BUG_ON(!buffer || !vb); - r_objid = ldm_relative (buffer, buflen, 0x18, 0); - r_name = ldm_relative (buffer, buflen, 0x18, r_objid); - r_diskid = ldm_relative (buffer, buflen, 0x18, r_name); + r_objid = ldm_relative(buffer, buflen, 0x18, 0); + r_name = ldm_relative(buffer, buflen, 0x18, r_objid); + r_diskid = ldm_relative(buffer, buflen, 0x18, r_name); if (buffer[0x12] & VBLK_FLAG_DGR3_IDS) { - r_id1 = ldm_relative (buffer, buflen, 0x24, r_diskid); - r_id2 = ldm_relative (buffer, buflen, 0x24, r_id1); + r_id1 = ldm_relative(buffer, buflen, 0x24, r_diskid); + r_id2 = ldm_relative(buffer, buflen, 0x24, r_id1); len = r_id2; } else { r_id1 = 0; @@ -864,8 +871,8 @@ static int ldm_parse_dgr3 (const u8 *buffer, int buflen, struct vblk *vb) return false; dgrp = &vb->vblk.dgrp; - ldm_get_vstr (buffer + 0x18 + r_name, dgrp->disk_id, - sizeof (dgrp->disk_id)); + ldm_get_vstr(buffer + 0x18 + r_name, dgrp->disk_id, + sizeof(dgrp->disk_id)); return true; } @@ -886,14 +893,14 @@ static bool ldm_parse_dgr4 (const u8 *buffer, int buflen, struct vblk *vb) int r_objid, r_name, r_id1, r_id2, len; struct vblk_dgrp *dgrp; - BUG_ON (!buffer || !vb); + BUG_ON(!buffer || !vb); - r_objid = ldm_relative (buffer, buflen, 0x18, 0); - r_name = ldm_relative (buffer, buflen, 0x18, r_objid); + r_objid = ldm_relative(buffer, buflen, 0x18, 0); + r_name = ldm_relative(buffer, buflen, 0x18, r_objid); if (buffer[0x12] & VBLK_FLAG_DGR4_IDS) { - r_id1 = ldm_relative (buffer, buflen, 0x44, r_name); - r_id2 = ldm_relative (buffer, buflen, 0x44, r_id1); + r_id1 = ldm_relative(buffer, buflen, 0x44, r_name); + r_id2 = ldm_relative(buffer, buflen, 0x44, r_id1); len = r_id2; } else { r_id1 = 0; @@ -909,7 +916,7 @@ static bool ldm_parse_dgr4 (const u8 *buffer, int buflen, struct vblk *vb) dgrp = &vb->vblk.dgrp; - ldm_get_vstr (buffer + 0x18 + r_objid, buf, sizeof (buf)); + ldm_get_vstr(buffer + 0x18 + r_objid, buf, sizeof(buf)); return true; } @@ -924,17 +931,17 @@ static bool ldm_parse_dgr4 (const u8 *buffer, int buflen, struct vblk *vb) * Return: 'true' @vb contains a Disk VBLK * 'false' @vb contents are not defined */ -static bool ldm_parse_dsk3 (const u8 *buffer, int buflen, struct vblk *vb) +static bool ldm_parse_dsk3(const u8 *buffer, int buflen, struct vblk *vb) { int r_objid, r_name, r_diskid, r_altname, len; struct vblk_disk *disk; - BUG_ON (!buffer || !vb); + BUG_ON(!buffer || !vb); - r_objid = ldm_relative (buffer, buflen, 0x18, 0); - r_name = ldm_relative (buffer, buflen, 0x18, r_objid); - r_diskid = ldm_relative (buffer, buflen, 0x18, r_name); - r_altname = ldm_relative (buffer, buflen, 0x18, r_diskid); + r_objid = ldm_relative(buffer, buflen, 0x18, 0); + r_name = ldm_relative(buffer, buflen, 0x18, r_objid); + r_diskid = ldm_relative(buffer, buflen, 0x18, r_name); + r_altname = ldm_relative(buffer, buflen, 0x18, r_diskid); len = r_altname; if (len < 0) return false; @@ -944,9 +951,9 @@ static bool ldm_parse_dsk3 (const u8 *buffer, int buflen, struct vblk *vb) return false; disk = &vb->vblk.disk; - ldm_get_vstr (buffer + 0x18 + r_diskid, disk->alt_name, - sizeof (disk->alt_name)); - if (!ldm_parse_guid (buffer + 0x19 + r_name, disk->disk_id)) + ldm_get_vstr(buffer + 0x18 + r_diskid, disk->alt_name, + sizeof(disk->alt_name)); + if (!ldm_parse_guid(buffer + 0x19 + r_name, disk->disk_id)) return false; return true; @@ -963,15 +970,15 @@ static bool ldm_parse_dsk3 (const u8 *buffer, int buflen, struct vblk *vb) * Return: 'true' @vb contains a Disk VBLK * 'false' @vb contents are not defined */ -static bool ldm_parse_dsk4 (const u8 *buffer, int buflen, struct vblk *vb) +static bool ldm_parse_dsk4(const u8 *buffer, int buflen, struct vblk *vb) { int r_objid, r_name, len; struct vblk_disk *disk; - BUG_ON (!buffer || !vb); + BUG_ON(!buffer || !vb); - r_objid = ldm_relative (buffer, buflen, 0x18, 0); - r_name = ldm_relative (buffer, buflen, 0x18, r_objid); + r_objid = ldm_relative(buffer, buflen, 0x18, 0); + r_name = ldm_relative(buffer, buflen, 0x18, r_objid); len = r_name; if (len < 0) return false; @@ -981,7 +988,7 @@ static bool ldm_parse_dsk4 (const u8 *buffer, int buflen, struct vblk *vb) return false; disk = &vb->vblk.disk; - memcpy (disk->disk_id, buffer + 0x18 + r_name, GUID_SIZE); + memcpy(disk->disk_id, buffer + 0x18 + r_name, GUID_SIZE); return true; } @@ -1181,39 +1188,53 @@ static bool ldm_parse_vol5(const u8 *buffer, int buflen, struct vblk *vb) * Return: 'true' @vb contains a VBLK * 'false' @vb contents are not defined */ -static bool ldm_parse_vblk (const u8 *buf, int len, struct vblk *vb) +static bool ldm_parse_vblk(const u8 *buf, int len, struct vblk *vb) { bool result = false; int r_objid; - BUG_ON (!buf || !vb); + BUG_ON(!buf || !vb); - r_objid = ldm_relative (buf, len, 0x18, 0); + r_objid = ldm_relative(buf, len, 0x18, 0); if (r_objid < 0) { - ldm_error ("VBLK header is corrupt."); + ldm_error("VBLK header is corrupt."); return false; } vb->flags = buf[0x12]; vb->type = buf[0x13]; - vb->obj_id = ldm_get_vnum (buf + 0x18); - ldm_get_vstr (buf+0x18+r_objid, vb->name, sizeof (vb->name)); + vb->obj_id = ldm_get_vnum(buf + 0x18); + ldm_get_vstr(buf + 0x18 + r_objid, vb->name, sizeof(vb->name)); switch (vb->type) { - case VBLK_CMP3: result = ldm_parse_cmp3 (buf, len, vb); break; - case VBLK_DSK3: result = ldm_parse_dsk3 (buf, len, vb); break; - case VBLK_DSK4: result = ldm_parse_dsk4 (buf, len, vb); break; - case VBLK_DGR3: result = ldm_parse_dgr3 (buf, len, vb); break; - case VBLK_DGR4: result = ldm_parse_dgr4 (buf, len, vb); break; - case VBLK_PRT3: result = ldm_parse_prt3 (buf, len, vb); break; - case VBLK_VOL5: result = ldm_parse_vol5 (buf, len, vb); break; + case VBLK_CMP3: + result = ldm_parse_cmp3(buf, len, vb); + break; + case VBLK_DSK3: + result = ldm_parse_dsk3(buf, len, vb); + break; + case VBLK_DSK4: + result = ldm_parse_dsk4(buf, len, vb); + break; + case VBLK_DGR3: + result = ldm_parse_dgr3(buf, len, vb); + break; + case VBLK_DGR4: + result = ldm_parse_dgr4(buf, len, vb); + break; + case VBLK_PRT3: + result = ldm_parse_prt3(buf, len, vb); + break; + case VBLK_VOL5: + result = ldm_parse_vol5(buf, len, vb); + break; } if (result) - ldm_debug ("Parsed VBLK 0x%llx (type: 0x%02x) ok.", + ldm_debug("Parsed VBLK 0x%llx (type: 0x%02x) ok.", (unsigned long long) vb->obj_id, vb->type); else - ldm_error ("Failed to parse VBLK 0x%llx (type: 0x%02x).", + ldm_error("Failed to parse VBLK 0x%llx (type: 0x%02x).", (unsigned long long) vb->obj_id, vb->type); return result; @@ -1238,13 +1259,13 @@ static bool ldm_ldmdb_add (u8 *data, int len, struct ldmdb *ldb) struct vblk *vb; struct list_head *item; - BUG_ON (!data || !ldb); + BUG_ON(!data || !ldb); - vb = kmalloc (sizeof (*vb), GFP_KERNEL); + vb = kmalloc(sizeof(*vb), GFP_KERNEL); if (!vb) return false; - if (!ldm_parse_vblk (data, len, vb)) { + if (!ldm_parse_vblk(data, len, vb)) { kfree(vb); return false; /* Already logged */ } @@ -1253,29 +1274,29 @@ static bool ldm_ldmdb_add (u8 *data, int len, struct ldmdb *ldb) switch (vb->type) { case VBLK_DGR3: case VBLK_DGR4: - list_add (&vb->list, &ldb->v_dgrp); + list_add(&vb->list, &ldb->v_dgrp); break; case VBLK_DSK3: case VBLK_DSK4: - list_add (&vb->list, &ldb->v_disk); + list_add(&vb->list, &ldb->v_disk); break; case VBLK_VOL5: - list_add (&vb->list, &ldb->v_volu); + list_add(&vb->list, &ldb->v_volu); break; case VBLK_CMP3: - list_add (&vb->list, &ldb->v_comp); + list_add(&vb->list, &ldb->v_comp); break; case VBLK_PRT3: /* Sort by the partition's start sector. */ - list_for_each (item, &ldb->v_part) { - struct vblk *v = list_entry (item, struct vblk, list); + list_for_each(item, &ldb->v_part) { + struct vblk *v = list_entry(item, struct vblk, list); if ((v->vblk.part.disk_id == vb->vblk.part.disk_id) && (v->vblk.part.start > vb->vblk.part.start)) { - list_add_tail (&vb->list, &v->list); + list_add_tail(&vb->list, &v->list); return true; } } - list_add_tail (&vb->list, &ldb->v_part); + list_add_tail(&vb->list, &ldb->v_part); break; } return true; @@ -1293,13 +1314,13 @@ static bool ldm_ldmdb_add (u8 *data, int len, struct ldmdb *ldb) * Return: 'true' Success, the VBLK was added to the list * 'false' Error, a problem occurred */ -static bool ldm_frag_add (const u8 *data, int size, struct list_head *frags) +static bool ldm_frag_add(const u8 *data, int size, struct list_head *frags) { struct frag *f; struct list_head *item; int rec, num, group; - BUG_ON (!data || !frags); + BUG_ON(!data || !frags); if (size < 2 * VBLK_SIZE_HEAD) { ldm_error("Value of size is to small."); @@ -1310,7 +1331,7 @@ static bool ldm_frag_add (const u8 *data, int size, struct list_head *frags) rec = get_unaligned_be16(data + 0x0C); num = get_unaligned_be16(data + 0x0E); if ((num < 1) || (num > 4)) { - ldm_error ("A VBLK claims to have %d parts.", num); + ldm_error("A VBLK claims to have %d parts.", num); return false; } if (rec >= num) { @@ -1318,13 +1339,13 @@ static bool ldm_frag_add (const u8 *data, int size, struct list_head *frags) return false; } - list_for_each (item, frags) { - f = list_entry (item, struct frag, list); + list_for_each(item, frags) { + f = list_entry(item, struct frag, list); if (f->group == group) goto found; } - f = kmalloc (sizeof (*f) + size*num, GFP_KERNEL); + f = kmalloc(sizeof(*f) + size*num, GFP_KERNEL); if (!f) return false; @@ -1340,7 +1361,7 @@ found: return false; } if (f->map & (1 << rec)) { - ldm_error ("Duplicate VBLK, part %d.", rec); + ldm_error("Duplicate VBLK, part %d.", rec); f->map &= 0x7F; /* Mark the group as broken */ return false; } @@ -1361,14 +1382,14 @@ found: * * Return: none */ -static void ldm_frag_free (struct list_head *list) +static void ldm_frag_free(struct list_head *list) { struct list_head *item, *tmp; - BUG_ON (!list); + BUG_ON(!list); - list_for_each_safe (item, tmp, list) - kfree (list_entry (item, struct frag, list)); + list_for_each_safe(item, tmp, list) + kfree(list_entry(item, struct frag, list)); } /** @@ -1382,23 +1403,23 @@ static void ldm_frag_free (struct list_head *list) * Return: 'true' All the fragments we added successfully * 'false' One or more of the fragments we invalid */ -static bool ldm_frag_commit (struct list_head *frags, struct ldmdb *ldb) +static bool ldm_frag_commit(struct list_head *frags, struct ldmdb *ldb) { struct frag *f; struct list_head *item; - BUG_ON (!frags || !ldb); + BUG_ON(!frags || !ldb); - list_for_each (item, frags) { - f = list_entry (item, struct frag, list); + list_for_each(item, frags) { + f = list_entry(item, struct frag, list); if (f->map != 0xFF) { - ldm_error ("VBLK group %d is incomplete (0x%02x).", + ldm_error("VBLK group %d is incomplete (0x%02x).", f->group, f->map); return false; } - if (!ldm_ldmdb_add (f->data, f->num*ldb->vm.vblk_size, ldb)) + if (!ldm_ldmdb_add(f->data, f->num*ldb->vm.vblk_size, ldb)) return false; /* Already logged */ } return true; @@ -1435,35 +1456,35 @@ static bool ldm_get_vblks(struct parsed_partitions *state, unsigned long base, for (s = skip; s < finish; s++) { /* For each sector */ data = read_part_sector(state, base + OFF_VMDB + s, §); if (!data) { - ldm_crit ("Disk read failed."); + ldm_crit("Disk read failed."); goto out; } for (v = 0; v < perbuf; v++, data+=size) { /* For each vblk */ if (MAGIC_VBLK != get_unaligned_be32(data)) { - ldm_error ("Expected to find a VBLK."); + ldm_error("Expected to find a VBLK."); goto out; } recs = get_unaligned_be16(data + 0x0E); /* Number of records */ if (recs == 1) { - if (!ldm_ldmdb_add (data, size, ldb)) + if (!ldm_ldmdb_add(data, size, ldb)) goto out; /* Already logged */ } else if (recs > 1) { - if (!ldm_frag_add (data, size, &frags)) + if (!ldm_frag_add(data, size, &frags)) goto out; /* Already logged */ } /* else Record is not in use, ignore it. */ } - put_dev_sector (sect); + put_dev_sector(sect); data = NULL; } - result = ldm_frag_commit (&frags, ldb); /* Failures, already logged */ + result = ldm_frag_commit(&frags, ldb); /* Failures, already logged */ out: if (data) - put_dev_sector (sect); - ldm_frag_free (&frags); + put_dev_sector(sect); + ldm_frag_free(&frags); return result; } @@ -1476,14 +1497,14 @@ out: * * Return: none */ -static void ldm_free_vblks (struct list_head *lh) +static void ldm_free_vblks(struct list_head *lh) { struct list_head *item, *tmp; - BUG_ON (!lh); + BUG_ON(!lh); - list_for_each_safe (item, tmp, lh) - kfree (list_entry (item, struct vblk, list)); + list_for_each_safe(item, tmp, lh) + kfree(list_entry(item, struct vblk, list)); } @@ -1516,7 +1537,7 @@ int ldm_partition(struct parsed_partitions *state) if (!ldm_validate_partition_table(state)) return 0; - ldb = kmalloc (sizeof (*ldb), GFP_KERNEL); + ldb = kmalloc(sizeof(*ldb), GFP_KERNEL); if (!ldb) return -1; @@ -1533,31 +1554,31 @@ int ldm_partition(struct parsed_partitions *state) goto out; /* Already logged */ /* Initialize vblk lists in ldmdb struct */ - INIT_LIST_HEAD (&ldb->v_dgrp); - INIT_LIST_HEAD (&ldb->v_disk); - INIT_LIST_HEAD (&ldb->v_volu); - INIT_LIST_HEAD (&ldb->v_comp); - INIT_LIST_HEAD (&ldb->v_part); + INIT_LIST_HEAD(&ldb->v_dgrp); + INIT_LIST_HEAD(&ldb->v_disk); + INIT_LIST_HEAD(&ldb->v_volu); + INIT_LIST_HEAD(&ldb->v_comp); + INIT_LIST_HEAD(&ldb->v_part); if (!ldm_get_vblks(state, base, ldb)) { - ldm_crit ("Failed to read the VBLKs from the database."); + ldm_crit("Failed to read the VBLKs from the database."); goto cleanup; } /* Finally, create the data partition devices. */ if (ldm_create_data_partitions(state, ldb)) { - ldm_debug ("Parsed LDM database successfully."); + ldm_debug("Parsed LDM database successfully."); result = 1; } /* else Already logged */ cleanup: - ldm_free_vblks (&ldb->v_dgrp); - ldm_free_vblks (&ldb->v_disk); - ldm_free_vblks (&ldb->v_volu); - ldm_free_vblks (&ldb->v_comp); - ldm_free_vblks (&ldb->v_part); + ldm_free_vblks(&ldb->v_dgrp); + ldm_free_vblks(&ldb->v_disk); + ldm_free_vblks(&ldb->v_volu); + ldm_free_vblks(&ldb->v_comp); + ldm_free_vblks(&ldb->v_part); out: - kfree (ldb); + kfree(ldb); return result; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 5/5] block-LDM: Fine-tuning for the source code formatting @ 2015-12-23 18:13 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-23 18:13 UTC (permalink / raw) To: linux-ntfs-dev, linux-block, Jens Axboe, Richard Russon Cc: Julia Lawall, LKML, kernel-janitors From: Markus Elfring <elfring@users.sourceforge.net> Date: Wed, 23 Dec 2015 17:23:25 +0100 1. Remove some space characters and add a few according to the Linux coding style convention. 2. Reformat a bit of source code also for one switch statement. 3. Apply a few more recommendations from the script "checkpatch.pl". Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- block/partitions/ldm.c | 405 ++++++++++++++++++++++++++----------------------- 1 file changed, 213 insertions(+), 192 deletions(-) diff --git a/block/partitions/ldm.c b/block/partitions/ldm.c index 6fc9150..3ebe033 100644 --- a/block/partitions/ldm.c +++ b/block/partitions/ldm.c @@ -42,12 +42,12 @@ #ifndef CONFIG_LDM_DEBUG #define ldm_debug(...) do {} while (0) #else -#define ldm_debug(f, a...) _ldm_printk (KERN_DEBUG, __func__, f, ##a) +#define ldm_debug(f, a...) _ldm_printk(KERN_DEBUG, __func__, f, ##a) #endif -#define ldm_crit(f, a...) _ldm_printk (KERN_CRIT, __func__, f, ##a) -#define ldm_error(f, a...) _ldm_printk (KERN_ERR, __func__, f, ##a) -#define ldm_info(f, a...) _ldm_printk (KERN_INFO, __func__, f, ##a) +#define ldm_crit(f, a...) _ldm_printk(KERN_CRIT, __func__, f, ##a) +#define ldm_error(f, a...) _ldm_printk(KERN_ERR, __func__, f, ##a) +#define ldm_info(f, a...) _ldm_printk(KERN_INFO, __func__, f, ##a) static __printf(3, 4) void _ldm_printk(const char *level, const char *function, const char *fmt, ...) @@ -55,7 +55,7 @@ void _ldm_printk(const char *level, const char *function, const char *fmt, ...) struct va_format vaf; va_list args; - va_start (args, fmt); + va_start(args, fmt); vaf.fmt = fmt; vaf.va = &args; @@ -74,7 +74,7 @@ void _ldm_printk(const char *level, const char *function, const char *fmt, ...) * Return: 0-255 Success, the byte was parsed correctly * -1 Error, an invalid character was supplied */ -static int ldm_parse_hexbyte (const u8 *src) +static int ldm_parse_hexbyte(const u8 *src) { unsigned int x; /* For correct wrapping */ int h; @@ -102,7 +102,7 @@ static int ldm_parse_hexbyte (const u8 *src) * Return: 'true' @dest contains binary GUID * 'false' @dest contents are undefined */ -static bool ldm_parse_guid (const u8 *src, u8 *dest) +static bool ldm_parse_guid(const u8 *src, u8 *dest) { static const int size[] = { 4, 2, 2, 2, 6 }; int i, j, v; @@ -112,10 +112,11 @@ static bool ldm_parse_guid (const u8 *src, u8 *dest) return false; for (j = 0; j < 5; j++, src++) - for (i = 0; i < size[j]; i++, src+=2, *dest++ = v) - if ((v = ldm_parse_hexbyte (src)) < 0) + for (i = 0; i < size[j]; i++, src += 2, *dest++ = v) { + v = ldm_parse_hexbyte(src); + if (v < 0) return false; - + } return true; } @@ -189,36 +190,36 @@ static bool ldm_parse_privhead(const u8 *data, struct privhead *ph) * Return: 'true' @toc contains the TOCBLOCK data * 'false' @toc contents are undefined */ -static bool ldm_parse_tocblock (const u8 *data, struct tocblock *toc) +static bool ldm_parse_tocblock(const u8 *data, struct tocblock *toc) { - BUG_ON (!data || !toc); + BUG_ON(!data || !toc); if (MAGIC_TOCBLOCK != get_unaligned_be64(data)) { - ldm_crit ("Cannot find TOCBLOCK, database may be corrupt."); + ldm_crit("Cannot find TOCBLOCK, database may be corrupt."); return false; } - strncpy (toc->bitmap1_name, data + 0x24, sizeof (toc->bitmap1_name)); + strncpy(toc->bitmap1_name, data + 0x24, sizeof(toc->bitmap1_name)); toc->bitmap1_name[sizeof (toc->bitmap1_name) - 1] = 0; toc->bitmap1_start = get_unaligned_be64(data + 0x2E); toc->bitmap1_size = get_unaligned_be64(data + 0x36); - if (strncmp (toc->bitmap1_name, TOC_BITMAP1, - sizeof (toc->bitmap1_name)) != 0) { - ldm_crit ("TOCBLOCK's first bitmap is '%s', should be '%s'.", + if (strncmp(toc->bitmap1_name, TOC_BITMAP1, + sizeof(toc->bitmap1_name)) != 0) { + ldm_crit("TOCBLOCK's first bitmap is '%s', should be '%s'.", TOC_BITMAP1, toc->bitmap1_name); return false; } - strncpy (toc->bitmap2_name, data + 0x46, sizeof (toc->bitmap2_name)); - toc->bitmap2_name[sizeof (toc->bitmap2_name) - 1] = 0; + strncpy(toc->bitmap2_name, data + 0x46, sizeof(toc->bitmap2_name)); + toc->bitmap2_name[sizeof(toc->bitmap2_name) - 1] = 0; toc->bitmap2_start = get_unaligned_be64(data + 0x50); toc->bitmap2_size = get_unaligned_be64(data + 0x58); - if (strncmp (toc->bitmap2_name, TOC_BITMAP2, - sizeof (toc->bitmap2_name)) != 0) { - ldm_crit ("TOCBLOCK's second bitmap is '%s', should be '%s'.", + if (strncmp(toc->bitmap2_name, TOC_BITMAP2, + sizeof(toc->bitmap2_name)) != 0) { + ldm_crit("TOCBLOCK's second bitmap is '%s', should be '%s'.", TOC_BITMAP2, toc->bitmap2_name); return false; } - ldm_debug ("Parsed TOCBLOCK successfully."); + ldm_debug("Parsed TOCBLOCK successfully."); return true; } @@ -235,33 +236,33 @@ static bool ldm_parse_tocblock (const u8 *data, struct tocblock *toc) * Return: 'true' @vm contains VMDB info * 'false' @vm contents are undefined */ -static bool ldm_parse_vmdb (const u8 *data, struct vmdb *vm) +static bool ldm_parse_vmdb(const u8 *data, struct vmdb *vm) { - BUG_ON (!data || !vm); + BUG_ON(!data || !vm); if (MAGIC_VMDB != get_unaligned_be32(data)) { - ldm_crit ("Cannot find the VMDB, database may be corrupt."); + ldm_crit("Cannot find the VMDB, database may be corrupt."); return false; } vm->ver_major = get_unaligned_be16(data + 0x12); vm->ver_minor = get_unaligned_be16(data + 0x14); if ((vm->ver_major != 4) || (vm->ver_minor != 10)) { - ldm_error ("Expected VMDB version %d.%d, got %d.%d. " + ldm_error("Expected VMDB version %d.%d, got %d.%d. " "Aborting.", 4, 10, vm->ver_major, vm->ver_minor); return false; } vm->vblk_size = get_unaligned_be32(data + 0x08); if (vm->vblk_size = 0) { - ldm_error ("Illegal VBLK size"); + ldm_error("Illegal VBLK size"); return false; } vm->vblk_offset = get_unaligned_be32(data + 0x0C); vm->last_vblk_seq = get_unaligned_be32(data + 0x04); - ldm_debug ("Parsed VMDB successfully."); + ldm_debug("Parsed VMDB successfully."); return true; } @@ -275,10 +276,10 @@ static bool ldm_parse_vmdb (const u8 *data, struct vmdb *vm) * Return: 'true' Identical * 'false' Different */ -static bool ldm_compare_privheads (const struct privhead *ph1, +static bool ldm_compare_privheads(const struct privhead *ph1, const struct privhead *ph2) { - BUG_ON (!ph1 || !ph2); + BUG_ON(!ph1 || !ph2); return ((ph1->ver_major = ph2->ver_major) && (ph1->ver_minor = ph2->ver_minor) && @@ -286,7 +287,7 @@ static bool ldm_compare_privheads (const struct privhead *ph1, (ph1->logical_disk_size = ph2->logical_disk_size) && (ph1->config_start = ph2->config_start) && (ph1->config_size = ph2->config_size) && - !memcmp (ph1->disk_id, ph2->disk_id, GUID_SIZE)); + !memcmp(ph1->disk_id, ph2->disk_id, GUID_SIZE)); } /** @@ -299,19 +300,19 @@ static bool ldm_compare_privheads (const struct privhead *ph1, * Return: 'true' Identical * 'false' Different */ -static bool ldm_compare_tocblocks (const struct tocblock *toc1, +static bool ldm_compare_tocblocks(const struct tocblock *toc1, const struct tocblock *toc2) { - BUG_ON (!toc1 || !toc2); + BUG_ON(!toc1 || !toc2); return ((toc1->bitmap1_start = toc2->bitmap1_start) && (toc1->bitmap1_size = toc2->bitmap1_size) && (toc1->bitmap2_start = toc2->bitmap2_start) && (toc1->bitmap2_size = toc2->bitmap2_size) && - !strncmp (toc1->bitmap1_name, toc2->bitmap1_name, - sizeof (toc1->bitmap1_name)) && - !strncmp (toc1->bitmap2_name, toc2->bitmap2_name, - sizeof (toc1->bitmap2_name))); + !strncmp(toc1->bitmap1_name, toc2->bitmap1_name, + sizeof(toc1->bitmap1_name)) && + !strncmp(toc1->bitmap2_name, toc2->bitmap2_name, + sizeof(toc1->bitmap2_name))); } /** @@ -339,12 +340,12 @@ static bool ldm_validate_privheads(struct parsed_partitions *state, long num_sects; int i; - BUG_ON (!state || !ph1); + BUG_ON(!state || !ph1); - ph[1] = kmalloc (sizeof (*ph[1]), GFP_KERNEL); + ph[1] = kmalloc(sizeof(*ph[1]), GFP_KERNEL); if (!ph[1]) return false; - ph[2] = kmalloc (sizeof (*ph[2]), GFP_KERNEL); + ph[2] = kmalloc(sizeof(*ph[2]), GFP_KERNEL); if (!ph[2]) { result = false; goto free_a_head; @@ -358,18 +359,23 @@ static bool ldm_validate_privheads(struct parsed_partitions *state, data = read_part_sector(state, ph[0]->config_start + off[i], §); if (!data) { - ldm_crit ("Disk read failed."); + ldm_crit("Disk read failed."); result = false; goto free_another_head; } - result = ldm_parse_privhead (data, ph[i]); + result = ldm_parse_privhead(data, ph[i]); put_dev_sector (sect); if (!result) { - ldm_error ("Cannot find PRIVHEAD %d.", i+1); /* Log again */ + /* Log again */ + ldm_error("Cannot find PRIVHEAD %d.", i + 1); if (i < 2) goto free_another_head; /* Already logged */ else - break; /* FIXME ignore for now, 3rd PH can fail on odd-sized disks */ + /* + * FIXME: ignore for now, + * 3rd PH can fail on odd-sized disks + */ + break; } } @@ -377,19 +383,19 @@ static bool ldm_validate_privheads(struct parsed_partitions *state, if ((ph[0]->config_start > num_sects) || ((ph[0]->config_start + ph[0]->config_size) > num_sects)) { - ldm_crit ("Database extends beyond the end of the disk."); + ldm_crit("Database extends beyond the end of the disk."); goto free_another_head; } if ((ph[0]->logical_disk_start > ph[0]->config_start) || ((ph[0]->logical_disk_start + ph[0]->logical_disk_size) > ph[0]->config_start)) { - ldm_crit ("Disk and database overlap."); + ldm_crit("Disk and database overlap."); goto free_another_head; } - if (!ldm_compare_privheads (ph[0], ph[1])) { - ldm_crit ("Primary and backup PRIVHEADs don't match."); + if (!ldm_compare_privheads(ph[0], ph[1])) { + ldm_crit("Primary and backup PRIVHEADs don't match."); goto free_another_head; } /* FIXME ignore this for now @@ -397,7 +403,7 @@ static bool ldm_validate_privheads(struct parsed_partitions *state, ldm_crit ("Primary and backup PRIVHEADs don't match."); goto free_another_head; }*/ - ldm_debug ("Validated PRIVHEADs successfully."); + ldm_debug("Validated PRIVHEADs successfully."); result = true; free_another_head: kfree(ph[2]); @@ -501,42 +507,42 @@ static bool ldm_validate_vmdb(struct parsed_partitions *state, struct vmdb *vm; struct tocblock *toc; - BUG_ON (!state || !ldb); + BUG_ON(!state || !ldb); vm = &ldb->vm; toc = &ldb->toc; data = read_part_sector(state, base + OFF_VMDB, §); if (!data) { - ldm_crit ("Disk read failed."); + ldm_crit("Disk read failed."); return false; } - if (!ldm_parse_vmdb (data, vm)) + if (!ldm_parse_vmdb(data, vm)) goto out; /* Already logged */ /* Are there uncommitted transactions? */ if (get_unaligned_be16(data + 0x10) != 0x01) { - ldm_crit ("Database is not in a consistent state. Aborting."); + ldm_crit("Database is not in a consistent state. Aborting."); goto out; } if (vm->vblk_offset != 512) - ldm_info ("VBLKs start at offset 0x%04x.", vm->vblk_offset); + ldm_info("VBLKs start at offset 0x%04x.", vm->vblk_offset); /* * The last_vblkd_seq can be before the end of the vmdb, just make sure * it is not out of bounds. */ if ((vm->vblk_size * vm->last_vblk_seq) > (toc->bitmap1_size << 9)) { - ldm_crit ("VMDB exceeds allowed size specified by TOCBLOCK. " + ldm_crit("VMDB exceeds allowed size specified by TOCBLOCK. " "Database is corrupt. Aborting."); goto out; } result = true; out: - put_dev_sector (sect); + put_dev_sector(sect); return result; } @@ -569,11 +575,11 @@ static bool ldm_validate_partition_table(struct parsed_partitions *state) data = read_part_sector(state, 0, §); if (!data) { - ldm_info ("Disk read failed."); + ldm_info("Disk read failed."); return false; } - if (*(__le16*) (data + 0x01FE) != cpu_to_le16 (MSDOS_LABEL_MAGIC)) + if (*(__le16 *) (data + 0x01FE) != cpu_to_le16(MSDOS_LABEL_MAGIC)) goto out; p = (struct partition*)(data + 0x01BE); @@ -584,10 +590,10 @@ static bool ldm_validate_partition_table(struct parsed_partitions *state) } if (result) - ldm_debug ("Found W2K dynamic disk partition type."); + ldm_debug("Found W2K dynamic disk partition type."); out: - put_dev_sector (sect); + put_dev_sector(sect); return result; } @@ -603,15 +609,16 @@ out: * Return: Pointer, A matching vblk was found * NULL, No match, or an error */ -static struct vblk * ldm_get_disk_objid (const struct ldmdb *ldb) +static struct vblk *ldm_get_disk_objid(const struct ldmdb *ldb) { struct list_head *item; - BUG_ON (!ldb); + BUG_ON(!ldb); - list_for_each (item, &ldb->v_disk) { - struct vblk *v = list_entry (item, struct vblk, list); - if (!memcmp (v->vblk.disk.disk_id, ldb->ph.disk_id, GUID_SIZE)) + list_for_each(item, &ldb->v_disk) { + struct vblk *v = list_entry(item, struct vblk, list); + + if (!memcmp(v->vblk.disk.disk_id, ldb->ph.disk_id, GUID_SIZE)) return v; } @@ -635,7 +642,7 @@ static struct vblk * ldm_get_disk_objid (const struct ldmdb *ldb) * Return: 'true' Partition created * 'false' Error, probably a range checking problem */ -static bool ldm_create_data_partitions (struct parsed_partitions *pp, +static bool ldm_create_data_partitions(struct parsed_partitions *pp, const struct ldmdb *ldb) { struct list_head *item; @@ -644,25 +651,25 @@ static bool ldm_create_data_partitions (struct parsed_partitions *pp, struct vblk_part *part; int part_num = 1; - BUG_ON (!pp || !ldb); + BUG_ON(!pp || !ldb); - disk = ldm_get_disk_objid (ldb); + disk = ldm_get_disk_objid(ldb); if (!disk) { - ldm_crit ("Can't find the ID of this disk in the database."); + ldm_crit("Can't find the ID of this disk in the database."); return false; } strlcat(pp->pp_buf, " [LDM]", PAGE_SIZE); /* Create the data partitions */ - list_for_each (item, &ldb->v_part) { - vb = list_entry (item, struct vblk, list); + list_for_each(item, &ldb->v_part) { + vb = list_entry(item, struct vblk, list); part = &vb->vblk.part; if (part->disk_id != disk->obj_id) continue; - put_partition (pp, part_num, ldb->ph.logical_disk_start + + put_partition(pp, part_num, ldb->ph.logical_disk_start + part->start, part->size); part_num++; } @@ -722,12 +729,12 @@ static int ldm_relative(const u8 *buffer, int buflen, int base, int offset) * Return: n A number * 0 Zero, or an error occurred */ -static u64 ldm_get_vnum (const u8 *block) +static u64 ldm_get_vnum(const u8 *block) { u64 tmp = 0; u8 length; - BUG_ON (!block); + BUG_ON(!block); length = *block++; @@ -735,7 +742,7 @@ static u64 ldm_get_vnum (const u8 *block) while (length--) tmp = (tmp << 8) | *block++; else - ldm_error ("Illegal length %d.", length); + ldm_error("Illegal length %d.", length); return tmp; } @@ -757,18 +764,18 @@ static u64 ldm_get_vnum (const u8 *block) * n, String length in characters (excluding NULL) * buflen-1, String was truncated. */ -static int ldm_get_vstr (const u8 *block, u8 *buffer, int buflen) +static int ldm_get_vstr(const u8 *block, u8 *buffer, int buflen) { int length; - BUG_ON (!block || !buffer); + BUG_ON(!block || !buffer); length = block[0]; if (length >= buflen) { - ldm_error ("Truncating string %d -> %d.", length, buflen); + ldm_error("Truncating string %d -> %d.", length, buflen); length = buflen - 1; } - memcpy (buffer, block + 1, length); + memcpy(buffer, block + 1, length); buffer[length] = 0; return length; } @@ -785,22 +792,22 @@ static int ldm_get_vstr (const u8 *block, u8 *buffer, int buflen) * Return: 'true' @vb contains a Component VBLK * 'false' @vb contents are not defined */ -static bool ldm_parse_cmp3 (const u8 *buffer, int buflen, struct vblk *vb) +static bool ldm_parse_cmp3(const u8 *buffer, int buflen, struct vblk *vb) { int r_objid, r_name, r_vstate, r_child, r_parent, r_stripe, r_cols, len; struct vblk_comp *comp; - BUG_ON (!buffer || !vb); + BUG_ON(!buffer || !vb); - r_objid = ldm_relative (buffer, buflen, 0x18, 0); - r_name = ldm_relative (buffer, buflen, 0x18, r_objid); - r_vstate = ldm_relative (buffer, buflen, 0x18, r_name); - r_child = ldm_relative (buffer, buflen, 0x1D, r_vstate); - r_parent = ldm_relative (buffer, buflen, 0x2D, r_child); + r_objid = ldm_relative(buffer, buflen, 0x18, 0); + r_name = ldm_relative(buffer, buflen, 0x18, r_objid); + r_vstate = ldm_relative(buffer, buflen, 0x18, r_name); + r_child = ldm_relative(buffer, buflen, 0x1D, r_vstate); + r_parent = ldm_relative(buffer, buflen, 0x2D, r_child); if (buffer[0x12] & VBLK_FLAG_COMP_STRIPE) { - r_stripe = ldm_relative (buffer, buflen, 0x2E, r_parent); - r_cols = ldm_relative (buffer, buflen, 0x2E, r_stripe); + r_stripe = ldm_relative(buffer, buflen, 0x2E, r_parent); + r_cols = ldm_relative(buffer, buflen, 0x2E, r_stripe); len = r_cols; } else { r_stripe = 0; @@ -815,12 +822,12 @@ static bool ldm_parse_cmp3 (const u8 *buffer, int buflen, struct vblk *vb) return false; comp = &vb->vblk.comp; - ldm_get_vstr (buffer + 0x18 + r_name, comp->state, - sizeof (comp->state)); + ldm_get_vstr(buffer + 0x18 + r_name, comp->state, + sizeof(comp->state)); comp->type = buffer[0x18 + r_vstate]; - comp->children = ldm_get_vnum (buffer + 0x1D + r_vstate); - comp->parent_id = ldm_get_vnum (buffer + 0x2D + r_child); - comp->chunksize = r_stripe ? ldm_get_vnum (buffer+r_parent+0x2E) : 0; + comp->children = ldm_get_vnum(buffer + 0x1D + r_vstate); + comp->parent_id = ldm_get_vnum(buffer + 0x2D + r_child); + comp->chunksize = r_stripe ? ldm_get_vnum(buffer + r_parent + 0x2E) : 0; return true; } @@ -836,20 +843,20 @@ static bool ldm_parse_cmp3 (const u8 *buffer, int buflen, struct vblk *vb) * Return: 'true' @vb contains a Disk Group VBLK * 'false' @vb contents are not defined */ -static int ldm_parse_dgr3 (const u8 *buffer, int buflen, struct vblk *vb) +static int ldm_parse_dgr3(const u8 *buffer, int buflen, struct vblk *vb) { int r_objid, r_name, r_diskid, r_id1, r_id2, len; struct vblk_dgrp *dgrp; - BUG_ON (!buffer || !vb); + BUG_ON(!buffer || !vb); - r_objid = ldm_relative (buffer, buflen, 0x18, 0); - r_name = ldm_relative (buffer, buflen, 0x18, r_objid); - r_diskid = ldm_relative (buffer, buflen, 0x18, r_name); + r_objid = ldm_relative(buffer, buflen, 0x18, 0); + r_name = ldm_relative(buffer, buflen, 0x18, r_objid); + r_diskid = ldm_relative(buffer, buflen, 0x18, r_name); if (buffer[0x12] & VBLK_FLAG_DGR3_IDS) { - r_id1 = ldm_relative (buffer, buflen, 0x24, r_diskid); - r_id2 = ldm_relative (buffer, buflen, 0x24, r_id1); + r_id1 = ldm_relative(buffer, buflen, 0x24, r_diskid); + r_id2 = ldm_relative(buffer, buflen, 0x24, r_id1); len = r_id2; } else { r_id1 = 0; @@ -864,8 +871,8 @@ static int ldm_parse_dgr3 (const u8 *buffer, int buflen, struct vblk *vb) return false; dgrp = &vb->vblk.dgrp; - ldm_get_vstr (buffer + 0x18 + r_name, dgrp->disk_id, - sizeof (dgrp->disk_id)); + ldm_get_vstr(buffer + 0x18 + r_name, dgrp->disk_id, + sizeof(dgrp->disk_id)); return true; } @@ -886,14 +893,14 @@ static bool ldm_parse_dgr4 (const u8 *buffer, int buflen, struct vblk *vb) int r_objid, r_name, r_id1, r_id2, len; struct vblk_dgrp *dgrp; - BUG_ON (!buffer || !vb); + BUG_ON(!buffer || !vb); - r_objid = ldm_relative (buffer, buflen, 0x18, 0); - r_name = ldm_relative (buffer, buflen, 0x18, r_objid); + r_objid = ldm_relative(buffer, buflen, 0x18, 0); + r_name = ldm_relative(buffer, buflen, 0x18, r_objid); if (buffer[0x12] & VBLK_FLAG_DGR4_IDS) { - r_id1 = ldm_relative (buffer, buflen, 0x44, r_name); - r_id2 = ldm_relative (buffer, buflen, 0x44, r_id1); + r_id1 = ldm_relative(buffer, buflen, 0x44, r_name); + r_id2 = ldm_relative(buffer, buflen, 0x44, r_id1); len = r_id2; } else { r_id1 = 0; @@ -909,7 +916,7 @@ static bool ldm_parse_dgr4 (const u8 *buffer, int buflen, struct vblk *vb) dgrp = &vb->vblk.dgrp; - ldm_get_vstr (buffer + 0x18 + r_objid, buf, sizeof (buf)); + ldm_get_vstr(buffer + 0x18 + r_objid, buf, sizeof(buf)); return true; } @@ -924,17 +931,17 @@ static bool ldm_parse_dgr4 (const u8 *buffer, int buflen, struct vblk *vb) * Return: 'true' @vb contains a Disk VBLK * 'false' @vb contents are not defined */ -static bool ldm_parse_dsk3 (const u8 *buffer, int buflen, struct vblk *vb) +static bool ldm_parse_dsk3(const u8 *buffer, int buflen, struct vblk *vb) { int r_objid, r_name, r_diskid, r_altname, len; struct vblk_disk *disk; - BUG_ON (!buffer || !vb); + BUG_ON(!buffer || !vb); - r_objid = ldm_relative (buffer, buflen, 0x18, 0); - r_name = ldm_relative (buffer, buflen, 0x18, r_objid); - r_diskid = ldm_relative (buffer, buflen, 0x18, r_name); - r_altname = ldm_relative (buffer, buflen, 0x18, r_diskid); + r_objid = ldm_relative(buffer, buflen, 0x18, 0); + r_name = ldm_relative(buffer, buflen, 0x18, r_objid); + r_diskid = ldm_relative(buffer, buflen, 0x18, r_name); + r_altname = ldm_relative(buffer, buflen, 0x18, r_diskid); len = r_altname; if (len < 0) return false; @@ -944,9 +951,9 @@ static bool ldm_parse_dsk3 (const u8 *buffer, int buflen, struct vblk *vb) return false; disk = &vb->vblk.disk; - ldm_get_vstr (buffer + 0x18 + r_diskid, disk->alt_name, - sizeof (disk->alt_name)); - if (!ldm_parse_guid (buffer + 0x19 + r_name, disk->disk_id)) + ldm_get_vstr(buffer + 0x18 + r_diskid, disk->alt_name, + sizeof(disk->alt_name)); + if (!ldm_parse_guid(buffer + 0x19 + r_name, disk->disk_id)) return false; return true; @@ -963,15 +970,15 @@ static bool ldm_parse_dsk3 (const u8 *buffer, int buflen, struct vblk *vb) * Return: 'true' @vb contains a Disk VBLK * 'false' @vb contents are not defined */ -static bool ldm_parse_dsk4 (const u8 *buffer, int buflen, struct vblk *vb) +static bool ldm_parse_dsk4(const u8 *buffer, int buflen, struct vblk *vb) { int r_objid, r_name, len; struct vblk_disk *disk; - BUG_ON (!buffer || !vb); + BUG_ON(!buffer || !vb); - r_objid = ldm_relative (buffer, buflen, 0x18, 0); - r_name = ldm_relative (buffer, buflen, 0x18, r_objid); + r_objid = ldm_relative(buffer, buflen, 0x18, 0); + r_name = ldm_relative(buffer, buflen, 0x18, r_objid); len = r_name; if (len < 0) return false; @@ -981,7 +988,7 @@ static bool ldm_parse_dsk4 (const u8 *buffer, int buflen, struct vblk *vb) return false; disk = &vb->vblk.disk; - memcpy (disk->disk_id, buffer + 0x18 + r_name, GUID_SIZE); + memcpy(disk->disk_id, buffer + 0x18 + r_name, GUID_SIZE); return true; } @@ -1181,39 +1188,53 @@ static bool ldm_parse_vol5(const u8 *buffer, int buflen, struct vblk *vb) * Return: 'true' @vb contains a VBLK * 'false' @vb contents are not defined */ -static bool ldm_parse_vblk (const u8 *buf, int len, struct vblk *vb) +static bool ldm_parse_vblk(const u8 *buf, int len, struct vblk *vb) { bool result = false; int r_objid; - BUG_ON (!buf || !vb); + BUG_ON(!buf || !vb); - r_objid = ldm_relative (buf, len, 0x18, 0); + r_objid = ldm_relative(buf, len, 0x18, 0); if (r_objid < 0) { - ldm_error ("VBLK header is corrupt."); + ldm_error("VBLK header is corrupt."); return false; } vb->flags = buf[0x12]; vb->type = buf[0x13]; - vb->obj_id = ldm_get_vnum (buf + 0x18); - ldm_get_vstr (buf+0x18+r_objid, vb->name, sizeof (vb->name)); + vb->obj_id = ldm_get_vnum(buf + 0x18); + ldm_get_vstr(buf + 0x18 + r_objid, vb->name, sizeof(vb->name)); switch (vb->type) { - case VBLK_CMP3: result = ldm_parse_cmp3 (buf, len, vb); break; - case VBLK_DSK3: result = ldm_parse_dsk3 (buf, len, vb); break; - case VBLK_DSK4: result = ldm_parse_dsk4 (buf, len, vb); break; - case VBLK_DGR3: result = ldm_parse_dgr3 (buf, len, vb); break; - case VBLK_DGR4: result = ldm_parse_dgr4 (buf, len, vb); break; - case VBLK_PRT3: result = ldm_parse_prt3 (buf, len, vb); break; - case VBLK_VOL5: result = ldm_parse_vol5 (buf, len, vb); break; + case VBLK_CMP3: + result = ldm_parse_cmp3(buf, len, vb); + break; + case VBLK_DSK3: + result = ldm_parse_dsk3(buf, len, vb); + break; + case VBLK_DSK4: + result = ldm_parse_dsk4(buf, len, vb); + break; + case VBLK_DGR3: + result = ldm_parse_dgr3(buf, len, vb); + break; + case VBLK_DGR4: + result = ldm_parse_dgr4(buf, len, vb); + break; + case VBLK_PRT3: + result = ldm_parse_prt3(buf, len, vb); + break; + case VBLK_VOL5: + result = ldm_parse_vol5(buf, len, vb); + break; } if (result) - ldm_debug ("Parsed VBLK 0x%llx (type: 0x%02x) ok.", + ldm_debug("Parsed VBLK 0x%llx (type: 0x%02x) ok.", (unsigned long long) vb->obj_id, vb->type); else - ldm_error ("Failed to parse VBLK 0x%llx (type: 0x%02x).", + ldm_error("Failed to parse VBLK 0x%llx (type: 0x%02x).", (unsigned long long) vb->obj_id, vb->type); return result; @@ -1238,13 +1259,13 @@ static bool ldm_ldmdb_add (u8 *data, int len, struct ldmdb *ldb) struct vblk *vb; struct list_head *item; - BUG_ON (!data || !ldb); + BUG_ON(!data || !ldb); - vb = kmalloc (sizeof (*vb), GFP_KERNEL); + vb = kmalloc(sizeof(*vb), GFP_KERNEL); if (!vb) return false; - if (!ldm_parse_vblk (data, len, vb)) { + if (!ldm_parse_vblk(data, len, vb)) { kfree(vb); return false; /* Already logged */ } @@ -1253,29 +1274,29 @@ static bool ldm_ldmdb_add (u8 *data, int len, struct ldmdb *ldb) switch (vb->type) { case VBLK_DGR3: case VBLK_DGR4: - list_add (&vb->list, &ldb->v_dgrp); + list_add(&vb->list, &ldb->v_dgrp); break; case VBLK_DSK3: case VBLK_DSK4: - list_add (&vb->list, &ldb->v_disk); + list_add(&vb->list, &ldb->v_disk); break; case VBLK_VOL5: - list_add (&vb->list, &ldb->v_volu); + list_add(&vb->list, &ldb->v_volu); break; case VBLK_CMP3: - list_add (&vb->list, &ldb->v_comp); + list_add(&vb->list, &ldb->v_comp); break; case VBLK_PRT3: /* Sort by the partition's start sector. */ - list_for_each (item, &ldb->v_part) { - struct vblk *v = list_entry (item, struct vblk, list); + list_for_each(item, &ldb->v_part) { + struct vblk *v = list_entry(item, struct vblk, list); if ((v->vblk.part.disk_id = vb->vblk.part.disk_id) && (v->vblk.part.start > vb->vblk.part.start)) { - list_add_tail (&vb->list, &v->list); + list_add_tail(&vb->list, &v->list); return true; } } - list_add_tail (&vb->list, &ldb->v_part); + list_add_tail(&vb->list, &ldb->v_part); break; } return true; @@ -1293,13 +1314,13 @@ static bool ldm_ldmdb_add (u8 *data, int len, struct ldmdb *ldb) * Return: 'true' Success, the VBLK was added to the list * 'false' Error, a problem occurred */ -static bool ldm_frag_add (const u8 *data, int size, struct list_head *frags) +static bool ldm_frag_add(const u8 *data, int size, struct list_head *frags) { struct frag *f; struct list_head *item; int rec, num, group; - BUG_ON (!data || !frags); + BUG_ON(!data || !frags); if (size < 2 * VBLK_SIZE_HEAD) { ldm_error("Value of size is to small."); @@ -1310,7 +1331,7 @@ static bool ldm_frag_add (const u8 *data, int size, struct list_head *frags) rec = get_unaligned_be16(data + 0x0C); num = get_unaligned_be16(data + 0x0E); if ((num < 1) || (num > 4)) { - ldm_error ("A VBLK claims to have %d parts.", num); + ldm_error("A VBLK claims to have %d parts.", num); return false; } if (rec >= num) { @@ -1318,13 +1339,13 @@ static bool ldm_frag_add (const u8 *data, int size, struct list_head *frags) return false; } - list_for_each (item, frags) { - f = list_entry (item, struct frag, list); + list_for_each(item, frags) { + f = list_entry(item, struct frag, list); if (f->group = group) goto found; } - f = kmalloc (sizeof (*f) + size*num, GFP_KERNEL); + f = kmalloc(sizeof(*f) + size*num, GFP_KERNEL); if (!f) return false; @@ -1340,7 +1361,7 @@ found: return false; } if (f->map & (1 << rec)) { - ldm_error ("Duplicate VBLK, part %d.", rec); + ldm_error("Duplicate VBLK, part %d.", rec); f->map &= 0x7F; /* Mark the group as broken */ return false; } @@ -1361,14 +1382,14 @@ found: * * Return: none */ -static void ldm_frag_free (struct list_head *list) +static void ldm_frag_free(struct list_head *list) { struct list_head *item, *tmp; - BUG_ON (!list); + BUG_ON(!list); - list_for_each_safe (item, tmp, list) - kfree (list_entry (item, struct frag, list)); + list_for_each_safe(item, tmp, list) + kfree(list_entry(item, struct frag, list)); } /** @@ -1382,23 +1403,23 @@ static void ldm_frag_free (struct list_head *list) * Return: 'true' All the fragments we added successfully * 'false' One or more of the fragments we invalid */ -static bool ldm_frag_commit (struct list_head *frags, struct ldmdb *ldb) +static bool ldm_frag_commit(struct list_head *frags, struct ldmdb *ldb) { struct frag *f; struct list_head *item; - BUG_ON (!frags || !ldb); + BUG_ON(!frags || !ldb); - list_for_each (item, frags) { - f = list_entry (item, struct frag, list); + list_for_each(item, frags) { + f = list_entry(item, struct frag, list); if (f->map != 0xFF) { - ldm_error ("VBLK group %d is incomplete (0x%02x).", + ldm_error("VBLK group %d is incomplete (0x%02x).", f->group, f->map); return false; } - if (!ldm_ldmdb_add (f->data, f->num*ldb->vm.vblk_size, ldb)) + if (!ldm_ldmdb_add(f->data, f->num*ldb->vm.vblk_size, ldb)) return false; /* Already logged */ } return true; @@ -1435,35 +1456,35 @@ static bool ldm_get_vblks(struct parsed_partitions *state, unsigned long base, for (s = skip; s < finish; s++) { /* For each sector */ data = read_part_sector(state, base + OFF_VMDB + s, §); if (!data) { - ldm_crit ("Disk read failed."); + ldm_crit("Disk read failed."); goto out; } for (v = 0; v < perbuf; v++, data+=size) { /* For each vblk */ if (MAGIC_VBLK != get_unaligned_be32(data)) { - ldm_error ("Expected to find a VBLK."); + ldm_error("Expected to find a VBLK."); goto out; } recs = get_unaligned_be16(data + 0x0E); /* Number of records */ if (recs = 1) { - if (!ldm_ldmdb_add (data, size, ldb)) + if (!ldm_ldmdb_add(data, size, ldb)) goto out; /* Already logged */ } else if (recs > 1) { - if (!ldm_frag_add (data, size, &frags)) + if (!ldm_frag_add(data, size, &frags)) goto out; /* Already logged */ } /* else Record is not in use, ignore it. */ } - put_dev_sector (sect); + put_dev_sector(sect); data = NULL; } - result = ldm_frag_commit (&frags, ldb); /* Failures, already logged */ + result = ldm_frag_commit(&frags, ldb); /* Failures, already logged */ out: if (data) - put_dev_sector (sect); - ldm_frag_free (&frags); + put_dev_sector(sect); + ldm_frag_free(&frags); return result; } @@ -1476,14 +1497,14 @@ out: * * Return: none */ -static void ldm_free_vblks (struct list_head *lh) +static void ldm_free_vblks(struct list_head *lh) { struct list_head *item, *tmp; - BUG_ON (!lh); + BUG_ON(!lh); - list_for_each_safe (item, tmp, lh) - kfree (list_entry (item, struct vblk, list)); + list_for_each_safe(item, tmp, lh) + kfree(list_entry(item, struct vblk, list)); } @@ -1516,7 +1537,7 @@ int ldm_partition(struct parsed_partitions *state) if (!ldm_validate_partition_table(state)) return 0; - ldb = kmalloc (sizeof (*ldb), GFP_KERNEL); + ldb = kmalloc(sizeof(*ldb), GFP_KERNEL); if (!ldb) return -1; @@ -1533,31 +1554,31 @@ int ldm_partition(struct parsed_partitions *state) goto out; /* Already logged */ /* Initialize vblk lists in ldmdb struct */ - INIT_LIST_HEAD (&ldb->v_dgrp); - INIT_LIST_HEAD (&ldb->v_disk); - INIT_LIST_HEAD (&ldb->v_volu); - INIT_LIST_HEAD (&ldb->v_comp); - INIT_LIST_HEAD (&ldb->v_part); + INIT_LIST_HEAD(&ldb->v_dgrp); + INIT_LIST_HEAD(&ldb->v_disk); + INIT_LIST_HEAD(&ldb->v_volu); + INIT_LIST_HEAD(&ldb->v_comp); + INIT_LIST_HEAD(&ldb->v_part); if (!ldm_get_vblks(state, base, ldb)) { - ldm_crit ("Failed to read the VBLKs from the database."); + ldm_crit("Failed to read the VBLKs from the database."); goto cleanup; } /* Finally, create the data partition devices. */ if (ldm_create_data_partitions(state, ldb)) { - ldm_debug ("Parsed LDM database successfully."); + ldm_debug("Parsed LDM database successfully."); result = 1; } /* else Already logged */ cleanup: - ldm_free_vblks (&ldb->v_dgrp); - ldm_free_vblks (&ldb->v_disk); - ldm_free_vblks (&ldb->v_volu); - ldm_free_vblks (&ldb->v_comp); - ldm_free_vblks (&ldb->v_part); + ldm_free_vblks(&ldb->v_dgrp); + ldm_free_vblks(&ldb->v_disk); + ldm_free_vblks(&ldb->v_volu); + ldm_free_vblks(&ldb->v_comp); + ldm_free_vblks(&ldb->v_part); out: - kfree (ldb); + kfree(ldb); return result; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 0/3] Documentation-getdelays: Fine-tuning for two functions 2015-12-11 12:08 ` SF Markus Elfring @ 2015-12-24 12:31 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-24 12:31 UTC (permalink / raw) To: linux-doc, Jonathan Corbet; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Thu, 24 Dec 2015 13:23:34 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (3): Fix a check for container file usage in main() Apply a recommendation from "checkpatch.pl" in main() Less function calls in usage() Documentation/accounting/getdelays.c | 36 ++++++++++++++++++++---------------- 1 file changed, 20 insertions(+), 16 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/3] Documentation-getdelays: Fine-tuning for two functions @ 2015-12-24 12:31 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-24 12:31 UTC (permalink / raw) To: linux-doc, Jonathan Corbet; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Thu, 24 Dec 2015 13:23:34 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (3): Fix a check for container file usage in main() Apply a recommendation from "checkpatch.pl" in main() Less function calls in usage() Documentation/accounting/getdelays.c | 36 ++++++++++++++++++++---------------- 1 file changed, 20 insertions(+), 16 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 1/3] Documentation-getdelays: Fix a check for container file usage in main() 2015-12-24 12:31 ` SF Markus Elfring @ 2015-12-24 12:34 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-24 12:34 UTC (permalink / raw) To: linux-doc, Jonathan Corbet; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Thu, 24 Dec 2015 11:00:54 +0100 The close() function could be called by the main() function even if the passed variable "cfd" was assigned a negative value. * Corresponding implementation details could be improved by adjustments for jump targets according to the Linux coding style convention. * Fix the affected condition check. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- Documentation/accounting/getdelays.c | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/Documentation/accounting/getdelays.c b/Documentation/accounting/getdelays.c index f405780..6656c0c 100644 --- a/Documentation/accounting/getdelays.c +++ b/Documentation/accounting/getdelays.c @@ -383,7 +383,7 @@ int main(int argc, char *argv[]) id = get_family_id(nl_sd); if (!id) { fprintf(stderr, "Error getting family id, errno %d\n", errno); - goto err; + goto close_socket; } PRINTF("family id %d\n", id); @@ -394,13 +394,13 @@ int main(int argc, char *argv[]) PRINTF("Sent register cpumask, retval %d\n", rc); if (rc < 0) { fprintf(stderr, "error sending register cpumask\n"); - goto err; + goto close_socket; } } if (tid && containerset) { fprintf(stderr, "Select either -t or -C, not both\n"); - goto err; + goto close_socket; } /* @@ -426,18 +426,18 @@ int main(int argc, char *argv[]) cfd = open(containerpath, O_RDONLY); if (cfd < 0) { perror("error opening container file"); - goto err; + goto close_socket; } rc = send_cmd(nl_sd, id, mypid, CGROUPSTATS_CMD_GET, CGROUPSTATS_CMD_ATTR_FD, &cfd, sizeof(__u32)); if (rc < 0) { perror("error sending cgroupstats command"); - goto err; + goto close_container; } } if (!maskset && !tid && !containerset) { usage(); - goto err; + goto check_container; } do { @@ -536,11 +536,14 @@ done: if (rc < 0) err(rc, "error sending deregister cpumask\n"); } -err: +check_container: + if (cfd >= 0) { +close_container: + close(cfd); + } +close_socket: close(nl_sd); if (fd) close(fd); - if (cfd) - close(cfd); return 0; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 1/3] Documentation-getdelays: Fix a check for container file usage in main() @ 2015-12-24 12:34 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-24 12:34 UTC (permalink / raw) To: linux-doc, Jonathan Corbet; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Thu, 24 Dec 2015 11:00:54 +0100 The close() function could be called by the main() function even if the passed variable "cfd" was assigned a negative value. * Corresponding implementation details could be improved by adjustments for jump targets according to the Linux coding style convention. * Fix the affected condition check. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- Documentation/accounting/getdelays.c | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/Documentation/accounting/getdelays.c b/Documentation/accounting/getdelays.c index f405780..6656c0c 100644 --- a/Documentation/accounting/getdelays.c +++ b/Documentation/accounting/getdelays.c @@ -383,7 +383,7 @@ int main(int argc, char *argv[]) id = get_family_id(nl_sd); if (!id) { fprintf(stderr, "Error getting family id, errno %d\n", errno); - goto err; + goto close_socket; } PRINTF("family id %d\n", id); @@ -394,13 +394,13 @@ int main(int argc, char *argv[]) PRINTF("Sent register cpumask, retval %d\n", rc); if (rc < 0) { fprintf(stderr, "error sending register cpumask\n"); - goto err; + goto close_socket; } } if (tid && containerset) { fprintf(stderr, "Select either -t or -C, not both\n"); - goto err; + goto close_socket; } /* @@ -426,18 +426,18 @@ int main(int argc, char *argv[]) cfd = open(containerpath, O_RDONLY); if (cfd < 0) { perror("error opening container file"); - goto err; + goto close_socket; } rc = send_cmd(nl_sd, id, mypid, CGROUPSTATS_CMD_GET, CGROUPSTATS_CMD_ATTR_FD, &cfd, sizeof(__u32)); if (rc < 0) { perror("error sending cgroupstats command"); - goto err; + goto close_container; } } if (!maskset && !tid && !containerset) { usage(); - goto err; + goto check_container; } do { @@ -536,11 +536,14 @@ done: if (rc < 0) err(rc, "error sending deregister cpumask\n"); } -err: +check_container: + if (cfd >= 0) { +close_container: + close(cfd); + } +close_socket: close(nl_sd); if (fd) close(fd); - if (cfd) - close(cfd); return 0; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/3] Documentation-getdelays: Fix a check for container file usage in main() 2015-12-24 12:34 ` SF Markus Elfring @ 2015-12-24 14:22 ` Jonathan Corbet -1 siblings, 0 replies; 3089+ messages in thread From: Jonathan Corbet @ 2015-12-24 14:22 UTC (permalink / raw) To: SF Markus Elfring; +Cc: linux-doc, LKML, kernel-janitors, Julia Lawall On Thu, 24 Dec 2015 13:34:20 +0100 SF Markus Elfring <elfring@users.sourceforge.net> wrote: > The close() function could be called by the main() function even if > the passed variable "cfd" was assigned a negative value. > > * Corresponding implementation details could be improved by adjustments > for jump targets according to the Linux coding style convention. > > * Fix the affected condition check. This seems more easily fixed by simply making the condition > 0. Meanwhile, I'd really not add labels-inside-if-statements as an example in the documentation tree. Thanks, jon ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/3] Documentation-getdelays: Fix a check for container file usage in main() @ 2015-12-24 14:22 ` Jonathan Corbet 0 siblings, 0 replies; 3089+ messages in thread From: Jonathan Corbet @ 2015-12-24 14:22 UTC (permalink / raw) To: SF Markus Elfring; +Cc: linux-doc, LKML, kernel-janitors, Julia Lawall On Thu, 24 Dec 2015 13:34:20 +0100 SF Markus Elfring <elfring@users.sourceforge.net> wrote: > The close() function could be called by the main() function even if > the passed variable "cfd" was assigned a negative value. > > * Corresponding implementation details could be improved by adjustments > for jump targets according to the Linux coding style convention. > > * Fix the affected condition check. This seems more easily fixed by simply making the condition > 0. Meanwhile, I'd really not add labels-inside-if-statements as an example in the documentation tree. Thanks, jon ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: Documentation-getdelays: Fix a check for container file usage in main() 2015-12-24 14:22 ` Jonathan Corbet @ 2015-12-24 17:54 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-24 17:54 UTC (permalink / raw) To: Jonathan Corbet; +Cc: linux-doc, LKML, kernel-janitors, Julia Lawall >> The close() function could be called by the main() function even if >> the passed variable "cfd" was assigned a negative value. … > This seems more easily fixed by simply making the condition > 0. How do you think about the reuse of the error predicate "cfd != -1" for the return value from a call of the function "open"? http://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Documentation/accounting/getdelays.c?id=80c75a0f1d81922bf322c0634d1e1a15825a89e6#n425 > Meanwhile, I'd really not add labels-inside-if-statements as an example > in the documentation tree. How are the chances to improve the affected error detection and corresponding exception handling? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: Documentation-getdelays: Fix a check for container file usage in main() @ 2015-12-24 17:54 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-24 17:54 UTC (permalink / raw) To: Jonathan Corbet; +Cc: linux-doc, LKML, kernel-janitors, Julia Lawall >> The close() function could be called by the main() function even if >> the passed variable "cfd" was assigned a negative value. … > This seems more easily fixed by simply making the condition > 0. How do you think about the reuse of the error predicate "cfd != -1" for the return value from a call of the function "open"? http://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Documentation/accounting/getdelays.c?id€c75a0f1d81922bf322c0634d1e1a15825a89e6#n425 > Meanwhile, I'd really not add labels-inside-if-statements as an example > in the documentation tree. How are the chances to improve the affected error detection and corresponding exception handling? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 2/3] Documentation-getdelays: Apply a recommendation from "checkpatch.pl" in main() 2015-12-24 12:31 ` SF Markus Elfring @ 2015-12-24 12:36 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-24 12:36 UTC (permalink / raw) To: linux-doc, Jonathan Corbet; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Thu, 24 Dec 2015 11:05:32 +0100 The script "checkpatch.pl" pointed out that assignments should usually not be performed within condition checks. Thus move the assignment for the variable "nl_sd" to a separate statement. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- Documentation/accounting/getdelays.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/accounting/getdelays.c b/Documentation/accounting/getdelays.c index 6656c0c..9ca318d 100644 --- a/Documentation/accounting/getdelays.c +++ b/Documentation/accounting/getdelays.c @@ -375,7 +375,8 @@ int main(int argc, char *argv[]) } } - if ((nl_sd = create_nl_socket(NETLINK_GENERIC)) < 0) + nl_sd = create_nl_socket(NETLINK_GENERIC); + if (nl_sd < 0) err(1, "error creating Netlink socket\n"); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 2/3] Documentation-getdelays: Apply a recommendation from "checkpatch.pl" in main() @ 2015-12-24 12:36 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-24 12:36 UTC (permalink / raw) To: linux-doc, Jonathan Corbet; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Thu, 24 Dec 2015 11:05:32 +0100 The script "checkpatch.pl" pointed out that assignments should usually not be performed within condition checks. Thus move the assignment for the variable "nl_sd" to a separate statement. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- Documentation/accounting/getdelays.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/accounting/getdelays.c b/Documentation/accounting/getdelays.c index 6656c0c..9ca318d 100644 --- a/Documentation/accounting/getdelays.c +++ b/Documentation/accounting/getdelays.c @@ -375,7 +375,8 @@ int main(int argc, char *argv[]) } } - if ((nl_sd = create_nl_socket(NETLINK_GENERIC)) < 0) + nl_sd = create_nl_socket(NETLINK_GENERIC); + if (nl_sd < 0) err(1, "error creating Netlink socket\n"); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/3] Documentation-getdelays: Apply a recommendation from "checkpatch.pl" in main() 2015-12-24 12:36 ` SF Markus Elfring @ 2015-12-24 14:22 ` Jonathan Corbet -1 siblings, 0 replies; 3089+ messages in thread From: Jonathan Corbet @ 2015-12-24 14:22 UTC (permalink / raw) To: SF Markus Elfring; +Cc: linux-doc, LKML, kernel-janitors, Julia Lawall On Thu, 24 Dec 2015 13:36:48 +0100 SF Markus Elfring <elfring@users.sourceforge.net> wrote: > The script "checkpatch.pl" pointed out that assignments should usually > not be performed within condition checks. > Thus move the assignment for the variable "nl_sd" to a separate statement. Fine, applied to the docs tree. jon ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/3] Documentation-getdelays: Apply a recommendation from "checkpatch.pl" in main() @ 2015-12-24 14:22 ` Jonathan Corbet 0 siblings, 0 replies; 3089+ messages in thread From: Jonathan Corbet @ 2015-12-24 14:22 UTC (permalink / raw) To: SF Markus Elfring; +Cc: linux-doc, LKML, kernel-janitors, Julia Lawall On Thu, 24 Dec 2015 13:36:48 +0100 SF Markus Elfring <elfring@users.sourceforge.net> wrote: > The script "checkpatch.pl" pointed out that assignments should usually > not be performed within condition checks. > Thus move the assignment for the variable "nl_sd" to a separate statement. Fine, applied to the docs tree. jon ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 3/3] Documentation-getdelays: Less function calls in usage() 2015-12-24 12:31 ` SF Markus Elfring @ 2015-12-24 12:38 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-24 12:38 UTC (permalink / raw) To: linux-doc, Jonathan Corbet; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Thu, 24 Dec 2015 13:10:19 +0100 A single call of the fprintf() function is sufficient for the desired display of the usage information. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- Documentation/accounting/getdelays.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Documentation/accounting/getdelays.c b/Documentation/accounting/getdelays.c index 9ca318d..1ad3de8 100644 --- a/Documentation/accounting/getdelays.c +++ b/Documentation/accounting/getdelays.c @@ -74,12 +74,12 @@ char cpumask[100+6*MAX_CPUS]; static void usage(void) { fprintf(stderr, "getdelays [-dilv] [-w logfile] [-r bufsize] " - "[-m cpumask] [-t tgid] [-p pid]\n"); - fprintf(stderr, " -d: print delayacct stats\n"); - fprintf(stderr, " -i: print IO accounting (works only with -p)\n"); - fprintf(stderr, " -l: listen forever\n"); - fprintf(stderr, " -v: debug on\n"); - fprintf(stderr, " -C: container path\n"); + "[-m cpumask] [-t tgid] [-p pid]\n" + " -d: print delayacct stats\n" + " -i: print IO accounting (works only with -p)\n" + " -l: listen forever\n" + " -v: debug on\n" + " -C: container path\n"); } /* -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 3/3] Documentation-getdelays: Less function calls in usage() @ 2015-12-24 12:38 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-24 12:38 UTC (permalink / raw) To: linux-doc, Jonathan Corbet; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Thu, 24 Dec 2015 13:10:19 +0100 A single call of the fprintf() function is sufficient for the desired display of the usage information. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- Documentation/accounting/getdelays.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Documentation/accounting/getdelays.c b/Documentation/accounting/getdelays.c index 9ca318d..1ad3de8 100644 --- a/Documentation/accounting/getdelays.c +++ b/Documentation/accounting/getdelays.c @@ -74,12 +74,12 @@ char cpumask[100+6*MAX_CPUS]; static void usage(void) { fprintf(stderr, "getdelays [-dilv] [-w logfile] [-r bufsize] " - "[-m cpumask] [-t tgid] [-p pid]\n"); - fprintf(stderr, " -d: print delayacct stats\n"); - fprintf(stderr, " -i: print IO accounting (works only with -p)\n"); - fprintf(stderr, " -l: listen forever\n"); - fprintf(stderr, " -v: debug on\n"); - fprintf(stderr, " -C: container path\n"); + "[-m cpumask] [-t tgid] [-p pid]\n" + " -d: print delayacct stats\n" + " -i: print IO accounting (works only with -p)\n" + " -l: listen forever\n" + " -v: debug on\n" + " -C: container path\n"); } /* -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 3/3] Documentation-getdelays: Less function calls in usage() 2015-12-24 12:38 ` SF Markus Elfring @ 2015-12-24 14:23 ` Jonathan Corbet -1 siblings, 0 replies; 3089+ messages in thread From: Jonathan Corbet @ 2015-12-24 14:23 UTC (permalink / raw) To: SF Markus Elfring; +Cc: linux-doc, LKML, kernel-janitors, Julia Lawall On Thu, 24 Dec 2015 13:38:01 +0100 SF Markus Elfring <elfring@users.sourceforge.net> wrote: > A single call of the fprintf() function is sufficient for the desired > display of the usage information. This seems like churn that doesn't actually fix anything. jon ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 3/3] Documentation-getdelays: Less function calls in usage() @ 2015-12-24 14:23 ` Jonathan Corbet 0 siblings, 0 replies; 3089+ messages in thread From: Jonathan Corbet @ 2015-12-24 14:23 UTC (permalink / raw) To: SF Markus Elfring; +Cc: linux-doc, LKML, kernel-janitors, Julia Lawall On Thu, 24 Dec 2015 13:38:01 +0100 SF Markus Elfring <elfring@users.sourceforge.net> wrote: > A single call of the fprintf() function is sufficient for the desired > display of the usage information. This seems like churn that doesn't actually fix anything. jon ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: Documentation-getdelays: Less function calls in usage() 2015-12-24 14:23 ` Jonathan Corbet @ 2015-12-24 19:40 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-24 19:40 UTC (permalink / raw) To: Jonathan Corbet; +Cc: linux-doc, LKML, kernel-janitors, Julia Lawall >> A single call of the fprintf() function is sufficient for the desired >> display of the usage information. > > This seems like churn that doesn't actually fix anything. Will it matter occasionally to reduce the number of function calls by combining several text fragments into the passing of one longer string parameter? Does a warning like "quoted string split across lines" need also any further considerations for the Linux coding style specification? https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/scripts/checkpatch.pl?id=80c75a0f1d81922bf322c0634d1e1a15825a89e6#n4837 Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: Documentation-getdelays: Less function calls in usage() @ 2015-12-24 19:40 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-24 19:40 UTC (permalink / raw) To: Jonathan Corbet; +Cc: linux-doc, LKML, kernel-janitors, Julia Lawall >> A single call of the fprintf() function is sufficient for the desired >> display of the usage information. > > This seems like churn that doesn't actually fix anything. Will it matter occasionally to reduce the number of function calls by combining several text fragments into the passing of one longer string parameter? Does a warning like "quoted string split across lines" need also any further considerations for the Linux coding style specification? https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/scripts/checkpatch.pl?id€c75a0f1d81922bf322c0634d1e1a15825a89e6#n4837 Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* ACPI-fan: Another source code review around null pointer handling? 2015-12-11 12:08 ` SF Markus Elfring @ 2015-12-25 10:35 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-25 10:35 UTC (permalink / raw) To: linux-acpi, Len Brown, Rafael J. Wysocki Cc: LKML, kernel-janitors, Julia Lawall Hello, I have looked at the source file for the ACPI fan driver once more. I would appreciate if a specific implementation detail can be clarified there. Static source code analysis can point out that functions like the following share an approach for error detection and corresponding exception handling. * acpi_fan_get_fif * acpi_fan_get_fps * fan_get_state_acpi4 https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/acpi/fan.c?id=80c75a0f1d81922bf322c0634d1e1a15825a89e6#n107 Can it matter eventually to handle a detected null pointer differently from further checks for an attribute like "obj->type" or "obj->package"? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* ACPI-fan: Another source code review around null pointer handling? @ 2015-12-25 10:35 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-25 10:35 UTC (permalink / raw) To: linux-acpi, Len Brown, Rafael J. Wysocki Cc: LKML, kernel-janitors, Julia Lawall Hello, I have looked at the source file for the ACPI fan driver once more. I would appreciate if a specific implementation detail can be clarified there. Static source code analysis can point out that functions like the following share an approach for error detection and corresponding exception handling. * acpi_fan_get_fif * acpi_fan_get_fps * fan_get_state_acpi4 https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/acpi/fan.c?id€c75a0f1d81922bf322c0634d1e1a15825a89e6#n107 Can it matter eventually to handle a detected null pointer differently from further checks for an attribute like "obj->type" or "obj->package"? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* sata_mv: Another source code review around exception handling? 2015-12-11 12:08 ` SF Markus Elfring @ 2015-12-25 16:00 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-25 16:00 UTC (permalink / raw) To: linux-ide, Tejun Heo; +Cc: LKML, kernel-janitors, Julia Lawall Hello, I have looked at the source file for the Marvell SATA support driver once more. I would appreciate if a specific implementation detail can be clarified there. Static source code analysis can point out that functions like the following are called by the mv_platform_probe() function. https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/ata/sata_mv.c?id=80c75a0f1d81922bf322c0634d1e1a15825a89e6#n4055 * ata_host_alloc_pinfo http://lxr.free-electrons.com/source/drivers/ata/libata-core.c?v=4.3#L5768 * devm_kzalloc http://lxr.free-electrons.com/source/include/linux/device.h?v=4.3#L645 The value "-ENOMEM" will be returned if one of these function calls failed. Can it be that any system resources (like memory) are not appropriately released if any calls of this sequence succeeded before the failure? Is the use of the single jump label "err" also suspicious here? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* sata_mv: Another source code review around exception handling? @ 2015-12-25 16:00 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-25 16:00 UTC (permalink / raw) To: linux-ide, Tejun Heo; +Cc: LKML, kernel-janitors, Julia Lawall Hello, I have looked at the source file for the Marvell SATA support driver once more. I would appreciate if a specific implementation detail can be clarified there. Static source code analysis can point out that functions like the following are called by the mv_platform_probe() function. https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/ata/sata_mv.c?id€c75a0f1d81922bf322c0634d1e1a15825a89e6#n4055 * ata_host_alloc_pinfo http://lxr.free-electrons.com/source/drivers/ata/libata-core.c?v=4.3#L5768 * devm_kzalloc http://lxr.free-electrons.com/source/include/linux/device.h?v=4.3#L645 The value "-ENOMEM" will be returned if one of these function calls failed. Can it be that any system resources (like memory) are not appropriately released if any calls of this sequence succeeded before the failure? Is the use of the single jump label "err" also suspicious here? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: sata_mv: Another source code review around exception handling? 2015-12-25 16:00 ` SF Markus Elfring @ 2015-12-28 16:10 ` Tejun Heo -1 siblings, 0 replies; 3089+ messages in thread From: Tejun Heo @ 2015-12-28 16:10 UTC (permalink / raw) To: SF Markus Elfring; +Cc: linux-ide, LKML, kernel-janitors, Julia Lawall Hello, On Fri, Dec 25, 2015 at 05:00:30PM +0100, SF Markus Elfring wrote: > The value "-ENOMEM" will be returned if one of these function calls failed. > Can it be that any system resources (like memory) are not appropriately > released if any calls of this sequence succeeded before the failure? Most of those are managed resources (devm_, pcim_ and so on) and are released automatically when the driver detaches from the device. > Is the use of the single jump label "err" also suspicious here? And that exit label deal with resources which aren't managed - some just haven't grown managed variant yet while others don't fit the model too well. Thanks. -- tejun ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: sata_mv: Another source code review around exception handling? @ 2015-12-28 16:10 ` Tejun Heo 0 siblings, 0 replies; 3089+ messages in thread From: Tejun Heo @ 2015-12-28 16:10 UTC (permalink / raw) To: SF Markus Elfring; +Cc: linux-ide, LKML, kernel-janitors, Julia Lawall Hello, On Fri, Dec 25, 2015 at 05:00:30PM +0100, SF Markus Elfring wrote: > The value "-ENOMEM" will be returned if one of these function calls failed. > Can it be that any system resources (like memory) are not appropriately > released if any calls of this sequence succeeded before the failure? Most of those are managed resources (devm_, pcim_ and so on) and are released automatically when the driver detaches from the device. > Is the use of the single jump label "err" also suspicious here? And that exit label deal with resources which aren't managed - some just haven't grown managed variant yet while others don't fit the model too well. Thanks. -- tejun ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH] gpio-ucb1400: Delete an unnecessary variable initialisation in ucb1400_gpio_probe() 2015-12-11 12:08 ` SF Markus Elfring @ 2015-12-25 18:49 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-25 18:49 UTC (permalink / raw) To: linux-gpio, Alexandre Courbot, Linus Walleij Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 25 Dec 2015 19:36:20 +0100 The variable "err" will eventually be set to an appropriate value from a call of the gpiochip_add() function. Thus let us omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/gpio/gpio-ucb1400.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpio/gpio-ucb1400.c b/drivers/gpio/gpio-ucb1400.c index d502825..c963517 100644 --- a/drivers/gpio/gpio-ucb1400.c +++ b/drivers/gpio/gpio-ucb1400.c @@ -46,7 +46,7 @@ static void ucb1400_gpio_set(struct gpio_chip *gc, unsigned off, int val) static int ucb1400_gpio_probe(struct platform_device *dev) { struct ucb1400_gpio *ucb = dev_get_platdata(&dev->dev); - int err = 0; + int err; if (!(ucb && ucb->gpio_offset)) { err = -EINVAL; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH] gpio-ucb1400: Delete an unnecessary variable initialisation in ucb1400_gpio_probe() @ 2015-12-25 18:49 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-25 18:49 UTC (permalink / raw) To: linux-gpio, Alexandre Courbot, Linus Walleij Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 25 Dec 2015 19:36:20 +0100 The variable "err" will eventually be set to an appropriate value from a call of the gpiochip_add() function. Thus let us omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/gpio/gpio-ucb1400.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpio/gpio-ucb1400.c b/drivers/gpio/gpio-ucb1400.c index d502825..c963517 100644 --- a/drivers/gpio/gpio-ucb1400.c +++ b/drivers/gpio/gpio-ucb1400.c @@ -46,7 +46,7 @@ static void ucb1400_gpio_set(struct gpio_chip *gc, unsigned off, int val) static int ucb1400_gpio_probe(struct platform_device *dev) { struct ucb1400_gpio *ucb = dev_get_platdata(&dev->dev); - int err = 0; + int err; if (!(ucb && ucb->gpio_offset)) { err = -EINVAL; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH] i2c-core: One function call less in acpi_i2c_space_handler() after error detection 2015-12-11 12:08 ` SF Markus Elfring @ 2015-12-26 6:34 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-26 6:34 UTC (permalink / raw) To: linux-i2c, Wolfram Sang; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 26 Dec 2015 07:30:35 +0100 The kfree() function was called in one case by the acpi_i2c_space_handler() function during error handling even if the passed variable "client" contained a null pointer. Implementation details could be improved by the adjustment of jump targets. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/i2c/i2c-core.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c index 7349b00..a24e06c 100644 --- a/drivers/i2c/i2c-core.c +++ b/drivers/i2c/i2c-core.c @@ -313,18 +313,18 @@ acpi_i2c_space_handler(u32 function, acpi_physical_address command, client = kzalloc(sizeof(*client), GFP_KERNEL); if (!client) { ret = AE_NO_MEMORY; - goto err; + goto free_ares; } if (!value64 || ares->type != ACPI_RESOURCE_TYPE_SERIAL_BUS) { ret = AE_BAD_PARAMETER; - goto err; + goto free_client; } sb = &ares->data.i2c_serial_bus; if (sb->type != ACPI_RESOURCE_SERIAL_TYPE_I2C) { ret = AE_BAD_PARAMETER; - goto err; + goto free_client; } client->adapter = adapter; @@ -405,9 +405,9 @@ acpi_i2c_space_handler(u32 function, acpi_physical_address command, } gsb->status = status; - - err: +free_client: kfree(client); +free_ares: ACPI_FREE(ares); return ret; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH] i2c-core: One function call less in acpi_i2c_space_handler() after error detection @ 2015-12-26 6:34 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-26 6:34 UTC (permalink / raw) To: linux-i2c, Wolfram Sang; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 26 Dec 2015 07:30:35 +0100 The kfree() function was called in one case by the acpi_i2c_space_handler() function during error handling even if the passed variable "client" contained a null pointer. Implementation details could be improved by the adjustment of jump targets. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/i2c/i2c-core.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c index 7349b00..a24e06c 100644 --- a/drivers/i2c/i2c-core.c +++ b/drivers/i2c/i2c-core.c @@ -313,18 +313,18 @@ acpi_i2c_space_handler(u32 function, acpi_physical_address command, client = kzalloc(sizeof(*client), GFP_KERNEL); if (!client) { ret = AE_NO_MEMORY; - goto err; + goto free_ares; } if (!value64 || ares->type != ACPI_RESOURCE_TYPE_SERIAL_BUS) { ret = AE_BAD_PARAMETER; - goto err; + goto free_client; } sb = &ares->data.i2c_serial_bus; if (sb->type != ACPI_RESOURCE_SERIAL_TYPE_I2C) { ret = AE_BAD_PARAMETER; - goto err; + goto free_client; } client->adapter = adapter; @@ -405,9 +405,9 @@ acpi_i2c_space_handler(u32 function, acpi_physical_address command, } gsb->status = status; - - err: +free_client: kfree(client); +free_ares: ACPI_FREE(ares); return ret; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH] i2c-core: One function call less in acpi_i2c_space_handler() after error detection 2015-12-26 6:34 ` SF Markus Elfring @ 2015-12-26 6:47 ` kbuild test robot -1 siblings, 0 replies; 3089+ messages in thread From: kbuild test robot @ 2015-12-26 6:47 UTC (permalink / raw) To: SF Markus Elfring Cc: kbuild-all, linux-i2c, Wolfram Sang, LKML, kernel-janitors, Julia Lawall [-- Attachment #1: Type: text/plain, Size: 1789 bytes --] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] Hi Markus, [auto build test ERROR on wsa/i2c/for-next] [also build test ERROR on v4.4-rc6 next-20151223] url: https://github.com/0day-ci/linux/commits/SF-Markus-Elfring/i2c-core-One-function-call-less-in-acpi_i2c_space_handler-after-error-detection/20151226-143820 base: https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux i2c/for-next config: x86_64-randconfig-x010-12251849 (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): drivers/i2c/i2c-core.c: In function 'acpi_i2c_space_handler': >> drivers/i2c/i2c-core.c:404:3: error: label 'err' used but not defined goto err; ^ vim +/err +404 drivers/i2c/i2c-core.c 17f4a5c4 Wolfram Sang 2014-09-22 398 } 17f4a5c4 Wolfram Sang 2014-09-22 399 break; 17f4a5c4 Wolfram Sang 2014-09-22 400 17f4a5c4 Wolfram Sang 2014-09-22 401 default: 17f4a5c4 Wolfram Sang 2014-09-22 402 pr_info("protocol(0x%02x) is not supported.\n", accessor_type); 17f4a5c4 Wolfram Sang 2014-09-22 403 ret = AE_BAD_PARAMETER; 17f4a5c4 Wolfram Sang 2014-09-22 @404 goto err; 17f4a5c4 Wolfram Sang 2014-09-22 405 } 17f4a5c4 Wolfram Sang 2014-09-22 406 17f4a5c4 Wolfram Sang 2014-09-22 407 gsb->status = status; :::::: The code at line 404 was first introduced by commit :::::: 17f4a5c47f28de9ea59182f48d07f8c44ee5dcc9 i2c: move acpi code back into the core :::::: TO: Wolfram Sang <wsa@the-dreams.de> :::::: CC: Wolfram Sang <wsa@the-dreams.de> --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation [-- Attachment #2: .config.gz --] [-- Type: application/octet-stream, Size: 25102 bytes --] ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] i2c-core: One function call less in acpi_i2c_space_handler() after error detection @ 2015-12-26 6:47 ` kbuild test robot 0 siblings, 0 replies; 3089+ messages in thread From: kbuild test robot @ 2015-12-26 6:47 UTC (permalink / raw) To: kernel-janitors [-- Attachment #1: Type: text/plain, Size: 1789 bytes --] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] Hi Markus, [auto build test ERROR on wsa/i2c/for-next] [also build test ERROR on v4.4-rc6 next-20151223] url: https://github.com/0day-ci/linux/commits/SF-Markus-Elfring/i2c-core-One-function-call-less-in-acpi_i2c_space_handler-after-error-detection/20151226-143820 base: https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux i2c/for-next config: x86_64-randconfig-x010-12251849 (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): drivers/i2c/i2c-core.c: In function 'acpi_i2c_space_handler': >> drivers/i2c/i2c-core.c:404:3: error: label 'err' used but not defined goto err; ^ vim +/err +404 drivers/i2c/i2c-core.c 17f4a5c4 Wolfram Sang 2014-09-22 398 } 17f4a5c4 Wolfram Sang 2014-09-22 399 break; 17f4a5c4 Wolfram Sang 2014-09-22 400 17f4a5c4 Wolfram Sang 2014-09-22 401 default: 17f4a5c4 Wolfram Sang 2014-09-22 402 pr_info("protocol(0x%02x) is not supported.\n", accessor_type); 17f4a5c4 Wolfram Sang 2014-09-22 403 ret = AE_BAD_PARAMETER; 17f4a5c4 Wolfram Sang 2014-09-22 @404 goto err; 17f4a5c4 Wolfram Sang 2014-09-22 405 } 17f4a5c4 Wolfram Sang 2014-09-22 406 17f4a5c4 Wolfram Sang 2014-09-22 407 gsb->status = status; :::::: The code at line 404 was first introduced by commit :::::: 17f4a5c47f28de9ea59182f48d07f8c44ee5dcc9 i2c: move acpi code back into the core :::::: TO: Wolfram Sang <wsa@the-dreams.de> :::::: CC: Wolfram Sang <wsa@the-dreams.de> --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation [-- Attachment #2: .config.gz --] [-- Type: application/octet-stream, Size: 25102 bytes --] ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH v2] i2c-core: One function call less in acpi_i2c_space_handler() after error detection 2015-12-26 6:47 ` kbuild test robot @ 2015-12-26 7:08 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-26 7:08 UTC (permalink / raw) To: linux-i2c, Wolfram Sang; +Cc: kbuild-all, LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 26 Dec 2015 08:00:52 +0100 The kfree() function was called in one case by the acpi_i2c_space_handler() function during error handling even if the passed variable "client" contained a null pointer. Implementation details could be improved by the adjustment of jump targets according to the Linux coding style convention. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/i2c/i2c-core.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c index 7349b00..9996531 100644 --- a/drivers/i2c/i2c-core.c +++ b/drivers/i2c/i2c-core.c @@ -313,18 +313,18 @@ acpi_i2c_space_handler(u32 function, acpi_physical_address command, client = kzalloc(sizeof(*client), GFP_KERNEL); if (!client) { ret = AE_NO_MEMORY; - goto err; + goto free_ares; } if (!value64 || ares->type != ACPI_RESOURCE_TYPE_SERIAL_BUS) { ret = AE_BAD_PARAMETER; - goto err; + goto free_client; } sb = &ares->data.i2c_serial_bus; if (sb->type != ACPI_RESOURCE_SERIAL_TYPE_I2C) { ret = AE_BAD_PARAMETER; - goto err; + goto free_client; } client->adapter = adapter; @@ -401,13 +401,13 @@ acpi_i2c_space_handler(u32 function, acpi_physical_address command, default: pr_info("protocol(0x%02x) is not supported.\n", accessor_type); ret = AE_BAD_PARAMETER; - goto err; + goto free_client; } gsb->status = status; - - err: +free_client: kfree(client); +free_ares: ACPI_FREE(ares); return ret; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH v2] i2c-core: One function call less in acpi_i2c_space_handler() after error detection @ 2015-12-26 7:08 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-26 7:08 UTC (permalink / raw) To: linux-i2c, Wolfram Sang; +Cc: kbuild-all, LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 26 Dec 2015 08:00:52 +0100 The kfree() function was called in one case by the acpi_i2c_space_handler() function during error handling even if the passed variable "client" contained a null pointer. Implementation details could be improved by the adjustment of jump targets according to the Linux coding style convention. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/i2c/i2c-core.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c index 7349b00..9996531 100644 --- a/drivers/i2c/i2c-core.c +++ b/drivers/i2c/i2c-core.c @@ -313,18 +313,18 @@ acpi_i2c_space_handler(u32 function, acpi_physical_address command, client = kzalloc(sizeof(*client), GFP_KERNEL); if (!client) { ret = AE_NO_MEMORY; - goto err; + goto free_ares; } if (!value64 || ares->type != ACPI_RESOURCE_TYPE_SERIAL_BUS) { ret = AE_BAD_PARAMETER; - goto err; + goto free_client; } sb = &ares->data.i2c_serial_bus; if (sb->type != ACPI_RESOURCE_SERIAL_TYPE_I2C) { ret = AE_BAD_PARAMETER; - goto err; + goto free_client; } client->adapter = adapter; @@ -401,13 +401,13 @@ acpi_i2c_space_handler(u32 function, acpi_physical_address command, default: pr_info("protocol(0x%02x) is not supported.\n", accessor_type); ret = AE_BAD_PARAMETER; - goto err; + goto free_client; } gsb->status = status; - - err: +free_client: kfree(client); +free_ares: ACPI_FREE(ares); return ret; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH v2] i2c-core: One function call less in acpi_i2c_space_handler() after error detection 2015-12-26 7:08 ` SF Markus Elfring @ 2015-12-26 7:48 ` Wolfram Sang -1 siblings, 0 replies; 3089+ messages in thread From: Wolfram Sang @ 2015-12-26 7:48 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-i2c, kbuild-all, LKML, kernel-janitors, Julia Lawall [-- Attachment #1: Type: text/plain, Size: 289 bytes --] > The kfree() function was called in one case by the > acpi_i2c_space_handler() function during error handling > even if the passed variable "client" contained a null pointer. This is OK. kfree() is known to be NULL-tolerant and we rely on it in various places to keep the code simpler. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH v2] i2c-core: One function call less in acpi_i2c_space_handler() after error detection @ 2015-12-26 7:48 ` Wolfram Sang 0 siblings, 0 replies; 3089+ messages in thread From: Wolfram Sang @ 2015-12-26 7:48 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-i2c, kbuild-all, LKML, kernel-janitors, Julia Lawall [-- Attachment #1: Type: text/plain, Size: 289 bytes --] > The kfree() function was called in one case by the > acpi_i2c_space_handler() function during error handling > even if the passed variable "client" contained a null pointer. This is OK. kfree() is known to be NULL-tolerant and we rely on it in various places to keep the code simpler. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: i2c-core: One function call less in acpi_i2c_space_handler() after error detection 2015-12-26 7:48 ` Wolfram Sang @ 2015-12-26 8:52 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-26 8:52 UTC (permalink / raw) To: Wolfram Sang; +Cc: linux-i2c, LKML, kernel-janitors, Julia Lawall >> The kfree() function was called in one case by the >> acpi_i2c_space_handler() function during error handling >> even if the passed variable "client" contained a null pointer. > > This is OK. kfree() is known to be NULL-tolerant and we rely on it in > various places to keep the code simpler. I would appreciate if an unnecessary function call can be avoided here so that the affected exception handling can become also a bit more efficient. Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: i2c-core: One function call less in acpi_i2c_space_handler() after error detection @ 2015-12-26 8:52 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-26 8:52 UTC (permalink / raw) To: Wolfram Sang; +Cc: linux-i2c, LKML, kernel-janitors, Julia Lawall >> The kfree() function was called in one case by the >> acpi_i2c_space_handler() function during error handling >> even if the passed variable "client" contained a null pointer. > > This is OK. kfree() is known to be NULL-tolerant and we rely on it in > various places to keep the code simpler. I would appreciate if an unnecessary function call can be avoided here so that the affected exception handling can become also a bit more efficient. Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: i2c-core: One function call less in acpi_i2c_space_handler() after error detection 2015-12-26 8:52 ` SF Markus Elfring @ 2015-12-26 18:41 ` Wolfram Sang -1 siblings, 0 replies; 3089+ messages in thread From: Wolfram Sang @ 2015-12-26 18:41 UTC (permalink / raw) To: SF Markus Elfring; +Cc: linux-i2c, LKML, kernel-janitors, Julia Lawall [-- Attachment #1: Type: text/plain, Size: 758 bytes --] On Sat, Dec 26, 2015 at 09:52:11AM +0100, SF Markus Elfring wrote: > >> The kfree() function was called in one case by the > >> acpi_i2c_space_handler() function during error handling > >> even if the passed variable "client" contained a null pointer. > > > > This is OK. kfree() is known to be NULL-tolerant and we rely on it in > > various places to keep the code simpler. > > I would appreciate if an unnecessary function call can be avoided here > so that the affected exception handling can become also a bit more efficient. Simpler code is easier to maintain. See your patch, you didn't get it correctly at your first try. Also, this is not a hot path, so I see it as a micro-optimization also adding complexity. I don't favor that. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: i2c-core: One function call less in acpi_i2c_space_handler() after error detection @ 2015-12-26 18:41 ` Wolfram Sang 0 siblings, 0 replies; 3089+ messages in thread From: Wolfram Sang @ 2015-12-26 18:41 UTC (permalink / raw) To: SF Markus Elfring; +Cc: linux-i2c, LKML, kernel-janitors, Julia Lawall [-- Attachment #1: Type: text/plain, Size: 758 bytes --] On Sat, Dec 26, 2015 at 09:52:11AM +0100, SF Markus Elfring wrote: > >> The kfree() function was called in one case by the > >> acpi_i2c_space_handler() function during error handling > >> even if the passed variable "client" contained a null pointer. > > > > This is OK. kfree() is known to be NULL-tolerant and we rely on it in > > various places to keep the code simpler. > > I would appreciate if an unnecessary function call can be avoided here > so that the affected exception handling can become also a bit more efficient. Simpler code is easier to maintain. See your patch, you didn't get it correctly at your first try. Also, this is not a hot path, so I see it as a micro-optimization also adding complexity. I don't favor that. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: i2c-core: One function call less in acpi_i2c_space_handler() after error detection 2015-12-26 18:41 ` Wolfram Sang @ 2015-12-26 19:30 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-26 19:30 UTC (permalink / raw) To: Wolfram Sang; +Cc: linux-i2c, LKML, kernel-janitors, Julia Lawall >> I would appreciate if an unnecessary function call can be avoided here >> so that the affected exception handling can become also a bit more efficient. > > Simpler code is easier to maintain. There are different opinions available around the desired simplicity. > See your patch, you didn't get it correctly at your first try. I wonder myself about the circumstances on how my incomplete update suggestion did happen. > Also, this is not a hot path, I'm curious if approaches around better exception handling can eventually become a "hot topic". > so I see it as a micro-optimization I can agree to this view for this function implementation. > also adding complexity. There are the usual software development trade-offs. > I don't favor that. Thanks for your constructive feedback. Is an identifier like "free_client" a bit nicer (according to the Linux coding style recommendations) than the short jump label "err" in the discussed use case? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: i2c-core: One function call less in acpi_i2c_space_handler() after error detection @ 2015-12-26 19:30 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-26 19:30 UTC (permalink / raw) To: Wolfram Sang; +Cc: linux-i2c, LKML, kernel-janitors, Julia Lawall >> I would appreciate if an unnecessary function call can be avoided here >> so that the affected exception handling can become also a bit more efficient. > > Simpler code is easier to maintain. There are different opinions available around the desired simplicity. > See your patch, you didn't get it correctly at your first try. I wonder myself about the circumstances on how my incomplete update suggestion did happen. > Also, this is not a hot path, I'm curious if approaches around better exception handling can eventually become a "hot topic". > so I see it as a micro-optimization I can agree to this view for this function implementation. > also adding complexity. There are the usual software development trade-offs. > I don't favor that. Thanks for your constructive feedback. Is an identifier like "free_client" a bit nicer (according to the Linux coding style recommendations) than the short jump label "err" in the discussed use case? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/3] IDE-ACPI: Fine-tuning for a function 2015-12-11 12:08 ` SF Markus Elfring @ 2015-12-26 10:10 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-26 10:10 UTC (permalink / raw) To: linux-ide, David S. Miller; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 26 Dec 2015 11:04:56 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (3): One function call less in ide_get_dev_handle() after error detection Delete unnecessary null pointer checks in ide_get_dev_handle() Move an assignment for one variable in ide_get_dev_handle() drivers/ide/ide-acpi.c | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/3] IDE-ACPI: Fine-tuning for a function @ 2015-12-26 10:10 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-26 10:10 UTC (permalink / raw) To: linux-ide, David S. Miller; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 26 Dec 2015 11:04:56 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (3): One function call less in ide_get_dev_handle() after error detection Delete unnecessary null pointer checks in ide_get_dev_handle() Move an assignment for one variable in ide_get_dev_handle() drivers/ide/ide-acpi.c | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 1/3] IDE-ACPI: One function call less in ide_get_dev_handle() after error detection 2015-12-26 10:10 ` SF Markus Elfring @ 2015-12-26 10:15 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-26 10:15 UTC (permalink / raw) To: linux-ide, David S. Miller; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 26 Dec 2015 10:01:36 +0100 The kfree() function was called in two cases by the ide_get_dev_handle() function during error handling even if the passed variable "dinfo" contained a null pointer. * Let us return directly if a call of the function "ACPI_HANDLE" or "acpi_get_object_info" failed. * Delete the explicit initialisation for the variables "dinfo" and "ret" at the beginning then. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/ide/ide-acpi.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/ide/ide-acpi.c b/drivers/ide/ide-acpi.c index b694099..319b754 100644 --- a/drivers/ide/ide-acpi.c +++ b/drivers/ide/ide-acpi.c @@ -126,8 +126,8 @@ static int ide_get_dev_handle(struct device *dev, acpi_handle *handle, u64 addr; acpi_handle dev_handle; acpi_status status; - struct acpi_device_info *dinfo = NULL; - int ret = -ENODEV; + struct acpi_device_info *dinfo; + int ret; bus = pdev->bus->number; devnum = PCI_SLOT(pdev->devfn); @@ -140,13 +140,13 @@ static int ide_get_dev_handle(struct device *dev, acpi_handle *handle, dev_handle = ACPI_HANDLE(dev); if (!dev_handle) { DEBPRINT("no acpi handle for device\n"); - goto err; + return -ENODEV; } status = acpi_get_object_info(dev_handle, &dinfo); if (ACPI_FAILURE(status)) { DEBPRINT("get_object_info for device failed\n"); - goto err; + return -ENODEV; } if (dinfo && (dinfo->valid & ACPI_VALID_ADR) && dinfo->address == addr) { @@ -157,13 +157,14 @@ static int ide_get_dev_handle(struct device *dev, acpi_handle *handle, " address: %llu, should be %u\n", dinfo ? (unsigned long long)dinfo->address : -1ULL, (unsigned int)addr); - goto err; + ret = -ENODEV; + goto free_info; } DEBPRINT("for dev=0x%x.%x, addr=0x%llx, *handle=0x%p\n", devnum, func, (unsigned long long)addr, *handle); ret = 0; -err: +free_info: kfree(dinfo); return ret; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 1/3] IDE-ACPI: One function call less in ide_get_dev_handle() after error detection @ 2015-12-26 10:15 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-26 10:15 UTC (permalink / raw) To: linux-ide, David S. Miller; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 26 Dec 2015 10:01:36 +0100 The kfree() function was called in two cases by the ide_get_dev_handle() function during error handling even if the passed variable "dinfo" contained a null pointer. * Let us return directly if a call of the function "ACPI_HANDLE" or "acpi_get_object_info" failed. * Delete the explicit initialisation for the variables "dinfo" and "ret" at the beginning then. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/ide/ide-acpi.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/ide/ide-acpi.c b/drivers/ide/ide-acpi.c index b694099..319b754 100644 --- a/drivers/ide/ide-acpi.c +++ b/drivers/ide/ide-acpi.c @@ -126,8 +126,8 @@ static int ide_get_dev_handle(struct device *dev, acpi_handle *handle, u64 addr; acpi_handle dev_handle; acpi_status status; - struct acpi_device_info *dinfo = NULL; - int ret = -ENODEV; + struct acpi_device_info *dinfo; + int ret; bus = pdev->bus->number; devnum = PCI_SLOT(pdev->devfn); @@ -140,13 +140,13 @@ static int ide_get_dev_handle(struct device *dev, acpi_handle *handle, dev_handle = ACPI_HANDLE(dev); if (!dev_handle) { DEBPRINT("no acpi handle for device\n"); - goto err; + return -ENODEV; } status = acpi_get_object_info(dev_handle, &dinfo); if (ACPI_FAILURE(status)) { DEBPRINT("get_object_info for device failed\n"); - goto err; + return -ENODEV; } if (dinfo && (dinfo->valid & ACPI_VALID_ADR) && dinfo->address = addr) { @@ -157,13 +157,14 @@ static int ide_get_dev_handle(struct device *dev, acpi_handle *handle, " address: %llu, should be %u\n", dinfo ? (unsigned long long)dinfo->address : -1ULL, (unsigned int)addr); - goto err; + ret = -ENODEV; + goto free_info; } DEBPRINT("for dev=0x%x.%x, addr=0x%llx, *handle=0x%p\n", devnum, func, (unsigned long long)addr, *handle); ret = 0; -err: +free_info: kfree(dinfo); return ret; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 2/3] IDE-ACPI: Delete unnecessary null pointer checks in ide_get_dev_handle() 2015-12-26 10:10 ` SF Markus Elfring @ 2015-12-26 10:17 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-26 10:17 UTC (permalink / raw) To: linux-ide, David S. Miller; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 26 Dec 2015 10:33:48 +0100 The variable "dinfo" will contain an appropropriate pointer after a call of the acpi_get_object_info() function succeeded. Thus remove two safety checks. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/ide/ide-acpi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/ide/ide-acpi.c b/drivers/ide/ide-acpi.c index 319b754..b6b2111 100644 --- a/drivers/ide/ide-acpi.c +++ b/drivers/ide/ide-acpi.c @@ -148,14 +148,14 @@ static int ide_get_dev_handle(struct device *dev, acpi_handle *handle, DEBPRINT("get_object_info for device failed\n"); return -ENODEV; } - if (dinfo && (dinfo->valid & ACPI_VALID_ADR) && + if ((dinfo->valid & ACPI_VALID_ADR) && dinfo->address == addr) { *pcidevfn = addr; *handle = dev_handle; } else { DEBPRINT("get_object_info for device has wrong " " address: %llu, should be %u\n", - dinfo ? (unsigned long long)dinfo->address : -1ULL, + (unsigned long long)dinfo->address, (unsigned int)addr); ret = -ENODEV; goto free_info; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 2/3] IDE-ACPI: Delete unnecessary null pointer checks in ide_get_dev_handle() @ 2015-12-26 10:17 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-26 10:17 UTC (permalink / raw) To: linux-ide, David S. Miller; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 26 Dec 2015 10:33:48 +0100 The variable "dinfo" will contain an appropropriate pointer after a call of the acpi_get_object_info() function succeeded. Thus remove two safety checks. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/ide/ide-acpi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/ide/ide-acpi.c b/drivers/ide/ide-acpi.c index 319b754..b6b2111 100644 --- a/drivers/ide/ide-acpi.c +++ b/drivers/ide/ide-acpi.c @@ -148,14 +148,14 @@ static int ide_get_dev_handle(struct device *dev, acpi_handle *handle, DEBPRINT("get_object_info for device failed\n"); return -ENODEV; } - if (dinfo && (dinfo->valid & ACPI_VALID_ADR) && + if ((dinfo->valid & ACPI_VALID_ADR) && dinfo->address = addr) { *pcidevfn = addr; *handle = dev_handle; } else { DEBPRINT("get_object_info for device has wrong " " address: %llu, should be %u\n", - dinfo ? (unsigned long long)dinfo->address : -1ULL, + (unsigned long long)dinfo->address, (unsigned int)addr); ret = -ENODEV; goto free_info; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 3/3] IDE-ACPI: Move an assignment for one variable in ide_get_dev_handle() 2015-12-26 10:10 ` SF Markus Elfring @ 2015-12-26 10:20 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-26 10:20 UTC (permalink / raw) To: linux-ide, David S. Miller; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 26 Dec 2015 10:50:33 +0100 Move the assignment for the variable "addr" to the statement where its value is used after previous function calls succeeded. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/ide/ide-acpi.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/ide/ide-acpi.c b/drivers/ide/ide-acpi.c index b6b2111..c2de9f9 100644 --- a/drivers/ide/ide-acpi.c +++ b/drivers/ide/ide-acpi.c @@ -132,9 +132,6 @@ static int ide_get_dev_handle(struct device *dev, acpi_handle *handle, bus = pdev->bus->number; devnum = PCI_SLOT(pdev->devfn); func = PCI_FUNC(pdev->devfn); - /* ACPI _ADR encoding for PCI bus: */ - addr = (u64)(devnum << 16 | func); - DEBPRINT("ENTER: pci %02x:%02x.%01x\n", bus, devnum, func); dev_handle = ACPI_HANDLE(dev); @@ -148,6 +145,8 @@ static int ide_get_dev_handle(struct device *dev, acpi_handle *handle, DEBPRINT("get_object_info for device failed\n"); return -ENODEV; } + /* ACPI _ADR encoding for PCI bus: */ + addr = (u64)(devnum << 16 | func); if ((dinfo->valid & ACPI_VALID_ADR) && dinfo->address == addr) { *pcidevfn = addr; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 3/3] IDE-ACPI: Move an assignment for one variable in ide_get_dev_handle() @ 2015-12-26 10:20 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-26 10:20 UTC (permalink / raw) To: linux-ide, David S. Miller; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 26 Dec 2015 10:50:33 +0100 Move the assignment for the variable "addr" to the statement where its value is used after previous function calls succeeded. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/ide/ide-acpi.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/ide/ide-acpi.c b/drivers/ide/ide-acpi.c index b6b2111..c2de9f9 100644 --- a/drivers/ide/ide-acpi.c +++ b/drivers/ide/ide-acpi.c @@ -132,9 +132,6 @@ static int ide_get_dev_handle(struct device *dev, acpi_handle *handle, bus = pdev->bus->number; devnum = PCI_SLOT(pdev->devfn); func = PCI_FUNC(pdev->devfn); - /* ACPI _ADR encoding for PCI bus: */ - addr = (u64)(devnum << 16 | func); - DEBPRINT("ENTER: pci %02x:%02x.%01x\n", bus, devnum, func); dev_handle = ACPI_HANDLE(dev); @@ -148,6 +145,8 @@ static int ide_get_dev_handle(struct device *dev, acpi_handle *handle, DEBPRINT("get_object_info for device failed\n"); return -ENODEV; } + /* ACPI _ADR encoding for PCI bus: */ + addr = (u64)(devnum << 16 | func); if ((dinfo->valid & ACPI_VALID_ADR) && dinfo->address = addr) { *pcidevfn = addr; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/3] IDE-ACPI: Fine-tuning for a function 2015-12-26 10:10 ` SF Markus Elfring @ 2015-12-26 18:12 ` David Miller -1 siblings, 0 replies; 3089+ messages in thread From: David Miller @ 2015-12-26 18:12 UTC (permalink / raw) To: elfring; +Cc: linux-ide, linux-kernel, kernel-janitors, julia.lawall IDE is in deep freeze maintainence mode. Therefore patches that perform simplications and cleanups will not be accepted. Thanks. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/3] IDE-ACPI: Fine-tuning for a function @ 2015-12-26 18:12 ` David Miller 0 siblings, 0 replies; 3089+ messages in thread From: David Miller @ 2015-12-26 18:12 UTC (permalink / raw) To: elfring; +Cc: linux-ide, linux-kernel, kernel-janitors, julia.lawall IDE is in deep freeze maintainence mode. Therefore patches that perform simplications and cleanups will not be accepted. Thanks. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/3] IDE-ACPI: Fine-tuning for a function 2015-12-26 18:12 ` David Miller @ 2015-12-26 23:43 ` Joe Perches -1 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2015-12-26 23:43 UTC (permalink / raw) To: David Miller, elfring Cc: linux-ide, linux-kernel, kernel-janitors, julia.lawall On Sat, 2015-12-26 at 13:12 -0500, David Miller wrote: > IDE is in deep freeze maintainence mode. > > Therefore patches that perform simplications and cleanups will > not be accepted. Maybe there should be something like a README in drivers/ide that says that. Maybe the MAINTAINERS entry for "IDE SUBSYSTEM" should be something like: S: Frozen - critical fixes only ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/3] IDE-ACPI: Fine-tuning for a function @ 2015-12-26 23:43 ` Joe Perches 0 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2015-12-26 23:43 UTC (permalink / raw) To: David Miller, elfring Cc: linux-ide, linux-kernel, kernel-janitors, julia.lawall On Sat, 2015-12-26 at 13:12 -0500, David Miller wrote: > IDE is in deep freeze maintainence mode. > > Therefore patches that perform simplications and cleanups will > not be accepted. Maybe there should be something like a README in drivers/ide that says that. Maybe the MAINTAINERS entry for "IDE SUBSYSTEM" should be something like: S: Frozen - critical fixes only ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/3] IDE-ACPI: Fine-tuning for a function 2015-12-26 23:43 ` Joe Perches @ 2015-12-27 6:08 ` Julia Lawall -1 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2015-12-27 6:08 UTC (permalink / raw) To: Joe Perches Cc: David Miller, elfring, linux-ide, linux-kernel, kernel-janitors On Sat, 26 Dec 2015, Joe Perches wrote: > On Sat, 2015-12-26 at 13:12 -0500, David Miller wrote: > > IDE is in deep freeze maintainence mode. > > > > Therefore patches that perform simplications and cleanups will > > not be accepted. > > Maybe there should be something like a README > in drivers/ide that says that. > > Maybe the MAINTAINERS entry for "IDE SUBSYSTEM" > should be something like: > > S: Frozen - critical fixes only This could be a good idea. Sometimes I hold off on sending patches for things becuse I have the impression that the subsystem doesn't want minor fixes, but I could be wrong, and if one could have a deterministic way to know, it could be better for everyone. julia ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/3] IDE-ACPI: Fine-tuning for a function @ 2015-12-27 6:08 ` Julia Lawall 0 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2015-12-27 6:08 UTC (permalink / raw) To: Joe Perches Cc: David Miller, elfring, linux-ide, linux-kernel, kernel-janitors On Sat, 26 Dec 2015, Joe Perches wrote: > On Sat, 2015-12-26 at 13:12 -0500, David Miller wrote: > > IDE is in deep freeze maintainence mode. > > > > Therefore patches that perform simplications and cleanups will > > not be accepted. > > Maybe there should be something like a README > in drivers/ide that says that. > > Maybe the MAINTAINERS entry for "IDE SUBSYSTEM" > should be something like: > > S: Frozen - critical fixes only This could be a good idea. Sometimes I hold off on sending patches for things becuse I have the impression that the subsystem doesn't want minor fixes, but I could be wrong, and if one could have a deterministic way to know, it could be better for everyone. julia ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH] iio: qcom-spmi-vadc: One check less in vadc_measure_ref_points() after error detection 2015-12-11 12:08 ` SF Markus Elfring @ 2015-12-26 13:04 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-26 13:04 UTC (permalink / raw) To: linux-iio, Hartmut Knaack, Jonathan Cameron, Lars-Peter Clausen, Peter Meerwald Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 26 Dec 2015 13:53:15 +0100 This issue was detected by using the Coccinelle software. Move the jump label directly before the desired log statement so that the variable "ret" does not need to be checked once more after it was determined that a function call failed. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/iio/adc/qcom-spmi-vadc.c | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/drivers/iio/adc/qcom-spmi-vadc.c b/drivers/iio/adc/qcom-spmi-vadc.c index c2babe5..391eefa 100644 --- a/drivers/iio/adc/qcom-spmi-vadc.c +++ b/drivers/iio/adc/qcom-spmi-vadc.c @@ -424,7 +424,7 @@ static int vadc_measure_ref_points(struct vadc_priv *vadc) prop = vadc_get_channel(vadc, VADC_REF_1250MV); ret = vadc_do_conversion(vadc, prop, &read_1); if (ret) - goto err; + goto report_failure; /* Try with buffered 625mV channel first */ prop = vadc_get_channel(vadc, VADC_SPARE1); @@ -433,11 +433,11 @@ static int vadc_measure_ref_points(struct vadc_priv *vadc) ret = vadc_do_conversion(vadc, prop, &read_2); if (ret) - goto err; + goto report_failure; if (read_1 == read_2) { ret = -EINVAL; - goto err; + goto report_failure; } vadc->graph[VADC_CALIB_ABSOLUTE].dy = read_1 - read_2; @@ -447,23 +447,24 @@ static int vadc_measure_ref_points(struct vadc_priv *vadc) prop = vadc_get_channel(vadc, VADC_VDD_VADC); ret = vadc_do_conversion(vadc, prop, &read_1); if (ret) - goto err; + goto report_failure; prop = vadc_get_channel(vadc, VADC_GND_REF); ret = vadc_do_conversion(vadc, prop, &read_2); if (ret) - goto err; + goto report_failure; if (read_1 == read_2) { ret = -EINVAL; - goto err; + goto report_failure; } vadc->graph[VADC_CALIB_RATIOMETRIC].dy = read_1 - read_2; vadc->graph[VADC_CALIB_RATIOMETRIC].gnd = read_2; -err: - if (ret) + if (ret) { +report_failure: dev_err(vadc->dev, "measure reference points failed\n"); + } return ret; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH] iio: qcom-spmi-vadc: One check less in vadc_measure_ref_points() after error detection @ 2015-12-26 13:04 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-26 13:04 UTC (permalink / raw) To: linux-iio, Hartmut Knaack, Jonathan Cameron, Lars-Peter Clausen, Peter Meerwald Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 26 Dec 2015 13:53:15 +0100 This issue was detected by using the Coccinelle software. Move the jump label directly before the desired log statement so that the variable "ret" does not need to be checked once more after it was determined that a function call failed. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/iio/adc/qcom-spmi-vadc.c | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/drivers/iio/adc/qcom-spmi-vadc.c b/drivers/iio/adc/qcom-spmi-vadc.c index c2babe5..391eefa 100644 --- a/drivers/iio/adc/qcom-spmi-vadc.c +++ b/drivers/iio/adc/qcom-spmi-vadc.c @@ -424,7 +424,7 @@ static int vadc_measure_ref_points(struct vadc_priv *vadc) prop = vadc_get_channel(vadc, VADC_REF_1250MV); ret = vadc_do_conversion(vadc, prop, &read_1); if (ret) - goto err; + goto report_failure; /* Try with buffered 625mV channel first */ prop = vadc_get_channel(vadc, VADC_SPARE1); @@ -433,11 +433,11 @@ static int vadc_measure_ref_points(struct vadc_priv *vadc) ret = vadc_do_conversion(vadc, prop, &read_2); if (ret) - goto err; + goto report_failure; if (read_1 = read_2) { ret = -EINVAL; - goto err; + goto report_failure; } vadc->graph[VADC_CALIB_ABSOLUTE].dy = read_1 - read_2; @@ -447,23 +447,24 @@ static int vadc_measure_ref_points(struct vadc_priv *vadc) prop = vadc_get_channel(vadc, VADC_VDD_VADC); ret = vadc_do_conversion(vadc, prop, &read_1); if (ret) - goto err; + goto report_failure; prop = vadc_get_channel(vadc, VADC_GND_REF); ret = vadc_do_conversion(vadc, prop, &read_2); if (ret) - goto err; + goto report_failure; if (read_1 = read_2) { ret = -EINVAL; - goto err; + goto report_failure; } vadc->graph[VADC_CALIB_RATIOMETRIC].dy = read_1 - read_2; vadc->graph[VADC_CALIB_RATIOMETRIC].gnd = read_2; -err: - if (ret) + if (ret) { +report_failure: dev_err(vadc->dev, "measure reference points failed\n"); + } return ret; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH] iio: qcom-spmi-vadc: One check less in vadc_measure_ref_points() after error detection 2015-12-26 13:04 ` SF Markus Elfring @ 2016-01-02 18:28 ` Jonathan Cameron -1 siblings, 0 replies; 3089+ messages in thread From: Jonathan Cameron @ 2016-01-02 18:28 UTC (permalink / raw) To: SF Markus Elfring, linux-iio, Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald Cc: LKML, kernel-janitors, Julia Lawall On 26/12/15 13:04, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sat, 26 Dec 2015 13:53:15 +0100 > > This issue was detected by using the Coccinelle software. > > Move the jump label directly before the desired log statement > so that the variable "ret" does not need to be checked once more > after it was determined that a function call failed. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> If we are going to change this, I would prefer to see more useful local error messages and direct returns rather than jumping to a very generic message at the end. I'm also less than keen on jumping into conditionals as I find it slightly less readable. We might technically be 'simplifying' the code, but in this case the gain is very minor for a fair bit of code churn... Thanks, Jonathan > --- > drivers/iio/adc/qcom-spmi-vadc.c | 17 +++++++++-------- > 1 file changed, 9 insertions(+), 8 deletions(-) > > diff --git a/drivers/iio/adc/qcom-spmi-vadc.c b/drivers/iio/adc/qcom-spmi-vadc.c > index c2babe5..391eefa 100644 > --- a/drivers/iio/adc/qcom-spmi-vadc.c > +++ b/drivers/iio/adc/qcom-spmi-vadc.c > @@ -424,7 +424,7 @@ static int vadc_measure_ref_points(struct vadc_priv *vadc) > prop = vadc_get_channel(vadc, VADC_REF_1250MV); > ret = vadc_do_conversion(vadc, prop, &read_1); > if (ret) > - goto err; > + goto report_failure; In this first case we have already had a report that a conversion failed. I suppose adding that it was during reference point measurement 'might' be useful additional information. I'm not really convinced of it does however... Hence I'd drop reporting it entirely in this function. > > /* Try with buffered 625mV channel first */ > prop = vadc_get_channel(vadc, VADC_SPARE1); > @@ -433,11 +433,11 @@ static int vadc_measure_ref_points(struct vadc_priv *vadc) > > ret = vadc_do_conversion(vadc, prop, &read_2); > if (ret) > - goto err; > + goto report_failure; > > if (read_1 == read_2) { > ret = -EINVAL; I think this one indicates we can't actually read anything at all for some reason... It's the only form of error we won't have effectively already reported so is worthy of some sort of debug message... > - goto err; > + goto report_failure; > } > > vadc->graph[VADC_CALIB_ABSOLUTE].dy = read_1 - read_2; > @@ -447,23 +447,24 @@ static int vadc_measure_ref_points(struct vadc_priv *vadc) > prop = vadc_get_channel(vadc, VADC_VDD_VADC); > ret = vadc_do_conversion(vadc, prop, &read_1); > if (ret) > - goto err; > + goto report_failure; > > prop = vadc_get_channel(vadc, VADC_GND_REF); > ret = vadc_do_conversion(vadc, prop, &read_2); > if (ret) > - goto err; > + goto report_failure; > > if (read_1 == read_2) { > ret = -EINVAL; > - goto err; > + goto report_failure; > } > > vadc->graph[VADC_CALIB_RATIOMETRIC].dy = read_1 - read_2; > vadc->graph[VADC_CALIB_RATIOMETRIC].gnd = read_2; > -err: > - if (ret) > + if (ret) { > +report_failure: > dev_err(vadc->dev, "measure reference points failed\n"); > + } > > return ret; > } > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] iio: qcom-spmi-vadc: One check less in vadc_measure_ref_points() after error detection @ 2016-01-02 18:28 ` Jonathan Cameron 0 siblings, 0 replies; 3089+ messages in thread From: Jonathan Cameron @ 2016-01-02 18:28 UTC (permalink / raw) To: SF Markus Elfring, linux-iio, Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald Cc: LKML, kernel-janitors, Julia Lawall On 26/12/15 13:04, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sat, 26 Dec 2015 13:53:15 +0100 > > This issue was detected by using the Coccinelle software. > > Move the jump label directly before the desired log statement > so that the variable "ret" does not need to be checked once more > after it was determined that a function call failed. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> If we are going to change this, I would prefer to see more useful local error messages and direct returns rather than jumping to a very generic message at the end. I'm also less than keen on jumping into conditionals as I find it slightly less readable. We might technically be 'simplifying' the code, but in this case the gain is very minor for a fair bit of code churn... Thanks, Jonathan > --- > drivers/iio/adc/qcom-spmi-vadc.c | 17 +++++++++-------- > 1 file changed, 9 insertions(+), 8 deletions(-) > > diff --git a/drivers/iio/adc/qcom-spmi-vadc.c b/drivers/iio/adc/qcom-spmi-vadc.c > index c2babe5..391eefa 100644 > --- a/drivers/iio/adc/qcom-spmi-vadc.c > +++ b/drivers/iio/adc/qcom-spmi-vadc.c > @@ -424,7 +424,7 @@ static int vadc_measure_ref_points(struct vadc_priv *vadc) > prop = vadc_get_channel(vadc, VADC_REF_1250MV); > ret = vadc_do_conversion(vadc, prop, &read_1); > if (ret) > - goto err; > + goto report_failure; In this first case we have already had a report that a conversion failed. I suppose adding that it was during reference point measurement 'might' be useful additional information. I'm not really convinced of it does however... Hence I'd drop reporting it entirely in this function. > > /* Try with buffered 625mV channel first */ > prop = vadc_get_channel(vadc, VADC_SPARE1); > @@ -433,11 +433,11 @@ static int vadc_measure_ref_points(struct vadc_priv *vadc) > > ret = vadc_do_conversion(vadc, prop, &read_2); > if (ret) > - goto err; > + goto report_failure; > > if (read_1 = read_2) { > ret = -EINVAL; I think this one indicates we can't actually read anything at all for some reason... It's the only form of error we won't have effectively already reported so is worthy of some sort of debug message... > - goto err; > + goto report_failure; > } > > vadc->graph[VADC_CALIB_ABSOLUTE].dy = read_1 - read_2; > @@ -447,23 +447,24 @@ static int vadc_measure_ref_points(struct vadc_priv *vadc) > prop = vadc_get_channel(vadc, VADC_VDD_VADC); > ret = vadc_do_conversion(vadc, prop, &read_1); > if (ret) > - goto err; > + goto report_failure; > > prop = vadc_get_channel(vadc, VADC_GND_REF); > ret = vadc_do_conversion(vadc, prop, &read_2); > if (ret) > - goto err; > + goto report_failure; > > if (read_1 = read_2) { > ret = -EINVAL; > - goto err; > + goto report_failure; > } > > vadc->graph[VADC_CALIB_RATIOMETRIC].dy = read_1 - read_2; > vadc->graph[VADC_CALIB_RATIOMETRIC].gnd = read_2; > -err: > - if (ret) > + if (ret) { > +report_failure: > dev_err(vadc->dev, "measure reference points failed\n"); > + } > > return ret; > } > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/6] InfiniBand-ocrdma: Fine-tuning for some function implementations 2015-12-11 12:08 ` SF Markus Elfring @ 2015-12-26 18:39 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-26 18:39 UTC (permalink / raw) To: linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 26 Dec 2015 19:30:54 +0100 Several update suggestions were taken into account from static source code analysis. Markus Elfring (6): One variable and jump label less in ocrdma_alloc_ucontext_pd() Delete unnecessary variable initialisations in 11 functions Returning only value constants in ocrdma_qp_state_change() Return a value from a function call in _ocrdma_modify_qp() directly Returning only value constants in ocrdma_resize_cq() Delete an unnecessary variable in ocrdma_dealloc_pd() drivers/infiniband/hw/ocrdma/ocrdma_ah.c | 2 +- drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 7 +++--- drivers/infiniband/hw/ocrdma/ocrdma_stats.c | 4 +-- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 39 +++++++++++------------------ 4 files changed, 20 insertions(+), 32 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/6] InfiniBand-ocrdma: Fine-tuning for some function implementations @ 2015-12-26 18:39 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-26 18:39 UTC (permalink / raw) To: linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 26 Dec 2015 19:30:54 +0100 Several update suggestions were taken into account from static source code analysis. Markus Elfring (6): One variable and jump label less in ocrdma_alloc_ucontext_pd() Delete unnecessary variable initialisations in 11 functions Returning only value constants in ocrdma_qp_state_change() Return a value from a function call in _ocrdma_modify_qp() directly Returning only value constants in ocrdma_resize_cq() Delete an unnecessary variable in ocrdma_dealloc_pd() drivers/infiniband/hw/ocrdma/ocrdma_ah.c | 2 +- drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 7 +++--- drivers/infiniband/hw/ocrdma/ocrdma_stats.c | 4 +-- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 39 +++++++++++------------------ 4 files changed, 20 insertions(+), 32 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 1/6] InfiniBand-ocrdma: One variable and jump label less in ocrdma_alloc_ucontext_pd() 2015-12-26 18:39 ` SF Markus Elfring @ 2015-12-26 18:43 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-26 18:43 UTC (permalink / raw) To: linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 26 Dec 2015 17:16:00 +0100 This issue was detected by using the Coccinelle software. * Let us return directly if a call of the _ocrdma_alloc_pd() function failed. * Delete the jump label "err" and the local variable "status" then. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c index 583001b..374c839 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c @@ -483,19 +483,15 @@ static int ocrdma_alloc_ucontext_pd(struct ocrdma_dev *dev, struct ocrdma_ucontext *uctx, struct ib_udata *udata) { - int status = 0; - uctx->cntxt_pd = _ocrdma_alloc_pd(dev, uctx, udata); if (IS_ERR(uctx->cntxt_pd)) { - status = PTR_ERR(uctx->cntxt_pd); uctx->cntxt_pd = NULL; - goto err; + return PTR_ERR(uctx->cntxt_pd); } uctx->cntxt_pd->uctx = uctx; uctx->cntxt_pd->ibpd.device = &dev->ibdev; -err: - return status; + return 0; } static int ocrdma_dealloc_ucontext_pd(struct ocrdma_ucontext *uctx) -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 1/6] InfiniBand-ocrdma: One variable and jump label less in ocrdma_alloc_ucontext_pd() @ 2015-12-26 18:43 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-26 18:43 UTC (permalink / raw) To: linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 26 Dec 2015 17:16:00 +0100 This issue was detected by using the Coccinelle software. * Let us return directly if a call of the _ocrdma_alloc_pd() function failed. * Delete the jump label "err" and the local variable "status" then. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c index 583001b..374c839 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c @@ -483,19 +483,15 @@ static int ocrdma_alloc_ucontext_pd(struct ocrdma_dev *dev, struct ocrdma_ucontext *uctx, struct ib_udata *udata) { - int status = 0; - uctx->cntxt_pd = _ocrdma_alloc_pd(dev, uctx, udata); if (IS_ERR(uctx->cntxt_pd)) { - status = PTR_ERR(uctx->cntxt_pd); uctx->cntxt_pd = NULL; - goto err; + return PTR_ERR(uctx->cntxt_pd); } uctx->cntxt_pd->uctx = uctx; uctx->cntxt_pd->ibpd.device = &dev->ibdev; -err: - return status; + return 0; } static int ocrdma_dealloc_ucontext_pd(struct ocrdma_ucontext *uctx) -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/6] InfiniBand-ocrdma: One variable and jump label less in ocrdma_alloc_ucontext_pd() 2015-12-26 18:43 ` SF Markus Elfring @ 2015-12-26 19:41 ` kbuild test robot -1 siblings, 0 replies; 3089+ messages in thread From: kbuild test robot @ 2015-12-26 19:41 UTC (permalink / raw) To: SF Markus Elfring Cc: kbuild-all, linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier, LKML, kernel-janitors, Julia Lawall [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] Hi Markus, [auto build test WARNING on v4.4-rc6] [also build test WARNING on next-20151223] url: https://github.com/0day-ci/linux/commits/SF-Markus-Elfring/InfiniBand-ocrdma-Fine-tuning-for-some-function-implementations/20151227-025304 coccinelle warnings: (new ones prefixed by >>) >> drivers/infiniband/hw/ocrdma/ocrdma_verbs.c:489:9-16: ERROR: PTR_ERR applied after initialization to constant on line 488 vim +489 drivers/infiniband/hw/ocrdma/ocrdma_verbs.c 482 static int ocrdma_alloc_ucontext_pd(struct ocrdma_dev *dev, 483 struct ocrdma_ucontext *uctx, 484 struct ib_udata *udata) 485 { 486 uctx->cntxt_pd = _ocrdma_alloc_pd(dev, uctx, udata); 487 if (IS_ERR(uctx->cntxt_pd)) { > 488 uctx->cntxt_pd = NULL; > 489 return PTR_ERR(uctx->cntxt_pd); 490 } 491 492 uctx->cntxt_pd->uctx = uctx; --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/6] InfiniBand-ocrdma: One variable and jump label less in ocrdma_alloc_ucontext_pd() @ 2015-12-26 19:41 ` kbuild test robot 0 siblings, 0 replies; 3089+ messages in thread From: kbuild test robot @ 2015-12-26 19:41 UTC (permalink / raw) To: kernel-janitors [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] Hi Markus, [auto build test WARNING on v4.4-rc6] [also build test WARNING on next-20151223] url: https://github.com/0day-ci/linux/commits/SF-Markus-Elfring/InfiniBand-ocrdma-Fine-tuning-for-some-function-implementations/20151227-025304 coccinelle warnings: (new ones prefixed by >>) >> drivers/infiniband/hw/ocrdma/ocrdma_verbs.c:489:9-16: ERROR: PTR_ERR applied after initialization to constant on line 488 vim +489 drivers/infiniband/hw/ocrdma/ocrdma_verbs.c 482 static int ocrdma_alloc_ucontext_pd(struct ocrdma_dev *dev, 483 struct ocrdma_ucontext *uctx, 484 struct ib_udata *udata) 485 { 486 uctx->cntxt_pd = _ocrdma_alloc_pd(dev, uctx, udata); 487 if (IS_ERR(uctx->cntxt_pd)) { > 488 uctx->cntxt_pd = NULL; > 489 return PTR_ERR(uctx->cntxt_pd); 490 } 491 492 uctx->cntxt_pd->uctx = uctx; --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH v2 1/6] InfiniBand-ocrdma: One jump label less in ocrdma_alloc_ucontext_pd() 2015-12-26 19:41 ` kbuild test robot @ 2015-12-26 21:28 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-26 21:28 UTC (permalink / raw) To: linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier Cc: kbuild-all, LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 26 Dec 2015 22:18:38 +0100 This issue was detected by using the Coccinelle software. * Let us return directly if a call of the _ocrdma_alloc_pd() function failed. * Reduce the scope for the local variable "status" to one case of an if statement. * Delete the jump label "err" then. * Return zero as a constant at the end. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c index 583001b..7f10cc47 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c @@ -483,19 +483,16 @@ static int ocrdma_alloc_ucontext_pd(struct ocrdma_dev *dev, struct ocrdma_ucontext *uctx, struct ib_udata *udata) { - int status = 0; - uctx->cntxt_pd = _ocrdma_alloc_pd(dev, uctx, udata); if (IS_ERR(uctx->cntxt_pd)) { - status = PTR_ERR(uctx->cntxt_pd); + int status = PTR_ERR(uctx->cntxt_pd); uctx->cntxt_pd = NULL; - goto err; + return status; } uctx->cntxt_pd->uctx = uctx; uctx->cntxt_pd->ibpd.device = &dev->ibdev; -err: - return status; + return 0; } static int ocrdma_dealloc_ucontext_pd(struct ocrdma_ucontext *uctx) -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH v2 1/6] InfiniBand-ocrdma: One jump label less in ocrdma_alloc_ucontext_pd() @ 2015-12-26 21:28 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-26 21:28 UTC (permalink / raw) To: linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier Cc: kbuild-all, LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 26 Dec 2015 22:18:38 +0100 This issue was detected by using the Coccinelle software. * Let us return directly if a call of the _ocrdma_alloc_pd() function failed. * Reduce the scope for the local variable "status" to one case of an if statement. * Delete the jump label "err" then. * Return zero as a constant at the end. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c index 583001b..7f10cc47 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c @@ -483,19 +483,16 @@ static int ocrdma_alloc_ucontext_pd(struct ocrdma_dev *dev, struct ocrdma_ucontext *uctx, struct ib_udata *udata) { - int status = 0; - uctx->cntxt_pd = _ocrdma_alloc_pd(dev, uctx, udata); if (IS_ERR(uctx->cntxt_pd)) { - status = PTR_ERR(uctx->cntxt_pd); + int status = PTR_ERR(uctx->cntxt_pd); uctx->cntxt_pd = NULL; - goto err; + return status; } uctx->cntxt_pd->uctx = uctx; uctx->cntxt_pd->ibpd.device = &dev->ibdev; -err: - return status; + return 0; } static int ocrdma_dealloc_ucontext_pd(struct ocrdma_ucontext *uctx) -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH v2 1/6] InfiniBand-ocrdma: One jump label less in ocrdma_alloc_ucontext_pd() 2015-12-26 21:28 ` SF Markus Elfring @ 2016-01-11 13:23 ` Selvin Xavier -1 siblings, 0 replies; 3089+ messages in thread From: Selvin Xavier @ 2016-01-11 13:11 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, kbuild-all, LKML, kernel-janitors, Julia Lawall This patch series looks good to me Thanks, Acked-by: Selvin Xavier <selvin.xavier@avagotech.com> On Sun, Dec 27, 2015 at 2:58 AM, SF Markus Elfring <elfring@users.sourceforge.net> wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sat, 26 Dec 2015 22:18:38 +0100 > > This issue was detected by using the Coccinelle software. > > * Let us return directly if a call of the _ocrdma_alloc_pd() > function failed. > > * Reduce the scope for the local variable "status" to one case > of an if statement. > > * Delete the jump label "err" then. > > * Return zero as a constant at the end. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 9 +++------ > 1 file changed, 3 insertions(+), 6 deletions(-) > > diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c > index 583001b..7f10cc47 100644 > --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c > +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c > @@ -483,19 +483,16 @@ static int ocrdma_alloc_ucontext_pd(struct ocrdma_dev *dev, > struct ocrdma_ucontext *uctx, > struct ib_udata *udata) > { > - int status = 0; > - > uctx->cntxt_pd = _ocrdma_alloc_pd(dev, uctx, udata); > if (IS_ERR(uctx->cntxt_pd)) { > - status = PTR_ERR(uctx->cntxt_pd); > + int status = PTR_ERR(uctx->cntxt_pd); > uctx->cntxt_pd = NULL; > - goto err; > + return status; > } > > uctx->cntxt_pd->uctx = uctx; > uctx->cntxt_pd->ibpd.device = &dev->ibdev; > -err: > - return status; > + return 0; > } > > static int ocrdma_dealloc_ucontext_pd(struct ocrdma_ucontext *uctx) > -- > 2.6.3 > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH v2 1/6] InfiniBand-ocrdma: One jump label less in ocrdma_alloc_ucontext_pd() @ 2016-01-11 13:23 ` Selvin Xavier 0 siblings, 0 replies; 3089+ messages in thread From: Selvin Xavier @ 2016-01-11 13:23 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, kbuild-all, LKML, kernel-janitors, Julia Lawall This patch series looks good to me Thanks, Acked-by: Selvin Xavier <selvin.xavier@avagotech.com> On Sun, Dec 27, 2015 at 2:58 AM, SF Markus Elfring <elfring@users.sourceforge.net> wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sat, 26 Dec 2015 22:18:38 +0100 > > This issue was detected by using the Coccinelle software. > > * Let us return directly if a call of the _ocrdma_alloc_pd() > function failed. > > * Reduce the scope for the local variable "status" to one case > of an if statement. > > * Delete the jump label "err" then. > > * Return zero as a constant at the end. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 9 +++------ > 1 file changed, 3 insertions(+), 6 deletions(-) > > diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c > index 583001b..7f10cc47 100644 > --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c > +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c > @@ -483,19 +483,16 @@ static int ocrdma_alloc_ucontext_pd(struct ocrdma_dev *dev, > struct ocrdma_ucontext *uctx, > struct ib_udata *udata) > { > - int status = 0; > - > uctx->cntxt_pd = _ocrdma_alloc_pd(dev, uctx, udata); > if (IS_ERR(uctx->cntxt_pd)) { > - status = PTR_ERR(uctx->cntxt_pd); > + int status = PTR_ERR(uctx->cntxt_pd); > uctx->cntxt_pd = NULL; > - goto err; > + return status; > } > > uctx->cntxt_pd->uctx = uctx; > uctx->cntxt_pd->ibpd.device = &dev->ibdev; > -err: > - return status; > + return 0; > } > > static int ocrdma_dealloc_ucontext_pd(struct ocrdma_ucontext *uctx) > -- > 2.6.3 > ^ permalink raw reply [flat|nested] 3089+ messages in thread
[parent not found: <567EDED5.4040201-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>]
* [PATCH 2/6] InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions 2015-12-26 18:39 ` SF Markus Elfring (?) @ 2015-12-26 18:45 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-26 18:45 UTC (permalink / raw) To: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier Cc: LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall From: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> Date: Sat, 26 Dec 2015 18:18:18 +0100 The variable "status" will be set to an appropriate value a bit later. Thus let us omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> --- drivers/infiniband/hw/ocrdma/ocrdma_ah.c | 2 +- drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 4 ++-- drivers/infiniband/hw/ocrdma/ocrdma_stats.c | 4 ++-- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 12 ++++++------ 4 files changed, 11 insertions(+), 11 deletions(-) diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_ah.c b/drivers/infiniband/hw/ocrdma/ocrdma_ah.c index 9820074..98c0abd 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_ah.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_ah.c @@ -59,7 +59,7 @@ static inline int set_av_attr(struct ocrdma_dev *dev, struct ocrdma_ah *ah, struct ib_ah_attr *attr, union ib_gid *sgid, int pdid, bool *isvlan, u16 vlan_tag) { - int status = 0; + int status; struct ocrdma_eth_vlan eth; struct ocrdma_grh grh; int eth_sz; diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c index 30f67be..6647aa6 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c @@ -1089,7 +1089,7 @@ mbx_err: static int ocrdma_nonemb_mbx_cmd(struct ocrdma_dev *dev, struct ocrdma_mqe *mqe, void *payload_va) { - int status = 0; + int status; struct ocrdma_mbx_rsp *rsp = payload_va; if ((mqe->hdr.spcl_sge_cnt_emb & OCRDMA_MQE_HDR_EMB_MASK) >> @@ -2842,7 +2842,7 @@ int ocrdma_mbx_destroy_srq(struct ocrdma_dev *dev, struct ocrdma_srq *srq) static int ocrdma_mbx_get_dcbx_config(struct ocrdma_dev *dev, u32 ptype, struct ocrdma_dcbx_cfg *dcbxcfg) { - int status = 0; + int status; dma_addr_t pa; struct ocrdma_mqe cmd; diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_stats.c b/drivers/infiniband/hw/ocrdma/ocrdma_stats.c index 86c303a..119baa3 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_stats.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_stats.c @@ -608,7 +608,7 @@ static char *ocrdma_driver_dbg_stats(struct ocrdma_dev *dev) static void ocrdma_update_stats(struct ocrdma_dev *dev) { ulong now = jiffies, secs; - int status = 0; + int status; struct ocrdma_rdma_stats_resp *rdma_stats = (struct ocrdma_rdma_stats_resp *)dev->stats_mem.va; struct ocrdma_rsrc_stats *rsrc_stats = &rdma_stats->act_rsrc_stats; @@ -639,7 +639,7 @@ static ssize_t ocrdma_dbgfs_ops_write(struct file *filp, { char tmp_str[32]; long reset; - int status = 0; + int status; struct ocrdma_stats *pstats = filp->private_data; struct ocrdma_dev *dev = pstats->dev; diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c index 374c839..aba1b5a 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c @@ -419,7 +419,7 @@ static struct ocrdma_pd *_ocrdma_alloc_pd(struct ocrdma_dev *dev, struct ib_udata *udata) { struct ocrdma_pd *pd = NULL; - int status = 0; + int status; pd = kzalloc(sizeof(*pd), GFP_KERNEL); if (!pd) @@ -468,7 +468,7 @@ static inline int is_ucontext_pd(struct ocrdma_ucontext *uctx, static int _ocrdma_dealloc_pd(struct ocrdma_dev *dev, struct ocrdma_pd *pd) { - int status = 0; + int status; if (dev->pd_mgr->pd_prealloc_valid) status = ocrdma_put_pd_num(dev, pd->id, pd->dpp_enabled); @@ -592,7 +592,7 @@ map_err: int ocrdma_dealloc_ucontext(struct ib_ucontext *ibctx) { - int status = 0; + int status; struct ocrdma_mm *mm, *tmp; struct ocrdma_ucontext *uctx = get_ocrdma_ucontext(ibctx); struct ocrdma_dev *dev = get_ocrdma_dev(ibctx->device); @@ -619,7 +619,7 @@ int ocrdma_mmap(struct ib_ucontext *context, struct vm_area_struct *vma) unsigned long vm_page = vma->vm_pgoff << PAGE_SHIFT; u64 unmapped_db = (u64) dev->nic_info.unmapped_db; unsigned long len = (vma->vm_end - vma->vm_start); - int status = 0; + int status; bool found; if (vma->vm_start & (PAGE_SIZE - 1)) @@ -1282,7 +1282,7 @@ static int ocrdma_copy_qp_uresp(struct ocrdma_qp *qp, struct ib_udata *udata, int dpp_offset, int dpp_credit_lmt, int srq) { - int status = 0; + int status; u64 usr_db; struct ocrdma_create_qp_uresp uresp; struct ocrdma_pd *pd = qp->pd; @@ -1946,7 +1946,7 @@ int ocrdma_modify_srq(struct ib_srq *ibsrq, enum ib_srq_attr_mask srq_attr_mask, struct ib_udata *udata) { - int status = 0; + int status; struct ocrdma_srq *srq; srq = get_ocrdma_srq(ibsrq); -- 2.6.3 -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 2/6] InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions @ 2015-12-26 18:45 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-26 18:45 UTC (permalink / raw) To: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier Cc: LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 26 Dec 2015 18:18:18 +0100 The variable "status" will be set to an appropriate value a bit later. Thus let us omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/infiniband/hw/ocrdma/ocrdma_ah.c | 2 +- drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 4 ++-- drivers/infiniband/hw/ocrdma/ocrdma_stats.c | 4 ++-- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 12 ++++++------ 4 files changed, 11 insertions(+), 11 deletions(-) diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_ah.c b/drivers/infiniband/hw/ocrdma/ocrdma_ah.c index 9820074..98c0abd 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_ah.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_ah.c @@ -59,7 +59,7 @@ static inline int set_av_attr(struct ocrdma_dev *dev, struct ocrdma_ah *ah, struct ib_ah_attr *attr, union ib_gid *sgid, int pdid, bool *isvlan, u16 vlan_tag) { - int status = 0; + int status; struct ocrdma_eth_vlan eth; struct ocrdma_grh grh; int eth_sz; diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c index 30f67be..6647aa6 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c @@ -1089,7 +1089,7 @@ mbx_err: static int ocrdma_nonemb_mbx_cmd(struct ocrdma_dev *dev, struct ocrdma_mqe *mqe, void *payload_va) { - int status = 0; + int status; struct ocrdma_mbx_rsp *rsp = payload_va; if ((mqe->hdr.spcl_sge_cnt_emb & OCRDMA_MQE_HDR_EMB_MASK) >> @@ -2842,7 +2842,7 @@ int ocrdma_mbx_destroy_srq(struct ocrdma_dev *dev, struct ocrdma_srq *srq) static int ocrdma_mbx_get_dcbx_config(struct ocrdma_dev *dev, u32 ptype, struct ocrdma_dcbx_cfg *dcbxcfg) { - int status = 0; + int status; dma_addr_t pa; struct ocrdma_mqe cmd; diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_stats.c b/drivers/infiniband/hw/ocrdma/ocrdma_stats.c index 86c303a..119baa3 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_stats.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_stats.c @@ -608,7 +608,7 @@ static char *ocrdma_driver_dbg_stats(struct ocrdma_dev *dev) static void ocrdma_update_stats(struct ocrdma_dev *dev) { ulong now = jiffies, secs; - int status = 0; + int status; struct ocrdma_rdma_stats_resp *rdma_stats (struct ocrdma_rdma_stats_resp *)dev->stats_mem.va; struct ocrdma_rsrc_stats *rsrc_stats = &rdma_stats->act_rsrc_stats; @@ -639,7 +639,7 @@ static ssize_t ocrdma_dbgfs_ops_write(struct file *filp, { char tmp_str[32]; long reset; - int status = 0; + int status; struct ocrdma_stats *pstats = filp->private_data; struct ocrdma_dev *dev = pstats->dev; diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c index 374c839..aba1b5a 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c @@ -419,7 +419,7 @@ static struct ocrdma_pd *_ocrdma_alloc_pd(struct ocrdma_dev *dev, struct ib_udata *udata) { struct ocrdma_pd *pd = NULL; - int status = 0; + int status; pd = kzalloc(sizeof(*pd), GFP_KERNEL); if (!pd) @@ -468,7 +468,7 @@ static inline int is_ucontext_pd(struct ocrdma_ucontext *uctx, static int _ocrdma_dealloc_pd(struct ocrdma_dev *dev, struct ocrdma_pd *pd) { - int status = 0; + int status; if (dev->pd_mgr->pd_prealloc_valid) status = ocrdma_put_pd_num(dev, pd->id, pd->dpp_enabled); @@ -592,7 +592,7 @@ map_err: int ocrdma_dealloc_ucontext(struct ib_ucontext *ibctx) { - int status = 0; + int status; struct ocrdma_mm *mm, *tmp; struct ocrdma_ucontext *uctx = get_ocrdma_ucontext(ibctx); struct ocrdma_dev *dev = get_ocrdma_dev(ibctx->device); @@ -619,7 +619,7 @@ int ocrdma_mmap(struct ib_ucontext *context, struct vm_area_struct *vma) unsigned long vm_page = vma->vm_pgoff << PAGE_SHIFT; u64 unmapped_db = (u64) dev->nic_info.unmapped_db; unsigned long len = (vma->vm_end - vma->vm_start); - int status = 0; + int status; bool found; if (vma->vm_start & (PAGE_SIZE - 1)) @@ -1282,7 +1282,7 @@ static int ocrdma_copy_qp_uresp(struct ocrdma_qp *qp, struct ib_udata *udata, int dpp_offset, int dpp_credit_lmt, int srq) { - int status = 0; + int status; u64 usr_db; struct ocrdma_create_qp_uresp uresp; struct ocrdma_pd *pd = qp->pd; @@ -1946,7 +1946,7 @@ int ocrdma_modify_srq(struct ib_srq *ibsrq, enum ib_srq_attr_mask srq_attr_mask, struct ib_udata *udata) { - int status = 0; + int status; struct ocrdma_srq *srq; srq = get_ocrdma_srq(ibsrq); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 2/6] InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions @ 2015-12-26 18:45 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-26 18:45 UTC (permalink / raw) To: linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 26 Dec 2015 18:18:18 +0100 The variable "status" will be set to an appropriate value a bit later. Thus let us omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/infiniband/hw/ocrdma/ocrdma_ah.c | 2 +- drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 4 ++-- drivers/infiniband/hw/ocrdma/ocrdma_stats.c | 4 ++-- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 12 ++++++------ 4 files changed, 11 insertions(+), 11 deletions(-) diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_ah.c b/drivers/infiniband/hw/ocrdma/ocrdma_ah.c index 9820074..98c0abd 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_ah.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_ah.c @@ -59,7 +59,7 @@ static inline int set_av_attr(struct ocrdma_dev *dev, struct ocrdma_ah *ah, struct ib_ah_attr *attr, union ib_gid *sgid, int pdid, bool *isvlan, u16 vlan_tag) { - int status = 0; + int status; struct ocrdma_eth_vlan eth; struct ocrdma_grh grh; int eth_sz; diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c index 30f67be..6647aa6 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c @@ -1089,7 +1089,7 @@ mbx_err: static int ocrdma_nonemb_mbx_cmd(struct ocrdma_dev *dev, struct ocrdma_mqe *mqe, void *payload_va) { - int status = 0; + int status; struct ocrdma_mbx_rsp *rsp = payload_va; if ((mqe->hdr.spcl_sge_cnt_emb & OCRDMA_MQE_HDR_EMB_MASK) >> @@ -2842,7 +2842,7 @@ int ocrdma_mbx_destroy_srq(struct ocrdma_dev *dev, struct ocrdma_srq *srq) static int ocrdma_mbx_get_dcbx_config(struct ocrdma_dev *dev, u32 ptype, struct ocrdma_dcbx_cfg *dcbxcfg) { - int status = 0; + int status; dma_addr_t pa; struct ocrdma_mqe cmd; diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_stats.c b/drivers/infiniband/hw/ocrdma/ocrdma_stats.c index 86c303a..119baa3 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_stats.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_stats.c @@ -608,7 +608,7 @@ static char *ocrdma_driver_dbg_stats(struct ocrdma_dev *dev) static void ocrdma_update_stats(struct ocrdma_dev *dev) { ulong now = jiffies, secs; - int status = 0; + int status; struct ocrdma_rdma_stats_resp *rdma_stats = (struct ocrdma_rdma_stats_resp *)dev->stats_mem.va; struct ocrdma_rsrc_stats *rsrc_stats = &rdma_stats->act_rsrc_stats; @@ -639,7 +639,7 @@ static ssize_t ocrdma_dbgfs_ops_write(struct file *filp, { char tmp_str[32]; long reset; - int status = 0; + int status; struct ocrdma_stats *pstats = filp->private_data; struct ocrdma_dev *dev = pstats->dev; diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c index 374c839..aba1b5a 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c @@ -419,7 +419,7 @@ static struct ocrdma_pd *_ocrdma_alloc_pd(struct ocrdma_dev *dev, struct ib_udata *udata) { struct ocrdma_pd *pd = NULL; - int status = 0; + int status; pd = kzalloc(sizeof(*pd), GFP_KERNEL); if (!pd) @@ -468,7 +468,7 @@ static inline int is_ucontext_pd(struct ocrdma_ucontext *uctx, static int _ocrdma_dealloc_pd(struct ocrdma_dev *dev, struct ocrdma_pd *pd) { - int status = 0; + int status; if (dev->pd_mgr->pd_prealloc_valid) status = ocrdma_put_pd_num(dev, pd->id, pd->dpp_enabled); @@ -592,7 +592,7 @@ map_err: int ocrdma_dealloc_ucontext(struct ib_ucontext *ibctx) { - int status = 0; + int status; struct ocrdma_mm *mm, *tmp; struct ocrdma_ucontext *uctx = get_ocrdma_ucontext(ibctx); struct ocrdma_dev *dev = get_ocrdma_dev(ibctx->device); @@ -619,7 +619,7 @@ int ocrdma_mmap(struct ib_ucontext *context, struct vm_area_struct *vma) unsigned long vm_page = vma->vm_pgoff << PAGE_SHIFT; u64 unmapped_db = (u64) dev->nic_info.unmapped_db; unsigned long len = (vma->vm_end - vma->vm_start); - int status = 0; + int status; bool found; if (vma->vm_start & (PAGE_SIZE - 1)) @@ -1282,7 +1282,7 @@ static int ocrdma_copy_qp_uresp(struct ocrdma_qp *qp, struct ib_udata *udata, int dpp_offset, int dpp_credit_lmt, int srq) { - int status = 0; + int status; u64 usr_db; struct ocrdma_create_qp_uresp uresp; struct ocrdma_pd *pd = qp->pd; @@ -1946,7 +1946,7 @@ int ocrdma_modify_srq(struct ib_srq *ibsrq, enum ib_srq_attr_mask srq_attr_mask, struct ib_udata *udata) { - int status = 0; + int status; struct ocrdma_srq *srq; srq = get_ocrdma_srq(ibsrq); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 3/6] InfiniBand-ocrdma: Returning only value constants in ocrdma_qp_state_change() 2015-12-26 18:39 ` SF Markus Elfring (?) @ 2015-12-26 18:47 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-26 18:47 UTC (permalink / raw) To: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier Cc: LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall From: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> Date: Sat, 26 Dec 2015 18:28:35 +0100 Return zero at the end without using the local variable "status". Signed-off-by: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> --- drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c index 6647aa6..9a2b153 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c @@ -2110,7 +2110,6 @@ int ocrdma_qp_state_change(struct ocrdma_qp *qp, enum ib_qp_state new_ib_state, enum ib_qp_state *old_ib_state) { unsigned long flags; - int status = 0; enum ocrdma_qp_state new_state; new_state = get_ocrdma_qp_state(new_ib_state); @@ -2135,7 +2134,7 @@ int ocrdma_qp_state_change(struct ocrdma_qp *qp, enum ib_qp_state new_ib_state, qp->state = new_state; spin_unlock_irqrestore(&qp->q_lock, flags); - return status; + return 0; } static u32 ocrdma_set_create_qp_mbx_access_flags(struct ocrdma_qp *qp) -- 2.6.3 -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 3/6] InfiniBand-ocrdma: Returning only value constants in ocrdma_qp_state_change() @ 2015-12-26 18:47 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-26 18:47 UTC (permalink / raw) To: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier Cc: LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 26 Dec 2015 18:28:35 +0100 Return zero at the end without using the local variable "status". Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c index 6647aa6..9a2b153 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c @@ -2110,7 +2110,6 @@ int ocrdma_qp_state_change(struct ocrdma_qp *qp, enum ib_qp_state new_ib_state, enum ib_qp_state *old_ib_state) { unsigned long flags; - int status = 0; enum ocrdma_qp_state new_state; new_state = get_ocrdma_qp_state(new_ib_state); @@ -2135,7 +2134,7 @@ int ocrdma_qp_state_change(struct ocrdma_qp *qp, enum ib_qp_state new_ib_state, qp->state = new_state; spin_unlock_irqrestore(&qp->q_lock, flags); - return status; + return 0; } static u32 ocrdma_set_create_qp_mbx_access_flags(struct ocrdma_qp *qp) -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 3/6] InfiniBand-ocrdma: Returning only value constants in ocrdma_qp_state_change() @ 2015-12-26 18:47 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-26 18:47 UTC (permalink / raw) To: linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 26 Dec 2015 18:28:35 +0100 Return zero at the end without using the local variable "status". Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c index 6647aa6..9a2b153 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c @@ -2110,7 +2110,6 @@ int ocrdma_qp_state_change(struct ocrdma_qp *qp, enum ib_qp_state new_ib_state, enum ib_qp_state *old_ib_state) { unsigned long flags; - int status = 0; enum ocrdma_qp_state new_state; new_state = get_ocrdma_qp_state(new_ib_state); @@ -2135,7 +2134,7 @@ int ocrdma_qp_state_change(struct ocrdma_qp *qp, enum ib_qp_state new_ib_state, qp->state = new_state; spin_unlock_irqrestore(&qp->q_lock, flags); - return status; + return 0; } static u32 ocrdma_set_create_qp_mbx_access_flags(struct ocrdma_qp *qp) -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 4/6] InfiniBand-ocrdma: Return a value from a function call in _ocrdma_modify_qp() directly 2015-12-26 18:39 ` SF Markus Elfring (?) @ 2015-12-26 18:49 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-26 18:49 UTC (permalink / raw) To: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier Cc: LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall From: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> Date: Sat, 26 Dec 2015 18:40:43 +0100 Return the value from a call of the ocrdma_mbx_modify_qp() function without using an extra assignment for the local variable "status". Signed-off-by: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> --- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c index aba1b5a..2de39d3 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c @@ -1491,9 +1491,7 @@ int _ocrdma_modify_qp(struct ib_qp *ibqp, struct ib_qp_attr *attr, */ if (status < 0) return status; - status = ocrdma_mbx_modify_qp(dev, qp, attr, attr_mask); - - return status; + return ocrdma_mbx_modify_qp(dev, qp, attr, attr_mask); } int ocrdma_modify_qp(struct ib_qp *ibqp, struct ib_qp_attr *attr, -- 2.6.3 -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 4/6] InfiniBand-ocrdma: Return a value from a function call in _ocrdma_modify_qp() directly @ 2015-12-26 18:49 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-26 18:49 UTC (permalink / raw) To: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier Cc: LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 26 Dec 2015 18:40:43 +0100 Return the value from a call of the ocrdma_mbx_modify_qp() function without using an extra assignment for the local variable "status". Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c index aba1b5a..2de39d3 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c @@ -1491,9 +1491,7 @@ int _ocrdma_modify_qp(struct ib_qp *ibqp, struct ib_qp_attr *attr, */ if (status < 0) return status; - status = ocrdma_mbx_modify_qp(dev, qp, attr, attr_mask); - - return status; + return ocrdma_mbx_modify_qp(dev, qp, attr, attr_mask); } int ocrdma_modify_qp(struct ib_qp *ibqp, struct ib_qp_attr *attr, -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 4/6] InfiniBand-ocrdma: Return a value from a function call in _ocrdma_modify_qp() directly @ 2015-12-26 18:49 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-26 18:49 UTC (permalink / raw) To: linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 26 Dec 2015 18:40:43 +0100 Return the value from a call of the ocrdma_mbx_modify_qp() function without using an extra assignment for the local variable "status". Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c index aba1b5a..2de39d3 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c @@ -1491,9 +1491,7 @@ int _ocrdma_modify_qp(struct ib_qp *ibqp, struct ib_qp_attr *attr, */ if (status < 0) return status; - status = ocrdma_mbx_modify_qp(dev, qp, attr, attr_mask); - - return status; + return ocrdma_mbx_modify_qp(dev, qp, attr, attr_mask); } int ocrdma_modify_qp(struct ib_qp *ibqp, struct ib_qp_attr *attr, -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH v3 0/6] InfiniBand-ocrdma: Fine-tuning for some function implementations 2015-12-26 18:39 ` SF Markus Elfring (?) @ 2016-01-14 17:18 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-14 17:18 UTC (permalink / raw) To: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier Cc: LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall From: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> Date: Thu, 14 Jan 2016 18:15:54 +0100 Several update suggestions were taken into account from static source code analysis. Markus Elfring (6): One variable and jump label less in ocrdma_alloc_ucontext_pd() Delete unnecessary variable initialisations in 11 functions Returning only value constants in ocrdma_qp_state_change() Return a value from a function call in _ocrdma_modify_qp() directly Returning only value constants in ocrdma_resize_cq() Delete an unnecessary variable in ocrdma_dealloc_pd() --- v3: Rebase proposed changes on the source files for the software "Linux next-20160114". v2: Unfortunately, the first update step from this series contained an inappropriate suggestion. Thus fix that. drivers/infiniband/hw/ocrdma/ocrdma_ah.c | 2 +- drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 7 +++--- drivers/infiniband/hw/ocrdma/ocrdma_stats.c | 4 +-- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 39 +++++++++++------------------ 4 files changed, 20 insertions(+), 32 deletions(-) -- 2.6.3 -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH v3 0/6] InfiniBand-ocrdma: Fine-tuning for some function implementations @ 2016-01-14 17:18 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-14 17:18 UTC (permalink / raw) To: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier Cc: LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Thu, 14 Jan 2016 18:15:54 +0100 Several update suggestions were taken into account from static source code analysis. Markus Elfring (6): One variable and jump label less in ocrdma_alloc_ucontext_pd() Delete unnecessary variable initialisations in 11 functions Returning only value constants in ocrdma_qp_state_change() Return a value from a function call in _ocrdma_modify_qp() directly Returning only value constants in ocrdma_resize_cq() Delete an unnecessary variable in ocrdma_dealloc_pd() --- v3: Rebase proposed changes on the source files for the software "Linux next-20160114". v2: Unfortunately, the first update step from this series contained an inappropriate suggestion. Thus fix that. drivers/infiniband/hw/ocrdma/ocrdma_ah.c | 2 +- drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 7 +++--- drivers/infiniband/hw/ocrdma/ocrdma_stats.c | 4 +-- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 39 +++++++++++------------------ 4 files changed, 20 insertions(+), 32 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH v3 0/6] InfiniBand-ocrdma: Fine-tuning for some function implementations @ 2016-01-14 17:18 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-14 17:18 UTC (permalink / raw) To: linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Thu, 14 Jan 2016 18:15:54 +0100 Several update suggestions were taken into account from static source code analysis. Markus Elfring (6): One variable and jump label less in ocrdma_alloc_ucontext_pd() Delete unnecessary variable initialisations in 11 functions Returning only value constants in ocrdma_qp_state_change() Return a value from a function call in _ocrdma_modify_qp() directly Returning only value constants in ocrdma_resize_cq() Delete an unnecessary variable in ocrdma_dealloc_pd() --- v3: Rebase proposed changes on the source files for the software "Linux next-20160114". v2: Unfortunately, the first update step from this series contained an inappropriate suggestion. Thus fix that. drivers/infiniband/hw/ocrdma/ocrdma_ah.c | 2 +- drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 7 +++--- drivers/infiniband/hw/ocrdma/ocrdma_stats.c | 4 +-- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 39 +++++++++++------------------ 4 files changed, 20 insertions(+), 32 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
[parent not found: <5697D865.5010507-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>]
* [PATCH v3 1/6] InfiniBand-ocrdma: One jump label less in ocrdma_alloc_ucontext_pd() 2016-01-14 17:18 ` SF Markus Elfring (?) @ 2016-01-14 17:38 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-14 17:38 UTC (permalink / raw) To: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier Cc: LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall From: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> Date: Thu, 14 Jan 2016 17:17:44 +0100 This issue was detected by using the Coccinelle software. * Let us return directly if a call of the _ocrdma_alloc_pd() function failed. * Reduce the scope for the local variable "status" to one case of an if statement. * Delete the jump label "err" then. * Return zero as a constant at the end. Signed-off-by: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> --- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c index d4c687b..4caf167 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c @@ -483,19 +483,16 @@ static int ocrdma_alloc_ucontext_pd(struct ocrdma_dev *dev, struct ocrdma_ucontext *uctx, struct ib_udata *udata) { - int status = 0; - uctx->cntxt_pd = _ocrdma_alloc_pd(dev, uctx, udata); if (IS_ERR(uctx->cntxt_pd)) { - status = PTR_ERR(uctx->cntxt_pd); + int status = PTR_ERR(uctx->cntxt_pd); uctx->cntxt_pd = NULL; - goto err; + return status; } uctx->cntxt_pd->uctx = uctx; uctx->cntxt_pd->ibpd.device = &dev->ibdev; -err: - return status; + return 0; } static int ocrdma_dealloc_ucontext_pd(struct ocrdma_ucontext *uctx) -- 2.6.3 -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH v3 1/6] InfiniBand-ocrdma: One jump label less in ocrdma_alloc_ucontext_pd() @ 2016-01-14 17:38 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-14 17:38 UTC (permalink / raw) To: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier Cc: LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Thu, 14 Jan 2016 17:17:44 +0100 This issue was detected by using the Coccinelle software. * Let us return directly if a call of the _ocrdma_alloc_pd() function failed. * Reduce the scope for the local variable "status" to one case of an if statement. * Delete the jump label "err" then. * Return zero as a constant at the end. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c index d4c687b..4caf167 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c @@ -483,19 +483,16 @@ static int ocrdma_alloc_ucontext_pd(struct ocrdma_dev *dev, struct ocrdma_ucontext *uctx, struct ib_udata *udata) { - int status = 0; - uctx->cntxt_pd = _ocrdma_alloc_pd(dev, uctx, udata); if (IS_ERR(uctx->cntxt_pd)) { - status = PTR_ERR(uctx->cntxt_pd); + int status = PTR_ERR(uctx->cntxt_pd); uctx->cntxt_pd = NULL; - goto err; + return status; } uctx->cntxt_pd->uctx = uctx; uctx->cntxt_pd->ibpd.device = &dev->ibdev; -err: - return status; + return 0; } static int ocrdma_dealloc_ucontext_pd(struct ocrdma_ucontext *uctx) -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH v3 1/6] InfiniBand-ocrdma: One jump label less in ocrdma_alloc_ucontext_pd() @ 2016-01-14 17:38 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-14 17:38 UTC (permalink / raw) To: linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Thu, 14 Jan 2016 17:17:44 +0100 This issue was detected by using the Coccinelle software. * Let us return directly if a call of the _ocrdma_alloc_pd() function failed. * Reduce the scope for the local variable "status" to one case of an if statement. * Delete the jump label "err" then. * Return zero as a constant at the end. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c index d4c687b..4caf167 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c @@ -483,19 +483,16 @@ static int ocrdma_alloc_ucontext_pd(struct ocrdma_dev *dev, struct ocrdma_ucontext *uctx, struct ib_udata *udata) { - int status = 0; - uctx->cntxt_pd = _ocrdma_alloc_pd(dev, uctx, udata); if (IS_ERR(uctx->cntxt_pd)) { - status = PTR_ERR(uctx->cntxt_pd); + int status = PTR_ERR(uctx->cntxt_pd); uctx->cntxt_pd = NULL; - goto err; + return status; } uctx->cntxt_pd->uctx = uctx; uctx->cntxt_pd->ibpd.device = &dev->ibdev; -err: - return status; + return 0; } static int ocrdma_dealloc_ucontext_pd(struct ocrdma_ucontext *uctx) -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH v3 5/6] InfiniBand-ocrdma: Returning only value constants in ocrdma_resize_cq() 2016-01-14 17:18 ` SF Markus Elfring (?) @ 2016-01-14 17:50 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-14 17:50 UTC (permalink / raw) To: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier Cc: LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall From: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> Date: Thu, 14 Jan 2016 18:04:17 +0100 Return constant integer values without storing them in the local variable "status". Signed-off-by: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> --- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c index 5f2a34a..d87985b 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c @@ -1121,15 +1121,12 @@ ctx_err: int ocrdma_resize_cq(struct ib_cq *ibcq, int new_cnt, struct ib_udata *udata) { - int status = 0; struct ocrdma_cq *cq = get_ocrdma_cq(ibcq); - if (new_cnt < 1 || new_cnt > cq->max_hw_cqe) { - status = -EINVAL; - return status; - } + if (new_cnt < 1 || new_cnt > cq->max_hw_cqe) + return -EINVAL; ibcq->cqe = new_cnt; - return status; + return 0; } static void ocrdma_flush_cq(struct ocrdma_cq *cq) -- 2.6.3 -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH v3 5/6] InfiniBand-ocrdma: Returning only value constants in ocrdma_resize_cq() @ 2016-01-14 17:50 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-14 17:50 UTC (permalink / raw) To: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier Cc: LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Thu, 14 Jan 2016 18:04:17 +0100 Return constant integer values without storing them in the local variable "status". Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c index 5f2a34a..d87985b 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c @@ -1121,15 +1121,12 @@ ctx_err: int ocrdma_resize_cq(struct ib_cq *ibcq, int new_cnt, struct ib_udata *udata) { - int status = 0; struct ocrdma_cq *cq = get_ocrdma_cq(ibcq); - if (new_cnt < 1 || new_cnt > cq->max_hw_cqe) { - status = -EINVAL; - return status; - } + if (new_cnt < 1 || new_cnt > cq->max_hw_cqe) + return -EINVAL; ibcq->cqe = new_cnt; - return status; + return 0; } static void ocrdma_flush_cq(struct ocrdma_cq *cq) -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH v3 5/6] InfiniBand-ocrdma: Returning only value constants in ocrdma_resize_cq() @ 2016-01-14 17:50 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-14 17:50 UTC (permalink / raw) To: linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Thu, 14 Jan 2016 18:04:17 +0100 Return constant integer values without storing them in the local variable "status". Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c index 5f2a34a..d87985b 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c @@ -1121,15 +1121,12 @@ ctx_err: int ocrdma_resize_cq(struct ib_cq *ibcq, int new_cnt, struct ib_udata *udata) { - int status = 0; struct ocrdma_cq *cq = get_ocrdma_cq(ibcq); - if (new_cnt < 1 || new_cnt > cq->max_hw_cqe) { - status = -EINVAL; - return status; - } + if (new_cnt < 1 || new_cnt > cq->max_hw_cqe) + return -EINVAL; ibcq->cqe = new_cnt; - return status; + return 0; } static void ocrdma_flush_cq(struct ocrdma_cq *cq) -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH v3 2/6] InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions 2016-01-14 17:18 ` SF Markus Elfring @ 2016-01-14 17:43 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-14 17:43 UTC (permalink / raw) To: linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Thu, 14 Jan 2016 17:47:59 +0100 The variable "status" will 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/infiniband/hw/ocrdma/ocrdma_ah.c | 2 +- drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 4 ++-- drivers/infiniband/hw/ocrdma/ocrdma_stats.c | 4 ++-- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 12 ++++++------ 4 files changed, 11 insertions(+), 11 deletions(-) diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_ah.c b/drivers/infiniband/hw/ocrdma/ocrdma_ah.c index a343e03..41f0171 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_ah.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_ah.c @@ -59,7 +59,7 @@ static inline int set_av_attr(struct ocrdma_dev *dev, struct ocrdma_ah *ah, struct ib_ah_attr *attr, union ib_gid *sgid, int pdid, bool *isvlan, u16 vlan_tag) { - int status = 0; + int status; struct ocrdma_eth_vlan eth; struct ocrdma_grh grh; int eth_sz; diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c index 283ca84..159b1d5 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c @@ -1113,7 +1113,7 @@ mbx_err: static int ocrdma_nonemb_mbx_cmd(struct ocrdma_dev *dev, struct ocrdma_mqe *mqe, void *payload_va) { - int status = 0; + int status; struct ocrdma_mbx_rsp *rsp = payload_va; if ((mqe->hdr.spcl_sge_cnt_emb & OCRDMA_MQE_HDR_EMB_MASK) >> @@ -2871,7 +2871,7 @@ int ocrdma_mbx_destroy_srq(struct ocrdma_dev *dev, struct ocrdma_srq *srq) static int ocrdma_mbx_get_dcbx_config(struct ocrdma_dev *dev, u32 ptype, struct ocrdma_dcbx_cfg *dcbxcfg) { - int status = 0; + int status; dma_addr_t pa; struct ocrdma_mqe cmd; diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_stats.c b/drivers/infiniband/hw/ocrdma/ocrdma_stats.c index 86c303a..119baa3 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_stats.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_stats.c @@ -608,7 +608,7 @@ static char *ocrdma_driver_dbg_stats(struct ocrdma_dev *dev) static void ocrdma_update_stats(struct ocrdma_dev *dev) { ulong now = jiffies, secs; - int status = 0; + int status; struct ocrdma_rdma_stats_resp *rdma_stats = (struct ocrdma_rdma_stats_resp *)dev->stats_mem.va; struct ocrdma_rsrc_stats *rsrc_stats = &rdma_stats->act_rsrc_stats; @@ -639,7 +639,7 @@ static ssize_t ocrdma_dbgfs_ops_write(struct file *filp, { char tmp_str[32]; long reset; - int status = 0; + int status; struct ocrdma_stats *pstats = filp->private_data; struct ocrdma_dev *dev = pstats->dev; diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c index 4caf167..1d90d18 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c @@ -419,7 +419,7 @@ static struct ocrdma_pd *_ocrdma_alloc_pd(struct ocrdma_dev *dev, struct ib_udata *udata) { struct ocrdma_pd *pd = NULL; - int status = 0; + int status; pd = kzalloc(sizeof(*pd), GFP_KERNEL); if (!pd) @@ -468,7 +468,7 @@ static inline int is_ucontext_pd(struct ocrdma_ucontext *uctx, static int _ocrdma_dealloc_pd(struct ocrdma_dev *dev, struct ocrdma_pd *pd) { - int status = 0; + int status; if (dev->pd_mgr->pd_prealloc_valid) status = ocrdma_put_pd_num(dev, pd->id, pd->dpp_enabled); @@ -593,7 +593,7 @@ map_err: int ocrdma_dealloc_ucontext(struct ib_ucontext *ibctx) { - int status = 0; + int status; struct ocrdma_mm *mm, *tmp; struct ocrdma_ucontext *uctx = get_ocrdma_ucontext(ibctx); struct ocrdma_dev *dev = get_ocrdma_dev(ibctx->device); @@ -620,7 +620,7 @@ int ocrdma_mmap(struct ib_ucontext *context, struct vm_area_struct *vma) unsigned long vm_page = vma->vm_pgoff << PAGE_SHIFT; u64 unmapped_db = (u64) dev->nic_info.unmapped_db; unsigned long len = (vma->vm_end - vma->vm_start); - int status = 0; + int status; bool found; if (vma->vm_start & (PAGE_SIZE - 1)) @@ -1283,7 +1283,7 @@ static int ocrdma_copy_qp_uresp(struct ocrdma_qp *qp, struct ib_udata *udata, int dpp_offset, int dpp_credit_lmt, int srq) { - int status = 0; + int status; u64 usr_db; struct ocrdma_create_qp_uresp uresp; struct ocrdma_pd *pd = qp->pd; @@ -1947,7 +1947,7 @@ int ocrdma_modify_srq(struct ib_srq *ibsrq, enum ib_srq_attr_mask srq_attr_mask, struct ib_udata *udata) { - int status = 0; + int status; struct ocrdma_srq *srq; srq = get_ocrdma_srq(ibsrq); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH v3 2/6] InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions @ 2016-01-14 17:43 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-14 17:43 UTC (permalink / raw) To: linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Thu, 14 Jan 2016 17:47:59 +0100 The variable "status" will 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/infiniband/hw/ocrdma/ocrdma_ah.c | 2 +- drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 4 ++-- drivers/infiniband/hw/ocrdma/ocrdma_stats.c | 4 ++-- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 12 ++++++------ 4 files changed, 11 insertions(+), 11 deletions(-) diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_ah.c b/drivers/infiniband/hw/ocrdma/ocrdma_ah.c index a343e03..41f0171 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_ah.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_ah.c @@ -59,7 +59,7 @@ static inline int set_av_attr(struct ocrdma_dev *dev, struct ocrdma_ah *ah, struct ib_ah_attr *attr, union ib_gid *sgid, int pdid, bool *isvlan, u16 vlan_tag) { - int status = 0; + int status; struct ocrdma_eth_vlan eth; struct ocrdma_grh grh; int eth_sz; diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c index 283ca84..159b1d5 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c @@ -1113,7 +1113,7 @@ mbx_err: static int ocrdma_nonemb_mbx_cmd(struct ocrdma_dev *dev, struct ocrdma_mqe *mqe, void *payload_va) { - int status = 0; + int status; struct ocrdma_mbx_rsp *rsp = payload_va; if ((mqe->hdr.spcl_sge_cnt_emb & OCRDMA_MQE_HDR_EMB_MASK) >> @@ -2871,7 +2871,7 @@ int ocrdma_mbx_destroy_srq(struct ocrdma_dev *dev, struct ocrdma_srq *srq) static int ocrdma_mbx_get_dcbx_config(struct ocrdma_dev *dev, u32 ptype, struct ocrdma_dcbx_cfg *dcbxcfg) { - int status = 0; + int status; dma_addr_t pa; struct ocrdma_mqe cmd; diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_stats.c b/drivers/infiniband/hw/ocrdma/ocrdma_stats.c index 86c303a..119baa3 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_stats.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_stats.c @@ -608,7 +608,7 @@ static char *ocrdma_driver_dbg_stats(struct ocrdma_dev *dev) static void ocrdma_update_stats(struct ocrdma_dev *dev) { ulong now = jiffies, secs; - int status = 0; + int status; struct ocrdma_rdma_stats_resp *rdma_stats (struct ocrdma_rdma_stats_resp *)dev->stats_mem.va; struct ocrdma_rsrc_stats *rsrc_stats = &rdma_stats->act_rsrc_stats; @@ -639,7 +639,7 @@ static ssize_t ocrdma_dbgfs_ops_write(struct file *filp, { char tmp_str[32]; long reset; - int status = 0; + int status; struct ocrdma_stats *pstats = filp->private_data; struct ocrdma_dev *dev = pstats->dev; diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c index 4caf167..1d90d18 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c @@ -419,7 +419,7 @@ static struct ocrdma_pd *_ocrdma_alloc_pd(struct ocrdma_dev *dev, struct ib_udata *udata) { struct ocrdma_pd *pd = NULL; - int status = 0; + int status; pd = kzalloc(sizeof(*pd), GFP_KERNEL); if (!pd) @@ -468,7 +468,7 @@ static inline int is_ucontext_pd(struct ocrdma_ucontext *uctx, static int _ocrdma_dealloc_pd(struct ocrdma_dev *dev, struct ocrdma_pd *pd) { - int status = 0; + int status; if (dev->pd_mgr->pd_prealloc_valid) status = ocrdma_put_pd_num(dev, pd->id, pd->dpp_enabled); @@ -593,7 +593,7 @@ map_err: int ocrdma_dealloc_ucontext(struct ib_ucontext *ibctx) { - int status = 0; + int status; struct ocrdma_mm *mm, *tmp; struct ocrdma_ucontext *uctx = get_ocrdma_ucontext(ibctx); struct ocrdma_dev *dev = get_ocrdma_dev(ibctx->device); @@ -620,7 +620,7 @@ int ocrdma_mmap(struct ib_ucontext *context, struct vm_area_struct *vma) unsigned long vm_page = vma->vm_pgoff << PAGE_SHIFT; u64 unmapped_db = (u64) dev->nic_info.unmapped_db; unsigned long len = (vma->vm_end - vma->vm_start); - int status = 0; + int status; bool found; if (vma->vm_start & (PAGE_SIZE - 1)) @@ -1283,7 +1283,7 @@ static int ocrdma_copy_qp_uresp(struct ocrdma_qp *qp, struct ib_udata *udata, int dpp_offset, int dpp_credit_lmt, int srq) { - int status = 0; + int status; u64 usr_db; struct ocrdma_create_qp_uresp uresp; struct ocrdma_pd *pd = qp->pd; @@ -1947,7 +1947,7 @@ int ocrdma_modify_srq(struct ib_srq *ibsrq, enum ib_srq_attr_mask srq_attr_mask, struct ib_udata *udata) { - int status = 0; + int status; struct ocrdma_srq *srq; srq = get_ocrdma_srq(ibsrq); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH v3 2/6] InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions 2016-01-14 17:43 ` SF Markus Elfring @ 2016-01-15 13:20 ` Leon Romanovsky -1 siblings, 0 replies; 3089+ messages in thread From: Leon Romanovsky @ 2016-01-15 13:20 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier, LKML, kernel-janitors, Julia Lawall On Thu, Jan 14, 2016 at 06:43:13PM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Thu, 14 Jan 2016 17:47:59 +0100 > > The variable "status" will be set to an appropriate value a bit later. > Thus omit the explicit initialisation at the beginning. What did you try to achieve by this patch? > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/infiniband/hw/ocrdma/ocrdma_ah.c | 2 +- > drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 4 ++-- > drivers/infiniband/hw/ocrdma/ocrdma_stats.c | 4 ++-- > drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 12 ++++++------ > 4 files changed, 11 insertions(+), 11 deletions(-) > > diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_ah.c b/drivers/infiniband/hw/ocrdma/ocrdma_ah.c > index a343e03..41f0171 100644 > --- a/drivers/infiniband/hw/ocrdma/ocrdma_ah.c > +++ b/drivers/infiniband/hw/ocrdma/ocrdma_ah.c > @@ -59,7 +59,7 @@ static inline int set_av_attr(struct ocrdma_dev *dev, struct ocrdma_ah *ah, > struct ib_ah_attr *attr, union ib_gid *sgid, > int pdid, bool *isvlan, u16 vlan_tag) > { > - int status = 0; > + int status; > struct ocrdma_eth_vlan eth; > struct ocrdma_grh grh; > int eth_sz; > diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c > index 283ca84..159b1d5 100644 > --- a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c > +++ b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c > @@ -1113,7 +1113,7 @@ mbx_err: > static int ocrdma_nonemb_mbx_cmd(struct ocrdma_dev *dev, struct ocrdma_mqe *mqe, > void *payload_va) > { > - int status = 0; > + int status; > struct ocrdma_mbx_rsp *rsp = payload_va; > > if ((mqe->hdr.spcl_sge_cnt_emb & OCRDMA_MQE_HDR_EMB_MASK) >> > @@ -2871,7 +2871,7 @@ int ocrdma_mbx_destroy_srq(struct ocrdma_dev *dev, struct ocrdma_srq *srq) > static int ocrdma_mbx_get_dcbx_config(struct ocrdma_dev *dev, u32 ptype, > struct ocrdma_dcbx_cfg *dcbxcfg) > { > - int status = 0; > + int status; > dma_addr_t pa; > struct ocrdma_mqe cmd; > > diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_stats.c b/drivers/infiniband/hw/ocrdma/ocrdma_stats.c > index 86c303a..119baa3 100644 > --- a/drivers/infiniband/hw/ocrdma/ocrdma_stats.c > +++ b/drivers/infiniband/hw/ocrdma/ocrdma_stats.c > @@ -608,7 +608,7 @@ static char *ocrdma_driver_dbg_stats(struct ocrdma_dev *dev) > static void ocrdma_update_stats(struct ocrdma_dev *dev) > { > ulong now = jiffies, secs; > - int status = 0; > + int status; > struct ocrdma_rdma_stats_resp *rdma_stats = > (struct ocrdma_rdma_stats_resp *)dev->stats_mem.va; > struct ocrdma_rsrc_stats *rsrc_stats = &rdma_stats->act_rsrc_stats; > @@ -639,7 +639,7 @@ static ssize_t ocrdma_dbgfs_ops_write(struct file *filp, > { > char tmp_str[32]; > long reset; > - int status = 0; > + int status; > struct ocrdma_stats *pstats = filp->private_data; > struct ocrdma_dev *dev = pstats->dev; > > diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c > index 4caf167..1d90d18 100644 > --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c > +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c > @@ -419,7 +419,7 @@ static struct ocrdma_pd *_ocrdma_alloc_pd(struct ocrdma_dev *dev, > struct ib_udata *udata) > { > struct ocrdma_pd *pd = NULL; > - int status = 0; > + int status; > > pd = kzalloc(sizeof(*pd), GFP_KERNEL); > if (!pd) > @@ -468,7 +468,7 @@ static inline int is_ucontext_pd(struct ocrdma_ucontext *uctx, > static int _ocrdma_dealloc_pd(struct ocrdma_dev *dev, > struct ocrdma_pd *pd) > { > - int status = 0; > + int status; > > if (dev->pd_mgr->pd_prealloc_valid) > status = ocrdma_put_pd_num(dev, pd->id, pd->dpp_enabled); > @@ -593,7 +593,7 @@ map_err: > > int ocrdma_dealloc_ucontext(struct ib_ucontext *ibctx) > { > - int status = 0; > + int status; > struct ocrdma_mm *mm, *tmp; > struct ocrdma_ucontext *uctx = get_ocrdma_ucontext(ibctx); > struct ocrdma_dev *dev = get_ocrdma_dev(ibctx->device); > @@ -620,7 +620,7 @@ int ocrdma_mmap(struct ib_ucontext *context, struct vm_area_struct *vma) > unsigned long vm_page = vma->vm_pgoff << PAGE_SHIFT; > u64 unmapped_db = (u64) dev->nic_info.unmapped_db; > unsigned long len = (vma->vm_end - vma->vm_start); > - int status = 0; > + int status; > bool found; > > if (vma->vm_start & (PAGE_SIZE - 1)) > @@ -1283,7 +1283,7 @@ static int ocrdma_copy_qp_uresp(struct ocrdma_qp *qp, > struct ib_udata *udata, int dpp_offset, > int dpp_credit_lmt, int srq) > { > - int status = 0; > + int status; > u64 usr_db; > struct ocrdma_create_qp_uresp uresp; > struct ocrdma_pd *pd = qp->pd; > @@ -1947,7 +1947,7 @@ int ocrdma_modify_srq(struct ib_srq *ibsrq, > enum ib_srq_attr_mask srq_attr_mask, > struct ib_udata *udata) > { > - int status = 0; > + int status; > struct ocrdma_srq *srq; > > srq = get_ocrdma_srq(ibsrq); > -- > 2.6.3 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH v3 2/6] InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions @ 2016-01-15 13:20 ` Leon Romanovsky 0 siblings, 0 replies; 3089+ messages in thread From: Leon Romanovsky @ 2016-01-15 13:20 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier, LKML, kernel-janitors, Julia Lawall On Thu, Jan 14, 2016 at 06:43:13PM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Thu, 14 Jan 2016 17:47:59 +0100 > > The variable "status" will be set to an appropriate value a bit later. > Thus omit the explicit initialisation at the beginning. What did you try to achieve by this patch? > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/infiniband/hw/ocrdma/ocrdma_ah.c | 2 +- > drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 4 ++-- > drivers/infiniband/hw/ocrdma/ocrdma_stats.c | 4 ++-- > drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 12 ++++++------ > 4 files changed, 11 insertions(+), 11 deletions(-) > > diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_ah.c b/drivers/infiniband/hw/ocrdma/ocrdma_ah.c > index a343e03..41f0171 100644 > --- a/drivers/infiniband/hw/ocrdma/ocrdma_ah.c > +++ b/drivers/infiniband/hw/ocrdma/ocrdma_ah.c > @@ -59,7 +59,7 @@ static inline int set_av_attr(struct ocrdma_dev *dev, struct ocrdma_ah *ah, > struct ib_ah_attr *attr, union ib_gid *sgid, > int pdid, bool *isvlan, u16 vlan_tag) > { > - int status = 0; > + int status; > struct ocrdma_eth_vlan eth; > struct ocrdma_grh grh; > int eth_sz; > diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c > index 283ca84..159b1d5 100644 > --- a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c > +++ b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c > @@ -1113,7 +1113,7 @@ mbx_err: > static int ocrdma_nonemb_mbx_cmd(struct ocrdma_dev *dev, struct ocrdma_mqe *mqe, > void *payload_va) > { > - int status = 0; > + int status; > struct ocrdma_mbx_rsp *rsp = payload_va; > > if ((mqe->hdr.spcl_sge_cnt_emb & OCRDMA_MQE_HDR_EMB_MASK) >> > @@ -2871,7 +2871,7 @@ int ocrdma_mbx_destroy_srq(struct ocrdma_dev *dev, struct ocrdma_srq *srq) > static int ocrdma_mbx_get_dcbx_config(struct ocrdma_dev *dev, u32 ptype, > struct ocrdma_dcbx_cfg *dcbxcfg) > { > - int status = 0; > + int status; > dma_addr_t pa; > struct ocrdma_mqe cmd; > > diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_stats.c b/drivers/infiniband/hw/ocrdma/ocrdma_stats.c > index 86c303a..119baa3 100644 > --- a/drivers/infiniband/hw/ocrdma/ocrdma_stats.c > +++ b/drivers/infiniband/hw/ocrdma/ocrdma_stats.c > @@ -608,7 +608,7 @@ static char *ocrdma_driver_dbg_stats(struct ocrdma_dev *dev) > static void ocrdma_update_stats(struct ocrdma_dev *dev) > { > ulong now = jiffies, secs; > - int status = 0; > + int status; > struct ocrdma_rdma_stats_resp *rdma_stats > (struct ocrdma_rdma_stats_resp *)dev->stats_mem.va; > struct ocrdma_rsrc_stats *rsrc_stats = &rdma_stats->act_rsrc_stats; > @@ -639,7 +639,7 @@ static ssize_t ocrdma_dbgfs_ops_write(struct file *filp, > { > char tmp_str[32]; > long reset; > - int status = 0; > + int status; > struct ocrdma_stats *pstats = filp->private_data; > struct ocrdma_dev *dev = pstats->dev; > > diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c > index 4caf167..1d90d18 100644 > --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c > +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c > @@ -419,7 +419,7 @@ static struct ocrdma_pd *_ocrdma_alloc_pd(struct ocrdma_dev *dev, > struct ib_udata *udata) > { > struct ocrdma_pd *pd = NULL; > - int status = 0; > + int status; > > pd = kzalloc(sizeof(*pd), GFP_KERNEL); > if (!pd) > @@ -468,7 +468,7 @@ static inline int is_ucontext_pd(struct ocrdma_ucontext *uctx, > static int _ocrdma_dealloc_pd(struct ocrdma_dev *dev, > struct ocrdma_pd *pd) > { > - int status = 0; > + int status; > > if (dev->pd_mgr->pd_prealloc_valid) > status = ocrdma_put_pd_num(dev, pd->id, pd->dpp_enabled); > @@ -593,7 +593,7 @@ map_err: > > int ocrdma_dealloc_ucontext(struct ib_ucontext *ibctx) > { > - int status = 0; > + int status; > struct ocrdma_mm *mm, *tmp; > struct ocrdma_ucontext *uctx = get_ocrdma_ucontext(ibctx); > struct ocrdma_dev *dev = get_ocrdma_dev(ibctx->device); > @@ -620,7 +620,7 @@ int ocrdma_mmap(struct ib_ucontext *context, struct vm_area_struct *vma) > unsigned long vm_page = vma->vm_pgoff << PAGE_SHIFT; > u64 unmapped_db = (u64) dev->nic_info.unmapped_db; > unsigned long len = (vma->vm_end - vma->vm_start); > - int status = 0; > + int status; > bool found; > > if (vma->vm_start & (PAGE_SIZE - 1)) > @@ -1283,7 +1283,7 @@ static int ocrdma_copy_qp_uresp(struct ocrdma_qp *qp, > struct ib_udata *udata, int dpp_offset, > int dpp_credit_lmt, int srq) > { > - int status = 0; > + int status; > u64 usr_db; > struct ocrdma_create_qp_uresp uresp; > struct ocrdma_pd *pd = qp->pd; > @@ -1947,7 +1947,7 @@ int ocrdma_modify_srq(struct ib_srq *ibsrq, > enum ib_srq_attr_mask srq_attr_mask, > struct ib_udata *udata) > { > - int status = 0; > + int status; > struct ocrdma_srq *srq; > > srq = get_ocrdma_srq(ibsrq); > -- > 2.6.3 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
[parent not found: <20160115132014.GC30615-2ukJVAZIZ/Y@public.gmane.org>]
* Re: InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions 2016-01-15 13:20 ` Leon Romanovsky (?) @ 2016-01-15 14:50 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-15 14:50 UTC (permalink / raw) To: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Leon Romanovsky Cc: Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier, LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall >> The variable "status" will be set to an appropriate value a bit later. >> Thus omit the explicit initialisation at the beginning. > > What did you try to achieve by this patch? I would like to optimise the affected source files a bit. Would you like to clarify any measurable effects around the implementation detail when various variables will only be initialised immediately before they will be read again? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions @ 2016-01-15 14:50 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-15 14:50 UTC (permalink / raw) To: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Leon Romanovsky Cc: Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier, LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall >> The variable "status" will be set to an appropriate value a bit later. >> Thus omit the explicit initialisation at the beginning. > > What did you try to achieve by this patch? I would like to optimise the affected source files a bit. Would you like to clarify any measurable effects around the implementation detail when various variables will only be initialised immediately before they will be read again? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions @ 2016-01-15 14:50 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-15 14:50 UTC (permalink / raw) To: linux-rdma, Leon Romanovsky Cc: Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier, LKML, kernel-janitors, Julia Lawall >> The variable "status" will be set to an appropriate value a bit later. >> Thus omit the explicit initialisation at the beginning. > > What did you try to achieve by this patch? I would like to optimise the affected source files a bit. Would you like to clarify any measurable effects around the implementation detail when various variables will only be initialised immediately before they will be read again? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
[parent not found: <56990733.7000506-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>]
* Re: InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions 2016-01-15 14:50 ` SF Markus Elfring (?) @ 2016-01-15 15:09 ` Leon Romanovsky -1 siblings, 0 replies; 3089+ messages in thread From: Leon Romanovsky @ 2016-01-15 15:09 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier, LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall On Fri, Jan 15, 2016 at 03:50:27PM +0100, SF Markus Elfring wrote: > >> The variable "status" will be set to an appropriate value a bit later. > >> Thus omit the explicit initialisation at the beginning. > > > > What did you try to achieve by this patch? > > I would like to optimise the affected source files a bit. > Would you like to clarify any measurable effects around the implementation > detail when various variables will only be initialised immediately > before they will be read again? Compiler will drop this variable initialization by itself because there are no reads between this variable initialization and write. I recommend you to take a look on the assembly code and ensure it by yourself. The proposed change won't affect performance at all. > > Regards, > Markus -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions @ 2016-01-15 15:09 ` Leon Romanovsky 0 siblings, 0 replies; 3089+ messages in thread From: Leon Romanovsky @ 2016-01-15 15:09 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier, LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall On Fri, Jan 15, 2016 at 03:50:27PM +0100, SF Markus Elfring wrote: > >> The variable "status" will be set to an appropriate value a bit later. > >> Thus omit the explicit initialisation at the beginning. > > > > What did you try to achieve by this patch? > > I would like to optimise the affected source files a bit. > Would you like to clarify any measurable effects around the implementation > detail when various variables will only be initialised immediately > before they will be read again? Compiler will drop this variable initialization by itself because there are no reads between this variable initialization and write. I recommend you to take a look on the assembly code and ensure it by yourself. The proposed change won't affect performance at all. > > Regards, > Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions @ 2016-01-15 15:09 ` Leon Romanovsky 0 siblings, 0 replies; 3089+ messages in thread From: Leon Romanovsky @ 2016-01-15 15:09 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier, LKML, kernel-janitors, Julia Lawall On Fri, Jan 15, 2016 at 03:50:27PM +0100, SF Markus Elfring wrote: > >> The variable "status" will be set to an appropriate value a bit later. > >> Thus omit the explicit initialisation at the beginning. > > > > What did you try to achieve by this patch? > > I would like to optimise the affected source files a bit. > Would you like to clarify any measurable effects around the implementation > detail when various variables will only be initialised immediately > before they will be read again? Compiler will drop this variable initialization by itself because there are no reads between this variable initialization and write. I recommend you to take a look on the assembly code and ensure it by yourself. The proposed change won't affect performance at all. > > Regards, > Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
[parent not found: <20160115150935.GA32346-2ukJVAZIZ/Y@public.gmane.org>]
* Re: InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions 2016-01-15 15:09 ` Leon Romanovsky (?) @ 2016-01-15 15:26 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-15 15:26 UTC (permalink / raw) To: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Leon Romanovsky Cc: Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier, LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall >> Would you like to clarify any measurable effects around the implementation >> detail when various variables will only be initialised immediately >> before they will be read again? > > Compiler will drop this variable initialization by itself because > there are no reads between this variable initialization and write. Which compiler variants would you to take into account for such an use case? > I recommend you to take a look on the assembly code and ensure it > by yourself. Will any configuration parameters and command arguments become relevant to improve also a corresponding software comparison? > The proposed change won't affect performance at all. Will unneeded variable assignments be really optimised away by default? By the way: Will a small source code reduction matter also a bit here? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions @ 2016-01-15 15:26 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-15 15:26 UTC (permalink / raw) To: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Leon Romanovsky Cc: Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier, LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall >> Would you like to clarify any measurable effects around the implementation >> detail when various variables will only be initialised immediately >> before they will be read again? > > Compiler will drop this variable initialization by itself because > there are no reads between this variable initialization and write. Which compiler variants would you to take into account for such an use case? > I recommend you to take a look on the assembly code and ensure it > by yourself. Will any configuration parameters and command arguments become relevant to improve also a corresponding software comparison? > The proposed change won't affect performance at all. Will unneeded variable assignments be really optimised away by default? By the way: Will a small source code reduction matter also a bit here? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions @ 2016-01-15 15:26 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-15 15:26 UTC (permalink / raw) To: linux-rdma, Leon Romanovsky Cc: Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier, LKML, kernel-janitors, Julia Lawall >> Would you like to clarify any measurable effects around the implementation >> detail when various variables will only be initialised immediately >> before they will be read again? > > Compiler will drop this variable initialization by itself because > there are no reads between this variable initialization and write. Which compiler variants would you to take into account for such an use case? > I recommend you to take a look on the assembly code and ensure it > by yourself. Will any configuration parameters and command arguments become relevant to improve also a corresponding software comparison? > The proposed change won't affect performance at all. Will unneeded variable assignments be really optimised away by default? By the way: Will a small source code reduction matter also a bit here? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
[parent not found: <56990FAC.6000506-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>]
* Re: InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions 2016-01-15 15:26 ` SF Markus Elfring (?) @ 2016-01-15 15:59 ` Leon Romanovsky -1 siblings, 0 replies; 3089+ messages in thread From: Leon Romanovsky @ 2016-01-15 15:59 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier, LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall On Fri, Jan 15, 2016 at 04:26:36PM +0100, SF Markus Elfring wrote: > >> Would you like to clarify any measurable effects around the implementation > >> detail when various variables will only be initialised immediately > >> before they will be read again? > > > > Compiler will drop this variable initialization by itself because > > there are no reads between this variable initialization and write. > > Which compiler variants would you to take into account for such an use case? GCC supported it before 1999 when I saw it first time. My assumption that in 2016 all compilers are doing such optimization now. I would be glad to hear an example of modern compiler which doesn't support this simple optimization. > > > > I recommend you to take a look on the assembly code and ensure it > > by yourself. > > Will any configuration parameters and command arguments become relevant > to improve also a corresponding software comparison? Please suggest us, you are proposing this change, and not me. > > > > The proposed change won't affect performance at all. > > Will unneeded variable assignments be really optimised away by default? Yes > > > By the way: > Will a small source code reduction matter also a bit here? If you are interested in saving space of one latter, you need to take into account git database increase, do you? > > Regards, > Markus -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions @ 2016-01-15 15:59 ` Leon Romanovsky 0 siblings, 0 replies; 3089+ messages in thread From: Leon Romanovsky @ 2016-01-15 15:59 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier, LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall On Fri, Jan 15, 2016 at 04:26:36PM +0100, SF Markus Elfring wrote: > >> Would you like to clarify any measurable effects around the implementation > >> detail when various variables will only be initialised immediately > >> before they will be read again? > > > > Compiler will drop this variable initialization by itself because > > there are no reads between this variable initialization and write. > > Which compiler variants would you to take into account for such an use case? GCC supported it before 1999 when I saw it first time. My assumption that in 2016 all compilers are doing such optimization now. I would be glad to hear an example of modern compiler which doesn't support this simple optimization. > > > > I recommend you to take a look on the assembly code and ensure it > > by yourself. > > Will any configuration parameters and command arguments become relevant > to improve also a corresponding software comparison? Please suggest us, you are proposing this change, and not me. > > > > The proposed change won't affect performance at all. > > Will unneeded variable assignments be really optimised away by default? Yes > > > By the way: > Will a small source code reduction matter also a bit here? If you are interested in saving space of one latter, you need to take into account git database increase, do you? > > Regards, > Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions @ 2016-01-15 15:59 ` Leon Romanovsky 0 siblings, 0 replies; 3089+ messages in thread From: Leon Romanovsky @ 2016-01-15 15:59 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier, LKML, kernel-janitors, Julia Lawall On Fri, Jan 15, 2016 at 04:26:36PM +0100, SF Markus Elfring wrote: > >> Would you like to clarify any measurable effects around the implementation > >> detail when various variables will only be initialised immediately > >> before they will be read again? > > > > Compiler will drop this variable initialization by itself because > > there are no reads between this variable initialization and write. > > Which compiler variants would you to take into account for such an use case? GCC supported it before 1999 when I saw it first time. My assumption that in 2016 all compilers are doing such optimization now. I would be glad to hear an example of modern compiler which doesn't support this simple optimization. > > > > I recommend you to take a look on the assembly code and ensure it > > by yourself. > > Will any configuration parameters and command arguments become relevant > to improve also a corresponding software comparison? Please suggest us, you are proposing this change, and not me. > > > > The proposed change won't affect performance at all. > > Will unneeded variable assignments be really optimised away by default? Yes > > > By the way: > Will a small source code reduction matter also a bit here? If you are interested in saving space of one latter, you need to take into account git database increase, do you? > > Regards, > Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
[parent not found: <20160115155938.GB32346-2ukJVAZIZ/Y@public.gmane.org>]
* Re: InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions 2016-01-15 15:59 ` Leon Romanovsky (?) @ 2016-01-15 16:10 ` Dan Carpenter -1 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2016-01-15 16:10 UTC (permalink / raw) To: SF Markus Elfring, linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier, LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall Doing bogus initializations turns off GCC's checking for uninitialized variables so it's a bad habbit. On the other hand, GCC's checking is not perfect and it sometimes misses bugs so these patches have to be reviewed manually which is maybe too much work to be worthwhile. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions @ 2016-01-15 16:10 ` Dan Carpenter 0 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2016-01-15 16:10 UTC (permalink / raw) To: SF Markus Elfring, linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier, LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall Doing bogus initializations turns off GCC's checking for uninitialized variables so it's a bad habbit. On the other hand, GCC's checking is not perfect and it sometimes misses bugs so these patches have to be reviewed manually which is maybe too much work to be worthwhile. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions @ 2016-01-15 16:10 ` Dan Carpenter 0 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2016-01-15 16:10 UTC (permalink / raw) To: SF Markus Elfring, linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier, LKML, kernel-janitors, Julia Lawall Doing bogus initializations turns off GCC's checking for uninitialized variables so it's a bad habbit. On the other hand, GCC's checking is not perfect and it sometimes misses bugs so these patches have to be reviewed manually which is maybe too much work to be worthwhile. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions 2016-01-15 15:59 ` Leon Romanovsky (?) @ 2016-01-15 16:24 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-15 16:24 UTC (permalink / raw) To: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Leon Romanovsky Cc: Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier, LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall > GCC supported it before 1999 when I saw it first time. My assumption > that in 2016 all compilers are doing such optimization now. Interesting … > I would be glad to hear an example of modern compiler which doesn't > support this simple optimization. Would you like to take into account any other source code analysis approaches? >> Will any configuration parameters and command arguments become relevant >> to improve also a corresponding software comparison? > > Please suggest us, you are proposing this change, and not me. Which combination of hardware and software versions would you find representative for a corresponding system check? >>> The proposed change won't affect performance at all. >> >> Will unneeded variable assignments be really optimised away by default? > > Yes Can it be that this result will depend on special parameters so that data flow analysis and optimisation will be performed in the way you seem to expect? > If you are interested in saving space of one latter, you need to take into > account git database increase, do you? There are also other aspects to consider: * Do you insist to initialise a return code at the beginning of every function with a non-void return type? * Does each bit of extra information can result also in unwanted consequences? * Is this a specific source code review concern? * Can this software be improved a bit more only if we dare to talk about potential update candidates? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions @ 2016-01-15 16:24 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-15 16:24 UTC (permalink / raw) To: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Leon Romanovsky Cc: Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier, LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall > GCC supported it before 1999 when I saw it first time. My assumption > that in 2016 all compilers are doing such optimization now. Interesting … > I would be glad to hear an example of modern compiler which doesn't > support this simple optimization. Would you like to take into account any other source code analysis approaches? >> Will any configuration parameters and command arguments become relevant >> to improve also a corresponding software comparison? > > Please suggest us, you are proposing this change, and not me. Which combination of hardware and software versions would you find representative for a corresponding system check? >>> The proposed change won't affect performance at all. >> >> Will unneeded variable assignments be really optimised away by default? > > Yes Can it be that this result will depend on special parameters so that data flow analysis and optimisation will be performed in the way you seem to expect? > If you are interested in saving space of one latter, you need to take into > account git database increase, do you? There are also other aspects to consider: * Do you insist to initialise a return code at the beginning of every function with a non-void return type? * Does each bit of extra information can result also in unwanted consequences? * Is this a specific source code review concern? * Can this software be improved a bit more only if we dare to talk about potential update candidates? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions @ 2016-01-15 16:24 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-15 16:24 UTC (permalink / raw) To: linux-rdma, Leon Romanovsky Cc: Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier, LKML, kernel-janitors, Julia Lawall > GCC supported it before 1999 when I saw it first time. My assumption > that in 2016 all compilers are doing such optimization now. Interesting … > I would be glad to hear an example of modern compiler which doesn't > support this simple optimization. Would you like to take into account any other source code analysis approaches? >> Will any configuration parameters and command arguments become relevant >> to improve also a corresponding software comparison? > > Please suggest us, you are proposing this change, and not me. Which combination of hardware and software versions would you find representative for a corresponding system check? >>> The proposed change won't affect performance at all. >> >> Will unneeded variable assignments be really optimised away by default? > > Yes Can it be that this result will depend on special parameters so that data flow analysis and optimisation will be performed in the way you seem to expect? > If you are interested in saving space of one latter, you need to take into > account git database increase, do you? There are also other aspects to consider: * Do you insist to initialise a return code at the beginning of every function with a non-void return type? * Does each bit of extra information can result also in unwanted consequences? * Is this a specific source code review concern? * Can this software be improved a bit more only if we dare to talk about potential update candidates? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
[parent not found: <56991D52.8030808-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>]
* Re: InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions 2016-01-15 16:24 ` SF Markus Elfring (?) @ 2016-01-15 17:00 ` Leon Romanovsky -1 siblings, 0 replies; 3089+ messages in thread From: Leon Romanovsky @ 2016-01-15 17:00 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier, LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall On Fri, Jan 15, 2016 at 05:24:50PM +0100, SF Markus Elfring wrote: Since, you didn't answer to my original question, I will repeat it again. [Q.] What did you try to achieve by this patch? P.S. This is mailing list for developers and not for patch bots. We are glad to see patches that clean the code, but they need to be meaningful. Your automated patches add noise without any real benefit. You was suggested to be ignored in MTD mailing list exactly for this type of patches, did you learn anything from that experience? -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions @ 2016-01-15 17:00 ` Leon Romanovsky 0 siblings, 0 replies; 3089+ messages in thread From: Leon Romanovsky @ 2016-01-15 17:00 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier, LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall On Fri, Jan 15, 2016 at 05:24:50PM +0100, SF Markus Elfring wrote: Since, you didn't answer to my original question, I will repeat it again. [Q.] What did you try to achieve by this patch? P.S. This is mailing list for developers and not for patch bots. We are glad to see patches that clean the code, but they need to be meaningful. Your automated patches add noise without any real benefit. You was suggested to be ignored in MTD mailing list exactly for this type of patches, did you learn anything from that experience? ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions @ 2016-01-15 17:00 ` Leon Romanovsky 0 siblings, 0 replies; 3089+ messages in thread From: Leon Romanovsky @ 2016-01-15 17:00 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier, LKML, kernel-janitors, Julia Lawall On Fri, Jan 15, 2016 at 05:24:50PM +0100, SF Markus Elfring wrote: Since, you didn't answer to my original question, I will repeat it again. [Q.] What did you try to achieve by this patch? P.S. This is mailing list for developers and not for patch bots. We are glad to see patches that clean the code, but they need to be meaningful. Your automated patches add noise without any real benefit. You was suggested to be ignored in MTD mailing list exactly for this type of patches, did you learn anything from that experience? ^ permalink raw reply [flat|nested] 3089+ messages in thread
[parent not found: <20160115170048.GC32346-2ukJVAZIZ/Y@public.gmane.org>]
* Re: InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions 2016-01-15 17:00 ` Leon Romanovsky (?) @ 2016-01-15 17:19 ` Bart Van Assche -1 siblings, 0 replies; 3089+ messages in thread From: Bart Van Assche @ 2016-01-15 17:19 UTC (permalink / raw) To: SF Markus Elfring, linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier, LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall On 01/15/2016 09:00 AM, Leon Romanovsky wrote: > On Fri, Jan 15, 2016 at 05:24:50PM +0100, SF Markus Elfring wrote: > > Since, you didn't answer to my original question, I will repeat it again. > [Q.] What did you try to achieve by this patch? Hello Leon, Have you noticed Dan's reply: "Doing bogus initializations turns off GCC's checking for uninitialized variables so it's a bad habit." Thanks, Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions @ 2016-01-15 17:19 ` Bart Van Assche 0 siblings, 0 replies; 3089+ messages in thread From: Bart Van Assche @ 2016-01-15 17:19 UTC (permalink / raw) To: SF Markus Elfring, linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier, LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall On 01/15/2016 09:00 AM, Leon Romanovsky wrote: > On Fri, Jan 15, 2016 at 05:24:50PM +0100, SF Markus Elfring wrote: > > Since, you didn't answer to my original question, I will repeat it again. > [Q.] What did you try to achieve by this patch? Hello Leon, Have you noticed Dan's reply: "Doing bogus initializations turns off GCC's checking for uninitialized variables so it's a bad habit." Thanks, Bart. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions @ 2016-01-15 17:19 ` Bart Van Assche 0 siblings, 0 replies; 3089+ messages in thread From: Bart Van Assche @ 2016-01-15 17:19 UTC (permalink / raw) To: SF Markus Elfring, linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier, LKML, kernel-janitors, Julia Lawall On 01/15/2016 09:00 AM, Leon Romanovsky wrote: > On Fri, Jan 15, 2016 at 05:24:50PM +0100, SF Markus Elfring wrote: > > Since, you didn't answer to my original question, I will repeat it again. > [Q.] What did you try to achieve by this patch? Hello Leon, Have you noticed Dan's reply: "Doing bogus initializations turns off GCC's checking for uninitialized variables so it's a bad habit." Thanks, Bart. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions 2016-01-15 17:19 ` Bart Van Assche @ 2016-01-15 17:41 ` Leon Romanovsky -1 siblings, 0 replies; 3089+ messages in thread From: Leon Romanovsky @ 2016-01-15 17:41 UTC (permalink / raw) To: Bart Van Assche Cc: SF Markus Elfring, linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier, LKML, kernel-janitors, Julia Lawall On Fri, Jan 15, 2016 at 09:19:38AM -0800, Bart Van Assche wrote: > On 01/15/2016 09:00 AM, Leon Romanovsky wrote: > >On Fri, Jan 15, 2016 at 05:24:50PM +0100, SF Markus Elfring wrote: > > > >Since, you didn't answer to my original question, I will repeat it again. > >[Q.] What did you try to achieve by this patch? > > Hello Leon, > > Have you noticed Dan's reply: "Doing bogus initializations turns off GCC's > checking for uninitialized variables so it's a bad habit." Yes and his second part of that message too, that uninitialized checks in GCC work as not as expected [1, 2]. Stackoverflow site has a lot examples of these types of bugs [3]. These examples together with Dan's suggestion requires from all reviewers to be extra cautions when removing variable initialization. [1] https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings [2] https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=may%20be%20uninitialized [3] http://stackoverflow.com/questions/27063678/compiler-not-detecting-obviously-uninitialized-variable > > Thanks, > > Bart. > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions @ 2016-01-15 17:41 ` Leon Romanovsky 0 siblings, 0 replies; 3089+ messages in thread From: Leon Romanovsky @ 2016-01-15 17:41 UTC (permalink / raw) To: Bart Van Assche Cc: SF Markus Elfring, linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier, LKML, kernel-janitors, Julia Lawall On Fri, Jan 15, 2016 at 09:19:38AM -0800, Bart Van Assche wrote: > On 01/15/2016 09:00 AM, Leon Romanovsky wrote: > >On Fri, Jan 15, 2016 at 05:24:50PM +0100, SF Markus Elfring wrote: > > > >Since, you didn't answer to my original question, I will repeat it again. > >[Q.] What did you try to achieve by this patch? > > Hello Leon, > > Have you noticed Dan's reply: "Doing bogus initializations turns off GCC's > checking for uninitialized variables so it's a bad habit." Yes and his second part of that message too, that uninitialized checks in GCC work as not as expected [1, 2]. Stackoverflow site has a lot examples of these types of bugs [3]. These examples together with Dan's suggestion requires from all reviewers to be extra cautions when removing variable initialization. [1] https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings [2] https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=may%20be%20uninitialized [3] http://stackoverflow.com/questions/27063678/compiler-not-detecting-obviously-uninitialized-variable > > Thanks, > > Bart. > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions 2016-01-15 17:00 ` Leon Romanovsky @ 2016-01-15 18:19 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-15 18:19 UTC (permalink / raw) To: linux-rdma, Leon Romanovsky Cc: Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier, LKML, kernel-janitors, Julia Lawall > [Q.] What did you try to achieve by this patch? I would appreciate a bit more fine-tuning in the affected source files. > P.S. This is mailing list for developers Do you try to express any further restrictions? > and not for patch bots. Would you like to explain such an information a bit more? > We are glad to see patches that clean the code, but they need to > be meaningful. This is usual. > Your automated patches add noise without any real benefit. Are you expecting a kind of special proof? > You was suggested to be ignored in MTD mailing list exactly > for this type of patches, Will the acceptance increase a bit for similar issues over time? > did you learn anything from that experience? Will another acknowledgement by Selvin Xavier influence any corresponding software improvements? How do you think about to add any further constructive comments also for the other proposed update steps? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions @ 2016-01-15 18:19 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-15 18:19 UTC (permalink / raw) To: linux-rdma, Leon Romanovsky Cc: Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier, LKML, kernel-janitors, Julia Lawall > [Q.] What did you try to achieve by this patch? I would appreciate a bit more fine-tuning in the affected source files. > P.S. This is mailing list for developers Do you try to express any further restrictions? > and not for patch bots. Would you like to explain such an information a bit more? > We are glad to see patches that clean the code, but they need to > be meaningful. This is usual. > Your automated patches add noise without any real benefit. Are you expecting a kind of special proof? > You was suggested to be ignored in MTD mailing list exactly > for this type of patches, Will the acceptance increase a bit for similar issues over time? > did you learn anything from that experience? Will another acknowledgement by Selvin Xavier influence any corresponding software improvements? How do you think about to add any further constructive comments also for the other proposed update steps? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions 2016-01-15 18:19 ` SF Markus Elfring @ 2016-01-16 6:18 ` Leon Romanovsky -1 siblings, 0 replies; 3089+ messages in thread From: Leon Romanovsky @ 2016-01-16 6:18 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier, LKML, kernel-janitors, Julia Lawall On Fri, Jan 15, 2016 at 07:19:31PM +0100, SF Markus Elfring wrote: > > [Q.] What did you try to achieve by this patch? > > I would appreciate a bit more fine-tuning in the affected source files. Please provide the numbers BEFORE and AFTER your change which can support that your so called "fine-tuning" worked. We are waiting to see it together with Tested-By tag to emphasize that your code was tested on real HW and passed minimal sanity checks. NAK on this patch. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions @ 2016-01-16 6:18 ` Leon Romanovsky 0 siblings, 0 replies; 3089+ messages in thread From: Leon Romanovsky @ 2016-01-16 6:18 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier, LKML, kernel-janitors, Julia Lawall On Fri, Jan 15, 2016 at 07:19:31PM +0100, SF Markus Elfring wrote: > > [Q.] What did you try to achieve by this patch? > > I would appreciate a bit more fine-tuning in the affected source files. Please provide the numbers BEFORE and AFTER your change which can support that your so called "fine-tuning" worked. We are waiting to see it together with Tested-By tag to emphasize that your code was tested on real HW and passed minimal sanity checks. NAK on this patch. ^ permalink raw reply [flat|nested] 3089+ messages in thread
[parent not found: <20160116061843.GE32346-2ukJVAZIZ/Y@public.gmane.org>]
* Re: InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions 2016-01-16 6:18 ` Leon Romanovsky (?) (?) @ 2016-01-16 8:30 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-16 8:30 UTC (permalink / raw) To: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Leon Romanovsky Cc: Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier, LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall, kbuild-all-JC7UmRfGjtg, ltp-cunTk1MwBs91InPhgRC9rw, users-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5 > Please provide the numbers BEFORE and AFTER your change which can > support that your so called "fine-tuning" worked. For which combinations of hardware and software versions would you like to see corresponding results from detailed system checks and special benchmarks? > We are waiting to see it together with Tested-By tag to emphasize > that your code was tested on real HW and passed minimal sanity checks. Are any other contributors interested to collaborate for such a task? > NAK on this patch. Thanks for your feedback. Does it mean that you reject (only) the proposed source code adjustments around the variable "status" in the shown function selection at the moment? Would you like to clarify the other update steps from this patch series a bit more? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [LTP] InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions @ 2016-01-16 8:30 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-16 8:30 UTC (permalink / raw) To: ltp > Please provide the numbers BEFORE and AFTER your change which can > support that your so called "fine-tuning" worked. For which combinations of hardware and software versions would you like to see corresponding results from detailed system checks and special benchmarks? > We are waiting to see it together with Tested-By tag to emphasize > that your code was tested on real HW and passed minimal sanity checks. Are any other contributors interested to collaborate for such a task? > NAK on this patch. Thanks for your feedback. Does it mean that you reject (only) the proposed source code adjustments around the variable "status" in the shown function selection at the moment? Would you like to clarify the other update steps from this patch series a bit more? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions @ 2016-01-16 8:30 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-16 8:30 UTC (permalink / raw) To: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Leon Romanovsky Cc: Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier, LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall, kbuild-all-JC7UmRfGjtg, ltp-cunTk1MwBs91InPhgRC9rw, users-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5 > Please provide the numbers BEFORE and AFTER your change which can > support that your so called "fine-tuning" worked. For which combinations of hardware and software versions would you like to see corresponding results from detailed system checks and special benchmarks? > We are waiting to see it together with Tested-By tag to emphasize > that your code was tested on real HW and passed minimal sanity checks. Are any other contributors interested to collaborate for such a task? > NAK on this patch. Thanks for your feedback. Does it mean that you reject (only) the proposed source code adjustments around the variable "status" in the shown function selection at the moment? Would you like to clarify the other update steps from this patch series a bit more? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions @ 2016-01-16 8:30 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-16 8:30 UTC (permalink / raw) To: linux-rdma, Leon Romanovsky Cc: Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier, LKML, kernel-janitors, Julia Lawall, kbuild-all, ltp, users > Please provide the numbers BEFORE and AFTER your change which can > support that your so called "fine-tuning" worked. For which combinations of hardware and software versions would you like to see corresponding results from detailed system checks and special benchmarks? > We are waiting to see it together with Tested-By tag to emphasize > that your code was tested on real HW and passed minimal sanity checks. Are any other contributors interested to collaborate for such a task? > NAK on this patch. Thanks for your feedback. Does it mean that you reject (only) the proposed source code adjustments around the variable "status" in the shown function selection at the moment? Would you like to clarify the other update steps from this patch series a bit more? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH v3 3/6] InfiniBand-ocrdma: Returning only value constants in ocrdma_qp_state_change() 2016-01-14 17:18 ` SF Markus Elfring @ 2016-01-14 17:45 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-14 17:45 UTC (permalink / raw) To: linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Thu, 14 Jan 2016 17:54:45 +0100 Return zero at the end without using the local variable "status". Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c index 159b1d5..3766927 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c @@ -2138,7 +2138,6 @@ int ocrdma_qp_state_change(struct ocrdma_qp *qp, enum ib_qp_state new_ib_state, enum ib_qp_state *old_ib_state) { unsigned long flags; - int status = 0; enum ocrdma_qp_state new_state; new_state = get_ocrdma_qp_state(new_ib_state); @@ -2163,7 +2162,7 @@ int ocrdma_qp_state_change(struct ocrdma_qp *qp, enum ib_qp_state new_ib_state, qp->state = new_state; spin_unlock_irqrestore(&qp->q_lock, flags); - return status; + return 0; } static u32 ocrdma_set_create_qp_mbx_access_flags(struct ocrdma_qp *qp) -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH v3 3/6] InfiniBand-ocrdma: Returning only value constants in ocrdma_qp_state_change() @ 2016-01-14 17:45 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-14 17:45 UTC (permalink / raw) To: linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Thu, 14 Jan 2016 17:54:45 +0100 Return zero at the end without using the local variable "status". Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c index 159b1d5..3766927 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c @@ -2138,7 +2138,6 @@ int ocrdma_qp_state_change(struct ocrdma_qp *qp, enum ib_qp_state new_ib_state, enum ib_qp_state *old_ib_state) { unsigned long flags; - int status = 0; enum ocrdma_qp_state new_state; new_state = get_ocrdma_qp_state(new_ib_state); @@ -2163,7 +2162,7 @@ int ocrdma_qp_state_change(struct ocrdma_qp *qp, enum ib_qp_state new_ib_state, qp->state = new_state; spin_unlock_irqrestore(&qp->q_lock, flags); - return status; + return 0; } static u32 ocrdma_set_create_qp_mbx_access_flags(struct ocrdma_qp *qp) -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH v3 4/6] InfiniBand-ocrdma: Return a value from a function call in _ocrdma_modify_qp() directly 2016-01-14 17:18 ` SF Markus Elfring @ 2016-01-14 17:48 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-14 17:48 UTC (permalink / raw) To: linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Thu, 14 Jan 2016 18:00:23 +0100 Return the value from a call of the ocrdma_mbx_modify_qp() function without using an extra assignment for the local variable "status". Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c index 1d90d18..5f2a34a 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c @@ -1492,9 +1492,7 @@ int _ocrdma_modify_qp(struct ib_qp *ibqp, struct ib_qp_attr *attr, */ if (status < 0) return status; - status = ocrdma_mbx_modify_qp(dev, qp, attr, attr_mask); - - return status; + return ocrdma_mbx_modify_qp(dev, qp, attr, attr_mask); } int ocrdma_modify_qp(struct ib_qp *ibqp, struct ib_qp_attr *attr, -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH v3 4/6] InfiniBand-ocrdma: Return a value from a function call in _ocrdma_modify_qp() directl @ 2016-01-14 17:48 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-14 17:48 UTC (permalink / raw) To: linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Thu, 14 Jan 2016 18:00:23 +0100 Return the value from a call of the ocrdma_mbx_modify_qp() function without using an extra assignment for the local variable "status". Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c index 1d90d18..5f2a34a 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c @@ -1492,9 +1492,7 @@ int _ocrdma_modify_qp(struct ib_qp *ibqp, struct ib_qp_attr *attr, */ if (status < 0) return status; - status = ocrdma_mbx_modify_qp(dev, qp, attr, attr_mask); - - return status; + return ocrdma_mbx_modify_qp(dev, qp, attr, attr_mask); } int ocrdma_modify_qp(struct ib_qp *ibqp, struct ib_qp_attr *attr, -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH v3 6/6] InfiniBand-ocrdma: Delete an unnecessary variable in ocrdma_dealloc_pd() 2016-01-14 17:18 ` SF Markus Elfring @ 2016-01-14 17:51 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-14 17:51 UTC (permalink / raw) To: linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Thu, 14 Jan 2016 18:08:08 +0100 1. Return zero in one case directly. 2. Return the value from a call of the _ocrdma_dealloc_pd() function without using an extra assignment for the local variable. 3. Remove the variable "status" in this function then. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c index d87985b..e6e1b51 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c @@ -751,7 +751,6 @@ int ocrdma_dealloc_pd(struct ib_pd *ibpd) struct ocrdma_pd *pd = get_ocrdma_pd(ibpd); struct ocrdma_dev *dev = get_ocrdma_dev(ibpd->device); struct ocrdma_ucontext *uctx = NULL; - int status = 0; u64 usr_db; uctx = pd->uctx; @@ -765,11 +764,10 @@ int ocrdma_dealloc_pd(struct ib_pd *ibpd) if (is_ucontext_pd(uctx, pd)) { ocrdma_release_ucontext_pd(uctx); - return status; + return 0; } } - status = _ocrdma_dealloc_pd(dev, pd); - return status; + return _ocrdma_dealloc_pd(dev, pd); } static int ocrdma_alloc_lkey(struct ocrdma_dev *dev, struct ocrdma_mr *mr, -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH v3 6/6] InfiniBand-ocrdma: Delete an unnecessary variable in ocrdma_dealloc_pd() @ 2016-01-14 17:51 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-14 17:51 UTC (permalink / raw) To: linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Thu, 14 Jan 2016 18:08:08 +0100 1. Return zero in one case directly. 2. Return the value from a call of the _ocrdma_dealloc_pd() function without using an extra assignment for the local variable. 3. Remove the variable "status" in this function then. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c index d87985b..e6e1b51 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c @@ -751,7 +751,6 @@ int ocrdma_dealloc_pd(struct ib_pd *ibpd) struct ocrdma_pd *pd = get_ocrdma_pd(ibpd); struct ocrdma_dev *dev = get_ocrdma_dev(ibpd->device); struct ocrdma_ucontext *uctx = NULL; - int status = 0; u64 usr_db; uctx = pd->uctx; @@ -765,11 +764,10 @@ int ocrdma_dealloc_pd(struct ib_pd *ibpd) if (is_ucontext_pd(uctx, pd)) { ocrdma_release_ucontext_pd(uctx); - return status; + return 0; } } - status = _ocrdma_dealloc_pd(dev, pd); - return status; + return _ocrdma_dealloc_pd(dev, pd); } static int ocrdma_alloc_lkey(struct ocrdma_dev *dev, struct ocrdma_mr *mr, -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 5/6] InfiniBand-ocrdma: Returning only value constants in ocrdma_resize_cq() 2015-12-26 18:39 ` SF Markus Elfring @ 2015-12-26 18:50 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-26 18:50 UTC (permalink / raw) To: linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 26 Dec 2015 18:54:47 +0100 Return constant integer values without storing them in the local variable "status". Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c index 2de39d3..7bedf44 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c @@ -1120,15 +1120,12 @@ ctx_err: int ocrdma_resize_cq(struct ib_cq *ibcq, int new_cnt, struct ib_udata *udata) { - int status = 0; struct ocrdma_cq *cq = get_ocrdma_cq(ibcq); - if (new_cnt < 1 || new_cnt > cq->max_hw_cqe) { - status = -EINVAL; - return status; - } + if (new_cnt < 1 || new_cnt > cq->max_hw_cqe) + return -EINVAL; ibcq->cqe = new_cnt; - return status; + return 0; } static void ocrdma_flush_cq(struct ocrdma_cq *cq) -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 5/6] InfiniBand-ocrdma: Returning only value constants in ocrdma_resize_cq() @ 2015-12-26 18:50 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-26 18:50 UTC (permalink / raw) To: linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 26 Dec 2015 18:54:47 +0100 Return constant integer values without storing them in the local variable "status". Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c index 2de39d3..7bedf44 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c @@ -1120,15 +1120,12 @@ ctx_err: int ocrdma_resize_cq(struct ib_cq *ibcq, int new_cnt, struct ib_udata *udata) { - int status = 0; struct ocrdma_cq *cq = get_ocrdma_cq(ibcq); - if (new_cnt < 1 || new_cnt > cq->max_hw_cqe) { - status = -EINVAL; - return status; - } + if (new_cnt < 1 || new_cnt > cq->max_hw_cqe) + return -EINVAL; ibcq->cqe = new_cnt; - return status; + return 0; } static void ocrdma_flush_cq(struct ocrdma_cq *cq) -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 6/6] InfiniBand-ocrdma: Delete an unnecessary variable in ocrdma_dealloc_pd() 2015-12-26 18:39 ` SF Markus Elfring @ 2015-12-26 18:51 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-26 18:51 UTC (permalink / raw) To: linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 26 Dec 2015 19:09:23 +0100 1. Return zero in one case directly. 2. Return the value from a call of the _ocrdma_dealloc_pd() function without using an extra assignment for the local variable. 3. Remove the variable "status" in this function then. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c index 7bedf44..0f79a01 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c @@ -750,7 +750,6 @@ int ocrdma_dealloc_pd(struct ib_pd *ibpd) struct ocrdma_pd *pd = get_ocrdma_pd(ibpd); struct ocrdma_dev *dev = get_ocrdma_dev(ibpd->device); struct ocrdma_ucontext *uctx = NULL; - int status = 0; u64 usr_db; uctx = pd->uctx; @@ -764,11 +763,10 @@ int ocrdma_dealloc_pd(struct ib_pd *ibpd) if (is_ucontext_pd(uctx, pd)) { ocrdma_release_ucontext_pd(uctx); - return status; + return 0; } } - status = _ocrdma_dealloc_pd(dev, pd); - return status; + return _ocrdma_dealloc_pd(dev, pd); } static int ocrdma_alloc_lkey(struct ocrdma_dev *dev, struct ocrdma_mr *mr, -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 6/6] InfiniBand-ocrdma: Delete an unnecessary variable in ocrdma_dealloc_pd() @ 2015-12-26 18:51 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-26 18:51 UTC (permalink / raw) To: linux-rdma, Devesh Sharma, Doug Ledford, Hal Rosenstock, Mitesh Ahuja, Sean Hefty, Selvin Xavier Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 26 Dec 2015 19:09:23 +0100 1. Return zero in one case directly. 2. Return the value from a call of the _ocrdma_dealloc_pd() function without using an extra assignment for the local variable. 3. Remove the variable "status" in this function then. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c index 7bedf44..0f79a01 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c @@ -750,7 +750,6 @@ int ocrdma_dealloc_pd(struct ib_pd *ibpd) struct ocrdma_pd *pd = get_ocrdma_pd(ibpd); struct ocrdma_dev *dev = get_ocrdma_dev(ibpd->device); struct ocrdma_ucontext *uctx = NULL; - int status = 0; u64 usr_db; uctx = pd->uctx; @@ -764,11 +763,10 @@ int ocrdma_dealloc_pd(struct ib_pd *ibpd) if (is_ucontext_pd(uctx, pd)) { ocrdma_release_ucontext_pd(uctx); - return status; + return 0; } } - status = _ocrdma_dealloc_pd(dev, pd); - return status; + return _ocrdma_dealloc_pd(dev, pd); } static int ocrdma_alloc_lkey(struct ocrdma_dev *dev, struct ocrdma_mr *mr, -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 0/2] InfiniBand-iSER: Refactoring for two function implementations 2015-12-11 12:08 ` SF Markus Elfring @ 2015-12-27 12:36 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-27 12:36 UTC (permalink / raw) To: linux-rdma, target-devel, Doug Ledford, Hal Rosenstock, Or Gerlitz, Roi Dayan, Sagi Grimberg, Sean Hefty Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 27 Dec 2015 13:12:10 +0100 Subject: [PATCH 0/2] InfiniBand-iSER: Refactoring for two function implementations I suggest to return directly instead of using the jump label "err" in two functions (which are working without clean-up there). Markus Elfring (2): One jump label less in iser_reg_sig_mr() One jump label less in isert_reg_sig_mr() drivers/infiniband/ulp/iser/iser_memory.c | 5 ++--- drivers/infiniband/ulp/isert/ib_isert.c | 7 +++---- 2 files changed, 5 insertions(+), 7 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/2] InfiniBand-iSER: Refactoring for two function implementations @ 2015-12-27 12:36 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-27 12:36 UTC (permalink / raw) To: linux-rdma, target-devel, Doug Ledford, Hal Rosenstock, Or Gerlitz, Roi Dayan, Sagi Grimberg, Sean Hefty Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 27 Dec 2015 13:12:10 +0100 Subject: [PATCH 0/2] InfiniBand-iSER: Refactoring for two function implementations I suggest to return directly instead of using the jump label "err" in two functions (which are working without clean-up there). Markus Elfring (2): One jump label less in iser_reg_sig_mr() One jump label less in isert_reg_sig_mr() drivers/infiniband/ulp/iser/iser_memory.c | 5 ++--- drivers/infiniband/ulp/isert/ib_isert.c | 7 +++---- 2 files changed, 5 insertions(+), 7 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 1/2] InfiniBand-iSER: One jump label less in iser_reg_sig_mr() 2015-12-27 12:36 ` SF Markus Elfring @ 2015-12-27 12:40 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-27 12:40 UTC (permalink / raw) To: linux-rdma, target-devel, Doug Ledford, Hal Rosenstock, Or Gerlitz, Roi Dayan, Sagi Grimberg, Sean Hefty Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 27 Dec 2015 11:41:42 +0100 This issue was detected by using the Coccinelle software. 1. Let us return directly if a call of the iser_set_sig_attrs() function failed. 2. Delete the jump label "err" then. 3. Return zero as a constant at the end. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/infiniband/ulp/iser/iser_memory.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/infiniband/ulp/iser/iser_memory.c b/drivers/infiniband/ulp/iser/iser_memory.c index ea765fb..14e08b3 100644 --- a/drivers/infiniband/ulp/iser/iser_memory.c +++ b/drivers/infiniband/ulp/iser/iser_memory.c @@ -443,7 +443,7 @@ iser_reg_sig_mr(struct iscsi_iser_task *iser_task, memset(sig_attrs, 0, sizeof(*sig_attrs)); ret = iser_set_sig_attrs(iser_task->sc, sig_attrs); if (ret) - goto err; + return ret; iser_set_prot_checks(iser_task->sc, &sig_attrs->check_mask); @@ -475,8 +475,7 @@ iser_reg_sig_mr(struct iscsi_iser_task *iser_task, iser_dbg("lkey=0x%x rkey=0x%x addr=0x%llx length=%u\n", sig_reg->sge.lkey, sig_reg->rkey, sig_reg->sge.addr, sig_reg->sge.length); -err: - return ret; + return 0; } static int iser_fast_reg_mr(struct iscsi_iser_task *iser_task, -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 1/2] InfiniBand-iSER: One jump label less in iser_reg_sig_mr() @ 2015-12-27 12:40 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-27 12:40 UTC (permalink / raw) To: linux-rdma, target-devel, Doug Ledford, Hal Rosenstock, Or Gerlitz, Roi Dayan, Sagi Grimberg, Sean Hefty Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 27 Dec 2015 11:41:42 +0100 This issue was detected by using the Coccinelle software. 1. Let us return directly if a call of the iser_set_sig_attrs() function failed. 2. Delete the jump label "err" then. 3. Return zero as a constant at the end. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/infiniband/ulp/iser/iser_memory.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/infiniband/ulp/iser/iser_memory.c b/drivers/infiniband/ulp/iser/iser_memory.c index ea765fb..14e08b3 100644 --- a/drivers/infiniband/ulp/iser/iser_memory.c +++ b/drivers/infiniband/ulp/iser/iser_memory.c @@ -443,7 +443,7 @@ iser_reg_sig_mr(struct iscsi_iser_task *iser_task, memset(sig_attrs, 0, sizeof(*sig_attrs)); ret = iser_set_sig_attrs(iser_task->sc, sig_attrs); if (ret) - goto err; + return ret; iser_set_prot_checks(iser_task->sc, &sig_attrs->check_mask); @@ -475,8 +475,7 @@ iser_reg_sig_mr(struct iscsi_iser_task *iser_task, iser_dbg("lkey=0x%x rkey=0x%x addr=0x%llx length=%u\n", sig_reg->sge.lkey, sig_reg->rkey, sig_reg->sge.addr, sig_reg->sge.length); -err: - return ret; + return 0; } static int iser_fast_reg_mr(struct iscsi_iser_task *iser_task, -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 2/2] InfiniBand-iSER-target: One jump label less in isert_reg_sig_mr() 2015-12-27 12:36 ` SF Markus Elfring @ 2015-12-27 12:41 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-27 12:41 UTC (permalink / raw) To: linux-rdma, target-devel, Doug Ledford, Hal Rosenstock, Or Gerlitz, Roi Dayan, Sagi Grimberg, Sean Hefty Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 27 Dec 2015 12:54:52 +0100 This issue was detected by using the Coccinelle software. 1. Let us return directly if a call of the function "isert_set_sig_attrs" or "ib_post_send" failed. 2. Delete the jump label "err" then. 3. Return zero as a constant at the end. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/infiniband/ulp/isert/ib_isert.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/infiniband/ulp/isert/ib_isert.c b/drivers/infiniband/ulp/isert/ib_isert.c index 8a51c3b..9b22db0 100644 --- a/drivers/infiniband/ulp/isert/ib_isert.c +++ b/drivers/infiniband/ulp/isert/ib_isert.c @@ -2660,7 +2660,7 @@ isert_reg_sig_mr(struct isert_conn *isert_conn, memset(&sig_attrs, 0, sizeof(sig_attrs)); ret = isert_set_sig_attrs(se_cmd, &sig_attrs); if (ret) - goto err; + return ret; sig_attrs.check_mask = isert_set_prot_checks(se_cmd->prot_checks); @@ -2688,7 +2688,7 @@ isert_reg_sig_mr(struct isert_conn *isert_conn, ret = ib_post_send(isert_conn->qp, wr, &bad_wr); if (ret) { isert_err("fast registration failed, ret:%d\n", ret); - goto err; + return ret; } fr_desc->ind &= ~ISERT_SIG_KEY_VALID; @@ -2706,8 +2706,7 @@ isert_reg_sig_mr(struct isert_conn *isert_conn, isert_dbg("sig_sge: addr: 0x%llx length: %u lkey: %x\n", rdma_wr->ib_sg[SIG].addr, rdma_wr->ib_sg[SIG].length, rdma_wr->ib_sg[SIG].lkey); -err: - return ret; + return 0; } static int -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 2/2] InfiniBand-iSER-target: One jump label less in isert_reg_sig_mr() @ 2015-12-27 12:41 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-27 12:41 UTC (permalink / raw) To: linux-rdma, target-devel, Doug Ledford, Hal Rosenstock, Or Gerlitz, Roi Dayan, Sagi Grimberg, Sean Hefty Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 27 Dec 2015 12:54:52 +0100 This issue was detected by using the Coccinelle software. 1. Let us return directly if a call of the function "isert_set_sig_attrs" or "ib_post_send" failed. 2. Delete the jump label "err" then. 3. Return zero as a constant at the end. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/infiniband/ulp/isert/ib_isert.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/infiniband/ulp/isert/ib_isert.c b/drivers/infiniband/ulp/isert/ib_isert.c index 8a51c3b..9b22db0 100644 --- a/drivers/infiniband/ulp/isert/ib_isert.c +++ b/drivers/infiniband/ulp/isert/ib_isert.c @@ -2660,7 +2660,7 @@ isert_reg_sig_mr(struct isert_conn *isert_conn, memset(&sig_attrs, 0, sizeof(sig_attrs)); ret = isert_set_sig_attrs(se_cmd, &sig_attrs); if (ret) - goto err; + return ret; sig_attrs.check_mask = isert_set_prot_checks(se_cmd->prot_checks); @@ -2688,7 +2688,7 @@ isert_reg_sig_mr(struct isert_conn *isert_conn, ret = ib_post_send(isert_conn->qp, wr, &bad_wr); if (ret) { isert_err("fast registration failed, ret:%d\n", ret); - goto err; + return ret; } fr_desc->ind &= ~ISERT_SIG_KEY_VALID; @@ -2706,8 +2706,7 @@ isert_reg_sig_mr(struct isert_conn *isert_conn, isert_dbg("sig_sge: addr: 0x%llx length: %u lkey: %x\n", rdma_wr->ib_sg[SIG].addr, rdma_wr->ib_sg[SIG].length, rdma_wr->ib_sg[SIG].lkey); -err: - return ret; + return 0; } static int -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
[parent not found: <567FDB4E.2040000-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>]
* Re: [PATCH 0/2] InfiniBand-iSER: Refactoring for two function implementations 2015-12-27 12:36 ` SF Markus Elfring (?) @ 2015-12-27 12:43 ` Leon Romanovsky -1 siblings, 0 replies; 3089+ messages in thread From: Leon Romanovsky @ 2015-12-27 12:43 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, target-devel-u79uwXL29TY76Z2rM5mHXA, Doug Ledford, Hal Rosenstock, Or Gerlitz, Roi Dayan, Sagi Grimberg, Sean Hefty, LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall On Sun, Dec 27, 2015 at 01:36:30PM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> > Date: Sun, 27 Dec 2015 13:12:10 +0100 > Subject: [PATCH 0/2] InfiniBand-iSER: Refactoring for two function implementations Just a note for the future submissions (no need to respin), we are using different subject line: InfiniBand-iSER: --> IB/iser: > > I suggest to return directly instead of using the jump label "err" > in two functions (which are working without clean-up there). > > Markus Elfring (2): > One jump label less in iser_reg_sig_mr() > One jump label less in isert_reg_sig_mr() > > drivers/infiniband/ulp/iser/iser_memory.c | 5 ++--- > drivers/infiniband/ulp/isert/ib_isert.c | 7 +++---- > 2 files changed, 5 insertions(+), 7 deletions(-) > > -- > 2.6.3 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/2] InfiniBand-iSER: Refactoring for two function implementations @ 2015-12-27 12:43 ` Leon Romanovsky 0 siblings, 0 replies; 3089+ messages in thread From: Leon Romanovsky @ 2015-12-27 12:43 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, target-devel-u79uwXL29TY76Z2rM5mHXA, Doug Ledford, Hal Rosenstock, Or Gerlitz, Roi Dayan, Sagi Grimberg, Sean Hefty, LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall On Sun, Dec 27, 2015 at 01:36:30PM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 27 Dec 2015 13:12:10 +0100 > Subject: [PATCH 0/2] InfiniBand-iSER: Refactoring for two function implementations Just a note for the future submissions (no need to respin), we are using different subject line: InfiniBand-iSER: --> IB/iser: > > I suggest to return directly instead of using the jump label "err" > in two functions (which are working without clean-up there). > > Markus Elfring (2): > One jump label less in iser_reg_sig_mr() > One jump label less in isert_reg_sig_mr() > > drivers/infiniband/ulp/iser/iser_memory.c | 5 ++--- > drivers/infiniband/ulp/isert/ib_isert.c | 7 +++---- > 2 files changed, 5 insertions(+), 7 deletions(-) > > -- > 2.6.3 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/2] InfiniBand-iSER: Refactoring for two function implementations @ 2015-12-27 12:43 ` Leon Romanovsky 0 siblings, 0 replies; 3089+ messages in thread From: Leon Romanovsky @ 2015-12-27 12:43 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-rdma, target-devel, Doug Ledford, Hal Rosenstock, Or Gerlitz, Roi Dayan, Sagi Grimberg, Sean Hefty, LKML, kernel-janitors, Julia Lawall On Sun, Dec 27, 2015 at 01:36:30PM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 27 Dec 2015 13:12:10 +0100 > Subject: [PATCH 0/2] InfiniBand-iSER: Refactoring for two function implementations Just a note for the future submissions (no need to respin), we are using different subject line: InfiniBand-iSER: --> IB/iser: > > I suggest to return directly instead of using the jump label "err" > in two functions (which are working without clean-up there). > > Markus Elfring (2): > One jump label less in iser_reg_sig_mr() > One jump label less in isert_reg_sig_mr() > > drivers/infiniband/ulp/iser/iser_memory.c | 5 ++--- > drivers/infiniband/ulp/isert/ib_isert.c | 7 +++---- > 2 files changed, 5 insertions(+), 7 deletions(-) > > -- > 2.6.3 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/2] InfiniBand-iSER: Refactoring for two function implementations 2015-12-27 12:36 ` SF Markus Elfring (?) @ 2015-12-27 12:52 ` Leon Romanovsky -1 siblings, 0 replies; 3089+ messages in thread From: Leon Romanovsky @ 2015-12-27 12:52 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, target-devel-u79uwXL29TY76Z2rM5mHXA, Doug Ledford, Hal Rosenstock, Or Gerlitz, Roi Dayan, Sagi Grimberg, Sean Hefty, LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall On Sun, Dec 27, 2015 at 01:36:30PM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> > Date: Sun, 27 Dec 2015 13:12:10 +0100 > Subject: [PATCH 0/2] InfiniBand-iSER: Refactoring for two function implementations > > I suggest to return directly instead of using the jump label "err" > in two functions (which are working without clean-up there). > > Markus Elfring (2): > One jump label less in iser_reg_sig_mr() > One jump label less in isert_reg_sig_mr() Looks good, Reviewed-by: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org> > > drivers/infiniband/ulp/iser/iser_memory.c | 5 ++--- > drivers/infiniband/ulp/isert/ib_isert.c | 7 +++---- > 2 files changed, 5 insertions(+), 7 deletions(-) > > -- > 2.6.3 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/2] InfiniBand-iSER: Refactoring for two function implementations @ 2015-12-27 12:52 ` Leon Romanovsky 0 siblings, 0 replies; 3089+ messages in thread From: Leon Romanovsky @ 2015-12-27 12:52 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, target-devel-u79uwXL29TY76Z2rM5mHXA, Doug Ledford, Hal Rosenstock, Or Gerlitz, Roi Dayan, Sagi Grimberg, Sean Hefty, LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall On Sun, Dec 27, 2015 at 01:36:30PM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 27 Dec 2015 13:12:10 +0100 > Subject: [PATCH 0/2] InfiniBand-iSER: Refactoring for two function implementations > > I suggest to return directly instead of using the jump label "err" > in two functions (which are working without clean-up there). > > Markus Elfring (2): > One jump label less in iser_reg_sig_mr() > One jump label less in isert_reg_sig_mr() Looks good, Reviewed-by: Leon Romanovsky <leonro@mellanox.com> > > drivers/infiniband/ulp/iser/iser_memory.c | 5 ++--- > drivers/infiniband/ulp/isert/ib_isert.c | 7 +++---- > 2 files changed, 5 insertions(+), 7 deletions(-) > > -- > 2.6.3 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/2] InfiniBand-iSER: Refactoring for two function implementations @ 2015-12-27 12:52 ` Leon Romanovsky 0 siblings, 0 replies; 3089+ messages in thread From: Leon Romanovsky @ 2015-12-27 12:52 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-rdma, target-devel, Doug Ledford, Hal Rosenstock, Or Gerlitz, Roi Dayan, Sagi Grimberg, Sean Hefty, LKML, kernel-janitors, Julia Lawall On Sun, Dec 27, 2015 at 01:36:30PM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 27 Dec 2015 13:12:10 +0100 > Subject: [PATCH 0/2] InfiniBand-iSER: Refactoring for two function implementations > > I suggest to return directly instead of using the jump label "err" > in two functions (which are working without clean-up there). > > Markus Elfring (2): > One jump label less in iser_reg_sig_mr() > One jump label less in isert_reg_sig_mr() Looks good, Reviewed-by: Leon Romanovsky <leonro@mellanox.com> > > drivers/infiniband/ulp/iser/iser_memory.c | 5 ++--- > drivers/infiniband/ulp/isert/ib_isert.c | 7 +++---- > 2 files changed, 5 insertions(+), 7 deletions(-) > > -- > 2.6.3 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/2] InfiniBand-iSER: Refactoring for two function implementations 2015-12-27 12:36 ` SF Markus Elfring (?) @ 2016-01-06 18:47 ` Nicholas A. Bellinger -1 siblings, 0 replies; 3089+ messages in thread From: Nicholas A. Bellinger @ 2016-01-06 18:47 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, target-devel-u79uwXL29TY76Z2rM5mHXA, Doug Ledford, Hal Rosenstock, Or Gerlitz, Roi Dayan, Sagi Grimberg, Sean Hefty, LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall On Sun, 2015-12-27 at 13:36 +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> > Date: Sun, 27 Dec 2015 13:12:10 +0100 > Subject: [PATCH 0/2] InfiniBand-iSER: Refactoring for two function implementations > > I suggest to return directly instead of using the jump label "err" > in two functions (which are working without clean-up there). > > Markus Elfring (2): > One jump label less in iser_reg_sig_mr() > One jump label less in isert_reg_sig_mr() > > drivers/infiniband/ulp/iser/iser_memory.c | 5 ++--- > drivers/infiniband/ulp/isert/ib_isert.c | 7 +++---- > 2 files changed, 5 insertions(+), 7 deletions(-) > Doug, are you going to pick these two minor patches up, or shall I..? -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/2] InfiniBand-iSER: Refactoring for two function implementations @ 2016-01-06 18:47 ` Nicholas A. Bellinger 0 siblings, 0 replies; 3089+ messages in thread From: Nicholas A. Bellinger @ 2016-01-06 18:47 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, target-devel-u79uwXL29TY76Z2rM5mHXA, Doug Ledford, Hal Rosenstock, Or Gerlitz, Roi Dayan, Sagi Grimberg, Sean Hefty, LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall On Sun, 2015-12-27 at 13:36 +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 27 Dec 2015 13:12:10 +0100 > Subject: [PATCH 0/2] InfiniBand-iSER: Refactoring for two function implementations > > I suggest to return directly instead of using the jump label "err" > in two functions (which are working without clean-up there). > > Markus Elfring (2): > One jump label less in iser_reg_sig_mr() > One jump label less in isert_reg_sig_mr() > > drivers/infiniband/ulp/iser/iser_memory.c | 5 ++--- > drivers/infiniband/ulp/isert/ib_isert.c | 7 +++---- > 2 files changed, 5 insertions(+), 7 deletions(-) > Doug, are you going to pick these two minor patches up, or shall I..? ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/2] InfiniBand-iSER: Refactoring for two function implementations @ 2016-01-06 18:47 ` Nicholas A. Bellinger 0 siblings, 0 replies; 3089+ messages in thread From: Nicholas A. Bellinger @ 2016-01-06 18:47 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-rdma, target-devel, Doug Ledford, Hal Rosenstock, Or Gerlitz, Roi Dayan, Sagi Grimberg, Sean Hefty, LKML, kernel-janitors, Julia Lawall On Sun, 2015-12-27 at 13:36 +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 27 Dec 2015 13:12:10 +0100 > Subject: [PATCH 0/2] InfiniBand-iSER: Refactoring for two function implementations > > I suggest to return directly instead of using the jump label "err" > in two functions (which are working without clean-up there). > > Markus Elfring (2): > One jump label less in iser_reg_sig_mr() > One jump label less in isert_reg_sig_mr() > > drivers/infiniband/ulp/iser/iser_memory.c | 5 ++--- > drivers/infiniband/ulp/isert/ib_isert.c | 7 +++---- > 2 files changed, 5 insertions(+), 7 deletions(-) > Doug, are you going to pick these two minor patches up, or shall I..? ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/2] InfiniBand-iSER: Refactoring for two function implementations 2015-12-27 12:36 ` SF Markus Elfring @ 2015-12-27 15:26 ` Sagi Grimberg -1 siblings, 0 replies; 3089+ messages in thread From: Sagi Grimberg @ 2015-12-27 15:26 UTC (permalink / raw) To: SF Markus Elfring, linux-rdma, target-devel, Doug Ledford, Hal Rosenstock, Or Gerlitz, Roi Dayan, Sagi Grimberg, Sean Hefty Cc: LKML, kernel-janitors, Julia Lawall Along with Leon's prefix comment: Acked-by: Sagi Grimberg <sagig@mellanox.com> ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/2] InfiniBand-iSER: Refactoring for two function implementations @ 2015-12-27 15:26 ` Sagi Grimberg 0 siblings, 0 replies; 3089+ messages in thread From: Sagi Grimberg @ 2015-12-27 15:26 UTC (permalink / raw) To: SF Markus Elfring, linux-rdma, target-devel, Doug Ledford, Hal Rosenstock, Or Gerlitz, Roi Dayan, Sagi Grimberg, Sean Hefty Cc: LKML, kernel-janitors, Julia Lawall Along with Leon's prefix comment: Acked-by: Sagi Grimberg <sagig@mellanox.com> ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH] [media] si2165: Refactoring for si2165_writereg_mask8() 2015-12-11 12:08 ` SF Markus Elfring @ 2015-12-27 17:33 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-27 17:33 UTC (permalink / raw) To: linux-media, Mauro Carvalho Chehab; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 27 Dec 2015 18:23:57 +0100 This issue was detected by using the Coccinelle software. 1. Let us return directly if a call of the si2165_readreg8() function failed. 2. Reduce the scope for the local variables "ret" and "tmp" to one branch of an if statement. 3. Delete the jump label "err" then. 4. Return the value from a call of the si2165_writereg8() function without using an extra assignment for the variable "ret" at the end. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/media/dvb-frontends/si2165.c | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/drivers/media/dvb-frontends/si2165.c b/drivers/media/dvb-frontends/si2165.c index 2b93241..e8518ae 100644 --- a/drivers/media/dvb-frontends/si2165.c +++ b/drivers/media/dvb-frontends/si2165.c @@ -225,22 +225,18 @@ static int si2165_writereg32(struct si2165_state *state, const u16 reg, u32 val) static int si2165_writereg_mask8(struct si2165_state *state, const u16 reg, u8 val, u8 mask) { - int ret; - u8 tmp; - if (mask != 0xff) { - ret = si2165_readreg8(state, reg, &tmp); + u8 tmp; + int ret = si2165_readreg8(state, reg, &tmp); + if (ret < 0) - goto err; + return ret; val &= mask; tmp &= ~mask; val |= tmp; } - - ret = si2165_writereg8(state, reg, val); -err: - return ret; + return si2165_writereg8(state, reg, val); } #define REG16(reg, val) { (reg), (val) & 0xff }, { (reg)+1, (val)>>8 & 0xff } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH] [media] si2165: Refactoring for si2165_writereg_mask8() @ 2015-12-27 17:33 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-27 17:33 UTC (permalink / raw) To: linux-media, Mauro Carvalho Chehab; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 27 Dec 2015 18:23:57 +0100 This issue was detected by using the Coccinelle software. 1. Let us return directly if a call of the si2165_readreg8() function failed. 2. Reduce the scope for the local variables "ret" and "tmp" to one branch of an if statement. 3. Delete the jump label "err" then. 4. Return the value from a call of the si2165_writereg8() function without using an extra assignment for the variable "ret" at the end. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/media/dvb-frontends/si2165.c | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/drivers/media/dvb-frontends/si2165.c b/drivers/media/dvb-frontends/si2165.c index 2b93241..e8518ae 100644 --- a/drivers/media/dvb-frontends/si2165.c +++ b/drivers/media/dvb-frontends/si2165.c @@ -225,22 +225,18 @@ static int si2165_writereg32(struct si2165_state *state, const u16 reg, u32 val) static int si2165_writereg_mask8(struct si2165_state *state, const u16 reg, u8 val, u8 mask) { - int ret; - u8 tmp; - if (mask != 0xff) { - ret = si2165_readreg8(state, reg, &tmp); + u8 tmp; + int ret = si2165_readreg8(state, reg, &tmp); + if (ret < 0) - goto err; + return ret; val &= mask; tmp &= ~mask; val |= tmp; } - - ret = si2165_writereg8(state, reg, val); -err: - return ret; + return si2165_writereg8(state, reg, val); } #define REG16(reg, val) { (reg), (val) & 0xff }, { (reg)+1, (val)>>8 & 0xff } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH] [media] si2165: Refactoring for si2165_writereg_mask8() 2015-12-27 17:33 ` SF Markus Elfring @ 2016-01-04 8:39 ` Matthias Schwarzott -1 siblings, 0 replies; 3089+ messages in thread From: Matthias Schwarzott @ 2016-01-04 8:39 UTC (permalink / raw) To: SF Markus Elfring, linux-media, Mauro Carvalho Chehab Cc: LKML, kernel-janitors, Julia Lawall Am 27.12.2015 um 18:33 schrieb SF Markus Elfring: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 27 Dec 2015 18:23:57 +0100 > > This issue was detected by using the Coccinelle software. > > 1. Let us return directly if a call of the si2165_readreg8() > function failed. > > 2. Reduce the scope for the local variables "ret" and "tmp" to one branch > of an if statement. > > 3. Delete the jump label "err" then. > > 4. Return the value from a call of the si2165_writereg8() function > without using an extra assignment for the variable "ret" at the end. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> The patch looks fine. Signed-off-by: Matthias Schwarzott <zzam@gentoo.org> Regards Matthias PS: I am going to switch to regmap, but this change is not yet polished and until now does not touch this function. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] [media] si2165: Refactoring for si2165_writereg_mask8() @ 2016-01-04 8:39 ` Matthias Schwarzott 0 siblings, 0 replies; 3089+ messages in thread From: Matthias Schwarzott @ 2016-01-04 8:39 UTC (permalink / raw) To: SF Markus Elfring, linux-media, Mauro Carvalho Chehab Cc: LKML, kernel-janitors, Julia Lawall Am 27.12.2015 um 18:33 schrieb SF Markus Elfring: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 27 Dec 2015 18:23:57 +0100 > > This issue was detected by using the Coccinelle software. > > 1. Let us return directly if a call of the si2165_readreg8() > function failed. > > 2. Reduce the scope for the local variables "ret" and "tmp" to one branch > of an if statement. > > 3. Delete the jump label "err" then. > > 4. Return the value from a call of the si2165_writereg8() function > without using an extra assignment for the variable "ret" at the end. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> The patch looks fine. Signed-off-by: Matthias Schwarzott <zzam@gentoo.org> Regards Matthias PS: I am going to switch to regmap, but this change is not yet polished and until now does not touch this function. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH] [media] bttv: Returning only value constants in two functions 2015-12-11 12:08 ` SF Markus Elfring @ 2015-12-27 21:22 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-27 21:22 UTC (permalink / raw) To: linux-media, Mauro Carvalho Chehab; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 27 Dec 2015 22:02:21 +0100 Return constant integer values without storing them in the local variable "err" or "rc". Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/media/pci/bt8xx/bttv-driver.c | 25 ++++++------------------- 1 file changed, 6 insertions(+), 19 deletions(-) diff --git a/drivers/media/pci/bt8xx/bttv-driver.c b/drivers/media/pci/bt8xx/bttv-driver.c index 9400e99..cd7d6ef 100644 --- a/drivers/media/pci/bt8xx/bttv-driver.c +++ b/drivers/media/pci/bt8xx/bttv-driver.c @@ -1726,22 +1726,15 @@ static int bttv_s_std(struct file *file, void *priv, v4l2_std_id id) struct bttv_fh *fh = priv; struct bttv *btv = fh->btv; unsigned int i; - int err = 0; for (i = 0; i < BTTV_TVNORMS; i++) if (id & bttv_tvnorms[i].v4l2_id) break; - if (i == BTTV_TVNORMS) { - err = -EINVAL; - goto err; - } - + if (i == BTTV_TVNORMS) + return -EINVAL; btv->std = id; set_tvnorm(btv, i); - -err: - - return err; + return 0; } static int bttv_g_std(struct file *file, void *priv, v4l2_std_id *id) @@ -1770,12 +1763,9 @@ static int bttv_enum_input(struct file *file, void *priv, { struct bttv_fh *fh = priv; struct bttv *btv = fh->btv; - int rc = 0; - if (i->index >= bttv_tvcards[btv->c.type].video_inputs) { - rc = -EINVAL; - goto err; - } + if (i->index >= bttv_tvcards[btv->c.type].video_inputs) + return -EINVAL; i->type = V4L2_INPUT_TYPE_CAMERA; i->audioset = 0; @@ -1799,10 +1789,7 @@ static int bttv_enum_input(struct file *file, void *priv, } i->std = BTTV_NORMS; - -err: - - return rc; + return 0; } static int bttv_g_input(struct file *file, void *priv, unsigned int *i) -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH] [media] bttv: Returning only value constants in two functions @ 2015-12-27 21:22 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-27 21:22 UTC (permalink / raw) To: linux-media, Mauro Carvalho Chehab; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 27 Dec 2015 22:02:21 +0100 Return constant integer values without storing them in the local variable "err" or "rc". Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/media/pci/bt8xx/bttv-driver.c | 25 ++++++------------------- 1 file changed, 6 insertions(+), 19 deletions(-) diff --git a/drivers/media/pci/bt8xx/bttv-driver.c b/drivers/media/pci/bt8xx/bttv-driver.c index 9400e99..cd7d6ef 100644 --- a/drivers/media/pci/bt8xx/bttv-driver.c +++ b/drivers/media/pci/bt8xx/bttv-driver.c @@ -1726,22 +1726,15 @@ static int bttv_s_std(struct file *file, void *priv, v4l2_std_id id) struct bttv_fh *fh = priv; struct bttv *btv = fh->btv; unsigned int i; - int err = 0; for (i = 0; i < BTTV_TVNORMS; i++) if (id & bttv_tvnorms[i].v4l2_id) break; - if (i = BTTV_TVNORMS) { - err = -EINVAL; - goto err; - } - + if (i = BTTV_TVNORMS) + return -EINVAL; btv->std = id; set_tvnorm(btv, i); - -err: - - return err; + return 0; } static int bttv_g_std(struct file *file, void *priv, v4l2_std_id *id) @@ -1770,12 +1763,9 @@ static int bttv_enum_input(struct file *file, void *priv, { struct bttv_fh *fh = priv; struct bttv *btv = fh->btv; - int rc = 0; - if (i->index >= bttv_tvcards[btv->c.type].video_inputs) { - rc = -EINVAL; - goto err; - } + if (i->index >= bttv_tvcards[btv->c.type].video_inputs) + return -EINVAL; i->type = V4L2_INPUT_TYPE_CAMERA; i->audioset = 0; @@ -1799,10 +1789,7 @@ static int bttv_enum_input(struct file *file, void *priv, } i->std = BTTV_NORMS; - -err: - - return rc; + return 0; } static int bttv_g_input(struct file *file, void *priv, unsigned int *i) -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH] [media] tuners: One check less in m88rs6000t_get_rf_strength() after error detection 2015-12-11 12:08 ` SF Markus Elfring @ 2015-12-28 9:15 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-28 9:15 UTC (permalink / raw) To: linux-media, Mauro Carvalho Chehab; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Mon, 28 Dec 2015 10:10:34 +0100 This issue was detected by using the Coccinelle software. Move the jump label directly before the desired log statement so that the variable "ret" will not be checked once more after it was determined that a function call failed. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/media/tuners/m88rs6000t.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/drivers/media/tuners/m88rs6000t.c b/drivers/media/tuners/m88rs6000t.c index 504bfbc..b45594e 100644 --- a/drivers/media/tuners/m88rs6000t.c +++ b/drivers/media/tuners/m88rs6000t.c @@ -510,27 +510,27 @@ static int m88rs6000t_get_rf_strength(struct dvb_frontend *fe, u16 *strength) ret = regmap_read(dev->regmap, 0x5A, &val); if (ret) - goto err; + goto report_failure; RF_GC = val & 0x0f; ret = regmap_read(dev->regmap, 0x5F, &val); if (ret) - goto err; + goto report_failure; IF_GC = val & 0x0f; ret = regmap_read(dev->regmap, 0x3F, &val); if (ret) - goto err; + goto report_failure; TIA_GC = (val >> 4) & 0x07; ret = regmap_read(dev->regmap, 0x77, &val); if (ret) - goto err; + goto report_failure; BB_GC = (val >> 4) & 0x0f; ret = regmap_read(dev->regmap, 0x76, &val); if (ret) - goto err; + goto report_failure; PGA2_GC = val & 0x3f; PGA2_cri = PGA2_GC >> 2; PGA2_crf = PGA2_GC & 0x03; @@ -562,9 +562,11 @@ static int m88rs6000t_get_rf_strength(struct dvb_frontend *fe, u16 *strength) /* scale value to 0x0000-0xffff */ gain = clamp_val(gain, 1000U, 10500U); *strength = (10500 - gain) * 0xffff / (10500 - 1000); -err: - if (ret) + + if (ret) { +report_failure: dev_dbg(&dev->client->dev, "failed=%d\n", ret); + } return ret; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH] [media] tuners: One check less in m88rs6000t_get_rf_strength() after error detection @ 2015-12-28 9:15 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-28 9:15 UTC (permalink / raw) To: linux-media, Mauro Carvalho Chehab; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Mon, 28 Dec 2015 10:10:34 +0100 This issue was detected by using the Coccinelle software. Move the jump label directly before the desired log statement so that the variable "ret" will not be checked once more after it was determined that a function call failed. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/media/tuners/m88rs6000t.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/drivers/media/tuners/m88rs6000t.c b/drivers/media/tuners/m88rs6000t.c index 504bfbc..b45594e 100644 --- a/drivers/media/tuners/m88rs6000t.c +++ b/drivers/media/tuners/m88rs6000t.c @@ -510,27 +510,27 @@ static int m88rs6000t_get_rf_strength(struct dvb_frontend *fe, u16 *strength) ret = regmap_read(dev->regmap, 0x5A, &val); if (ret) - goto err; + goto report_failure; RF_GC = val & 0x0f; ret = regmap_read(dev->regmap, 0x5F, &val); if (ret) - goto err; + goto report_failure; IF_GC = val & 0x0f; ret = regmap_read(dev->regmap, 0x3F, &val); if (ret) - goto err; + goto report_failure; TIA_GC = (val >> 4) & 0x07; ret = regmap_read(dev->regmap, 0x77, &val); if (ret) - goto err; + goto report_failure; BB_GC = (val >> 4) & 0x0f; ret = regmap_read(dev->regmap, 0x76, &val); if (ret) - goto err; + goto report_failure; PGA2_GC = val & 0x3f; PGA2_cri = PGA2_GC >> 2; PGA2_crf = PGA2_GC & 0x03; @@ -562,9 +562,11 @@ static int m88rs6000t_get_rf_strength(struct dvb_frontend *fe, u16 *strength) /* scale value to 0x0000-0xffff */ gain = clamp_val(gain, 1000U, 10500U); *strength = (10500 - gain) * 0xffff / (10500 - 1000); -err: - if (ret) + + if (ret) { +report_failure: dev_dbg(&dev->client->dev, "failed=%d\n", ret); + } return ret; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH] [media] tuners: One check less in m88rs6000t_get_rf_strength() after error detection 2015-12-28 9:15 ` SF Markus Elfring @ 2015-12-28 9:20 ` Julia Lawall -1 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2015-12-28 9:20 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-media, Mauro Carvalho Chehab, LKML, kernel-janitors On Mon, 28 Dec 2015, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Mon, 28 Dec 2015 10:10:34 +0100 > > This issue was detected by using the Coccinelle software. > > Move the jump label directly before the desired log statement > so that the variable "ret" will not be checked once more > after it was determined that a function call failed. Why not avoid both unnecessary ifs and the enormous ugliness of a label inside an if by making two returns: a return 0 for success and a dev_dbg and return ret for failure? julia > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/media/tuners/m88rs6000t.c | 16 +++++++++------- > 1 file changed, 9 insertions(+), 7 deletions(-) > > diff --git a/drivers/media/tuners/m88rs6000t.c b/drivers/media/tuners/m88rs6000t.c > index 504bfbc..b45594e 100644 > --- a/drivers/media/tuners/m88rs6000t.c > +++ b/drivers/media/tuners/m88rs6000t.c > @@ -510,27 +510,27 @@ static int m88rs6000t_get_rf_strength(struct dvb_frontend *fe, u16 *strength) > > ret = regmap_read(dev->regmap, 0x5A, &val); > if (ret) > - goto err; > + goto report_failure; > RF_GC = val & 0x0f; > > ret = regmap_read(dev->regmap, 0x5F, &val); > if (ret) > - goto err; > + goto report_failure; > IF_GC = val & 0x0f; > > ret = regmap_read(dev->regmap, 0x3F, &val); > if (ret) > - goto err; > + goto report_failure; > TIA_GC = (val >> 4) & 0x07; > > ret = regmap_read(dev->regmap, 0x77, &val); > if (ret) > - goto err; > + goto report_failure; > BB_GC = (val >> 4) & 0x0f; > > ret = regmap_read(dev->regmap, 0x76, &val); > if (ret) > - goto err; > + goto report_failure; > PGA2_GC = val & 0x3f; > PGA2_cri = PGA2_GC >> 2; > PGA2_crf = PGA2_GC & 0x03; > @@ -562,9 +562,11 @@ static int m88rs6000t_get_rf_strength(struct dvb_frontend *fe, u16 *strength) > /* scale value to 0x0000-0xffff */ > gain = clamp_val(gain, 1000U, 10500U); > *strength = (10500 - gain) * 0xffff / (10500 - 1000); > -err: > - if (ret) > + > + if (ret) { > +report_failure: > dev_dbg(&dev->client->dev, "failed=%d\n", ret); > + } > return ret; > } > > -- > 2.6.3 > > -- > To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] [media] tuners: One check less in m88rs6000t_get_rf_strength() after error detection @ 2015-12-28 9:20 ` Julia Lawall 0 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2015-12-28 9:20 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-media, Mauro Carvalho Chehab, LKML, kernel-janitors On Mon, 28 Dec 2015, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Mon, 28 Dec 2015 10:10:34 +0100 > > This issue was detected by using the Coccinelle software. > > Move the jump label directly before the desired log statement > so that the variable "ret" will not be checked once more > after it was determined that a function call failed. Why not avoid both unnecessary ifs and the enormous ugliness of a label inside an if by making two returns: a return 0 for success and a dev_dbg and return ret for failure? julia > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/media/tuners/m88rs6000t.c | 16 +++++++++------- > 1 file changed, 9 insertions(+), 7 deletions(-) > > diff --git a/drivers/media/tuners/m88rs6000t.c b/drivers/media/tuners/m88rs6000t.c > index 504bfbc..b45594e 100644 > --- a/drivers/media/tuners/m88rs6000t.c > +++ b/drivers/media/tuners/m88rs6000t.c > @@ -510,27 +510,27 @@ static int m88rs6000t_get_rf_strength(struct dvb_frontend *fe, u16 *strength) > > ret = regmap_read(dev->regmap, 0x5A, &val); > if (ret) > - goto err; > + goto report_failure; > RF_GC = val & 0x0f; > > ret = regmap_read(dev->regmap, 0x5F, &val); > if (ret) > - goto err; > + goto report_failure; > IF_GC = val & 0x0f; > > ret = regmap_read(dev->regmap, 0x3F, &val); > if (ret) > - goto err; > + goto report_failure; > TIA_GC = (val >> 4) & 0x07; > > ret = regmap_read(dev->regmap, 0x77, &val); > if (ret) > - goto err; > + goto report_failure; > BB_GC = (val >> 4) & 0x0f; > > ret = regmap_read(dev->regmap, 0x76, &val); > if (ret) > - goto err; > + goto report_failure; > PGA2_GC = val & 0x3f; > PGA2_cri = PGA2_GC >> 2; > PGA2_crf = PGA2_GC & 0x03; > @@ -562,9 +562,11 @@ static int m88rs6000t_get_rf_strength(struct dvb_frontend *fe, u16 *strength) > /* scale value to 0x0000-0xffff */ > gain = clamp_val(gain, 1000U, 10500U); > *strength = (10500 - gain) * 0xffff / (10500 - 1000); > -err: > - if (ret) > + > + if (ret) { > +report_failure: > dev_dbg(&dev->client->dev, "failed=%d\n", ret); > + } > return ret; > } > > -- > 2.6.3 > > -- > To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [media] tuners: One check less in m88rs6000t_get_rf_strength() after error detection 2015-12-28 9:20 ` Julia Lawall @ 2015-12-28 10:30 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-28 10:30 UTC (permalink / raw) To: Julia Lawall; +Cc: linux-media, Mauro Carvalho Chehab, LKML, kernel-janitors >> Move the jump label directly before the desired log statement >> so that the variable "ret" will not be checked once more >> after it was determined that a function call failed. > > Why not avoid both unnecessary ifs I would find such a fine-tuning also nice in principle at more source code places. > and the enormous ugliness of a label inside an if by making two returns: > a return 0 for success and a dev_dbg and return ret for failure? How should your suggestion finally work when the desired execution success can be determined for such functions only after several other calls succeeded? Is consistent checking of failure predicates usually required? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [media] tuners: One check less in m88rs6000t_get_rf_strength() after error detection @ 2015-12-28 10:30 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-28 10:30 UTC (permalink / raw) To: Julia Lawall; +Cc: linux-media, Mauro Carvalho Chehab, LKML, kernel-janitors >> Move the jump label directly before the desired log statement >> so that the variable "ret" will not be checked once more >> after it was determined that a function call failed. > > Why not avoid both unnecessary ifs I would find such a fine-tuning also nice in principle at more source code places. > and the enormous ugliness of a label inside an if by making two returns: > a return 0 for success and a dev_dbg and return ret for failure? How should your suggestion finally work when the desired execution success can be determined for such functions only after several other calls succeeded? Is consistent checking of failure predicates usually required? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [media] tuners: One check less in m88rs6000t_get_rf_strength() after error detection 2015-12-28 10:30 ` SF Markus Elfring @ 2015-12-28 10:36 ` Julia Lawall -1 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2015-12-28 10:36 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-media, Mauro Carvalho Chehab, LKML, kernel-janitors On Mon, 28 Dec 2015, SF Markus Elfring wrote: > >> Move the jump label directly before the desired log statement > >> so that the variable "ret" will not be checked once more > >> after it was determined that a function call failed. > > > > Why not avoid both unnecessary ifs > > I would find such a fine-tuning also nice in principle at more source code places. > > > > and the enormous ugliness of a label inside an if by making two returns: > > a return 0 for success and a dev_dbg and return ret for failure? > > How should your suggestion finally work when the desired execution success > can be determined for such functions only after several other calls succeeded? Not idea what this means, but immediate return 0 followed by various code for reacting to an error is very common, so it looks like it should be possible here. julia ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [media] tuners: One check less in m88rs6000t_get_rf_strength() after error detection @ 2015-12-28 10:36 ` Julia Lawall 0 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2015-12-28 10:36 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-media, Mauro Carvalho Chehab, LKML, kernel-janitors On Mon, 28 Dec 2015, SF Markus Elfring wrote: > >> Move the jump label directly before the desired log statement > >> so that the variable "ret" will not be checked once more > >> after it was determined that a function call failed. > > > > Why not avoid both unnecessary ifs > > I would find such a fine-tuning also nice in principle at more source code places. > > > > and the enormous ugliness of a label inside an if by making two returns: > > a return 0 for success and a dev_dbg and return ret for failure? > > How should your suggestion finally work when the desired execution success > can be determined for such functions only after several other calls succeeded? Not idea what this means, but immediate return 0 followed by various code for reacting to an error is very common, so it looks like it should be possible here. julia ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/2] [media] m88rs6000t: Fine-tuning for some function implementations 2015-12-28 10:36 ` Julia Lawall @ 2015-12-28 14:36 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-28 14:36 UTC (permalink / raw) To: linux-media, Mauro Carvalho Chehab; +Cc: Julia Lawall, LKML, kernel-janitors From: Markus Elfring <elfring@users.sourceforge.net> Date: Mon, 28 Dec 2015 15:32:20 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (2): Better exception handling in five functions Refactoring for m88rs6000t_sleep() drivers/media/tuners/m88rs6000t.c | 165 +++++++++++++++++++------------------- 1 file changed, 83 insertions(+), 82 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/2] [media] m88rs6000t: Fine-tuning for some function implementations @ 2015-12-28 14:36 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-28 14:36 UTC (permalink / raw) To: linux-media, Mauro Carvalho Chehab; +Cc: Julia Lawall, LKML, kernel-janitors From: Markus Elfring <elfring@users.sourceforge.net> Date: Mon, 28 Dec 2015 15:32:20 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (2): Better exception handling in five functions Refactoring for m88rs6000t_sleep() drivers/media/tuners/m88rs6000t.c | 165 +++++++++++++++++++------------------- 1 file changed, 83 insertions(+), 82 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 1/2] [media] m88rs6000t: Better exception handling in five functions 2015-12-28 14:36 ` SF Markus Elfring @ 2015-12-28 14:38 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-28 14:38 UTC (permalink / raw) To: linux-media, Mauro Carvalho Chehab; +Cc: Julia Lawall, LKML, kernel-janitors From: Markus Elfring <elfring@users.sourceforge.net> Date: Mon, 28 Dec 2015 15:10:30 +0100 This issue was detected by using the Coccinelle software. Move the jump label directly before the desired log statement so that the variable "ret" will not be checked once more after a function call. Use the identifier "report_failure" instead of "err". Suggested-by: Julia Lawall <julia.lawall@lip6.fr> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/media/tuners/m88rs6000t.c | 154 +++++++++++++++++++------------------- 1 file changed, 78 insertions(+), 76 deletions(-) diff --git a/drivers/media/tuners/m88rs6000t.c b/drivers/media/tuners/m88rs6000t.c index 504bfbc..7e59a9f 100644 --- a/drivers/media/tuners/m88rs6000t.c +++ b/drivers/media/tuners/m88rs6000t.c @@ -44,7 +44,7 @@ static int m88rs6000t_set_demod_mclk(struct dvb_frontend *fe) /* select demod main mclk */ ret = regmap_read(dev->regmap, 0x15, &utmp); if (ret) - goto err; + goto report_failure; reg15 = utmp; if (c->symbol_rate > 45010000) { reg11 = 0x0E; @@ -106,7 +106,7 @@ static int m88rs6000t_set_demod_mclk(struct dvb_frontend *fe) ret = regmap_read(dev->regmap, 0x1D, &utmp); if (ret) - goto err; + goto report_failure; reg1D = utmp; reg1D &= ~0x03; reg1D |= N - 1; @@ -116,42 +116,42 @@ static int m88rs6000t_set_demod_mclk(struct dvb_frontend *fe) /* program and recalibrate demod PLL */ ret = regmap_write(dev->regmap, 0x05, 0x40); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x11, 0x08); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x15, reg15); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x16, reg16); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x1D, reg1D); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x1E, reg1E); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x1F, reg1F); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x17, 0xc1); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x17, 0x81); if (ret) - goto err; + goto report_failure; usleep_range(5000, 50000); ret = regmap_write(dev->regmap, 0x05, 0x00); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x11, reg11); if (ret) - goto err; + goto report_failure; usleep_range(5000, 50000); -err: - if (ret) - dev_dbg(&dev->client->dev, "failed=%d\n", ret); + return 0; +report_failure: + dev_dbg(&dev->client->dev, "failed=%d\n", ret); return ret; } @@ -169,13 +169,13 @@ static int m88rs6000t_set_pll_freq(struct m88rs6000t_dev *dev, ret = regmap_write(dev->regmap, 0x36, (refDiv - 8)); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x31, 0x00); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x2c, 0x02); if (ret) - goto err; + goto report_failure; if (tuner_freq_MHz >= 1550) { ucLoDiv1 = 2; @@ -227,105 +227,105 @@ static int m88rs6000t_set_pll_freq(struct m88rs6000t_dev *dev, reg27 = (((ulNDiv1 >> 8) & 0x0F) + ucLomod1) & 0x7F; ret = regmap_write(dev->regmap, 0x27, reg27); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x28, (u8)(ulNDiv1 & 0xFF)); if (ret) - goto err; + goto report_failure; reg29 = (((ulNDiv2 >> 8) & 0x0F) + ucLomod2) & 0x7f; ret = regmap_write(dev->regmap, 0x29, reg29); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x2a, (u8)(ulNDiv2 & 0xFF)); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x2F, 0xf5); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x30, 0x05); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x08, 0x1f); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x08, 0x3f); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x09, 0x20); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x09, 0x00); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x3e, 0x11); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x08, 0x2f); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x08, 0x3f); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x09, 0x10); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x09, 0x00); if (ret) - goto err; + goto report_failure; usleep_range(2000, 50000); ret = regmap_read(dev->regmap, 0x42, &utmp); if (ret) - goto err; + goto report_failure; reg42 = utmp; ret = regmap_write(dev->regmap, 0x3e, 0x10); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x08, 0x2f); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x08, 0x3f); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x09, 0x10); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x09, 0x00); if (ret) - goto err; + goto report_failure; usleep_range(2000, 50000); ret = regmap_read(dev->regmap, 0x42, &utmp); if (ret) - goto err; + goto report_failure; reg42buf = utmp; if (reg42buf < reg42) { ret = regmap_write(dev->regmap, 0x3e, 0x11); if (ret) - goto err; + goto report_failure; } usleep_range(5000, 50000); ret = regmap_read(dev->regmap, 0x2d, &utmp); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x2d, utmp); if (ret) - goto err; + goto report_failure; ret = regmap_read(dev->regmap, 0x2e, &utmp); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x2e, utmp); if (ret) - goto err; + goto report_failure; ret = regmap_read(dev->regmap, 0x27, &utmp); if (ret) - goto err; + goto report_failure; reg27 = utmp & 0x70; ret = regmap_read(dev->regmap, 0x83, &utmp); if (ret) - goto err; + goto report_failure; if (reg27 == (utmp & 0x70)) { ucLoDiv = ucLoDiv1; ulNDiv = ulNDiv1; @@ -340,7 +340,7 @@ static int m88rs6000t_set_pll_freq(struct m88rs6000t_dev *dev, refDiv = 18; ret = regmap_write(dev->regmap, 0x36, (refDiv - 8)); if (ret) - goto err; + goto report_failure; ulNDiv = ((tuner_freq_MHz * ucLoDiv * 1000) * refDiv / fcry_KHz - 1024) / 2; } @@ -349,16 +349,16 @@ static int m88rs6000t_set_pll_freq(struct m88rs6000t_dev *dev, + ((ulNDiv >> 8) & 0x0F)) & 0xFF; ret = regmap_write(dev->regmap, 0x27, reg27); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x28, (u8)(ulNDiv & 0xFF)); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x29, 0x80); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x31, 0x03); if (ret) - goto err; + goto report_failure; if (ucLoDiv == 3) utmp = 0xCE; @@ -366,15 +366,15 @@ static int m88rs6000t_set_pll_freq(struct m88rs6000t_dev *dev, utmp = 0x8A; ret = regmap_write(dev->regmap, 0x3b, utmp); if (ret) - goto err; + goto report_failure; dev->frequency_khz = fcry_KHz * (ulNDiv * 2 + 1024) / refDiv / ucLoDiv; dev_dbg(&dev->client->dev, "actual tune frequency=%d\n", dev->frequency_khz); -err: - if (ret) - dev_dbg(&dev->client->dev, "failed=%d\n", ret); + return 0; +report_failure: + dev_dbg(&dev->client->dev, "failed=%d\n", ret); return ret; } @@ -413,21 +413,23 @@ static int m88rs6000t_set_params(struct dvb_frontend *fe) freq_MHz = (realFreq + 500) / 1000; ret = m88rs6000t_set_pll_freq(dev, freq_MHz); if (ret) - goto err; + goto report_failure; ret = m88rs6000t_set_bb(dev, c->symbol_rate / 1000, lpf_offset_KHz); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x00, 0x01); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x00, 0x00); if (ret) - goto err; + goto report_failure; /* set demod mlck */ ret = m88rs6000t_set_demod_mclk(fe); -err: if (ret) - dev_dbg(&dev->client->dev, "failed=%d\n", ret); + goto report_failure; + return 0; +report_failure: + dev_dbg(&dev->client->dev, "failed=%d\n", ret); return ret; } @@ -440,16 +442,16 @@ static int m88rs6000t_init(struct dvb_frontend *fe) ret = regmap_update_bits(dev->regmap, 0x11, 0x08, 0x08); if (ret) - goto err; + goto report_failure; usleep_range(5000, 50000); ret = regmap_update_bits(dev->regmap, 0x10, 0x01, 0x01); if (ret) - goto err; + goto report_failure; usleep_range(10000, 50000); ret = regmap_write(dev->regmap, 0x07, 0x7d); -err: - if (ret) - dev_dbg(&dev->client->dev, "failed=%d\n", ret); + return 0; +report_failure: + dev_dbg(&dev->client->dev, "failed=%d\n", ret); return ret; } @@ -510,27 +512,27 @@ static int m88rs6000t_get_rf_strength(struct dvb_frontend *fe, u16 *strength) ret = regmap_read(dev->regmap, 0x5A, &val); if (ret) - goto err; + goto report_failure; RF_GC = val & 0x0f; ret = regmap_read(dev->regmap, 0x5F, &val); if (ret) - goto err; + goto report_failure; IF_GC = val & 0x0f; ret = regmap_read(dev->regmap, 0x3F, &val); if (ret) - goto err; + goto report_failure; TIA_GC = (val >> 4) & 0x07; ret = regmap_read(dev->regmap, 0x77, &val); if (ret) - goto err; + goto report_failure; BB_GC = (val >> 4) & 0x0f; ret = regmap_read(dev->regmap, 0x76, &val); if (ret) - goto err; + goto report_failure; PGA2_GC = val & 0x3f; PGA2_cri = PGA2_GC >> 2; PGA2_crf = PGA2_GC & 0x03; @@ -562,9 +564,9 @@ static int m88rs6000t_get_rf_strength(struct dvb_frontend *fe, u16 *strength) /* scale value to 0x0000-0xffff */ gain = clamp_val(gain, 1000U, 10500U); *strength = (10500 - gain) * 0xffff / (10500 - 1000); -err: - if (ret) - dev_dbg(&dev->client->dev, "failed=%d\n", ret); + return 0; +report_failure: + dev_dbg(&dev->client->dev, "failed=%d\n", ret); return ret; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 1/2] [media] m88rs6000t: Better exception handling in five functions @ 2015-12-28 14:38 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-28 14:38 UTC (permalink / raw) To: linux-media, Mauro Carvalho Chehab; +Cc: Julia Lawall, LKML, kernel-janitors From: Markus Elfring <elfring@users.sourceforge.net> Date: Mon, 28 Dec 2015 15:10:30 +0100 This issue was detected by using the Coccinelle software. Move the jump label directly before the desired log statement so that the variable "ret" will not be checked once more after a function call. Use the identifier "report_failure" instead of "err". Suggested-by: Julia Lawall <julia.lawall@lip6.fr> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/media/tuners/m88rs6000t.c | 154 +++++++++++++++++++------------------- 1 file changed, 78 insertions(+), 76 deletions(-) diff --git a/drivers/media/tuners/m88rs6000t.c b/drivers/media/tuners/m88rs6000t.c index 504bfbc..7e59a9f 100644 --- a/drivers/media/tuners/m88rs6000t.c +++ b/drivers/media/tuners/m88rs6000t.c @@ -44,7 +44,7 @@ static int m88rs6000t_set_demod_mclk(struct dvb_frontend *fe) /* select demod main mclk */ ret = regmap_read(dev->regmap, 0x15, &utmp); if (ret) - goto err; + goto report_failure; reg15 = utmp; if (c->symbol_rate > 45010000) { reg11 = 0x0E; @@ -106,7 +106,7 @@ static int m88rs6000t_set_demod_mclk(struct dvb_frontend *fe) ret = regmap_read(dev->regmap, 0x1D, &utmp); if (ret) - goto err; + goto report_failure; reg1D = utmp; reg1D &= ~0x03; reg1D |= N - 1; @@ -116,42 +116,42 @@ static int m88rs6000t_set_demod_mclk(struct dvb_frontend *fe) /* program and recalibrate demod PLL */ ret = regmap_write(dev->regmap, 0x05, 0x40); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x11, 0x08); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x15, reg15); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x16, reg16); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x1D, reg1D); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x1E, reg1E); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x1F, reg1F); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x17, 0xc1); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x17, 0x81); if (ret) - goto err; + goto report_failure; usleep_range(5000, 50000); ret = regmap_write(dev->regmap, 0x05, 0x00); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x11, reg11); if (ret) - goto err; + goto report_failure; usleep_range(5000, 50000); -err: - if (ret) - dev_dbg(&dev->client->dev, "failed=%d\n", ret); + return 0; +report_failure: + dev_dbg(&dev->client->dev, "failed=%d\n", ret); return ret; } @@ -169,13 +169,13 @@ static int m88rs6000t_set_pll_freq(struct m88rs6000t_dev *dev, ret = regmap_write(dev->regmap, 0x36, (refDiv - 8)); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x31, 0x00); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x2c, 0x02); if (ret) - goto err; + goto report_failure; if (tuner_freq_MHz >= 1550) { ucLoDiv1 = 2; @@ -227,105 +227,105 @@ static int m88rs6000t_set_pll_freq(struct m88rs6000t_dev *dev, reg27 = (((ulNDiv1 >> 8) & 0x0F) + ucLomod1) & 0x7F; ret = regmap_write(dev->regmap, 0x27, reg27); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x28, (u8)(ulNDiv1 & 0xFF)); if (ret) - goto err; + goto report_failure; reg29 = (((ulNDiv2 >> 8) & 0x0F) + ucLomod2) & 0x7f; ret = regmap_write(dev->regmap, 0x29, reg29); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x2a, (u8)(ulNDiv2 & 0xFF)); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x2F, 0xf5); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x30, 0x05); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x08, 0x1f); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x08, 0x3f); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x09, 0x20); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x09, 0x00); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x3e, 0x11); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x08, 0x2f); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x08, 0x3f); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x09, 0x10); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x09, 0x00); if (ret) - goto err; + goto report_failure; usleep_range(2000, 50000); ret = regmap_read(dev->regmap, 0x42, &utmp); if (ret) - goto err; + goto report_failure; reg42 = utmp; ret = regmap_write(dev->regmap, 0x3e, 0x10); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x08, 0x2f); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x08, 0x3f); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x09, 0x10); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x09, 0x00); if (ret) - goto err; + goto report_failure; usleep_range(2000, 50000); ret = regmap_read(dev->regmap, 0x42, &utmp); if (ret) - goto err; + goto report_failure; reg42buf = utmp; if (reg42buf < reg42) { ret = regmap_write(dev->regmap, 0x3e, 0x11); if (ret) - goto err; + goto report_failure; } usleep_range(5000, 50000); ret = regmap_read(dev->regmap, 0x2d, &utmp); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x2d, utmp); if (ret) - goto err; + goto report_failure; ret = regmap_read(dev->regmap, 0x2e, &utmp); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x2e, utmp); if (ret) - goto err; + goto report_failure; ret = regmap_read(dev->regmap, 0x27, &utmp); if (ret) - goto err; + goto report_failure; reg27 = utmp & 0x70; ret = regmap_read(dev->regmap, 0x83, &utmp); if (ret) - goto err; + goto report_failure; if (reg27 = (utmp & 0x70)) { ucLoDiv = ucLoDiv1; ulNDiv = ulNDiv1; @@ -340,7 +340,7 @@ static int m88rs6000t_set_pll_freq(struct m88rs6000t_dev *dev, refDiv = 18; ret = regmap_write(dev->regmap, 0x36, (refDiv - 8)); if (ret) - goto err; + goto report_failure; ulNDiv = ((tuner_freq_MHz * ucLoDiv * 1000) * refDiv / fcry_KHz - 1024) / 2; } @@ -349,16 +349,16 @@ static int m88rs6000t_set_pll_freq(struct m88rs6000t_dev *dev, + ((ulNDiv >> 8) & 0x0F)) & 0xFF; ret = regmap_write(dev->regmap, 0x27, reg27); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x28, (u8)(ulNDiv & 0xFF)); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x29, 0x80); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x31, 0x03); if (ret) - goto err; + goto report_failure; if (ucLoDiv = 3) utmp = 0xCE; @@ -366,15 +366,15 @@ static int m88rs6000t_set_pll_freq(struct m88rs6000t_dev *dev, utmp = 0x8A; ret = regmap_write(dev->regmap, 0x3b, utmp); if (ret) - goto err; + goto report_failure; dev->frequency_khz = fcry_KHz * (ulNDiv * 2 + 1024) / refDiv / ucLoDiv; dev_dbg(&dev->client->dev, "actual tune frequency=%d\n", dev->frequency_khz); -err: - if (ret) - dev_dbg(&dev->client->dev, "failed=%d\n", ret); + return 0; +report_failure: + dev_dbg(&dev->client->dev, "failed=%d\n", ret); return ret; } @@ -413,21 +413,23 @@ static int m88rs6000t_set_params(struct dvb_frontend *fe) freq_MHz = (realFreq + 500) / 1000; ret = m88rs6000t_set_pll_freq(dev, freq_MHz); if (ret) - goto err; + goto report_failure; ret = m88rs6000t_set_bb(dev, c->symbol_rate / 1000, lpf_offset_KHz); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x00, 0x01); if (ret) - goto err; + goto report_failure; ret = regmap_write(dev->regmap, 0x00, 0x00); if (ret) - goto err; + goto report_failure; /* set demod mlck */ ret = m88rs6000t_set_demod_mclk(fe); -err: if (ret) - dev_dbg(&dev->client->dev, "failed=%d\n", ret); + goto report_failure; + return 0; +report_failure: + dev_dbg(&dev->client->dev, "failed=%d\n", ret); return ret; } @@ -440,16 +442,16 @@ static int m88rs6000t_init(struct dvb_frontend *fe) ret = regmap_update_bits(dev->regmap, 0x11, 0x08, 0x08); if (ret) - goto err; + goto report_failure; usleep_range(5000, 50000); ret = regmap_update_bits(dev->regmap, 0x10, 0x01, 0x01); if (ret) - goto err; + goto report_failure; usleep_range(10000, 50000); ret = regmap_write(dev->regmap, 0x07, 0x7d); -err: - if (ret) - dev_dbg(&dev->client->dev, "failed=%d\n", ret); + return 0; +report_failure: + dev_dbg(&dev->client->dev, "failed=%d\n", ret); return ret; } @@ -510,27 +512,27 @@ static int m88rs6000t_get_rf_strength(struct dvb_frontend *fe, u16 *strength) ret = regmap_read(dev->regmap, 0x5A, &val); if (ret) - goto err; + goto report_failure; RF_GC = val & 0x0f; ret = regmap_read(dev->regmap, 0x5F, &val); if (ret) - goto err; + goto report_failure; IF_GC = val & 0x0f; ret = regmap_read(dev->regmap, 0x3F, &val); if (ret) - goto err; + goto report_failure; TIA_GC = (val >> 4) & 0x07; ret = regmap_read(dev->regmap, 0x77, &val); if (ret) - goto err; + goto report_failure; BB_GC = (val >> 4) & 0x0f; ret = regmap_read(dev->regmap, 0x76, &val); if (ret) - goto err; + goto report_failure; PGA2_GC = val & 0x3f; PGA2_cri = PGA2_GC >> 2; PGA2_crf = PGA2_GC & 0x03; @@ -562,9 +564,9 @@ static int m88rs6000t_get_rf_strength(struct dvb_frontend *fe, u16 *strength) /* scale value to 0x0000-0xffff */ gain = clamp_val(gain, 1000U, 10500U); *strength = (10500 - gain) * 0xffff / (10500 - 1000); -err: - if (ret) - dev_dbg(&dev->client->dev, "failed=%d\n", ret); + return 0; +report_failure: + dev_dbg(&dev->client->dev, "failed=%d\n", ret); return ret; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/2] [media] m88rs6000t: Better exception handling in five functions 2015-12-28 14:38 ` SF Markus Elfring @ 2015-12-28 14:42 ` Julia Lawall -1 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2015-12-28 14:42 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-media, Mauro Carvalho Chehab, LKML, kernel-janitors On Mon, 28 Dec 2015, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Mon, 28 Dec 2015 15:10:30 +0100 > > This issue was detected by using the Coccinelle software. > > Move the jump label directly before the desired log statement > so that the variable "ret" will not be checked once more > after a function call. This commit message fits with the previous change. It could be nice to put a blank line before the error handling code. See what is done elsewhere in the file. julia > > Suggested-by: Julia Lawall <julia.lawall@lip6.fr> > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/media/tuners/m88rs6000t.c | 154 +++++++++++++++++++------------------- > 1 file changed, 78 insertions(+), 76 deletions(-) > > diff --git a/drivers/media/tuners/m88rs6000t.c b/drivers/media/tuners/m88rs6000t.c > index 504bfbc..7e59a9f 100644 > --- a/drivers/media/tuners/m88rs6000t.c > +++ b/drivers/media/tuners/m88rs6000t.c > @@ -44,7 +44,7 @@ static int m88rs6000t_set_demod_mclk(struct dvb_frontend *fe) > /* select demod main mclk */ > ret = regmap_read(dev->regmap, 0x15, &utmp); > if (ret) > - goto err; > + goto report_failure; > reg15 = utmp; > if (c->symbol_rate > 45010000) { > reg11 = 0x0E; > @@ -106,7 +106,7 @@ static int m88rs6000t_set_demod_mclk(struct dvb_frontend *fe) > > ret = regmap_read(dev->regmap, 0x1D, &utmp); > if (ret) > - goto err; > + goto report_failure; > reg1D = utmp; > reg1D &= ~0x03; > reg1D |= N - 1; > @@ -116,42 +116,42 @@ static int m88rs6000t_set_demod_mclk(struct dvb_frontend *fe) > /* program and recalibrate demod PLL */ > ret = regmap_write(dev->regmap, 0x05, 0x40); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x11, 0x08); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x15, reg15); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x16, reg16); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x1D, reg1D); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x1E, reg1E); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x1F, reg1F); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x17, 0xc1); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x17, 0x81); > if (ret) > - goto err; > + goto report_failure; > usleep_range(5000, 50000); > ret = regmap_write(dev->regmap, 0x05, 0x00); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x11, reg11); > if (ret) > - goto err; > + goto report_failure; > usleep_range(5000, 50000); > -err: > - if (ret) > - dev_dbg(&dev->client->dev, "failed=%d\n", ret); > + return 0; > +report_failure: > + dev_dbg(&dev->client->dev, "failed=%d\n", ret); > return ret; > } > > @@ -169,13 +169,13 @@ static int m88rs6000t_set_pll_freq(struct m88rs6000t_dev *dev, > > ret = regmap_write(dev->regmap, 0x36, (refDiv - 8)); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x31, 0x00); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x2c, 0x02); > if (ret) > - goto err; > + goto report_failure; > > if (tuner_freq_MHz >= 1550) { > ucLoDiv1 = 2; > @@ -227,105 +227,105 @@ static int m88rs6000t_set_pll_freq(struct m88rs6000t_dev *dev, > reg27 = (((ulNDiv1 >> 8) & 0x0F) + ucLomod1) & 0x7F; > ret = regmap_write(dev->regmap, 0x27, reg27); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x28, (u8)(ulNDiv1 & 0xFF)); > if (ret) > - goto err; > + goto report_failure; > reg29 = (((ulNDiv2 >> 8) & 0x0F) + ucLomod2) & 0x7f; > ret = regmap_write(dev->regmap, 0x29, reg29); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x2a, (u8)(ulNDiv2 & 0xFF)); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x2F, 0xf5); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x30, 0x05); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x08, 0x1f); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x08, 0x3f); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x09, 0x20); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x09, 0x00); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x3e, 0x11); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x08, 0x2f); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x08, 0x3f); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x09, 0x10); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x09, 0x00); > if (ret) > - goto err; > + goto report_failure; > usleep_range(2000, 50000); > > ret = regmap_read(dev->regmap, 0x42, &utmp); > if (ret) > - goto err; > + goto report_failure; > reg42 = utmp; > > ret = regmap_write(dev->regmap, 0x3e, 0x10); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x08, 0x2f); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x08, 0x3f); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x09, 0x10); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x09, 0x00); > if (ret) > - goto err; > + goto report_failure; > usleep_range(2000, 50000); > > ret = regmap_read(dev->regmap, 0x42, &utmp); > if (ret) > - goto err; > + goto report_failure; > reg42buf = utmp; > if (reg42buf < reg42) { > ret = regmap_write(dev->regmap, 0x3e, 0x11); > if (ret) > - goto err; > + goto report_failure; > } > usleep_range(5000, 50000); > > ret = regmap_read(dev->regmap, 0x2d, &utmp); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x2d, utmp); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_read(dev->regmap, 0x2e, &utmp); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x2e, utmp); > if (ret) > - goto err; > + goto report_failure; > > ret = regmap_read(dev->regmap, 0x27, &utmp); > if (ret) > - goto err; > + goto report_failure; > reg27 = utmp & 0x70; > ret = regmap_read(dev->regmap, 0x83, &utmp); > if (ret) > - goto err; > + goto report_failure; > if (reg27 == (utmp & 0x70)) { > ucLoDiv = ucLoDiv1; > ulNDiv = ulNDiv1; > @@ -340,7 +340,7 @@ static int m88rs6000t_set_pll_freq(struct m88rs6000t_dev *dev, > refDiv = 18; > ret = regmap_write(dev->regmap, 0x36, (refDiv - 8)); > if (ret) > - goto err; > + goto report_failure; > ulNDiv = ((tuner_freq_MHz * ucLoDiv * 1000) * refDiv > / fcry_KHz - 1024) / 2; > } > @@ -349,16 +349,16 @@ static int m88rs6000t_set_pll_freq(struct m88rs6000t_dev *dev, > + ((ulNDiv >> 8) & 0x0F)) & 0xFF; > ret = regmap_write(dev->regmap, 0x27, reg27); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x28, (u8)(ulNDiv & 0xFF)); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x29, 0x80); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x31, 0x03); > if (ret) > - goto err; > + goto report_failure; > > if (ucLoDiv == 3) > utmp = 0xCE; > @@ -366,15 +366,15 @@ static int m88rs6000t_set_pll_freq(struct m88rs6000t_dev *dev, > utmp = 0x8A; > ret = regmap_write(dev->regmap, 0x3b, utmp); > if (ret) > - goto err; > + goto report_failure; > > dev->frequency_khz = fcry_KHz * (ulNDiv * 2 + 1024) / refDiv / ucLoDiv; > > dev_dbg(&dev->client->dev, > "actual tune frequency=%d\n", dev->frequency_khz); > -err: > - if (ret) > - dev_dbg(&dev->client->dev, "failed=%d\n", ret); > + return 0; > +report_failure: > + dev_dbg(&dev->client->dev, "failed=%d\n", ret); > return ret; > } > > @@ -413,21 +413,23 @@ static int m88rs6000t_set_params(struct dvb_frontend *fe) > freq_MHz = (realFreq + 500) / 1000; > ret = m88rs6000t_set_pll_freq(dev, freq_MHz); > if (ret) > - goto err; > + goto report_failure; > ret = m88rs6000t_set_bb(dev, c->symbol_rate / 1000, lpf_offset_KHz); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x00, 0x01); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x00, 0x00); > if (ret) > - goto err; > + goto report_failure; > /* set demod mlck */ > ret = m88rs6000t_set_demod_mclk(fe); > -err: > if (ret) > - dev_dbg(&dev->client->dev, "failed=%d\n", ret); > + goto report_failure; > + return 0; > +report_failure: > + dev_dbg(&dev->client->dev, "failed=%d\n", ret); > return ret; > } > > @@ -440,16 +442,16 @@ static int m88rs6000t_init(struct dvb_frontend *fe) > > ret = regmap_update_bits(dev->regmap, 0x11, 0x08, 0x08); > if (ret) > - goto err; > + goto report_failure; > usleep_range(5000, 50000); > ret = regmap_update_bits(dev->regmap, 0x10, 0x01, 0x01); > if (ret) > - goto err; > + goto report_failure; > usleep_range(10000, 50000); > ret = regmap_write(dev->regmap, 0x07, 0x7d); > -err: > - if (ret) > - dev_dbg(&dev->client->dev, "failed=%d\n", ret); > + return 0; > +report_failure: > + dev_dbg(&dev->client->dev, "failed=%d\n", ret); > return ret; > } > > @@ -510,27 +512,27 @@ static int m88rs6000t_get_rf_strength(struct dvb_frontend *fe, u16 *strength) > > ret = regmap_read(dev->regmap, 0x5A, &val); > if (ret) > - goto err; > + goto report_failure; > RF_GC = val & 0x0f; > > ret = regmap_read(dev->regmap, 0x5F, &val); > if (ret) > - goto err; > + goto report_failure; > IF_GC = val & 0x0f; > > ret = regmap_read(dev->regmap, 0x3F, &val); > if (ret) > - goto err; > + goto report_failure; > TIA_GC = (val >> 4) & 0x07; > > ret = regmap_read(dev->regmap, 0x77, &val); > if (ret) > - goto err; > + goto report_failure; > BB_GC = (val >> 4) & 0x0f; > > ret = regmap_read(dev->regmap, 0x76, &val); > if (ret) > - goto err; > + goto report_failure; > PGA2_GC = val & 0x3f; > PGA2_cri = PGA2_GC >> 2; > PGA2_crf = PGA2_GC & 0x03; > @@ -562,9 +564,9 @@ static int m88rs6000t_get_rf_strength(struct dvb_frontend *fe, u16 *strength) > /* scale value to 0x0000-0xffff */ > gain = clamp_val(gain, 1000U, 10500U); > *strength = (10500 - gain) * 0xffff / (10500 - 1000); > -err: > - if (ret) > - dev_dbg(&dev->client->dev, "failed=%d\n", ret); > + return 0; > +report_failure: > + dev_dbg(&dev->client->dev, "failed=%d\n", ret); > return ret; > } > > -- > 2.6.3 > > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/2] [media] m88rs6000t: Better exception handling in five functions @ 2015-12-28 14:42 ` Julia Lawall 0 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2015-12-28 14:42 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-media, Mauro Carvalho Chehab, LKML, kernel-janitors On Mon, 28 Dec 2015, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Mon, 28 Dec 2015 15:10:30 +0100 > > This issue was detected by using the Coccinelle software. > > Move the jump label directly before the desired log statement > so that the variable "ret" will not be checked once more > after a function call. This commit message fits with the previous change. It could be nice to put a blank line before the error handling code. See what is done elsewhere in the file. julia > > Suggested-by: Julia Lawall <julia.lawall@lip6.fr> > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/media/tuners/m88rs6000t.c | 154 +++++++++++++++++++------------------- > 1 file changed, 78 insertions(+), 76 deletions(-) > > diff --git a/drivers/media/tuners/m88rs6000t.c b/drivers/media/tuners/m88rs6000t.c > index 504bfbc..7e59a9f 100644 > --- a/drivers/media/tuners/m88rs6000t.c > +++ b/drivers/media/tuners/m88rs6000t.c > @@ -44,7 +44,7 @@ static int m88rs6000t_set_demod_mclk(struct dvb_frontend *fe) > /* select demod main mclk */ > ret = regmap_read(dev->regmap, 0x15, &utmp); > if (ret) > - goto err; > + goto report_failure; > reg15 = utmp; > if (c->symbol_rate > 45010000) { > reg11 = 0x0E; > @@ -106,7 +106,7 @@ static int m88rs6000t_set_demod_mclk(struct dvb_frontend *fe) > > ret = regmap_read(dev->regmap, 0x1D, &utmp); > if (ret) > - goto err; > + goto report_failure; > reg1D = utmp; > reg1D &= ~0x03; > reg1D |= N - 1; > @@ -116,42 +116,42 @@ static int m88rs6000t_set_demod_mclk(struct dvb_frontend *fe) > /* program and recalibrate demod PLL */ > ret = regmap_write(dev->regmap, 0x05, 0x40); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x11, 0x08); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x15, reg15); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x16, reg16); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x1D, reg1D); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x1E, reg1E); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x1F, reg1F); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x17, 0xc1); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x17, 0x81); > if (ret) > - goto err; > + goto report_failure; > usleep_range(5000, 50000); > ret = regmap_write(dev->regmap, 0x05, 0x00); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x11, reg11); > if (ret) > - goto err; > + goto report_failure; > usleep_range(5000, 50000); > -err: > - if (ret) > - dev_dbg(&dev->client->dev, "failed=%d\n", ret); > + return 0; > +report_failure: > + dev_dbg(&dev->client->dev, "failed=%d\n", ret); > return ret; > } > > @@ -169,13 +169,13 @@ static int m88rs6000t_set_pll_freq(struct m88rs6000t_dev *dev, > > ret = regmap_write(dev->regmap, 0x36, (refDiv - 8)); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x31, 0x00); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x2c, 0x02); > if (ret) > - goto err; > + goto report_failure; > > if (tuner_freq_MHz >= 1550) { > ucLoDiv1 = 2; > @@ -227,105 +227,105 @@ static int m88rs6000t_set_pll_freq(struct m88rs6000t_dev *dev, > reg27 = (((ulNDiv1 >> 8) & 0x0F) + ucLomod1) & 0x7F; > ret = regmap_write(dev->regmap, 0x27, reg27); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x28, (u8)(ulNDiv1 & 0xFF)); > if (ret) > - goto err; > + goto report_failure; > reg29 = (((ulNDiv2 >> 8) & 0x0F) + ucLomod2) & 0x7f; > ret = regmap_write(dev->regmap, 0x29, reg29); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x2a, (u8)(ulNDiv2 & 0xFF)); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x2F, 0xf5); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x30, 0x05); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x08, 0x1f); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x08, 0x3f); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x09, 0x20); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x09, 0x00); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x3e, 0x11); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x08, 0x2f); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x08, 0x3f); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x09, 0x10); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x09, 0x00); > if (ret) > - goto err; > + goto report_failure; > usleep_range(2000, 50000); > > ret = regmap_read(dev->regmap, 0x42, &utmp); > if (ret) > - goto err; > + goto report_failure; > reg42 = utmp; > > ret = regmap_write(dev->regmap, 0x3e, 0x10); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x08, 0x2f); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x08, 0x3f); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x09, 0x10); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x09, 0x00); > if (ret) > - goto err; > + goto report_failure; > usleep_range(2000, 50000); > > ret = regmap_read(dev->regmap, 0x42, &utmp); > if (ret) > - goto err; > + goto report_failure; > reg42buf = utmp; > if (reg42buf < reg42) { > ret = regmap_write(dev->regmap, 0x3e, 0x11); > if (ret) > - goto err; > + goto report_failure; > } > usleep_range(5000, 50000); > > ret = regmap_read(dev->regmap, 0x2d, &utmp); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x2d, utmp); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_read(dev->regmap, 0x2e, &utmp); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x2e, utmp); > if (ret) > - goto err; > + goto report_failure; > > ret = regmap_read(dev->regmap, 0x27, &utmp); > if (ret) > - goto err; > + goto report_failure; > reg27 = utmp & 0x70; > ret = regmap_read(dev->regmap, 0x83, &utmp); > if (ret) > - goto err; > + goto report_failure; > if (reg27 = (utmp & 0x70)) { > ucLoDiv = ucLoDiv1; > ulNDiv = ulNDiv1; > @@ -340,7 +340,7 @@ static int m88rs6000t_set_pll_freq(struct m88rs6000t_dev *dev, > refDiv = 18; > ret = regmap_write(dev->regmap, 0x36, (refDiv - 8)); > if (ret) > - goto err; > + goto report_failure; > ulNDiv = ((tuner_freq_MHz * ucLoDiv * 1000) * refDiv > / fcry_KHz - 1024) / 2; > } > @@ -349,16 +349,16 @@ static int m88rs6000t_set_pll_freq(struct m88rs6000t_dev *dev, > + ((ulNDiv >> 8) & 0x0F)) & 0xFF; > ret = regmap_write(dev->regmap, 0x27, reg27); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x28, (u8)(ulNDiv & 0xFF)); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x29, 0x80); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x31, 0x03); > if (ret) > - goto err; > + goto report_failure; > > if (ucLoDiv = 3) > utmp = 0xCE; > @@ -366,15 +366,15 @@ static int m88rs6000t_set_pll_freq(struct m88rs6000t_dev *dev, > utmp = 0x8A; > ret = regmap_write(dev->regmap, 0x3b, utmp); > if (ret) > - goto err; > + goto report_failure; > > dev->frequency_khz = fcry_KHz * (ulNDiv * 2 + 1024) / refDiv / ucLoDiv; > > dev_dbg(&dev->client->dev, > "actual tune frequency=%d\n", dev->frequency_khz); > -err: > - if (ret) > - dev_dbg(&dev->client->dev, "failed=%d\n", ret); > + return 0; > +report_failure: > + dev_dbg(&dev->client->dev, "failed=%d\n", ret); > return ret; > } > > @@ -413,21 +413,23 @@ static int m88rs6000t_set_params(struct dvb_frontend *fe) > freq_MHz = (realFreq + 500) / 1000; > ret = m88rs6000t_set_pll_freq(dev, freq_MHz); > if (ret) > - goto err; > + goto report_failure; > ret = m88rs6000t_set_bb(dev, c->symbol_rate / 1000, lpf_offset_KHz); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x00, 0x01); > if (ret) > - goto err; > + goto report_failure; > ret = regmap_write(dev->regmap, 0x00, 0x00); > if (ret) > - goto err; > + goto report_failure; > /* set demod mlck */ > ret = m88rs6000t_set_demod_mclk(fe); > -err: > if (ret) > - dev_dbg(&dev->client->dev, "failed=%d\n", ret); > + goto report_failure; > + return 0; > +report_failure: > + dev_dbg(&dev->client->dev, "failed=%d\n", ret); > return ret; > } > > @@ -440,16 +442,16 @@ static int m88rs6000t_init(struct dvb_frontend *fe) > > ret = regmap_update_bits(dev->regmap, 0x11, 0x08, 0x08); > if (ret) > - goto err; > + goto report_failure; > usleep_range(5000, 50000); > ret = regmap_update_bits(dev->regmap, 0x10, 0x01, 0x01); > if (ret) > - goto err; > + goto report_failure; > usleep_range(10000, 50000); > ret = regmap_write(dev->regmap, 0x07, 0x7d); > -err: > - if (ret) > - dev_dbg(&dev->client->dev, "failed=%d\n", ret); > + return 0; > +report_failure: > + dev_dbg(&dev->client->dev, "failed=%d\n", ret); > return ret; > } > > @@ -510,27 +512,27 @@ static int m88rs6000t_get_rf_strength(struct dvb_frontend *fe, u16 *strength) > > ret = regmap_read(dev->regmap, 0x5A, &val); > if (ret) > - goto err; > + goto report_failure; > RF_GC = val & 0x0f; > > ret = regmap_read(dev->regmap, 0x5F, &val); > if (ret) > - goto err; > + goto report_failure; > IF_GC = val & 0x0f; > > ret = regmap_read(dev->regmap, 0x3F, &val); > if (ret) > - goto err; > + goto report_failure; > TIA_GC = (val >> 4) & 0x07; > > ret = regmap_read(dev->regmap, 0x77, &val); > if (ret) > - goto err; > + goto report_failure; > BB_GC = (val >> 4) & 0x0f; > > ret = regmap_read(dev->regmap, 0x76, &val); > if (ret) > - goto err; > + goto report_failure; > PGA2_GC = val & 0x3f; > PGA2_cri = PGA2_GC >> 2; > PGA2_crf = PGA2_GC & 0x03; > @@ -562,9 +564,9 @@ static int m88rs6000t_get_rf_strength(struct dvb_frontend *fe, u16 *strength) > /* scale value to 0x0000-0xffff */ > gain = clamp_val(gain, 1000U, 10500U); > *strength = (10500 - gain) * 0xffff / (10500 - 1000); > -err: > - if (ret) > - dev_dbg(&dev->client->dev, "failed=%d\n", ret); > + return 0; > +report_failure: > + dev_dbg(&dev->client->dev, "failed=%d\n", ret); > return ret; > } > > -- > 2.6.3 > > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [media] m88rs6000t: Better exception handling in five functions 2015-12-28 14:42 ` Julia Lawall @ 2015-12-28 15:03 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-28 15:03 UTC (permalink / raw) To: Julia Lawall; +Cc: linux-media, Mauro Carvalho Chehab, LKML, kernel-janitors >> Move the jump label directly before the desired log statement >> so that the variable "ret" will not be checked once more >> after a function call. > > This commit message fits with the previous change. Do you prefer an other wording? > It could be nice to put a blank line before the error handling code. Is it really a coding style requirement to insert another blank line between the suggested placement of the statement "return 0;" and the jump label? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [media] m88rs6000t: Better exception handling in five functions @ 2015-12-28 15:03 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-28 15:03 UTC (permalink / raw) To: Julia Lawall; +Cc: linux-media, Mauro Carvalho Chehab, LKML, kernel-janitors >> Move the jump label directly before the desired log statement >> so that the variable "ret" will not be checked once more >> after a function call. > > This commit message fits with the previous change. Do you prefer an other wording? > It could be nice to put a blank line before the error handling code. Is it really a coding style requirement to insert another blank line between the suggested placement of the statement "return 0;" and the jump label? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [media] m88rs6000t: Better exception handling in five functions 2015-12-28 15:03 ` SF Markus Elfring @ 2015-12-28 15:12 ` Julia Lawall -1 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2015-12-28 15:12 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-media, Mauro Carvalho Chehab, LKML, kernel-janitors On Mon, 28 Dec 2015, SF Markus Elfring wrote: > >> Move the jump label directly before the desired log statement > >> so that the variable "ret" will not be checked once more > >> after a function call. > > > > This commit message fits with the previous change. > > Do you prefer an other wording? Something like "Split the return into success and error cases, to avoid the need for testing before logging." The concept of the return being duplicated didn't come across in your message. > > It could be nice to put a blank line before the error handling code. > > Is it really a coding style requirement to insert another blank line between > the suggested placement of the statement "return 0;" and the jump label? I don't think it is a requirement. But some files do it, and if other functions in this file do it, then it would be nice to do the same. julia ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [media] m88rs6000t: Better exception handling in five functions @ 2015-12-28 15:12 ` Julia Lawall 0 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2015-12-28 15:12 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-media, Mauro Carvalho Chehab, LKML, kernel-janitors On Mon, 28 Dec 2015, SF Markus Elfring wrote: > >> Move the jump label directly before the desired log statement > >> so that the variable "ret" will not be checked once more > >> after a function call. > > > > This commit message fits with the previous change. > > Do you prefer an other wording? Something like "Split the return into success and error cases, to avoid the need for testing before logging." The concept of the return being duplicated didn't come across in your message. > > It could be nice to put a blank line before the error handling code. > > Is it really a coding style requirement to insert another blank line between > the suggested placement of the statement "return 0;" and the jump label? I don't think it is a requirement. But some files do it, and if other functions in this file do it, then it would be nice to do the same. julia ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/2] [media] m88rs6000t: Better exception handling in five functions 2015-12-28 14:38 ` SF Markus Elfring @ 2016-01-25 17:01 ` Mauro Carvalho Chehab -1 siblings, 0 replies; 3089+ messages in thread From: Mauro Carvalho Chehab @ 2016-01-25 17:01 UTC (permalink / raw) To: SF Markus Elfring; +Cc: linux-media, Julia Lawall, LKML, kernel-janitors Em Mon, 28 Dec 2015 15:38:54 +0100 SF Markus Elfring <elfring@users.sourceforge.net> escreveu: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Mon, 28 Dec 2015 15:10:30 +0100 > > This issue was detected by using the Coccinelle software. > > Move the jump label directly before the desired log statement > so that the variable "ret" will not be checked once more > after a function call. > Use the identifier "report_failure" instead of "err". > > Suggested-by: Julia Lawall <julia.lawall@lip6.fr> > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/media/tuners/m88rs6000t.c | 154 +++++++++++++++++++------------------- > 1 file changed, 78 insertions(+), 76 deletions(-) > > diff --git a/drivers/media/tuners/m88rs6000t.c b/drivers/media/tuners/m88rs6000t.c > index 504bfbc..7e59a9f 100644 > --- a/drivers/media/tuners/m88rs6000t.c > +++ b/drivers/media/tuners/m88rs6000t.c > @@ -44,7 +44,7 @@ static int m88rs6000t_set_demod_mclk(struct dvb_frontend *fe) > /* select demod main mclk */ > ret = regmap_read(dev->regmap, 0x15, &utmp); > if (ret) > - goto err; > + goto report_failure; Why to be so verbose? Calling it as "err" is enough, and it means less code to type if we need to add another goto. Regards, Mauro ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/2] [media] m88rs6000t: Better exception handling in five functions @ 2016-01-25 17:01 ` Mauro Carvalho Chehab 0 siblings, 0 replies; 3089+ messages in thread From: Mauro Carvalho Chehab @ 2016-01-25 17:01 UTC (permalink / raw) To: SF Markus Elfring; +Cc: linux-media, Julia Lawall, LKML, kernel-janitors Em Mon, 28 Dec 2015 15:38:54 +0100 SF Markus Elfring <elfring@users.sourceforge.net> escreveu: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Mon, 28 Dec 2015 15:10:30 +0100 > > This issue was detected by using the Coccinelle software. > > Move the jump label directly before the desired log statement > so that the variable "ret" will not be checked once more > after a function call. > Use the identifier "report_failure" instead of "err". > > Suggested-by: Julia Lawall <julia.lawall@lip6.fr> > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/media/tuners/m88rs6000t.c | 154 +++++++++++++++++++------------------- > 1 file changed, 78 insertions(+), 76 deletions(-) > > diff --git a/drivers/media/tuners/m88rs6000t.c b/drivers/media/tuners/m88rs6000t.c > index 504bfbc..7e59a9f 100644 > --- a/drivers/media/tuners/m88rs6000t.c > +++ b/drivers/media/tuners/m88rs6000t.c > @@ -44,7 +44,7 @@ static int m88rs6000t_set_demod_mclk(struct dvb_frontend *fe) > /* select demod main mclk */ > ret = regmap_read(dev->regmap, 0x15, &utmp); > if (ret) > - goto err; > + goto report_failure; Why to be so verbose? Calling it as "err" is enough, and it means less code to type if we need to add another goto. Regards, Mauro ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/2] [media] m88rs6000t: Better exception handling in five functions 2016-01-25 17:01 ` Mauro Carvalho Chehab @ 2016-01-25 18:15 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-25 18:15 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: linux-media, LKML, kernel-janitors, Julia Lawall >> This issue was detected by using the Coccinelle software. >> >> Move the jump label directly before the desired log statement >> so that the variable "ret" will not be checked once more >> after a function call. >> Use the identifier "report_failure" instead of "err". >> >> Suggested-by: Julia Lawall <julia.lawall@lip6.fr> >> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> >> --- >> drivers/media/tuners/m88rs6000t.c | 154 +++++++++++++++++++------------------- >> 1 file changed, 78 insertions(+), 76 deletions(-) >> >> diff --git a/drivers/media/tuners/m88rs6000t.c b/drivers/media/tuners/m88rs6000t.c >> index 504bfbc..7e59a9f 100644 >> --- a/drivers/media/tuners/m88rs6000t.c >> +++ b/drivers/media/tuners/m88rs6000t.c >> @@ -44,7 +44,7 @@ static int m88rs6000t_set_demod_mclk(struct dvb_frontend *fe) >> /* select demod main mclk */ >> ret = regmap_read(dev->regmap, 0x15, &utmp); >> if (ret) >> - goto err; >> + goto report_failure; > > Why to be so verbose? Does the document "CodingStyle" give an indication in the section "Chapter 7: Centralized exiting of functions"? > Calling it as "err" is enough, It seems that some short identifiers are popular during software development. > and it means less code to type if we need to add another goto. Would you like to increase the usage of jump labels which will contain only a single character? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/2] [media] m88rs6000t: Better exception handling in five functions @ 2016-01-25 18:15 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-25 18:15 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: linux-media, LKML, kernel-janitors, Julia Lawall >> This issue was detected by using the Coccinelle software. >> >> Move the jump label directly before the desired log statement >> so that the variable "ret" will not be checked once more >> after a function call. >> Use the identifier "report_failure" instead of "err". >> >> Suggested-by: Julia Lawall <julia.lawall@lip6.fr> >> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> >> --- >> drivers/media/tuners/m88rs6000t.c | 154 +++++++++++++++++++------------------- >> 1 file changed, 78 insertions(+), 76 deletions(-) >> >> diff --git a/drivers/media/tuners/m88rs6000t.c b/drivers/media/tuners/m88rs6000t.c >> index 504bfbc..7e59a9f 100644 >> --- a/drivers/media/tuners/m88rs6000t.c >> +++ b/drivers/media/tuners/m88rs6000t.c >> @@ -44,7 +44,7 @@ static int m88rs6000t_set_demod_mclk(struct dvb_frontend *fe) >> /* select demod main mclk */ >> ret = regmap_read(dev->regmap, 0x15, &utmp); >> if (ret) >> - goto err; >> + goto report_failure; > > Why to be so verbose? Does the document "CodingStyle" give an indication in the section "Chapter 7: Centralized exiting of functions"? > Calling it as "err" is enough, It seems that some short identifiers are popular during software development. > and it means less code to type if we need to add another goto. Would you like to increase the usage of jump labels which will contain only a single character? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 2/2] [media] tuners: Refactoring for m88rs6000t_sleep() 2015-12-28 14:36 ` SF Markus Elfring @ 2015-12-28 14:42 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-28 14:42 UTC (permalink / raw) To: linux-media, Mauro Carvalho Chehab; +Cc: Julia Lawall, LKML, kernel-janitors From: Markus Elfring <elfring@users.sourceforge.net> Date: Mon, 28 Dec 2015 15:20:45 +0100 This issue was detected by using the Coccinelle software. 1. Let us return directly if a call of the regmap_write() function failed. 2. Delete the jump label "err" then. 3. Return zero as a constant at the end. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/media/tuners/m88rs6000t.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/media/tuners/m88rs6000t.c b/drivers/media/tuners/m88rs6000t.c index 7e59a9f..8d10798 100644 --- a/drivers/media/tuners/m88rs6000t.c +++ b/drivers/media/tuners/m88rs6000t.c @@ -463,13 +463,12 @@ static int m88rs6000t_sleep(struct dvb_frontend *fe) dev_dbg(&dev->client->dev, "%s:\n", __func__); ret = regmap_write(dev->regmap, 0x07, 0x6d); - if (ret) - goto err; - usleep_range(5000, 10000); -err: - if (ret) + if (ret) { dev_dbg(&dev->client->dev, "failed=%d\n", ret); - return ret; + return ret; + } + usleep_range(5000, 10000); + return 0; } static int m88rs6000t_get_frequency(struct dvb_frontend *fe, u32 *frequency) -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 2/2] [media] tuners: Refactoring for m88rs6000t_sleep() @ 2015-12-28 14:42 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-28 14:42 UTC (permalink / raw) To: linux-media, Mauro Carvalho Chehab; +Cc: Julia Lawall, LKML, kernel-janitors From: Markus Elfring <elfring@users.sourceforge.net> Date: Mon, 28 Dec 2015 15:20:45 +0100 This issue was detected by using the Coccinelle software. 1. Let us return directly if a call of the regmap_write() function failed. 2. Delete the jump label "err" then. 3. Return zero as a constant at the end. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/media/tuners/m88rs6000t.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/media/tuners/m88rs6000t.c b/drivers/media/tuners/m88rs6000t.c index 7e59a9f..8d10798 100644 --- a/drivers/media/tuners/m88rs6000t.c +++ b/drivers/media/tuners/m88rs6000t.c @@ -463,13 +463,12 @@ static int m88rs6000t_sleep(struct dvb_frontend *fe) dev_dbg(&dev->client->dev, "%s:\n", __func__); ret = regmap_write(dev->regmap, 0x07, 0x6d); - if (ret) - goto err; - usleep_range(5000, 10000); -err: - if (ret) + if (ret) { dev_dbg(&dev->client->dev, "failed=%d\n", ret); - return ret; + return ret; + } + usleep_range(5000, 10000); + return 0; } static int m88rs6000t_get_frequency(struct dvb_frontend *fe, u32 *frequency) -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 0/2] [media] r820t: Fine-tuning for generic_set_freq() 2015-12-11 12:08 ` SF Markus Elfring @ 2015-12-28 16:24 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-28 16:24 UTC (permalink / raw) To: linux-media, Mauro Carvalho Chehab; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Mon, 28 Dec 2015 17:18:34 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an unnecessary variable initialisation Better exception handling drivers/media/tuners/r820t.c | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/2] [media] r820t: Fine-tuning for generic_set_freq() @ 2015-12-28 16:24 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-28 16:24 UTC (permalink / raw) To: linux-media, Mauro Carvalho Chehab; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Mon, 28 Dec 2015 17:18:34 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an unnecessary variable initialisation Better exception handling drivers/media/tuners/r820t.c | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 1/2] [media] r820t: Delete an unnecessary variable initialisation in generic_set_freq() 2015-12-28 16:24 ` SF Markus Elfring @ 2015-12-28 16:30 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-28 16:30 UTC (permalink / raw) To: linux-media, Mauro Carvalho Chehab; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Mon, 28 Dec 2015 16:36:44 +0100 The variable "rc" will be set to an appropriate value from a call of the r820t_set_tv_standard() function. Thus let us omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/media/tuners/r820t.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/tuners/r820t.c b/drivers/media/tuners/r820t.c index a7a8452..6ab35e3 100644 --- a/drivers/media/tuners/r820t.c +++ b/drivers/media/tuners/r820t.c @@ -1295,7 +1295,7 @@ static int generic_set_freq(struct dvb_frontend *fe, v4l2_std_id std, u32 delsys) { struct r820t_priv *priv = fe->tuner_priv; - int rc = -EINVAL; + int rc; u32 lo_freq; tuner_dbg("should set frequency to %d kHz, bw %d MHz\n", -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 1/2] [media] r820t: Delete an unnecessary variable initialisation in generic_set_freq() @ 2015-12-28 16:30 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-28 16:30 UTC (permalink / raw) To: linux-media, Mauro Carvalho Chehab; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Mon, 28 Dec 2015 16:36:44 +0100 The variable "rc" will be set to an appropriate value from a call of the r820t_set_tv_standard() function. Thus let us omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/media/tuners/r820t.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/tuners/r820t.c b/drivers/media/tuners/r820t.c index a7a8452..6ab35e3 100644 --- a/drivers/media/tuners/r820t.c +++ b/drivers/media/tuners/r820t.c @@ -1295,7 +1295,7 @@ static int generic_set_freq(struct dvb_frontend *fe, v4l2_std_id std, u32 delsys) { struct r820t_priv *priv = fe->tuner_priv; - int rc = -EINVAL; + int rc; u32 lo_freq; tuner_dbg("should set frequency to %d kHz, bw %d MHz\n", -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 2/2] [media] r820t: Better exception handling in generic_set_freq() 2015-12-28 16:24 ` SF Markus Elfring @ 2015-12-28 16:32 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-28 16:32 UTC (permalink / raw) To: linux-media, Mauro Carvalho Chehab; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Mon, 28 Dec 2015 17:13:02 +0100 This issue was detected by using the Coccinelle software. Move the jump label directly before the desired log statement so that the variable "rc" will not be checked once more after a function call. Use the identifier "report_failure" instead of "err". The error logging is performed in a separate section at the end now. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/media/tuners/r820t.c | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/drivers/media/tuners/r820t.c b/drivers/media/tuners/r820t.c index 6ab35e3..f71642e 100644 --- a/drivers/media/tuners/r820t.c +++ b/drivers/media/tuners/r820t.c @@ -1303,7 +1303,7 @@ static int generic_set_freq(struct dvb_frontend *fe, rc = r820t_set_tv_standard(priv, bw, type, std, delsys); if (rc < 0) - goto err; + goto report_failure; if ((type == V4L2_TUNER_ANALOG_TV) && (std == V4L2_STD_SECAM_LC)) lo_freq = freq - priv->int_freq; @@ -1312,23 +1312,21 @@ static int generic_set_freq(struct dvb_frontend *fe, rc = r820t_set_mux(priv, lo_freq); if (rc < 0) - goto err; + goto report_failure; rc = r820t_set_pll(priv, type, lo_freq); if (rc < 0 || !priv->has_lock) - goto err; + goto report_failure; rc = r820t_sysfreq_sel(priv, freq, type, std, delsys); if (rc < 0) - goto err; + goto report_failure; tuner_dbg("%s: PLL locked on frequency %d Hz, gain=%d\n", __func__, freq, r820t_read_gain(priv)); - -err: - - if (rc < 0) - tuner_dbg("%s: failed=%d\n", __func__, rc); + return 0; +report_failure: + tuner_dbg("%s: failed=%d\n", __func__, rc); return rc; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 2/2] [media] r820t: Better exception handling in generic_set_freq() @ 2015-12-28 16:32 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-28 16:32 UTC (permalink / raw) To: linux-media, Mauro Carvalho Chehab; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Mon, 28 Dec 2015 17:13:02 +0100 This issue was detected by using the Coccinelle software. Move the jump label directly before the desired log statement so that the variable "rc" will not be checked once more after a function call. Use the identifier "report_failure" instead of "err". The error logging is performed in a separate section at the end now. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/media/tuners/r820t.c | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/drivers/media/tuners/r820t.c b/drivers/media/tuners/r820t.c index 6ab35e3..f71642e 100644 --- a/drivers/media/tuners/r820t.c +++ b/drivers/media/tuners/r820t.c @@ -1303,7 +1303,7 @@ static int generic_set_freq(struct dvb_frontend *fe, rc = r820t_set_tv_standard(priv, bw, type, std, delsys); if (rc < 0) - goto err; + goto report_failure; if ((type = V4L2_TUNER_ANALOG_TV) && (std = V4L2_STD_SECAM_LC)) lo_freq = freq - priv->int_freq; @@ -1312,23 +1312,21 @@ static int generic_set_freq(struct dvb_frontend *fe, rc = r820t_set_mux(priv, lo_freq); if (rc < 0) - goto err; + goto report_failure; rc = r820t_set_pll(priv, type, lo_freq); if (rc < 0 || !priv->has_lock) - goto err; + goto report_failure; rc = r820t_sysfreq_sel(priv, freq, type, std, delsys); if (rc < 0) - goto err; + goto report_failure; tuner_dbg("%s: PLL locked on frequency %d Hz, gain=%d\n", __func__, freq, r820t_read_gain(priv)); - -err: - - if (rc < 0) - tuner_dbg("%s: failed=%d\n", __func__, rc); + return 0; +report_failure: + tuner_dbg("%s: failed=%d\n", __func__, rc); return rc; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] [media] r820t: Better exception handling in generic_set_freq() 2015-12-28 16:32 ` SF Markus Elfring @ 2016-01-25 17:04 ` Mauro Carvalho Chehab -1 siblings, 0 replies; 3089+ messages in thread From: Mauro Carvalho Chehab @ 2016-01-25 17:04 UTC (permalink / raw) To: SF Markus Elfring; +Cc: linux-media, LKML, kernel-janitors, Julia Lawall Em Mon, 28 Dec 2015 17:32:22 +0100 SF Markus Elfring <elfring@users.sourceforge.net> escreveu: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Mon, 28 Dec 2015 17:13:02 +0100 > > This issue was detected by using the Coccinelle software. > > Move the jump label directly before the desired log statement > so that the variable "rc" will not be checked once more > after a function call. > Use the identifier "report_failure" instead of "err". > > The error logging is performed in a separate section at the end now. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/media/tuners/r820t.c | 16 +++++++--------- > 1 file changed, 7 insertions(+), 9 deletions(-) > > diff --git a/drivers/media/tuners/r820t.c b/drivers/media/tuners/r820t.c > index 6ab35e3..f71642e 100644 > --- a/drivers/media/tuners/r820t.c > +++ b/drivers/media/tuners/r820t.c > @@ -1303,7 +1303,7 @@ static int generic_set_freq(struct dvb_frontend *fe, > > rc = r820t_set_tv_standard(priv, bw, type, std, delsys); > if (rc < 0) > - goto err; > + goto report_failure; Same thing as my previous comment: just "err" please. Same applies to other patches you sent with similar hunks. > > if ((type == V4L2_TUNER_ANALOG_TV) && (std == V4L2_STD_SECAM_LC)) > lo_freq = freq - priv->int_freq; > @@ -1312,23 +1312,21 @@ static int generic_set_freq(struct dvb_frontend *fe, > > rc = r820t_set_mux(priv, lo_freq); > if (rc < 0) > - goto err; > + goto report_failure; > > rc = r820t_set_pll(priv, type, lo_freq); > if (rc < 0 || !priv->has_lock) > - goto err; > + goto report_failure; > > rc = r820t_sysfreq_sel(priv, freq, type, std, delsys); > if (rc < 0) > - goto err; > + goto report_failure; > > tuner_dbg("%s: PLL locked on frequency %d Hz, gain=%d\n", > __func__, freq, r820t_read_gain(priv)); > - > -err: > - > - if (rc < 0) > - tuner_dbg("%s: failed=%d\n", __func__, rc); > + return 0; > +report_failure: > + tuner_dbg("%s: failed=%d\n", __func__, rc); > return rc; > } > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] [media] r820t: Better exception handling in generic_set_freq() @ 2016-01-25 17:04 ` Mauro Carvalho Chehab 0 siblings, 0 replies; 3089+ messages in thread From: Mauro Carvalho Chehab @ 2016-01-25 17:04 UTC (permalink / raw) To: SF Markus Elfring; +Cc: linux-media, LKML, kernel-janitors, Julia Lawall Em Mon, 28 Dec 2015 17:32:22 +0100 SF Markus Elfring <elfring@users.sourceforge.net> escreveu: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Mon, 28 Dec 2015 17:13:02 +0100 > > This issue was detected by using the Coccinelle software. > > Move the jump label directly before the desired log statement > so that the variable "rc" will not be checked once more > after a function call. > Use the identifier "report_failure" instead of "err". > > The error logging is performed in a separate section at the end now. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/media/tuners/r820t.c | 16 +++++++--------- > 1 file changed, 7 insertions(+), 9 deletions(-) > > diff --git a/drivers/media/tuners/r820t.c b/drivers/media/tuners/r820t.c > index 6ab35e3..f71642e 100644 > --- a/drivers/media/tuners/r820t.c > +++ b/drivers/media/tuners/r820t.c > @@ -1303,7 +1303,7 @@ static int generic_set_freq(struct dvb_frontend *fe, > > rc = r820t_set_tv_standard(priv, bw, type, std, delsys); > if (rc < 0) > - goto err; > + goto report_failure; Same thing as my previous comment: just "err" please. Same applies to other patches you sent with similar hunks. > > if ((type = V4L2_TUNER_ANALOG_TV) && (std = V4L2_STD_SECAM_LC)) > lo_freq = freq - priv->int_freq; > @@ -1312,23 +1312,21 @@ static int generic_set_freq(struct dvb_frontend *fe, > > rc = r820t_set_mux(priv, lo_freq); > if (rc < 0) > - goto err; > + goto report_failure; > > rc = r820t_set_pll(priv, type, lo_freq); > if (rc < 0 || !priv->has_lock) > - goto err; > + goto report_failure; > > rc = r820t_sysfreq_sel(priv, freq, type, std, delsys); > if (rc < 0) > - goto err; > + goto report_failure; > > tuner_dbg("%s: PLL locked on frequency %d Hz, gain=%d\n", > __func__, freq, r820t_read_gain(priv)); > - > -err: > - > - if (rc < 0) > - tuner_dbg("%s: failed=%d\n", __func__, rc); > + return 0; > +report_failure: > + tuner_dbg("%s: failed=%d\n", __func__, rc); > return rc; > } > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH] [media] xc5000: Faster result reporting in xc_load_fw_and_init_tuner() 2015-12-11 12:08 ` SF Markus Elfring @ 2015-12-28 19:20 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-28 19:20 UTC (permalink / raw) To: linux-media, Mauro Carvalho Chehab; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Mon, 28 Dec 2015 20:10:30 +0100 This issue was detected by using the Coccinelle software. Split the previous if statement at the end so that each final log statement will eventually be performed by a direct jump to these labels. * report_failure * report_success A check repetition can be excluded for the variable "ret" at the end then. Apply also two recommendations from the script "checkpatch.pl". Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/media/tuners/xc5000.c | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/drivers/media/tuners/xc5000.c b/drivers/media/tuners/xc5000.c index e6e5e90..1360677 100644 --- a/drivers/media/tuners/xc5000.c +++ b/drivers/media/tuners/xc5000.c @@ -1166,7 +1166,7 @@ static int xc_load_fw_and_init_tuner(struct dvb_frontend *fe, int force) ret = xc5000_fwupload(fe, desired_fw, fw); if (ret != 0) - goto err; + goto report_failure; msleep(20); @@ -1229,18 +1229,16 @@ static int xc_load_fw_and_init_tuner(struct dvb_frontend *fe, int force) /* Default to "CABLE" mode */ ret = xc_write_reg(priv, XREG_SIGNALSOURCE, XC_RF_MODE_CABLE); if (!ret) - break; + goto report_success; printk(KERN_ERR "xc5000: can't set to cable mode."); } -err: - if (!ret) - printk(KERN_INFO "xc5000: Firmware %s loaded and running.\n", - desired_fw->name); - else - printk(KERN_CONT " - too many retries. Giving up\n"); - +report_failure: + pr_cont(" - too many retries. Giving up\n"); return ret; +report_success: + pr_info("xc5000: Firmware %s loaded and running.\n", desired_fw->name); + return 0; } static void xc5000_do_timer_sleep(struct work_struct *timer_sleep) -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH] [media] xc5000: Faster result reporting in xc_load_fw_and_init_tuner() @ 2015-12-28 19:20 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-28 19:20 UTC (permalink / raw) To: linux-media, Mauro Carvalho Chehab; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Mon, 28 Dec 2015 20:10:30 +0100 This issue was detected by using the Coccinelle software. Split the previous if statement at the end so that each final log statement will eventually be performed by a direct jump to these labels. * report_failure * report_success A check repetition can be excluded for the variable "ret" at the end then. Apply also two recommendations from the script "checkpatch.pl". Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/media/tuners/xc5000.c | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/drivers/media/tuners/xc5000.c b/drivers/media/tuners/xc5000.c index e6e5e90..1360677 100644 --- a/drivers/media/tuners/xc5000.c +++ b/drivers/media/tuners/xc5000.c @@ -1166,7 +1166,7 @@ static int xc_load_fw_and_init_tuner(struct dvb_frontend *fe, int force) ret = xc5000_fwupload(fe, desired_fw, fw); if (ret != 0) - goto err; + goto report_failure; msleep(20); @@ -1229,18 +1229,16 @@ static int xc_load_fw_and_init_tuner(struct dvb_frontend *fe, int force) /* Default to "CABLE" mode */ ret = xc_write_reg(priv, XREG_SIGNALSOURCE, XC_RF_MODE_CABLE); if (!ret) - break; + goto report_success; printk(KERN_ERR "xc5000: can't set to cable mode."); } -err: - if (!ret) - printk(KERN_INFO "xc5000: Firmware %s loaded and running.\n", - desired_fw->name); - else - printk(KERN_CONT " - too many retries. Giving up\n"); - +report_failure: + pr_cont(" - too many retries. Giving up\n"); return ret; +report_success: + pr_info("xc5000: Firmware %s loaded and running.\n", desired_fw->name); + return 0; } static void xc5000_do_timer_sleep(struct work_struct *timer_sleep) -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH] [media] xc5000: Faster result reporting in xc_load_fw_and_init_tuner() 2015-12-28 19:20 ` SF Markus Elfring @ 2016-01-25 17:06 ` Mauro Carvalho Chehab -1 siblings, 0 replies; 3089+ messages in thread From: Mauro Carvalho Chehab @ 2016-01-25 17:06 UTC (permalink / raw) To: SF Markus Elfring; +Cc: linux-media, LKML, kernel-janitors, Julia Lawall Em Mon, 28 Dec 2015 20:20:27 +0100 SF Markus Elfring <elfring@users.sourceforge.net> escreveu: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Mon, 28 Dec 2015 20:10:30 +0100 > > This issue was detected by using the Coccinelle software. > > Split the previous if statement at the end so that each final log statement > will eventually be performed by a direct jump to these labels. > * report_failure > * report_success > > A check repetition can be excluded for the variable "ret" at the end then. > > > Apply also two recommendations from the script "checkpatch.pl". > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/media/tuners/xc5000.c | 16 +++++++--------- > 1 file changed, 7 insertions(+), 9 deletions(-) > > diff --git a/drivers/media/tuners/xc5000.c b/drivers/media/tuners/xc5000.c > index e6e5e90..1360677 100644 > --- a/drivers/media/tuners/xc5000.c > +++ b/drivers/media/tuners/xc5000.c > @@ -1166,7 +1166,7 @@ static int xc_load_fw_and_init_tuner(struct dvb_frontend *fe, int force) > > ret = xc5000_fwupload(fe, desired_fw, fw); > if (ret != 0) > - goto err; > + goto report_failure; > > msleep(20); > > @@ -1229,18 +1229,16 @@ static int xc_load_fw_and_init_tuner(struct dvb_frontend *fe, int force) > /* Default to "CABLE" mode */ > ret = xc_write_reg(priv, XREG_SIGNALSOURCE, XC_RF_MODE_CABLE); > if (!ret) > - break; > + goto report_success; > printk(KERN_ERR "xc5000: can't set to cable mode."); It sounds worth to avoid adding a goto here. > } > > -err: > - if (!ret) > - printk(KERN_INFO "xc5000: Firmware %s loaded and running.\n", > - desired_fw->name); > - else > - printk(KERN_CONT " - too many retries. Giving up\n"); > - > +report_failure: > + pr_cont(" - too many retries. Giving up\n"); > return ret; > +report_success: > + pr_info("xc5000: Firmware %s loaded and running.\n", desired_fw->name); > + return 0; > } > > static void xc5000_do_timer_sleep(struct work_struct *timer_sleep) ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] [media] xc5000: Faster result reporting in xc_load_fw_and_init_tuner() @ 2016-01-25 17:06 ` Mauro Carvalho Chehab 0 siblings, 0 replies; 3089+ messages in thread From: Mauro Carvalho Chehab @ 2016-01-25 17:06 UTC (permalink / raw) To: SF Markus Elfring; +Cc: linux-media, LKML, kernel-janitors, Julia Lawall Em Mon, 28 Dec 2015 20:20:27 +0100 SF Markus Elfring <elfring@users.sourceforge.net> escreveu: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Mon, 28 Dec 2015 20:10:30 +0100 > > This issue was detected by using the Coccinelle software. > > Split the previous if statement at the end so that each final log statement > will eventually be performed by a direct jump to these labels. > * report_failure > * report_success > > A check repetition can be excluded for the variable "ret" at the end then. > > > Apply also two recommendations from the script "checkpatch.pl". > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/media/tuners/xc5000.c | 16 +++++++--------- > 1 file changed, 7 insertions(+), 9 deletions(-) > > diff --git a/drivers/media/tuners/xc5000.c b/drivers/media/tuners/xc5000.c > index e6e5e90..1360677 100644 > --- a/drivers/media/tuners/xc5000.c > +++ b/drivers/media/tuners/xc5000.c > @@ -1166,7 +1166,7 @@ static int xc_load_fw_and_init_tuner(struct dvb_frontend *fe, int force) > > ret = xc5000_fwupload(fe, desired_fw, fw); > if (ret != 0) > - goto err; > + goto report_failure; > > msleep(20); > > @@ -1229,18 +1229,16 @@ static int xc_load_fw_and_init_tuner(struct dvb_frontend *fe, int force) > /* Default to "CABLE" mode */ > ret = xc_write_reg(priv, XREG_SIGNALSOURCE, XC_RF_MODE_CABLE); > if (!ret) > - break; > + goto report_success; > printk(KERN_ERR "xc5000: can't set to cable mode."); It sounds worth to avoid adding a goto here. > } > > -err: > - if (!ret) > - printk(KERN_INFO "xc5000: Firmware %s loaded and running.\n", > - desired_fw->name); > - else > - printk(KERN_CONT " - too many retries. Giving up\n"); > - > +report_failure: > + pr_cont(" - too many retries. Giving up\n"); > return ret; > +report_success: > + pr_info("xc5000: Firmware %s loaded and running.\n", desired_fw->name); > + return 0; > } > > static void xc5000_do_timer_sleep(struct work_struct *timer_sleep) ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] [media] xc5000: Faster result reporting in xc_load_fw_and_init_tuner() 2016-01-25 17:06 ` Mauro Carvalho Chehab @ 2016-01-25 18:23 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-25 18:23 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: linux-media, LKML, kernel-janitors, Julia Lawall >> This issue was detected by using the Coccinelle software. >> >> Split the previous if statement at the end so that each final log statement >> will eventually be performed by a direct jump to these labels. >> * report_failure >> * report_success >> >> A check repetition can be excluded for the variable "ret" at the end then. >> >> >> Apply also two recommendations from the script "checkpatch.pl". >> >> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> >> --- >> drivers/media/tuners/xc5000.c | 16 +++++++--------- >> 1 file changed, 7 insertions(+), 9 deletions(-) >> >> diff --git a/drivers/media/tuners/xc5000.c b/drivers/media/tuners/xc5000.c >> index e6e5e90..1360677 100644 >> --- a/drivers/media/tuners/xc5000.c >> +++ b/drivers/media/tuners/xc5000.c >> @@ -1166,7 +1166,7 @@ static int xc_load_fw_and_init_tuner(struct dvb_frontend *fe, int force) >> >> ret = xc5000_fwupload(fe, desired_fw, fw); >> if (ret != 0) >> - goto err; >> + goto report_failure; >> >> msleep(20); >> >> @@ -1229,18 +1229,16 @@ static int xc_load_fw_and_init_tuner(struct dvb_frontend *fe, int force) >> /* Default to "CABLE" mode */ >> ret = xc_write_reg(priv, XREG_SIGNALSOURCE, XC_RF_MODE_CABLE); >> if (!ret) >> - break; >> + goto report_success; >> printk(KERN_ERR "xc5000: can't set to cable mode."); > > It sounds worth to avoid adding a goto here. Are you interested in a bit of software optimisation for the implementation of the function "xc_load_fw_and_init_tuner"? >> } >> >> -err: >> - if (!ret) >> - printk(KERN_INFO "xc5000: Firmware %s loaded and running.\n", >> - desired_fw->name); >> - else >> - printk(KERN_CONT " - too many retries. Giving up\n"); >> - >> +report_failure: >> + pr_cont(" - too many retries. Giving up\n"); >> return ret; >> +report_success: >> + pr_info("xc5000: Firmware %s loaded and running.\n", desired_fw->name); >> + return 0; >> } >> >> static void xc5000_do_timer_sleep(struct work_struct *timer_sleep) Is the proposed source code restructuring interesting? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] [media] xc5000: Faster result reporting in xc_load_fw_and_init_tuner() @ 2016-01-25 18:23 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-25 18:23 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: linux-media, LKML, kernel-janitors, Julia Lawall >> This issue was detected by using the Coccinelle software. >> >> Split the previous if statement at the end so that each final log statement >> will eventually be performed by a direct jump to these labels. >> * report_failure >> * report_success >> >> A check repetition can be excluded for the variable "ret" at the end then. >> >> >> Apply also two recommendations from the script "checkpatch.pl". >> >> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> >> --- >> drivers/media/tuners/xc5000.c | 16 +++++++--------- >> 1 file changed, 7 insertions(+), 9 deletions(-) >> >> diff --git a/drivers/media/tuners/xc5000.c b/drivers/media/tuners/xc5000.c >> index e6e5e90..1360677 100644 >> --- a/drivers/media/tuners/xc5000.c >> +++ b/drivers/media/tuners/xc5000.c >> @@ -1166,7 +1166,7 @@ static int xc_load_fw_and_init_tuner(struct dvb_frontend *fe, int force) >> >> ret = xc5000_fwupload(fe, desired_fw, fw); >> if (ret != 0) >> - goto err; >> + goto report_failure; >> >> msleep(20); >> >> @@ -1229,18 +1229,16 @@ static int xc_load_fw_and_init_tuner(struct dvb_frontend *fe, int force) >> /* Default to "CABLE" mode */ >> ret = xc_write_reg(priv, XREG_SIGNALSOURCE, XC_RF_MODE_CABLE); >> if (!ret) >> - break; >> + goto report_success; >> printk(KERN_ERR "xc5000: can't set to cable mode."); > > It sounds worth to avoid adding a goto here. Are you interested in a bit of software optimisation for the implementation of the function "xc_load_fw_and_init_tuner"? >> } >> >> -err: >> - if (!ret) >> - printk(KERN_INFO "xc5000: Firmware %s loaded and running.\n", >> - desired_fw->name); >> - else >> - printk(KERN_CONT " - too many retries. Giving up\n"); >> - >> +report_failure: >> + pr_cont(" - too many retries. Giving up\n"); >> return ret; >> +report_success: >> + pr_info("xc5000: Firmware %s loaded and running.\n", desired_fw->name); >> + return 0; >> } >> >> static void xc5000_do_timer_sleep(struct work_struct *timer_sleep) Is the proposed source code restructuring interesting? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] [media] xc5000: Faster result reporting in xc_load_fw_and_init_tuner() 2016-01-25 18:23 ` SF Markus Elfring @ 2016-01-25 18:38 ` Devin Heitmueller -1 siblings, 0 replies; 3089+ messages in thread From: Devin Heitmueller @ 2016-01-25 18:38 UTC (permalink / raw) To: SF Markus Elfring Cc: Mauro Carvalho Chehab, Linux Media Mailing List, LKML, kernel-janitors, Julia Lawall > Are you interested in a bit of software optimisation for the implementation > of the function "xc_load_fw_and_init_tuner"? To be clear, absolutely none of the code in question is performance sensitive (i.e. saving a couple of extra CPU cycles has no value in this case). Hence given that I'm assuming you have no intention to actually test any of these patches with a real device I would recommend you do the bare minimum to prevent Coccinelle from complaining and not restructure any of the core business logic unless you plan to also do actual testing. Thanks, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] [media] xc5000: Faster result reporting in xc_load_fw_and_init_tuner() @ 2016-01-25 18:38 ` Devin Heitmueller 0 siblings, 0 replies; 3089+ messages in thread From: Devin Heitmueller @ 2016-01-25 18:38 UTC (permalink / raw) To: SF Markus Elfring Cc: Mauro Carvalho Chehab, Linux Media Mailing List, LKML, kernel-janitors, Julia Lawall > Are you interested in a bit of software optimisation for the implementation > of the function "xc_load_fw_and_init_tuner"? To be clear, absolutely none of the code in question is performance sensitive (i.e. saving a couple of extra CPU cycles has no value in this case). Hence given that I'm assuming you have no intention to actually test any of these patches with a real device I would recommend you do the bare minimum to prevent Coccinelle from complaining and not restructure any of the core business logic unless you plan to also do actual testing. Thanks, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH] [media] airspy: Better exception handling in two functions 2015-12-11 12:08 ` SF Markus Elfring @ 2015-12-28 21:15 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-28 21:15 UTC (permalink / raw) To: linux-media, Antti Palosaari, Mauro Carvalho Chehab Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Mon, 28 Dec 2015 22:10:28 +0100 This issue was detected by using the Coccinelle software. Move the jump label directly before the desired log statement so that the variable "ret" will not be checked once more after a function call. Use the identifier "report_failure" instead of "err". The error logging is performed in a separate section at the end now. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/media/usb/airspy/airspy.c | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/drivers/media/usb/airspy/airspy.c b/drivers/media/usb/airspy/airspy.c index 0d4ac59..cf2444a 100644 --- a/drivers/media/usb/airspy/airspy.c +++ b/drivers/media/usb/airspy/airspy.c @@ -889,18 +889,17 @@ static int airspy_set_lna_gain(struct airspy *s) ret = airspy_ctrl_msg(s, CMD_SET_LNA_AGC, 0, s->lna_gain_auto->val, &u8tmp, 1); if (ret) - goto err; + goto report_failure; if (s->lna_gain_auto->val == false) { ret = airspy_ctrl_msg(s, CMD_SET_LNA_GAIN, 0, s->lna_gain->val, &u8tmp, 1); if (ret) - goto err; + goto report_failure; } -err: - if (ret) - dev_dbg(s->dev, "failed=%d\n", ret); - + return 0; +report_failure: + dev_dbg(s->dev, "failed=%d\n", ret); return ret; } @@ -916,18 +915,17 @@ static int airspy_set_mixer_gain(struct airspy *s) ret = airspy_ctrl_msg(s, CMD_SET_MIXER_AGC, 0, s->mixer_gain_auto->val, &u8tmp, 1); if (ret) - goto err; + goto report_failure; if (s->mixer_gain_auto->val == false) { ret = airspy_ctrl_msg(s, CMD_SET_MIXER_GAIN, 0, s->mixer_gain->val, &u8tmp, 1); if (ret) - goto err; + goto report_failure; } -err: - if (ret) - dev_dbg(s->dev, "failed=%d\n", ret); - + return 0; +report_failure: + dev_dbg(s->dev, "failed=%d\n", ret); return ret; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH] [media] airspy: Better exception handling in two functions @ 2015-12-28 21:15 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-28 21:15 UTC (permalink / raw) To: linux-media, Antti Palosaari, Mauro Carvalho Chehab Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Mon, 28 Dec 2015 22:10:28 +0100 This issue was detected by using the Coccinelle software. Move the jump label directly before the desired log statement so that the variable "ret" will not be checked once more after a function call. Use the identifier "report_failure" instead of "err". The error logging is performed in a separate section at the end now. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/media/usb/airspy/airspy.c | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/drivers/media/usb/airspy/airspy.c b/drivers/media/usb/airspy/airspy.c index 0d4ac59..cf2444a 100644 --- a/drivers/media/usb/airspy/airspy.c +++ b/drivers/media/usb/airspy/airspy.c @@ -889,18 +889,17 @@ static int airspy_set_lna_gain(struct airspy *s) ret = airspy_ctrl_msg(s, CMD_SET_LNA_AGC, 0, s->lna_gain_auto->val, &u8tmp, 1); if (ret) - goto err; + goto report_failure; if (s->lna_gain_auto->val = false) { ret = airspy_ctrl_msg(s, CMD_SET_LNA_GAIN, 0, s->lna_gain->val, &u8tmp, 1); if (ret) - goto err; + goto report_failure; } -err: - if (ret) - dev_dbg(s->dev, "failed=%d\n", ret); - + return 0; +report_failure: + dev_dbg(s->dev, "failed=%d\n", ret); return ret; } @@ -916,18 +915,17 @@ static int airspy_set_mixer_gain(struct airspy *s) ret = airspy_ctrl_msg(s, CMD_SET_MIXER_AGC, 0, s->mixer_gain_auto->val, &u8tmp, 1); if (ret) - goto err; + goto report_failure; if (s->mixer_gain_auto->val = false) { ret = airspy_ctrl_msg(s, CMD_SET_MIXER_GAIN, 0, s->mixer_gain->val, &u8tmp, 1); if (ret) - goto err; + goto report_failure; } -err: - if (ret) - dev_dbg(s->dev, "failed=%d\n", ret); - + return 0; +report_failure: + dev_dbg(s->dev, "failed=%d\n", ret); return ret; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH] [media] au0828: Refactoring for start_urb_transfer() 2015-12-11 12:08 ` SF Markus Elfring @ 2015-12-28 21:56 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-28 21:56 UTC (permalink / raw) To: linux-media, Mauro Carvalho Chehab; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Mon, 28 Dec 2015 22:52:48 +0100 This issue was detected by using the Coccinelle software. 1. Let us return directly if a buffer allocation failed. 2. Delete the jump label "err" then. 3. Drop the explicit initialisation for the variable "ret" at the beginning. 4. Return zero as a constant at the end. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/media/usb/au0828/au0828-dvb.c | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/drivers/media/usb/au0828/au0828-dvb.c b/drivers/media/usb/au0828/au0828-dvb.c index cd542b4..e5f1e20 100644 --- a/drivers/media/usb/au0828/au0828-dvb.c +++ b/drivers/media/usb/au0828/au0828-dvb.c @@ -181,7 +181,7 @@ static int stop_urb_transfer(struct au0828_dev *dev) static int start_urb_transfer(struct au0828_dev *dev) { struct urb *purb; - int i, ret = -ENOMEM; + int i, ret; dprintk(2, "%s()\n", __func__); @@ -194,7 +194,7 @@ static int start_urb_transfer(struct au0828_dev *dev) dev->urbs[i] = usb_alloc_urb(0, GFP_KERNEL); if (!dev->urbs[i]) - goto err; + return -ENOMEM; purb = dev->urbs[i]; @@ -207,9 +207,10 @@ static int start_urb_transfer(struct au0828_dev *dev) if (!purb->transfer_buffer) { usb_free_urb(purb); dev->urbs[i] = NULL; + ret = -ENOMEM; pr_err("%s: failed big buffer allocation, err = %d\n", __func__, ret); - goto err; + return ret; } purb->status = -EINPROGRESS; @@ -235,10 +236,7 @@ static int start_urb_transfer(struct au0828_dev *dev) } dev->urb_streaming = true; - ret = 0; - -err: - return ret; + return 0; } static void au0828_start_transport(struct au0828_dev *dev) -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH] [media] au0828: Refactoring for start_urb_transfer() @ 2015-12-28 21:56 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-28 21:56 UTC (permalink / raw) To: linux-media, Mauro Carvalho Chehab; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Mon, 28 Dec 2015 22:52:48 +0100 This issue was detected by using the Coccinelle software. 1. Let us return directly if a buffer allocation failed. 2. Delete the jump label "err" then. 3. Drop the explicit initialisation for the variable "ret" at the beginning. 4. Return zero as a constant at the end. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/media/usb/au0828/au0828-dvb.c | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/drivers/media/usb/au0828/au0828-dvb.c b/drivers/media/usb/au0828/au0828-dvb.c index cd542b4..e5f1e20 100644 --- a/drivers/media/usb/au0828/au0828-dvb.c +++ b/drivers/media/usb/au0828/au0828-dvb.c @@ -181,7 +181,7 @@ static int stop_urb_transfer(struct au0828_dev *dev) static int start_urb_transfer(struct au0828_dev *dev) { struct urb *purb; - int i, ret = -ENOMEM; + int i, ret; dprintk(2, "%s()\n", __func__); @@ -194,7 +194,7 @@ static int start_urb_transfer(struct au0828_dev *dev) dev->urbs[i] = usb_alloc_urb(0, GFP_KERNEL); if (!dev->urbs[i]) - goto err; + return -ENOMEM; purb = dev->urbs[i]; @@ -207,9 +207,10 @@ static int start_urb_transfer(struct au0828_dev *dev) if (!purb->transfer_buffer) { usb_free_urb(purb); dev->urbs[i] = NULL; + ret = -ENOMEM; pr_err("%s: failed big buffer allocation, err = %d\n", __func__, ret); - goto err; + return ret; } purb->status = -EINPROGRESS; @@ -235,10 +236,7 @@ static int start_urb_transfer(struct au0828_dev *dev) } dev->urb_streaming = true; - ret = 0; - -err: - return ret; + return 0; } static void au0828_start_transport(struct au0828_dev *dev) -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH] [media] hdpvr: Refactoring for hdpvr_read() 2015-12-11 12:08 ` SF Markus Elfring @ 2015-12-29 10:18 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-29 10:18 UTC (permalink / raw) To: linux-media, Hans Verkuil, Mauro Carvalho Chehab Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 29 Dec 2015 11:02:43 +0100 Let us return directly if the element "status" of the variable "buf" indicates "BUFSTAT_READY". A check repetition can be excluded for the variable "ret" at the end then. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/media/usb/hdpvr/hdpvr-video.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/media/usb/hdpvr/hdpvr-video.c b/drivers/media/usb/hdpvr/hdpvr-video.c index 7dee22d..ba7f022 100644 --- a/drivers/media/usb/hdpvr/hdpvr-video.c +++ b/drivers/media/usb/hdpvr/hdpvr-video.c @@ -462,10 +462,8 @@ static ssize_t hdpvr_read(struct file *file, char __user *buffer, size_t count, } if (wait_event_interruptible(dev->wait_data, - buf->status == BUFSTAT_READY)) { - ret = -ERESTARTSYS; - goto err; - } + buf->status == BUFSTAT_READY)) + return -ERESTARTSYS; } if (buf->status != BUFSTAT_READY) -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH] [media] hdpvr: Refactoring for hdpvr_read() @ 2015-12-29 10:18 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-29 10:18 UTC (permalink / raw) To: linux-media, Hans Verkuil, Mauro Carvalho Chehab Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 29 Dec 2015 11:02:43 +0100 Let us return directly if the element "status" of the variable "buf" indicates "BUFSTAT_READY". A check repetition can be excluded for the variable "ret" at the end then. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/media/usb/hdpvr/hdpvr-video.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/media/usb/hdpvr/hdpvr-video.c b/drivers/media/usb/hdpvr/hdpvr-video.c index 7dee22d..ba7f022 100644 --- a/drivers/media/usb/hdpvr/hdpvr-video.c +++ b/drivers/media/usb/hdpvr/hdpvr-video.c @@ -462,10 +462,8 @@ static ssize_t hdpvr_read(struct file *file, char __user *buffer, size_t count, } if (wait_event_interruptible(dev->wait_data, - buf->status = BUFSTAT_READY)) { - ret = -ERESTARTSYS; - goto err; - } + buf->status = BUFSTAT_READY)) + return -ERESTARTSYS; } if (buf->status != BUFSTAT_READY) -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH] [media] msi2500: Delete an unnecessary check in msi2500_set_usb_adc() 2015-12-11 12:08 ` SF Markus Elfring @ 2015-12-29 11:37 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-29 11:37 UTC (permalink / raw) To: linux-media, Antti Palosaari, Mauro Carvalho Chehab Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 29 Dec 2015 12:32:41 +0100 This issue was detected by using the Coccinelle software. Return the value from a call of the msi2500_ctrl_msg() function without using an extra check for the variable "ret" at the end. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/media/usb/msi2500/msi2500.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/media/usb/msi2500/msi2500.c b/drivers/media/usb/msi2500/msi2500.c index c104315..2d33033 100644 --- a/drivers/media/usb/msi2500/msi2500.c +++ b/drivers/media/usb/msi2500/msi2500.c @@ -839,8 +839,6 @@ static int msi2500_set_usb_adc(struct msi2500_dev *dev) goto err; ret = msi2500_ctrl_msg(dev, CMD_WREG, reg3); - if (ret) - goto err; err: return ret; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH] [media] msi2500: Delete an unnecessary check in msi2500_set_usb_adc() @ 2015-12-29 11:37 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-29 11:37 UTC (permalink / raw) To: linux-media, Antti Palosaari, Mauro Carvalho Chehab Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 29 Dec 2015 12:32:41 +0100 This issue was detected by using the Coccinelle software. Return the value from a call of the msi2500_ctrl_msg() function without using an extra check for the variable "ret" at the end. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/media/usb/msi2500/msi2500.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/media/usb/msi2500/msi2500.c b/drivers/media/usb/msi2500/msi2500.c index c104315..2d33033 100644 --- a/drivers/media/usb/msi2500/msi2500.c +++ b/drivers/media/usb/msi2500/msi2500.c @@ -839,8 +839,6 @@ static int msi2500_set_usb_adc(struct msi2500_dev *dev) goto err; ret = msi2500_ctrl_msg(dev, CMD_WREG, reg3); - if (ret) - goto err; err: return ret; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH] mfd-dm355evm_msp: One function call less in add_child() after error detection 2015-12-11 12:08 ` SF Markus Elfring @ 2015-12-29 13:04 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-29 13:04 UTC (permalink / raw) To: LKML, Lee Jones; +Cc: kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 29 Dec 2015 13:56:42 +0100 The platform_device_put() function was called in one case by the add_child() function during error handling even if the passed variable "pdev" contained a null pointer. Implementation details could be improved by the adjustment of jump targets according to the Linux coding style convention. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/mfd/dm355evm_msp.c | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/drivers/mfd/dm355evm_msp.c b/drivers/mfd/dm355evm_msp.c index bc90efe..e4aa1b8 100644 --- a/drivers/mfd/dm355evm_msp.c +++ b/drivers/mfd/dm355evm_msp.c @@ -202,7 +202,7 @@ static struct device *add_child(struct i2c_client *client, const char *name, if (!pdev) { dev_dbg(&client->dev, "can't alloc dev\n"); status = -ENOMEM; - goto err; + goto report_failure; } device_init_wakeup(&pdev->dev, can_wakeup); @@ -212,7 +212,7 @@ static struct device *add_child(struct i2c_client *client, const char *name, status = platform_device_add_data(pdev, pdata, pdata_len); if (status < 0) { dev_dbg(&pdev->dev, "can't add platform_data\n"); - goto err; + goto put_device; } } @@ -225,19 +225,18 @@ static struct device *add_child(struct i2c_client *client, const char *name, status = platform_device_add_resources(pdev, &r, 1); if (status < 0) { dev_dbg(&pdev->dev, "can't add irq\n"); - goto err; + goto put_device; } } status = platform_device_add(pdev); - -err: - if (status < 0) { - platform_device_put(pdev); - dev_err(&client->dev, "can't add %s dev\n", name); - return ERR_PTR(status); - } - return &pdev->dev; + if (!status) + return &pdev->dev; +put_device: + platform_device_put(pdev); +report_failure: + dev_err(&client->dev, "can't add %s dev\n", name); + return ERR_PTR(status); } static int add_children(struct i2c_client *client) -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH] mfd-dm355evm_msp: One function call less in add_child() after error detection @ 2015-12-29 13:04 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-29 13:04 UTC (permalink / raw) To: LKML, Lee Jones; +Cc: kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 29 Dec 2015 13:56:42 +0100 The platform_device_put() function was called in one case by the add_child() function during error handling even if the passed variable "pdev" contained a null pointer. Implementation details could be improved by the adjustment of jump targets according to the Linux coding style convention. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/mfd/dm355evm_msp.c | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/drivers/mfd/dm355evm_msp.c b/drivers/mfd/dm355evm_msp.c index bc90efe..e4aa1b8 100644 --- a/drivers/mfd/dm355evm_msp.c +++ b/drivers/mfd/dm355evm_msp.c @@ -202,7 +202,7 @@ static struct device *add_child(struct i2c_client *client, const char *name, if (!pdev) { dev_dbg(&client->dev, "can't alloc dev\n"); status = -ENOMEM; - goto err; + goto report_failure; } device_init_wakeup(&pdev->dev, can_wakeup); @@ -212,7 +212,7 @@ static struct device *add_child(struct i2c_client *client, const char *name, status = platform_device_add_data(pdev, pdata, pdata_len); if (status < 0) { dev_dbg(&pdev->dev, "can't add platform_data\n"); - goto err; + goto put_device; } } @@ -225,19 +225,18 @@ static struct device *add_child(struct i2c_client *client, const char *name, status = platform_device_add_resources(pdev, &r, 1); if (status < 0) { dev_dbg(&pdev->dev, "can't add irq\n"); - goto err; + goto put_device; } } status = platform_device_add(pdev); - -err: - if (status < 0) { - platform_device_put(pdev); - dev_err(&client->dev, "can't add %s dev\n", name); - return ERR_PTR(status); - } - return &pdev->dev; + if (!status) + return &pdev->dev; +put_device: + platform_device_put(pdev); +report_failure: + dev_err(&client->dev, "can't add %s dev\n", name); + return ERR_PTR(status); } static int add_children(struct i2c_client *client) -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH] mfd-dm355evm_msp: One function call less in add_child() after error detection 2015-12-29 13:04 ` SF Markus Elfring @ 2016-01-11 8:31 ` Lee Jones -1 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-01-11 8:31 UTC (permalink / raw) To: SF Markus Elfring; +Cc: LKML, kernel-janitors, Julia Lawall On Tue, 29 Dec 2015, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Tue, 29 Dec 2015 13:56:42 +0100 > > The platform_device_put() function was called in one case by the > add_child() function during error handling even if the passed > variable "pdev" contained a null pointer. > > Implementation details could be improved by the adjustment of jump targets > according to the Linux coding style convention. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/mfd/dm355evm_msp.c | 21 ++++++++++----------- > 1 file changed, 10 insertions(+), 11 deletions(-) Same comments as before. > diff --git a/drivers/mfd/dm355evm_msp.c b/drivers/mfd/dm355evm_msp.c > index bc90efe..e4aa1b8 100644 > --- a/drivers/mfd/dm355evm_msp.c > +++ b/drivers/mfd/dm355evm_msp.c > @@ -202,7 +202,7 @@ static struct device *add_child(struct i2c_client *client, const char *name, > if (!pdev) { > dev_dbg(&client->dev, "can't alloc dev\n"); > status = -ENOMEM; > - goto err; > + goto report_failure; > } > > device_init_wakeup(&pdev->dev, can_wakeup); > @@ -212,7 +212,7 @@ static struct device *add_child(struct i2c_client *client, const char *name, > status = platform_device_add_data(pdev, pdata, pdata_len); > if (status < 0) { > dev_dbg(&pdev->dev, "can't add platform_data\n"); > - goto err; > + goto put_device; > } > } > > @@ -225,19 +225,18 @@ static struct device *add_child(struct i2c_client *client, const char *name, > status = platform_device_add_resources(pdev, &r, 1); > if (status < 0) { > dev_dbg(&pdev->dev, "can't add irq\n"); > - goto err; > + goto put_device; > } > } > > status = platform_device_add(pdev); > - > -err: > - if (status < 0) { > - platform_device_put(pdev); > - dev_err(&client->dev, "can't add %s dev\n", name); > - return ERR_PTR(status); > - } > - return &pdev->dev; > + if (!status) > + return &pdev->dev; > +put_device: > + platform_device_put(pdev); > +report_failure: > + dev_err(&client->dev, "can't add %s dev\n", name); > + return ERR_PTR(status); > } > > static int add_children(struct i2c_client *client) -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] mfd-dm355evm_msp: One function call less in add_child() after error detection @ 2016-01-11 8:31 ` Lee Jones 0 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-01-11 8:31 UTC (permalink / raw) To: SF Markus Elfring; +Cc: LKML, kernel-janitors, Julia Lawall On Tue, 29 Dec 2015, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Tue, 29 Dec 2015 13:56:42 +0100 > > The platform_device_put() function was called in one case by the > add_child() function during error handling even if the passed > variable "pdev" contained a null pointer. > > Implementation details could be improved by the adjustment of jump targets > according to the Linux coding style convention. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/mfd/dm355evm_msp.c | 21 ++++++++++----------- > 1 file changed, 10 insertions(+), 11 deletions(-) Same comments as before. > diff --git a/drivers/mfd/dm355evm_msp.c b/drivers/mfd/dm355evm_msp.c > index bc90efe..e4aa1b8 100644 > --- a/drivers/mfd/dm355evm_msp.c > +++ b/drivers/mfd/dm355evm_msp.c > @@ -202,7 +202,7 @@ static struct device *add_child(struct i2c_client *client, const char *name, > if (!pdev) { > dev_dbg(&client->dev, "can't alloc dev\n"); > status = -ENOMEM; > - goto err; > + goto report_failure; > } > > device_init_wakeup(&pdev->dev, can_wakeup); > @@ -212,7 +212,7 @@ static struct device *add_child(struct i2c_client *client, const char *name, > status = platform_device_add_data(pdev, pdata, pdata_len); > if (status < 0) { > dev_dbg(&pdev->dev, "can't add platform_data\n"); > - goto err; > + goto put_device; > } > } > > @@ -225,19 +225,18 @@ static struct device *add_child(struct i2c_client *client, const char *name, > status = platform_device_add_resources(pdev, &r, 1); > if (status < 0) { > dev_dbg(&pdev->dev, "can't add irq\n"); > - goto err; > + goto put_device; > } > } > > status = platform_device_add(pdev); > - > -err: > - if (status < 0) { > - platform_device_put(pdev); > - dev_err(&client->dev, "can't add %s dev\n", name); > - return ERR_PTR(status); > - } > - return &pdev->dev; > + if (!status) > + return &pdev->dev; > +put_device: > + platform_device_put(pdev); > +report_failure: > + dev_err(&client->dev, "can't add %s dev\n", name); > + return ERR_PTR(status); > } > > static int add_children(struct i2c_client *client) -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: mfd-dm355evm_msp: One function call less in add_child() after error detection 2016-01-11 8:31 ` Lee Jones @ 2016-01-12 8:34 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-12 8:34 UTC (permalink / raw) To: Lee Jones; +Cc: LKML, kernel-janitors, Julia Lawall >> The platform_device_put() function was called in one case by the >> add_child() function during error handling even if the passed >> variable "pdev" contained a null pointer. >> >> Implementation details could be improved by the adjustment of jump targets >> according to the Linux coding style convention. >> >> This issue was detected by using the Coccinelle software. >> >> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> >> --- >> drivers/mfd/dm355evm_msp.c | 21 ++++++++++----------- >> 1 file changed, 10 insertions(+), 11 deletions(-) > > Same comments as before. To which comments do you refer here? Are you interested in any further clarification of open issues? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: mfd-dm355evm_msp: One function call less in add_child() after error detection @ 2016-01-12 8:34 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-12 8:34 UTC (permalink / raw) To: Lee Jones; +Cc: LKML, kernel-janitors, Julia Lawall >> The platform_device_put() function was called in one case by the >> add_child() function during error handling even if the passed >> variable "pdev" contained a null pointer. >> >> Implementation details could be improved by the adjustment of jump targets >> according to the Linux coding style convention. >> >> This issue was detected by using the Coccinelle software. >> >> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> >> --- >> drivers/mfd/dm355evm_msp.c | 21 ++++++++++----------- >> 1 file changed, 10 insertions(+), 11 deletions(-) > > Same comments as before. To which comments do you refer here? Are you interested in any further clarification of open issues? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: mfd-dm355evm_msp: One function call less in add_child() after error detection 2016-01-12 8:34 ` SF Markus Elfring @ 2016-01-12 9:06 ` Lee Jones -1 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-01-12 9:06 UTC (permalink / raw) To: SF Markus Elfring; +Cc: LKML, kernel-janitors, Julia Lawall On Tue, 12 Jan 2016, SF Markus Elfring wrote: > >> The platform_device_put() function was called in one case by the > >> add_child() function during error handling even if the passed > >> variable "pdev" contained a null pointer. > >> > >> Implementation details could be improved by the adjustment of jump targets > >> according to the Linux coding style convention. > >> > >> This issue was detected by using the Coccinelle software. > >> > >> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > >> --- > >> drivers/mfd/dm355evm_msp.c | 21 ++++++++++----------- > >> 1 file changed, 10 insertions(+), 11 deletions(-) > > > > Same comments as before. > > To which comments do you refer here? > > Are you interested in any further clarification of open issues? I'm sure you'll work it out. ;) -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: mfd-dm355evm_msp: One function call less in add_child() after error detection @ 2016-01-12 9:06 ` Lee Jones 0 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-01-12 9:06 UTC (permalink / raw) To: SF Markus Elfring; +Cc: LKML, kernel-janitors, Julia Lawall On Tue, 12 Jan 2016, SF Markus Elfring wrote: > >> The platform_device_put() function was called in one case by the > >> add_child() function during error handling even if the passed > >> variable "pdev" contained a null pointer. > >> > >> Implementation details could be improved by the adjustment of jump targets > >> according to the Linux coding style convention. > >> > >> This issue was detected by using the Coccinelle software. > >> > >> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > >> --- > >> drivers/mfd/dm355evm_msp.c | 21 ++++++++++----------- > >> 1 file changed, 10 insertions(+), 11 deletions(-) > > > > Same comments as before. > > To which comments do you refer here? > > Are you interested in any further clarification of open issues? I'm sure you'll work it out. ;) -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: mfd-dm355evm_msp: One function call less in add_child() after error detection 2016-01-12 9:06 ` Lee Jones @ 2016-01-12 11:48 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-12 11:48 UTC (permalink / raw) To: Lee Jones; +Cc: LKML, kernel-janitors, Julia Lawall > I'm sure you'll work it out. ;) Do you want any changes for this suggestion around the software component "dm355evm_msp"? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: mfd-dm355evm_msp: One function call less in add_child() after error detection @ 2016-01-12 11:48 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-12 11:48 UTC (permalink / raw) To: Lee Jones; +Cc: LKML, kernel-janitors, Julia Lawall > I'm sure you'll work it out. ;) Do you want any changes for this suggestion around the software component "dm355evm_msp"? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: mfd-dm355evm_msp: One function call less in add_child() after error detection 2016-01-12 11:48 ` SF Markus Elfring @ 2016-01-12 11:59 ` Lee Jones -1 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-01-12 11:59 UTC (permalink / raw) To: SF Markus Elfring; +Cc: LKML, kernel-janitors, Julia Lawall On Tue, 12 Jan 2016, SF Markus Elfring wrote: > > I'm sure you'll work it out. ;) > > Do you want any changes for this suggestion around the software > component "dm355evm_msp"? There we go. I have been more explicit as there was obviously some confusion. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: mfd-dm355evm_msp: One function call less in add_child() after error detection @ 2016-01-12 11:59 ` Lee Jones 0 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-01-12 11:59 UTC (permalink / raw) To: SF Markus Elfring; +Cc: LKML, kernel-janitors, Julia Lawall On Tue, 12 Jan 2016, SF Markus Elfring wrote: > > I'm sure you'll work it out. ;) > > Do you want any changes for this suggestion around the software > component "dm355evm_msp"? There we go. I have been more explicit as there was obviously some confusion. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] mfd-dm355evm_msp: One function call less in add_child() after error detection 2015-12-29 13:04 ` SF Markus Elfring @ 2016-01-12 11:59 ` Lee Jones -1 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-01-12 11:59 UTC (permalink / raw) To: SF Markus Elfring; +Cc: LKML, kernel-janitors, Julia Lawall The subject format is wrong and the summary itself isn't very informative. On Tue, 29 Dec 2015, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Tue, 29 Dec 2015 13:56:42 +0100 This patch format is wrong, please consider using `git format-patch` and `git send-email`. > The platform_device_put() function was called in one case by the > add_child() function during error handling even if the passed > variable "pdev" contained a null pointer. > > Implementation details could be improved by the adjustment of jump targets > according to the Linux coding style convention. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/mfd/dm355evm_msp.c | 21 ++++++++++----------- > 1 file changed, 10 insertions(+), 11 deletions(-) > > diff --git a/drivers/mfd/dm355evm_msp.c b/drivers/mfd/dm355evm_msp.c > index bc90efe..e4aa1b8 100644 > --- a/drivers/mfd/dm355evm_msp.c > +++ b/drivers/mfd/dm355evm_msp.c > @@ -202,7 +202,7 @@ static struct device *add_child(struct i2c_client *client, const char *name, > if (!pdev) { > dev_dbg(&client->dev, "can't alloc dev\n"); Make this dev_err(). > status = -ENOMEM; > - goto err; > + goto report_failure; Return here. > } > > device_init_wakeup(&pdev->dev, can_wakeup); > @@ -212,7 +212,7 @@ static struct device *add_child(struct i2c_client *client, const char *name, > status = platform_device_add_data(pdev, pdata, pdata_len); > if (status < 0) { > dev_dbg(&pdev->dev, "can't add platform_data\n"); > - goto err; > + goto put_device; > } > } > > @@ -225,19 +225,18 @@ static struct device *add_child(struct i2c_client *client, const char *name, > status = platform_device_add_resources(pdev, &r, 1); > if (status < 0) { > dev_dbg(&pdev->dev, "can't add irq\n"); > - goto err; > + goto put_device; > } > } > > status = platform_device_add(pdev); > - > -err: > - if (status < 0) { > - platform_device_put(pdev); > - dev_err(&client->dev, "can't add %s dev\n", name); > - return ERR_PTR(status); > - } > - return &pdev->dev; > + if (!status) Be more consistent here. Reverse the condition and return an instead, as you do above. > + return &pdev->dev; > +put_device: > + platform_device_put(pdev); > +report_failure: > + dev_err(&client->dev, "can't add %s dev\n", name); This isn't a very friendly error message. Better to convert the dev_dbg() calls to dev_err() and tell the user what the problem was. > + return ERR_PTR(status); > } > > static int add_children(struct i2c_client *client) -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] mfd-dm355evm_msp: One function call less in add_child() after error detection @ 2016-01-12 11:59 ` Lee Jones 0 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-01-12 11:59 UTC (permalink / raw) To: SF Markus Elfring; +Cc: LKML, kernel-janitors, Julia Lawall The subject format is wrong and the summary itself isn't very informative. On Tue, 29 Dec 2015, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Tue, 29 Dec 2015 13:56:42 +0100 This patch format is wrong, please consider using `git format-patch` and `git send-email`. > The platform_device_put() function was called in one case by the > add_child() function during error handling even if the passed > variable "pdev" contained a null pointer. > > Implementation details could be improved by the adjustment of jump targets > according to the Linux coding style convention. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/mfd/dm355evm_msp.c | 21 ++++++++++----------- > 1 file changed, 10 insertions(+), 11 deletions(-) > > diff --git a/drivers/mfd/dm355evm_msp.c b/drivers/mfd/dm355evm_msp.c > index bc90efe..e4aa1b8 100644 > --- a/drivers/mfd/dm355evm_msp.c > +++ b/drivers/mfd/dm355evm_msp.c > @@ -202,7 +202,7 @@ static struct device *add_child(struct i2c_client *client, const char *name, > if (!pdev) { > dev_dbg(&client->dev, "can't alloc dev\n"); Make this dev_err(). > status = -ENOMEM; > - goto err; > + goto report_failure; Return here. > } > > device_init_wakeup(&pdev->dev, can_wakeup); > @@ -212,7 +212,7 @@ static struct device *add_child(struct i2c_client *client, const char *name, > status = platform_device_add_data(pdev, pdata, pdata_len); > if (status < 0) { > dev_dbg(&pdev->dev, "can't add platform_data\n"); > - goto err; > + goto put_device; > } > } > > @@ -225,19 +225,18 @@ static struct device *add_child(struct i2c_client *client, const char *name, > status = platform_device_add_resources(pdev, &r, 1); > if (status < 0) { > dev_dbg(&pdev->dev, "can't add irq\n"); > - goto err; > + goto put_device; > } > } > > status = platform_device_add(pdev); > - > -err: > - if (status < 0) { > - platform_device_put(pdev); > - dev_err(&client->dev, "can't add %s dev\n", name); > - return ERR_PTR(status); > - } > - return &pdev->dev; > + if (!status) Be more consistent here. Reverse the condition and return an instead, as you do above. > + return &pdev->dev; > +put_device: > + platform_device_put(pdev); > +report_failure: > + dev_err(&client->dev, "can't add %s dev\n", name); This isn't a very friendly error message. Better to convert the dev_dbg() calls to dev_err() and tell the user what the problem was. > + return ERR_PTR(status); > } > > static int add_children(struct i2c_client *client) -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: mfd-dm355evm_msp: One function call less in add_child() after error detection 2016-01-12 11:59 ` Lee Jones @ 2016-01-12 12:20 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-12 12:20 UTC (permalink / raw) To: Lee Jones; +Cc: LKML, kernel-janitors, Julia Lawall > The subject format is wrong Which format do you expect? > and the summary itself isn't very informative. Which wording do you find more useful? >> From: Markus Elfring <elfring@users.sourceforge.net> >> Date: Tue, 29 Dec 2015 13:56:42 +0100 > > This patch format is wrong, You might find the use of additional fields in the message body unusual. I have got an other impression from the canonical patch format. > please consider using `git format-patch` and `git send-email`. Thanks for your suggestion. >> The platform_device_put() function was called in one case by the >> add_child() function during error handling even if the passed >> variable "pdev" contained a null pointer. >> >> Implementation details could be improved by the adjustment of jump targets >> according to the Linux coding style convention. I am going to integrate the source code changes that you requested a bit later. >> +report_failure: >> + dev_err(&client->dev, "can't add %s dev\n", name); > > This isn't a very friendly error message. Better to convert the > dev_dbg() calls to dev_err() and tell the user what the problem was. Which information display would be more appropriate here? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: mfd-dm355evm_msp: One function call less in add_child() after error detection @ 2016-01-12 12:20 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-12 12:20 UTC (permalink / raw) To: Lee Jones; +Cc: LKML, kernel-janitors, Julia Lawall > The subject format is wrong Which format do you expect? > and the summary itself isn't very informative. Which wording do you find more useful? >> From: Markus Elfring <elfring@users.sourceforge.net> >> Date: Tue, 29 Dec 2015 13:56:42 +0100 > > This patch format is wrong, You might find the use of additional fields in the message body unusual. I have got an other impression from the canonical patch format. > please consider using `git format-patch` and `git send-email`. Thanks for your suggestion. >> The platform_device_put() function was called in one case by the >> add_child() function during error handling even if the passed >> variable "pdev" contained a null pointer. >> >> Implementation details could be improved by the adjustment of jump targets >> according to the Linux coding style convention. I am going to integrate the source code changes that you requested a bit later. >> +report_failure: >> + dev_err(&client->dev, "can't add %s dev\n", name); > > This isn't a very friendly error message. Better to convert the > dev_dbg() calls to dev_err() and tell the user what the problem was. Which information display would be more appropriate here? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/2] mfd: smsc-ece1099: Fine-tuning for smsc_i2c_probe() 2015-12-11 12:08 ` SF Markus Elfring @ 2015-12-29 14:15 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-29 14:15 UTC (permalink / raw) To: LKML, Lee Jones; +Cc: kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 29 Dec 2015 15:10:48 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an unnecessary variable initialisation Refactoring drivers/mfd/smsc-ece1099.c | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/2] mfd: smsc-ece1099: Fine-tuning for smsc_i2c_probe() @ 2015-12-29 14:15 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-29 14:15 UTC (permalink / raw) To: LKML, Lee Jones; +Cc: kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 29 Dec 2015 15:10:48 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an unnecessary variable initialisation Refactoring drivers/mfd/smsc-ece1099.c | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 1/2] mfd: smsc-ece1099: Delete an unnecessary variable initialisation in smsc_i2c_probe() 2015-12-29 14:15 ` SF Markus Elfring @ 2015-12-29 14:17 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-29 14:17 UTC (permalink / raw) To: LKML, Lee Jones; +Cc: kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 29 Dec 2015 14:47:40 +0100 The variable "ret" will be set to an appropriate value a bit later. Thus let us omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/mfd/smsc-ece1099.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mfd/smsc-ece1099.c b/drivers/mfd/smsc-ece1099.c index a4c0df7..bcac488 100644 --- a/drivers/mfd/smsc-ece1099.c +++ b/drivers/mfd/smsc-ece1099.c @@ -36,7 +36,7 @@ static int smsc_i2c_probe(struct i2c_client *i2c, { struct smsc *smsc; int devid, rev, venid_l, venid_h; - int ret = 0; + int ret; smsc = devm_kzalloc(&i2c->dev, sizeof(struct smsc), GFP_KERNEL); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 1/2] mfd: smsc-ece1099: Delete an unnecessary variable initialisation in smsc_i2c_probe() @ 2015-12-29 14:17 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-29 14:17 UTC (permalink / raw) To: LKML, Lee Jones; +Cc: kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 29 Dec 2015 14:47:40 +0100 The variable "ret" will be set to an appropriate value a bit later. Thus let us omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/mfd/smsc-ece1099.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mfd/smsc-ece1099.c b/drivers/mfd/smsc-ece1099.c index a4c0df7..bcac488 100644 --- a/drivers/mfd/smsc-ece1099.c +++ b/drivers/mfd/smsc-ece1099.c @@ -36,7 +36,7 @@ static int smsc_i2c_probe(struct i2c_client *i2c, { struct smsc *smsc; int devid, rev, venid_l, venid_h; - int ret = 0; + int ret; smsc = devm_kzalloc(&i2c->dev, sizeof(struct smsc), GFP_KERNEL); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/2] mfd: smsc-ece1099: Delete an unnecessary variable initialisation in smsc_i2c_probe() 2015-12-29 14:17 ` SF Markus Elfring @ 2016-01-11 8:15 ` Lee Jones -1 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-01-11 8:15 UTC (permalink / raw) To: SF Markus Elfring; +Cc: LKML, kernel-janitors, Julia Lawall On Tue, 29 Dec 2015, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Tue, 29 Dec 2015 14:47:40 +0100 > > The variable "ret" will be set to an appropriate value a bit later. > Thus let us omit the explicit initialisation at the beginning. Not sure this change is worth your or my time to be frank. I could understand if you were a first time submitter who was dipping their toe in the water, but for someone with 200+ patches, I really think you should be focusing on less trivial matters. > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/mfd/smsc-ece1099.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/mfd/smsc-ece1099.c b/drivers/mfd/smsc-ece1099.c > index a4c0df7..bcac488 100644 > --- a/drivers/mfd/smsc-ece1099.c > +++ b/drivers/mfd/smsc-ece1099.c > @@ -36,7 +36,7 @@ static int smsc_i2c_probe(struct i2c_client *i2c, > { > struct smsc *smsc; > int devid, rev, venid_l, venid_h; > - int ret = 0; > + int ret; > > smsc = devm_kzalloc(&i2c->dev, sizeof(struct smsc), > GFP_KERNEL); -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/2] mfd: smsc-ece1099: Delete an unnecessary variable initialisation in smsc_i2c_probe() @ 2016-01-11 8:15 ` Lee Jones 0 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-01-11 8:15 UTC (permalink / raw) To: SF Markus Elfring; +Cc: LKML, kernel-janitors, Julia Lawall On Tue, 29 Dec 2015, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Tue, 29 Dec 2015 14:47:40 +0100 > > The variable "ret" will be set to an appropriate value a bit later. > Thus let us omit the explicit initialisation at the beginning. Not sure this change is worth your or my time to be frank. I could understand if you were a first time submitter who was dipping their toe in the water, but for someone with 200+ patches, I really think you should be focusing on less trivial matters. > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/mfd/smsc-ece1099.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/mfd/smsc-ece1099.c b/drivers/mfd/smsc-ece1099.c > index a4c0df7..bcac488 100644 > --- a/drivers/mfd/smsc-ece1099.c > +++ b/drivers/mfd/smsc-ece1099.c > @@ -36,7 +36,7 @@ static int smsc_i2c_probe(struct i2c_client *i2c, > { > struct smsc *smsc; > int devid, rev, venid_l, venid_h; > - int ret = 0; > + int ret; > > smsc = devm_kzalloc(&i2c->dev, sizeof(struct smsc), > GFP_KERNEL); -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 2/2] mfd: smsc-ece1099: Refactoring for smsc_i2c_probe() 2015-12-29 14:15 ` SF Markus Elfring @ 2015-12-29 14:18 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-29 14:18 UTC (permalink / raw) To: LKML, Lee Jones; +Cc: kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 29 Dec 2015 15:03:31 +0100 This issue was detected by using the Coccinelle software. * Let us return directly if a call of the function "devm_regmap_init_i2c" or "regmap_write" failed. * Delete the jump label "err" then. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/mfd/smsc-ece1099.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/mfd/smsc-ece1099.c b/drivers/mfd/smsc-ece1099.c index bcac488..951333a 100644 --- a/drivers/mfd/smsc-ece1099.c +++ b/drivers/mfd/smsc-ece1099.c @@ -46,10 +46,8 @@ static int smsc_i2c_probe(struct i2c_client *i2c, } smsc->regmap = devm_regmap_init_i2c(i2c, &smsc_regmap_config); - if (IS_ERR(smsc->regmap)) { - ret = PTR_ERR(smsc->regmap); - goto err; - } + if (IS_ERR(smsc->regmap)) + return PTR_ERR(smsc->regmap); i2c_set_clientdata(i2c, smsc); smsc->dev = &i2c->dev; @@ -68,7 +66,7 @@ static int smsc_i2c_probe(struct i2c_client *i2c, ret = regmap_write(smsc->regmap, SMSC_CLK_CTRL, smsc->clk); if (ret) - goto err; + return ret; #ifdef CONFIG_OF if (i2c->dev.of_node) @@ -76,7 +74,6 @@ static int smsc_i2c_probe(struct i2c_client *i2c, NULL, NULL, &i2c->dev); #endif -err: return ret; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 2/2] mfd: smsc-ece1099: Refactoring for smsc_i2c_probe() @ 2015-12-29 14:18 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-29 14:18 UTC (permalink / raw) To: LKML, Lee Jones; +Cc: kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 29 Dec 2015 15:03:31 +0100 This issue was detected by using the Coccinelle software. * Let us return directly if a call of the function "devm_regmap_init_i2c" or "regmap_write" failed. * Delete the jump label "err" then. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/mfd/smsc-ece1099.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/mfd/smsc-ece1099.c b/drivers/mfd/smsc-ece1099.c index bcac488..951333a 100644 --- a/drivers/mfd/smsc-ece1099.c +++ b/drivers/mfd/smsc-ece1099.c @@ -46,10 +46,8 @@ static int smsc_i2c_probe(struct i2c_client *i2c, } smsc->regmap = devm_regmap_init_i2c(i2c, &smsc_regmap_config); - if (IS_ERR(smsc->regmap)) { - ret = PTR_ERR(smsc->regmap); - goto err; - } + if (IS_ERR(smsc->regmap)) + return PTR_ERR(smsc->regmap); i2c_set_clientdata(i2c, smsc); smsc->dev = &i2c->dev; @@ -68,7 +66,7 @@ static int smsc_i2c_probe(struct i2c_client *i2c, ret = regmap_write(smsc->regmap, SMSC_CLK_CTRL, smsc->clk); if (ret) - goto err; + return ret; #ifdef CONFIG_OF if (i2c->dev.of_node) @@ -76,7 +74,6 @@ static int smsc_i2c_probe(struct i2c_client *i2c, NULL, NULL, &i2c->dev); #endif -err: return ret; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] mfd: smsc-ece1099: Refactoring for smsc_i2c_probe() 2015-12-29 14:18 ` SF Markus Elfring @ 2016-01-11 8:10 ` Lee Jones -1 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-01-11 8:10 UTC (permalink / raw) To: SF Markus Elfring; +Cc: LKML, kernel-janitors, Julia Lawall On Tue, 29 Dec 2015, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Tue, 29 Dec 2015 15:03:31 +0100 > > This issue was detected by using the Coccinelle software. > > * Let us return directly if a call of the function "devm_regmap_init_i2c" > or "regmap_write" failed. > > * Delete the jump label "err" then. Why are you bullet pointing here? Just use proper sentences to tell us what's going on. > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/mfd/smsc-ece1099.c | 9 +++------ > 1 file changed, 3 insertions(+), 6 deletions(-) Code looks fine however. Please re-submit the set with the aforementioned changes along with my: Acked-by: Lee Jones <lee.jones@linaro.org> > diff --git a/drivers/mfd/smsc-ece1099.c b/drivers/mfd/smsc-ece1099.c > index bcac488..951333a 100644 > --- a/drivers/mfd/smsc-ece1099.c > +++ b/drivers/mfd/smsc-ece1099.c > @@ -46,10 +46,8 @@ static int smsc_i2c_probe(struct i2c_client *i2c, > } > > smsc->regmap = devm_regmap_init_i2c(i2c, &smsc_regmap_config); > - if (IS_ERR(smsc->regmap)) { > - ret = PTR_ERR(smsc->regmap); > - goto err; > - } > + if (IS_ERR(smsc->regmap)) > + return PTR_ERR(smsc->regmap); > > i2c_set_clientdata(i2c, smsc); > smsc->dev = &i2c->dev; > @@ -68,7 +66,7 @@ static int smsc_i2c_probe(struct i2c_client *i2c, > > ret = regmap_write(smsc->regmap, SMSC_CLK_CTRL, smsc->clk); > if (ret) > - goto err; > + return ret; > > #ifdef CONFIG_OF > if (i2c->dev.of_node) > @@ -76,7 +74,6 @@ static int smsc_i2c_probe(struct i2c_client *i2c, > NULL, NULL, &i2c->dev); > #endif > > -err: > return ret; > } > -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] mfd: smsc-ece1099: Refactoring for smsc_i2c_probe() @ 2016-01-11 8:10 ` Lee Jones 0 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-01-11 8:10 UTC (permalink / raw) To: SF Markus Elfring; +Cc: LKML, kernel-janitors, Julia Lawall On Tue, 29 Dec 2015, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Tue, 29 Dec 2015 15:03:31 +0100 > > This issue was detected by using the Coccinelle software. > > * Let us return directly if a call of the function "devm_regmap_init_i2c" > or "regmap_write" failed. > > * Delete the jump label "err" then. Why are you bullet pointing here? Just use proper sentences to tell us what's going on. > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/mfd/smsc-ece1099.c | 9 +++------ > 1 file changed, 3 insertions(+), 6 deletions(-) Code looks fine however. Please re-submit the set with the aforementioned changes along with my: Acked-by: Lee Jones <lee.jones@linaro.org> > diff --git a/drivers/mfd/smsc-ece1099.c b/drivers/mfd/smsc-ece1099.c > index bcac488..951333a 100644 > --- a/drivers/mfd/smsc-ece1099.c > +++ b/drivers/mfd/smsc-ece1099.c > @@ -46,10 +46,8 @@ static int smsc_i2c_probe(struct i2c_client *i2c, > } > > smsc->regmap = devm_regmap_init_i2c(i2c, &smsc_regmap_config); > - if (IS_ERR(smsc->regmap)) { > - ret = PTR_ERR(smsc->regmap); > - goto err; > - } > + if (IS_ERR(smsc->regmap)) > + return PTR_ERR(smsc->regmap); > > i2c_set_clientdata(i2c, smsc); > smsc->dev = &i2c->dev; > @@ -68,7 +66,7 @@ static int smsc_i2c_probe(struct i2c_client *i2c, > > ret = regmap_write(smsc->regmap, SMSC_CLK_CTRL, smsc->clk); > if (ret) > - goto err; > + return ret; > > #ifdef CONFIG_OF > if (i2c->dev.of_node) > @@ -76,7 +74,6 @@ static int smsc_i2c_probe(struct i2c_client *i2c, > NULL, NULL, &i2c->dev); > #endif > > -err: > return ret; > } > -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] mfd: smsc-ece1099: Refactoring for smsc_i2c_probe() 2016-01-11 8:10 ` Lee Jones @ 2016-01-11 8:12 ` Lee Jones -1 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-01-11 8:12 UTC (permalink / raw) To: SF Markus Elfring; +Cc: LKML, kernel-janitors, Julia Lawall Oh, the subject line is also duff. Please describe the changes properly. "refactoring X", "making changes to Y" are not good subject lines. On Mon, 11 Jan 2016, Lee Jones wrote: > On Tue, 29 Dec 2015, SF Markus Elfring wrote: > > > From: Markus Elfring <elfring@users.sourceforge.net> > > Date: Tue, 29 Dec 2015 15:03:31 +0100 > > > > This issue was detected by using the Coccinelle software. > > > > * Let us return directly if a call of the function "devm_regmap_init_i2c" > > or "regmap_write" failed. > > > > * Delete the jump label "err" then. > > Why are you bullet pointing here? > > Just use proper sentences to tell us what's going on. > > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > > --- > > drivers/mfd/smsc-ece1099.c | 9 +++------ > > 1 file changed, 3 insertions(+), 6 deletions(-) > > Code looks fine however. > > Please re-submit the set with the aforementioned changes along with my: > > Acked-by: Lee Jones <lee.jones@linaro.org> > > > diff --git a/drivers/mfd/smsc-ece1099.c b/drivers/mfd/smsc-ece1099.c > > index bcac488..951333a 100644 > > --- a/drivers/mfd/smsc-ece1099.c > > +++ b/drivers/mfd/smsc-ece1099.c > > @@ -46,10 +46,8 @@ static int smsc_i2c_probe(struct i2c_client *i2c, > > } > > > > smsc->regmap = devm_regmap_init_i2c(i2c, &smsc_regmap_config); > > - if (IS_ERR(smsc->regmap)) { > > - ret = PTR_ERR(smsc->regmap); > > - goto err; > > - } > > + if (IS_ERR(smsc->regmap)) > > + return PTR_ERR(smsc->regmap); > > > > i2c_set_clientdata(i2c, smsc); > > smsc->dev = &i2c->dev; > > @@ -68,7 +66,7 @@ static int smsc_i2c_probe(struct i2c_client *i2c, > > > > ret = regmap_write(smsc->regmap, SMSC_CLK_CTRL, smsc->clk); > > if (ret) > > - goto err; > > + return ret; > > > > #ifdef CONFIG_OF > > if (i2c->dev.of_node) > > @@ -76,7 +74,6 @@ static int smsc_i2c_probe(struct i2c_client *i2c, > > NULL, NULL, &i2c->dev); > > #endif > > > > -err: > > return ret; > > } > > > -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] mfd: smsc-ece1099: Refactoring for smsc_i2c_probe() @ 2016-01-11 8:12 ` Lee Jones 0 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-01-11 8:12 UTC (permalink / raw) To: SF Markus Elfring; +Cc: LKML, kernel-janitors, Julia Lawall Oh, the subject line is also duff. Please describe the changes properly. "refactoring X", "making changes to Y" are not good subject lines. On Mon, 11 Jan 2016, Lee Jones wrote: > On Tue, 29 Dec 2015, SF Markus Elfring wrote: > > > From: Markus Elfring <elfring@users.sourceforge.net> > > Date: Tue, 29 Dec 2015 15:03:31 +0100 > > > > This issue was detected by using the Coccinelle software. > > > > * Let us return directly if a call of the function "devm_regmap_init_i2c" > > or "regmap_write" failed. > > > > * Delete the jump label "err" then. > > Why are you bullet pointing here? > > Just use proper sentences to tell us what's going on. > > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > > --- > > drivers/mfd/smsc-ece1099.c | 9 +++------ > > 1 file changed, 3 insertions(+), 6 deletions(-) > > Code looks fine however. > > Please re-submit the set with the aforementioned changes along with my: > > Acked-by: Lee Jones <lee.jones@linaro.org> > > > diff --git a/drivers/mfd/smsc-ece1099.c b/drivers/mfd/smsc-ece1099.c > > index bcac488..951333a 100644 > > --- a/drivers/mfd/smsc-ece1099.c > > +++ b/drivers/mfd/smsc-ece1099.c > > @@ -46,10 +46,8 @@ static int smsc_i2c_probe(struct i2c_client *i2c, > > } > > > > smsc->regmap = devm_regmap_init_i2c(i2c, &smsc_regmap_config); > > - if (IS_ERR(smsc->regmap)) { > > - ret = PTR_ERR(smsc->regmap); > > - goto err; > > - } > > + if (IS_ERR(smsc->regmap)) > > + return PTR_ERR(smsc->regmap); > > > > i2c_set_clientdata(i2c, smsc); > > smsc->dev = &i2c->dev; > > @@ -68,7 +66,7 @@ static int smsc_i2c_probe(struct i2c_client *i2c, > > > > ret = regmap_write(smsc->regmap, SMSC_CLK_CTRL, smsc->clk); > > if (ret) > > - goto err; > > + return ret; > > > > #ifdef CONFIG_OF > > if (i2c->dev.of_node) > > @@ -76,7 +74,6 @@ static int smsc_i2c_probe(struct i2c_client *i2c, > > NULL, NULL, &i2c->dev); > > #endif > > > > -err: > > return ret; > > } > > > -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
[parent not found: <5694BE21.3010504@users.sourceforge.net>]
* Re: [PATCH 2/2] mfd: smsc-ece1099: Refactoring for smsc_i2c_probe() [not found] ` <5694BE21.3010504@users.sourceforge.net> @ 2016-01-12 9:05 ` Lee Jones 0 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-01-12 9:05 UTC (permalink / raw) To: SF Markus Elfring; +Cc: LKML, kernel-janitors, Julia Lawall Please refrain from replying off-list. Adding back the Cc's. On Tue, 12 Jan 2016, SF Markus Elfring wrote: > > Oh, the subject line is also duff. Please describe the changes properly. > > > > "refactoring X", "making changes to Y" are not good subject lines. > > Which topic would you prefer for my update suggestion instead? This one. "mfd: smsc-ece1099: Refactoring for smsc_i2c_probe()" The function name and just describing the changes as "refactoring" do not describe the changes in a helpful way. > >> Code looks fine however. > > Thanks for your look. > > > >> Please re-submit the set with the aforementioned changes along with my: > >> > >> Acked-by: Lee Jones <lee.jones@linaro.org> > > Do you really request that I should append this tag already to messages > for (my adjusted) commits you can not see so far? Yes. The code looks fine, and if the commit log is still not up to scratch I just won't apply it. :) -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] mfd: smsc-ece1099: Refactoring for smsc_i2c_probe() @ 2016-01-12 9:05 ` Lee Jones 0 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-01-12 9:05 UTC (permalink / raw) To: SF Markus Elfring; +Cc: LKML, kernel-janitors, Julia Lawall Please refrain from replying off-list. Adding back the Cc's. On Tue, 12 Jan 2016, SF Markus Elfring wrote: > > Oh, the subject line is also duff. Please describe the changes properly. > > > > "refactoring X", "making changes to Y" are not good subject lines. > > Which topic would you prefer for my update suggestion instead? This one. "mfd: smsc-ece1099: Refactoring for smsc_i2c_probe()" The function name and just describing the changes as "refactoring" do not describe the changes in a helpful way. > >> Code looks fine however. > > Thanks for your look. > > > >> Please re-submit the set with the aforementioned changes along with my: > >> > >> Acked-by: Lee Jones <lee.jones@linaro.org> > > Do you really request that I should append this tag already to messages > for (my adjusted) commits you can not see so far? Yes. The code looks fine, and if the commit log is still not up to scratch I just won't apply it. :) -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] mfd: smsc-ece1099: Refactoring for smsc_i2c_probe() 2016-01-12 9:05 ` Lee Jones @ 2016-01-12 11:28 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-12 11:28 UTC (permalink / raw) To: Lee Jones; +Cc: LKML, kernel-janitors, Julia Lawall >> Which topic would you prefer for my update suggestion instead? > > This one. > > "mfd: smsc-ece1099: Refactoring for smsc_i2c_probe()" > > The function name and just describing the changes as "refactoring" do > not describe the changes in a helpful way. Would you find a subject like "mfd: smsc-ece1099: Better exception handling in smsc_i2c_probe()" acceptable? >>>> Acked-by: Lee Jones <lee.jones@linaro.org> >> >> Do you really request that I should append this tag already to messages >> for (my adjusted) commits you can not see so far? > > Yes. Interesting … > The code looks fine, Thanks for a bit of positive feedback. > and if the commit log is still not up to scratch I just won't apply it. :) Can we eventually agree on an useful message before I would dare another commit? Will it be sufficient to delete the asterisks there? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] mfd: smsc-ece1099: Refactoring for smsc_i2c_probe() @ 2016-01-12 11:28 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-12 11:28 UTC (permalink / raw) To: Lee Jones; +Cc: LKML, kernel-janitors, Julia Lawall >> Which topic would you prefer for my update suggestion instead? > > This one. > > "mfd: smsc-ece1099: Refactoring for smsc_i2c_probe()" > > The function name and just describing the changes as "refactoring" do > not describe the changes in a helpful way. Would you find a subject like "mfd: smsc-ece1099: Better exception handling in smsc_i2c_probe()" acceptable? >>>> Acked-by: Lee Jones <lee.jones@linaro.org> >> >> Do you really request that I should append this tag already to messages >> for (my adjusted) commits you can not see so far? > > Yes. Interesting … > The code looks fine, Thanks for a bit of positive feedback. > and if the commit log is still not up to scratch I just won't apply it. :) Can we eventually agree on an useful message before I would dare another commit? Will it be sufficient to delete the asterisks there? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/2] mfd: smsc-ece1099: Fine-tuning for smsc_i2c_probe() 2015-12-29 14:15 ` SF Markus Elfring @ 2016-01-11 8:08 ` Lee Jones -1 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-01-11 8:08 UTC (permalink / raw) To: SF Markus Elfring; +Cc: LKML, kernel-janitors, Julia Lawall This set is confusing. Why do you have a cover letter specifying this as a 2 patch set, yet there are 4 patches attached to it? > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Tue, 29 Dec 2015 15:10:48 +0100 What format is this? > A few update suggestions were taken into account > from static source code analysis. > > Markus Elfring (2): > Delete an unnecessary variable initialisation > Refactoring > > drivers/mfd/smsc-ece1099.c | 11 ++++------- > 1 file changed, 4 insertions(+), 7 deletions(-) > -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/2] mfd: smsc-ece1099: Fine-tuning for smsc_i2c_probe() @ 2016-01-11 8:08 ` Lee Jones 0 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-01-11 8:08 UTC (permalink / raw) To: SF Markus Elfring; +Cc: LKML, kernel-janitors, Julia Lawall This set is confusing. Why do you have a cover letter specifying this as a 2 patch set, yet there are 4 patches attached to it? > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Tue, 29 Dec 2015 15:10:48 +0100 What format is this? > A few update suggestions were taken into account > from static source code analysis. > > Markus Elfring (2): > Delete an unnecessary variable initialisation > Refactoring > > drivers/mfd/smsc-ece1099.c | 11 ++++------- > 1 file changed, 4 insertions(+), 7 deletions(-) > -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/2] mfd: smsc-ece1099: Fine-tuning for smsc_i2c_probe() 2016-01-11 8:08 ` Lee Jones @ 2016-01-12 9:00 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-12 9:00 UTC (permalink / raw) To: Lee Jones; +Cc: LKML, kernel-janitors, Julia Lawall > This set is confusing. > > Why do you have a cover letter specifying this as a 2 patch set, > yet there are 4 patches attached to it? I do not see too many messages for this update suggestion. >> From: Markus Elfring <elfring@users.sourceforge.net> >> Date: Tue, 29 Dec 2015 15:10:48 +0100 > > What format is this? Are such specifications needed to preserve the desired authorship information during the transfer of commit messages by email? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/2] mfd: smsc-ece1099: Fine-tuning for smsc_i2c_probe() @ 2016-01-12 9:00 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-12 9:00 UTC (permalink / raw) To: Lee Jones; +Cc: LKML, kernel-janitors, Julia Lawall > This set is confusing. > > Why do you have a cover letter specifying this as a 2 patch set, > yet there are 4 patches attached to it? I do not see too many messages for this update suggestion. >> From: Markus Elfring <elfring@users.sourceforge.net> >> Date: Tue, 29 Dec 2015 15:10:48 +0100 > > What format is this? Are such specifications needed to preserve the desired authorship information during the transfer of commit messages by email? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/2] mfd: smsc-ece1099: Fine-tuning for smsc_i2c_probe() 2016-01-12 9:00 ` SF Markus Elfring (?) @ 2016-01-12 9:12 ` Lee Jones 2016-01-12 11:03 ` SF Markus Elfring -1 siblings, 1 reply; 3089+ messages in thread From: Lee Jones @ 2016-01-12 9:12 UTC (permalink / raw) To: SF Markus Elfring; +Cc: LKML, kernel-janitors, Julia Lawall On Tue, 12 Jan 2016, SF Markus Elfring wrote: > > This set is confusing. > > > > Why do you have a cover letter specifying this as a 2 patch set, > > yet there are 4 patches attached to it? > > I do not see too many messages for this update suggestion. In my inbox, your set looks like this: Dec 29 2015 SF Markus Elfring ( 0) ┬>[PATCH] mfd-dm355evm_msp: One function call less in add_child() after error detection Dec 29 2015 SF Markus Elfring ( 0) ├>[PATCH 0/2] mfd: smsc-ece1099: Fine-tuning for smsc_i2c_probe() Dec 29 2015 SF Markus Elfring ( 0) │├>[PATCH 2/2] mfd: smsc-ece1099: Refactoring for smsc_i2c_probe() Dec 29 2015 SF Markus Elfring ( 0) │└>[PATCH 1/2] mfd: smsc-ece1099: Delete an unnecessary variable initialisation in smsc_i2c_probe() Dec 29 2015 SF Markus Elfring ( 0) └>[PATCH] mfd: twl-core: One function call less in add_numbered_child() after error detection ... which is unconventional and pretty confusing. > >> From: Markus Elfring <elfring@users.sourceforge.net> > >> Date: Tue, 29 Dec 2015 15:10:48 +0100 > > > > What format is this? > > Are such specifications needed to preserve the desired authorship information > during the transfer of commit messages by email? How did you sent this set? I fear you are sending these patches manually, using your mail client. You should instead be creating patches with `git format-patch` and sending them using `git send-email`. Then the formatting will be correct. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: mfd: smsc-ece1099: Fine-tuning for smsc_i2c_probe() 2016-01-12 9:12 ` Lee Jones @ 2016-01-12 11:03 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-12 11:03 UTC (permalink / raw) To: Lee Jones; +Cc: LKML, kernel-janitors, Julia Lawall > In my inbox, your set looks like this: Thanks for your information. - I find the display correct. > ... which is unconventional and pretty confusing. Do you request that I should resend my four update suggestions for different components as a single patch series for the software area "drivers/mfd"? > I fear you are sending these patches manually, using your mail client. I admit that I am doing this usually. > You should instead be creating patches with `git format-patch` This happens also … > and sending them using `git send-email`. I prefer other software tools for this task so far. Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: mfd: smsc-ece1099: Fine-tuning for smsc_i2c_probe() @ 2016-01-12 11:03 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-12 11:03 UTC (permalink / raw) To: Lee Jones; +Cc: LKML, kernel-janitors, Julia Lawall > In my inbox, your set looks like this: Thanks for your information. - I find the display correct. > ... which is unconventional and pretty confusing. Do you request that I should resend my four update suggestions for different components as a single patch series for the software area "drivers/mfd"? > I fear you are sending these patches manually, using your mail client. I admit that I am doing this usually. > You should instead be creating patches with `git format-patch` This happens also … > and sending them using `git send-email`. I prefer other software tools for this task so far. Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: mfd: smsc-ece1099: Fine-tuning for smsc_i2c_probe() 2016-01-12 11:03 ` SF Markus Elfring (?) @ 2016-01-12 11:14 ` Lee Jones 2016-01-12 11:42 ` SF Markus Elfring -1 siblings, 1 reply; 3089+ messages in thread From: Lee Jones @ 2016-01-12 11:14 UTC (permalink / raw) To: SF Markus Elfring; +Cc: LKML, kernel-janitors, Julia Lawall On Tue, 12 Jan 2016, SF Markus Elfring wrote: > > In my inbox, your set looks like this: > > Thanks for your information. - I find the display correct. > > > ... which is unconventional and pretty confusing. > > Do you request that I should resend my four update suggestions > for different components as a single patch series for the software > area "drivers/mfd"? You have to make that decision yourself. What I'm saying is, if the cover letter says there are 2 patches in the set, that's what we should expect. > > I fear you are sending these patches manually, using your mail client. > > I admit that I am doing this usually. Please don't do that. > > You should instead be creating patches with `git format-patch` > > This happens also … > > > and sending them using `git send-email`. > > I prefer other software tools for this task so far. Such as? -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: mfd: smsc-ece1099: Fine-tuning for smsc_i2c_probe() 2016-01-12 11:14 ` Lee Jones @ 2016-01-12 11:42 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-12 11:42 UTC (permalink / raw) To: Lee Jones; +Cc: LKML, kernel-janitors, Julia Lawall >> Do you request that I should resend my four update suggestions >> for different components as a single patch series for the software >> area "drivers/mfd"? > > You have to make that decision yourself. I chose on 2015-12-29 to send them in the combination you see. > What I'm saying is, if the cover letter says there are 2 patches These refer to the component "smsc-ece1099". > in the set, that's what we should expect. Can changes for the components "dm355evm_msp" and "twl-core" be clarified independently? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: mfd: smsc-ece1099: Fine-tuning for smsc_i2c_probe() @ 2016-01-12 11:42 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-12 11:42 UTC (permalink / raw) To: Lee Jones; +Cc: LKML, kernel-janitors, Julia Lawall >> Do you request that I should resend my four update suggestions >> for different components as a single patch series for the software >> area "drivers/mfd"? > > You have to make that decision yourself. I chose on 2015-12-29 to send them in the combination you see. > What I'm saying is, if the cover letter says there are 2 patches These refer to the component "smsc-ece1099". > in the set, that's what we should expect. Can changes for the components "dm355evm_msp" and "twl-core" be clarified independently? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: mfd: smsc-ece1099: Fine-tuning for smsc_i2c_probe() 2016-01-12 11:42 ` SF Markus Elfring @ 2016-01-12 12:03 ` Lee Jones -1 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-01-12 12:03 UTC (permalink / raw) To: SF Markus Elfring; +Cc: LKML, kernel-janitors, Julia Lawall On Tue, 12 Jan 2016, SF Markus Elfring wrote: > >> Do you request that I should resend my four update suggestions > >> for different components as a single patch series for the software > >> area "drivers/mfd"? > > > > You have to make that decision yourself. > > I chose on 2015-12-29 to send them in the combination you see. That was not a good choice. > > What I'm saying is, if the cover letter says there are 2 patches > > These refer to the component "smsc-ece1099". That's fine. Then there should have been 2 patches in the set. But then to attach 2 unrelated patches to the set is not fine. They should have either been submitted as part of the set i.e. 0/4 or completely separately. > > in the set, that's what we should expect. > > Can changes for the components "dm355evm_msp" and "twl-core" > be clarified independently? Yes, or together would have also been fine. The only think that is not okay is to submit a set of 2 patches, then to "bolt-on" another 2 for some reason. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: mfd: smsc-ece1099: Fine-tuning for smsc_i2c_probe() @ 2016-01-12 12:03 ` Lee Jones 0 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-01-12 12:03 UTC (permalink / raw) To: SF Markus Elfring; +Cc: LKML, kernel-janitors, Julia Lawall On Tue, 12 Jan 2016, SF Markus Elfring wrote: > >> Do you request that I should resend my four update suggestions > >> for different components as a single patch series for the software > >> area "drivers/mfd"? > > > > You have to make that decision yourself. > > I chose on 2015-12-29 to send them in the combination you see. That was not a good choice. > > What I'm saying is, if the cover letter says there are 2 patches > > These refer to the component "smsc-ece1099". That's fine. Then there should have been 2 patches in the set. But then to attach 2 unrelated patches to the set is not fine. They should have either been submitted as part of the set i.e. 0/4 or completely separately. > > in the set, that's what we should expect. > > Can changes for the components "dm355evm_msp" and "twl-core" > be clarified independently? Yes, or together would have also been fine. The only think that is not okay is to submit a set of 2 patches, then to "bolt-on" another 2 for some reason. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH] mfd: twl-core: One function call less in add_numbered_child() after error detection 2015-12-11 12:08 ` SF Markus Elfring @ 2015-12-29 18:34 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-29 18:34 UTC (permalink / raw) To: linux-omap, Lee Jones, Tony Lindgren; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 29 Dec 2015 19:29:08 +0100 The platform_device_put() function was called in one case by the add_numbered_child() function during error handling even if the passed variable "pdev" contained a null pointer. Implementation details could be improved by the adjustment of jump targets according to the Linux coding style convention. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/mfd/twl-core.c | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c index 831696e..0d9350c 100644 --- a/drivers/mfd/twl-core.c +++ b/drivers/mfd/twl-core.c @@ -625,7 +625,7 @@ add_numbered_child(unsigned mod_no, const char *name, int num, if (!pdev) { dev_dbg(&twl->client->dev, "can't alloc dev\n"); status = -ENOMEM; - goto err; + goto report_failure; } pdev->dev.parent = &twl->client->dev; @@ -634,7 +634,7 @@ add_numbered_child(unsigned mod_no, const char *name, int num, status = platform_device_add_data(pdev, pdata, pdata_len); if (status < 0) { dev_dbg(&pdev->dev, "can't add platform_data\n"); - goto err; + goto put_device; } } @@ -647,21 +647,20 @@ add_numbered_child(unsigned mod_no, const char *name, int num, status = platform_device_add_resources(pdev, r, irq1 ? 2 : 1); if (status < 0) { dev_dbg(&pdev->dev, "can't add irqs\n"); - goto err; + goto put_device; } } status = platform_device_add(pdev); - if (status == 0) + if (!status) { device_init_wakeup(&pdev->dev, can_wakeup); - -err: - if (status < 0) { - platform_device_put(pdev); - dev_err(&twl->client->dev, "can't add %s dev\n", name); - return ERR_PTR(status); + return &pdev->dev; } - return &pdev->dev; +put_device: + platform_device_put(pdev); +report_failure: + dev_err(&twl->client->dev, "can't add %s dev\n", name); + return ERR_PTR(status); } static inline struct device *add_child(unsigned mod_no, const char *name, -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH] mfd: twl-core: One function call less in add_numbered_child() after error detection @ 2015-12-29 18:34 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-29 18:34 UTC (permalink / raw) To: linux-omap, Lee Jones, Tony Lindgren; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 29 Dec 2015 19:29:08 +0100 The platform_device_put() function was called in one case by the add_numbered_child() function during error handling even if the passed variable "pdev" contained a null pointer. Implementation details could be improved by the adjustment of jump targets according to the Linux coding style convention. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/mfd/twl-core.c | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c index 831696e..0d9350c 100644 --- a/drivers/mfd/twl-core.c +++ b/drivers/mfd/twl-core.c @@ -625,7 +625,7 @@ add_numbered_child(unsigned mod_no, const char *name, int num, if (!pdev) { dev_dbg(&twl->client->dev, "can't alloc dev\n"); status = -ENOMEM; - goto err; + goto report_failure; } pdev->dev.parent = &twl->client->dev; @@ -634,7 +634,7 @@ add_numbered_child(unsigned mod_no, const char *name, int num, status = platform_device_add_data(pdev, pdata, pdata_len); if (status < 0) { dev_dbg(&pdev->dev, "can't add platform_data\n"); - goto err; + goto put_device; } } @@ -647,21 +647,20 @@ add_numbered_child(unsigned mod_no, const char *name, int num, status = platform_device_add_resources(pdev, r, irq1 ? 2 : 1); if (status < 0) { dev_dbg(&pdev->dev, "can't add irqs\n"); - goto err; + goto put_device; } } status = platform_device_add(pdev); - if (status = 0) + if (!status) { device_init_wakeup(&pdev->dev, can_wakeup); - -err: - if (status < 0) { - platform_device_put(pdev); - dev_err(&twl->client->dev, "can't add %s dev\n", name); - return ERR_PTR(status); + return &pdev->dev; } - return &pdev->dev; +put_device: + platform_device_put(pdev); +report_failure: + dev_err(&twl->client->dev, "can't add %s dev\n", name); + return ERR_PTR(status); } static inline struct device *add_child(unsigned mod_no, const char *name, -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH] mfd: twl-core: One function call less in add_numbered_child() after error detection 2015-12-29 18:34 ` SF Markus Elfring (?) @ 2016-01-11 8:29 ` Lee Jones -1 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-01-11 8:29 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-omap, Tony Lindgren, LKML, kernel-janitors, Julia Lawall On Tue, 29 Dec 2015, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Tue, 29 Dec 2015 19:29:08 +0100 > > The platform_device_put() function was called in one case by the > add_numbered_child() function during error handling even if the passed > variable "pdev" contained a null pointer. > > Implementation details could be improved by the adjustment of jump targets > according to the Linux coding style convention. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/mfd/twl-core.c | 21 ++++++++++----------- > 1 file changed, 10 insertions(+), 11 deletions(-) > > diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c > index 831696e..0d9350c 100644 > --- a/drivers/mfd/twl-core.c > +++ b/drivers/mfd/twl-core.c > @@ -625,7 +625,7 @@ add_numbered_child(unsigned mod_no, const char *name, int num, > if (!pdev) { > dev_dbg(&twl->client->dev, "can't alloc dev\n"); Change this to be dev_err() > status = -ENOMEM; > - goto err; > + goto report_failure; ... and just return status from here. > } > > pdev->dev.parent = &twl->client->dev; > @@ -634,7 +634,7 @@ add_numbered_child(unsigned mod_no, const char *name, int num, > status = platform_device_add_data(pdev, pdata, pdata_len); > if (status < 0) { > dev_dbg(&pdev->dev, "can't add platform_data\n"); > - goto err; > + goto put_device; > } > } > > @@ -647,21 +647,20 @@ add_numbered_child(unsigned mod_no, const char *name, int num, > status = platform_device_add_resources(pdev, r, irq1 ? 2 : 1); > if (status < 0) { > dev_dbg(&pdev->dev, "can't add irqs\n"); > - goto err; > + goto put_device; > } > } > > status = platform_device_add(pdev); > - if (status == 0) > + if (!status) { You've changed the way you handle errors from this point. To be more consistent it would be better if you checked for status, then jump to put_device in the case of a failure, as you do above. > device_init_wakeup(&pdev->dev, can_wakeup); > - > -err: > - if (status < 0) { > - platform_device_put(pdev); > - dev_err(&twl->client->dev, "can't add %s dev\n", name); > - return ERR_PTR(status); > + return &pdev->dev; > } > - return &pdev->dev; > +put_device: > + platform_device_put(pdev); > +report_failure: > + dev_err(&twl->client->dev, "can't add %s dev\n", name); > + return ERR_PTR(status); > } > > static inline struct device *add_child(unsigned mod_no, const char *name, -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] mfd: twl-core: One function call less in add_numbered_child() after error detection @ 2016-01-11 8:29 ` Lee Jones 0 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-01-11 8:29 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-omap, Tony Lindgren, LKML, kernel-janitors, Julia Lawall On Tue, 29 Dec 2015, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Tue, 29 Dec 2015 19:29:08 +0100 > > The platform_device_put() function was called in one case by the > add_numbered_child() function during error handling even if the passed > variable "pdev" contained a null pointer. > > Implementation details could be improved by the adjustment of jump targets > according to the Linux coding style convention. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/mfd/twl-core.c | 21 ++++++++++----------- > 1 file changed, 10 insertions(+), 11 deletions(-) > > diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c > index 831696e..0d9350c 100644 > --- a/drivers/mfd/twl-core.c > +++ b/drivers/mfd/twl-core.c > @@ -625,7 +625,7 @@ add_numbered_child(unsigned mod_no, const char *name, int num, > if (!pdev) { > dev_dbg(&twl->client->dev, "can't alloc dev\n"); Change this to be dev_err() > status = -ENOMEM; > - goto err; > + goto report_failure; ... and just return status from here. > } > > pdev->dev.parent = &twl->client->dev; > @@ -634,7 +634,7 @@ add_numbered_child(unsigned mod_no, const char *name, int num, > status = platform_device_add_data(pdev, pdata, pdata_len); > if (status < 0) { > dev_dbg(&pdev->dev, "can't add platform_data\n"); > - goto err; > + goto put_device; > } > } > > @@ -647,21 +647,20 @@ add_numbered_child(unsigned mod_no, const char *name, int num, > status = platform_device_add_resources(pdev, r, irq1 ? 2 : 1); > if (status < 0) { > dev_dbg(&pdev->dev, "can't add irqs\n"); > - goto err; > + goto put_device; > } > } > > status = platform_device_add(pdev); > - if (status == 0) > + if (!status) { You've changed the way you handle errors from this point. To be more consistent it would be better if you checked for status, then jump to put_device in the case of a failure, as you do above. > device_init_wakeup(&pdev->dev, can_wakeup); > - > -err: > - if (status < 0) { > - platform_device_put(pdev); > - dev_err(&twl->client->dev, "can't add %s dev\n", name); > - return ERR_PTR(status); > + return &pdev->dev; > } > - return &pdev->dev; > +put_device: > + platform_device_put(pdev); > +report_failure: > + dev_err(&twl->client->dev, "can't add %s dev\n", name); > + return ERR_PTR(status); > } > > static inline struct device *add_child(unsigned mod_no, const char *name, -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] mfd: twl-core: One function call less in add_numbered_child() after error detection @ 2016-01-11 8:29 ` Lee Jones 0 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-01-11 8:29 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-omap, Tony Lindgren, LKML, kernel-janitors, Julia Lawall On Tue, 29 Dec 2015, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Tue, 29 Dec 2015 19:29:08 +0100 > > The platform_device_put() function was called in one case by the > add_numbered_child() function during error handling even if the passed > variable "pdev" contained a null pointer. > > Implementation details could be improved by the adjustment of jump targets > according to the Linux coding style convention. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/mfd/twl-core.c | 21 ++++++++++----------- > 1 file changed, 10 insertions(+), 11 deletions(-) > > diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c > index 831696e..0d9350c 100644 > --- a/drivers/mfd/twl-core.c > +++ b/drivers/mfd/twl-core.c > @@ -625,7 +625,7 @@ add_numbered_child(unsigned mod_no, const char *name, int num, > if (!pdev) { > dev_dbg(&twl->client->dev, "can't alloc dev\n"); Change this to be dev_err() > status = -ENOMEM; > - goto err; > + goto report_failure; ... and just return status from here. > } > > pdev->dev.parent = &twl->client->dev; > @@ -634,7 +634,7 @@ add_numbered_child(unsigned mod_no, const char *name, int num, > status = platform_device_add_data(pdev, pdata, pdata_len); > if (status < 0) { > dev_dbg(&pdev->dev, "can't add platform_data\n"); > - goto err; > + goto put_device; > } > } > > @@ -647,21 +647,20 @@ add_numbered_child(unsigned mod_no, const char *name, int num, > status = platform_device_add_resources(pdev, r, irq1 ? 2 : 1); > if (status < 0) { > dev_dbg(&pdev->dev, "can't add irqs\n"); > - goto err; > + goto put_device; > } > } > > status = platform_device_add(pdev); > - if (status = 0) > + if (!status) { You've changed the way you handle errors from this point. To be more consistent it would be better if you checked for status, then jump to put_device in the case of a failure, as you do above. > device_init_wakeup(&pdev->dev, can_wakeup); > - > -err: > - if (status < 0) { > - platform_device_put(pdev); > - dev_err(&twl->client->dev, "can't add %s dev\n", name); > - return ERR_PTR(status); > + return &pdev->dev; > } > - return &pdev->dev; > +put_device: > + platform_device_put(pdev); > +report_failure: > + dev_err(&twl->client->dev, "can't add %s dev\n", name); > + return ERR_PTR(status); > } > > static inline struct device *add_child(unsigned mod_no, const char *name, -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/2] mfd: twl-core: Fine-tuning for add_numbered_child() 2016-01-11 8:29 ` Lee Jones @ 2016-05-15 18:11 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-05-15 18:11 UTC (permalink / raw) To: Lee Jones, Tony Lindgren, linux-omap; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 15 May 2016 19:55:30 +0200 A few update suggestions were taken into account from static source code analysis. Markus Elfring (2): Return directly after a failed platform_device_alloc() in add_numbered_child() Refactoring for add_numbered_child() drivers/mfd/twl-core.c | 24 +++++++++++------------- 1 file changed, 11 insertions(+), 13 deletions(-) -- 2.8.2 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/2] mfd: twl-core: Fine-tuning for add_numbered_child() @ 2016-05-15 18:11 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-05-15 18:11 UTC (permalink / raw) To: Lee Jones, Tony Lindgren, linux-omap; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 15 May 2016 19:55:30 +0200 A few update suggestions were taken into account from static source code analysis. Markus Elfring (2): Return directly after a failed platform_device_alloc() in add_numbered_child() Refactoring for add_numbered_child() drivers/mfd/twl-core.c | 24 +++++++++++------------- 1 file changed, 11 insertions(+), 13 deletions(-) -- 2.8.2 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 1/2] mfd: twl-core: Return directly after a failed platform_device_alloc() in add_numbered_child() 2016-05-15 18:11 ` SF Markus Elfring @ 2016-05-16 6:26 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-05-16 6:26 UTC (permalink / raw) To: Lee Jones, Tony Lindgren, linux-omap; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 15 May 2016 19:20:28 +0200 The platform_device_put() function was called in one case by the add_numbered_child() function during error handling even if the passed variable "pdev" contained a null pointer. * Change an error message. * Return directly in this case. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/mfd/twl-core.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c index 831696e..dc34e69 100644 --- a/drivers/mfd/twl-core.c +++ b/drivers/mfd/twl-core.c @@ -623,9 +623,10 @@ add_numbered_child(unsigned mod_no, const char *name, int num, pdev = platform_device_alloc(name, num); if (!pdev) { - dev_dbg(&twl->client->dev, "can't alloc dev\n"); - status = -ENOMEM; - goto err; + dev_err(&twl->client->dev, + "Allocation failed for device: %s\n", + name); + return ERR_PTR(-ENOMEM); } pdev->dev.parent = &twl->client->dev; -- 2.8.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 1/2] mfd: twl-core: Return directly after a failed platform_device_alloc() in add_numbered_ch @ 2016-05-16 6:26 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-05-16 6:26 UTC (permalink / raw) To: Lee Jones, Tony Lindgren, linux-omap; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 15 May 2016 19:20:28 +0200 The platform_device_put() function was called in one case by the add_numbered_child() function during error handling even if the passed variable "pdev" contained a null pointer. * Change an error message. * Return directly in this case. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/mfd/twl-core.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c index 831696e..dc34e69 100644 --- a/drivers/mfd/twl-core.c +++ b/drivers/mfd/twl-core.c @@ -623,9 +623,10 @@ add_numbered_child(unsigned mod_no, const char *name, int num, pdev = platform_device_alloc(name, num); if (!pdev) { - dev_dbg(&twl->client->dev, "can't alloc dev\n"); - status = -ENOMEM; - goto err; + dev_err(&twl->client->dev, + "Allocation failed for device: %s\n", + name); + return ERR_PTR(-ENOMEM); } pdev->dev.parent = &twl->client->dev; -- 2.8.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/2] mfd: twl-core: Return directly after a failed platform_device_alloc() in add_numbered_child() 2016-05-16 6:26 ` [PATCH 1/2] mfd: twl-core: Return directly after a failed platform_device_alloc() in add_numbered_ch SF Markus Elfring @ 2016-05-16 6:51 ` Julia Lawall -1 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2016-05-16 6:51 UTC (permalink / raw) To: SF Markus Elfring Cc: Lee Jones, Tony Lindgren, linux-omap, LKML, kernel-janitors On Mon, 16 May 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 15 May 2016 19:20:28 +0200 > > The platform_device_put() function was called in one case by the > add_numbered_child() function during error handling even if the passed > variable "pdev" contained a null pointer. > > * Change an error message. Why? Is dev_err needed? Doesn't it already print out the device name? In any case, the only source of failure is failure of a kzalloc in platform_device_alloc, which means that a complete backtrace would be generated, so it is not clear that any message is needed at all. julia > > * Return directly in this case. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/mfd/twl-core.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c > index 831696e..dc34e69 100644 > --- a/drivers/mfd/twl-core.c > +++ b/drivers/mfd/twl-core.c > @@ -623,9 +623,10 @@ add_numbered_child(unsigned mod_no, const char *name, int num, > > pdev = platform_device_alloc(name, num); > if (!pdev) { > - dev_dbg(&twl->client->dev, "can't alloc dev\n"); > - status = -ENOMEM; > - goto err; > + dev_err(&twl->client->dev, > + "Allocation failed for device: %s\n", > + name); > + return ERR_PTR(-ENOMEM); > } > > pdev->dev.parent = &twl->client->dev; > -- > 2.8.2 > > -- > To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/2] mfd: twl-core: Return directly after a failed platform_device_alloc() in add_numbere @ 2016-05-16 6:51 ` Julia Lawall 0 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2016-05-16 6:51 UTC (permalink / raw) To: SF Markus Elfring Cc: Lee Jones, Tony Lindgren, linux-omap, LKML, kernel-janitors On Mon, 16 May 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 15 May 2016 19:20:28 +0200 > > The platform_device_put() function was called in one case by the > add_numbered_child() function during error handling even if the passed > variable "pdev" contained a null pointer. > > * Change an error message. Why? Is dev_err needed? Doesn't it already print out the device name? In any case, the only source of failure is failure of a kzalloc in platform_device_alloc, which means that a complete backtrace would be generated, so it is not clear that any message is needed at all. julia > > * Return directly in this case. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/mfd/twl-core.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c > index 831696e..dc34e69 100644 > --- a/drivers/mfd/twl-core.c > +++ b/drivers/mfd/twl-core.c > @@ -623,9 +623,10 @@ add_numbered_child(unsigned mod_no, const char *name, int num, > > pdev = platform_device_alloc(name, num); > if (!pdev) { > - dev_dbg(&twl->client->dev, "can't alloc dev\n"); > - status = -ENOMEM; > - goto err; > + dev_err(&twl->client->dev, > + "Allocation failed for device: %s\n", > + name); > + return ERR_PTR(-ENOMEM); > } > > pdev->dev.parent = &twl->client->dev; > -- > 2.8.2 > > -- > To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: mfd: twl-core: Return directly after a failed platform_device_alloc() in add_numbered_child() 2016-05-16 6:51 ` [PATCH 1/2] mfd: twl-core: Return directly after a failed platform_device_alloc() in add_numbere Julia Lawall @ 2016-05-16 7:54 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-05-16 7:54 UTC (permalink / raw) To: Julia Lawall; +Cc: Lee Jones, Tony Lindgren, linux-omap, LKML, kernel-janitors >> * Change an error message. > > Why? Is dev_err needed? I interpreted Lee's response in this way. https://lkml.org/lkml/2016/1/11/104 Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: mfd: twl-core: Return directly after a failed platform_device_alloc() in add_numbered_child() @ 2016-05-16 7:54 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-05-16 7:54 UTC (permalink / raw) To: Julia Lawall; +Cc: Lee Jones, Tony Lindgren, linux-omap, LKML, kernel-janitors >> * Change an error message. > > Why? Is dev_err needed? I interpreted Lee's response in this way. https://lkml.org/lkml/2016/1/11/104 Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: mfd: twl-core: Return directly after a failed platform_device_alloc() in add_numbered_child() 2016-05-16 7:54 ` SF Markus Elfring @ 2016-05-16 8:07 ` Julia Lawall -1 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2016-05-16 8:07 UTC (permalink / raw) To: SF Markus Elfring Cc: Lee Jones, Tony Lindgren, linux-omap, LKML, kernel-janitors On Mon, 16 May 2016, SF Markus Elfring wrote: > >> * Change an error message. > > > > Why? Is dev_err needed? > > I interpreted Lee's response in this way. > https://lkml.org/lkml/2016/1/11/104 OK. He didn't ask for the message to be changed though. It's a bit unfortunate that it now takes up multiple lines. And I believe it also prints redundant information. Perhaps he will have some further thoughts on the matter. julia ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: mfd: twl-core: Return directly after a failed platform_device_alloc() in add_numbered_child() @ 2016-05-16 8:07 ` Julia Lawall 0 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2016-05-16 8:07 UTC (permalink / raw) To: SF Markus Elfring Cc: Lee Jones, Tony Lindgren, linux-omap, LKML, kernel-janitors On Mon, 16 May 2016, SF Markus Elfring wrote: > >> * Change an error message. > > > > Why? Is dev_err needed? > > I interpreted Lee's response in this way. > https://lkml.org/lkml/2016/1/11/104 OK. He didn't ask for the message to be changed though. It's a bit unfortunate that it now takes up multiple lines. And I believe it also prints redundant information. Perhaps he will have some further thoughts on the matter. julia ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: mfd: twl-core: Return directly after a failed platform_device_alloc() in add_numbered_child() 2016-05-16 8:07 ` Julia Lawall @ 2016-05-17 6:00 ` Lee Jones -1 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-05-17 6:00 UTC (permalink / raw) To: Julia Lawall Cc: SF Markus Elfring, Tony Lindgren, linux-omap, LKML, kernel-janitors On Mon, 16 May 2016, Julia Lawall wrote: > On Mon, 16 May 2016, SF Markus Elfring wrote: > > > >> * Change an error message. > > > > > > Why? Is dev_err needed? > > > > I interpreted Lee's response in this way. > > https://lkml.org/lkml/2016/1/11/104 > > OK. He didn't ask for the message to be changed though. It's a bit > unfortunate that it now takes up multiple lines. And I believe it also > prints redundant information. Perhaps he will have some further thoughts > on the matter. Yes, Julia is right. We normally don't print anything for OOM errors since Linux reports on them already. Please remove the print altogether. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: mfd: twl-core: Return directly after a failed platform_device_alloc() in add_numbered_child() @ 2016-05-17 6:00 ` Lee Jones 0 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-05-17 6:00 UTC (permalink / raw) To: Julia Lawall Cc: SF Markus Elfring, Tony Lindgren, linux-omap, LKML, kernel-janitors On Mon, 16 May 2016, Julia Lawall wrote: > On Mon, 16 May 2016, SF Markus Elfring wrote: > > > >> * Change an error message. > > > > > > Why? Is dev_err needed? > > > > I interpreted Lee's response in this way. > > https://lkml.org/lkml/2016/1/11/104 > > OK. He didn't ask for the message to be changed though. It's a bit > unfortunate that it now takes up multiple lines. And I believe it also > prints redundant information. Perhaps he will have some further thoughts > on the matter. Yes, Julia is right. We normally don't print anything for OOM errors since Linux reports on them already. Please remove the print altogether. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: mfd: twl-core: Return directly after a failed platform_device_alloc() in add_numbered_child() 2016-05-17 6:00 ` Lee Jones @ 2016-05-17 14:15 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-05-17 14:15 UTC (permalink / raw) To: Lee Jones; +Cc: Julia Lawall, Tony Lindgren, linux-omap, LKML, kernel-janitors > Please remove the print altogether. Would you like to omit any extra logging statements at more source code places? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: mfd: twl-core: Return directly after a failed platform_device_alloc() in add_numbered_child() @ 2016-05-17 14:15 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-05-17 14:15 UTC (permalink / raw) To: Lee Jones; +Cc: Julia Lawall, Tony Lindgren, linux-omap, LKML, kernel-janitors > Please remove the print altogether. Would you like to omit any extra logging statements at more source code places? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 2/2] mfd: twl-core: Refactoring for add_numbered_child() 2016-05-15 18:11 ` SF Markus Elfring @ 2016-05-16 6:28 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-05-16 6:28 UTC (permalink / raw) To: Lee Jones, Tony Lindgren, linux-omap; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 15 May 2016 19:50:55 +0200 Adjust jump targets according to the Linux coding style convention. Another check for the variable "status" can be omitted then at the end. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/mfd/twl-core.c | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c index dc34e69..3e4f4e4 100644 --- a/drivers/mfd/twl-core.c +++ b/drivers/mfd/twl-core.c @@ -635,7 +635,7 @@ add_numbered_child(unsigned mod_no, const char *name, int num, status = platform_device_add_data(pdev, pdata, pdata_len); if (status < 0) { dev_dbg(&pdev->dev, "can't add platform_data\n"); - goto err; + goto put_device; } } @@ -648,21 +648,20 @@ add_numbered_child(unsigned mod_no, const char *name, int num, status = platform_device_add_resources(pdev, r, irq1 ? 2 : 1); if (status < 0) { dev_dbg(&pdev->dev, "can't add irqs\n"); - goto err; + goto put_device; } } status = platform_device_add(pdev); - if (status == 0) - device_init_wakeup(&pdev->dev, can_wakeup); + if (status) + goto put_device; -err: - if (status < 0) { - platform_device_put(pdev); - dev_err(&twl->client->dev, "can't add %s dev\n", name); - return ERR_PTR(status); - } + device_init_wakeup(&pdev->dev, can_wakeup); return &pdev->dev; +put_device: + platform_device_put(pdev); + dev_err(&twl->client->dev, "can't add %s dev\n", name); + return ERR_PTR(status); } static inline struct device *add_child(unsigned mod_no, const char *name, -- 2.8.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 2/2] mfd: twl-core: Refactoring for add_numbered_child() @ 2016-05-16 6:28 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-05-16 6:28 UTC (permalink / raw) To: Lee Jones, Tony Lindgren, linux-omap; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 15 May 2016 19:50:55 +0200 Adjust jump targets according to the Linux coding style convention. Another check for the variable "status" can be omitted then at the end. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/mfd/twl-core.c | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c index dc34e69..3e4f4e4 100644 --- a/drivers/mfd/twl-core.c +++ b/drivers/mfd/twl-core.c @@ -635,7 +635,7 @@ add_numbered_child(unsigned mod_no, const char *name, int num, status = platform_device_add_data(pdev, pdata, pdata_len); if (status < 0) { dev_dbg(&pdev->dev, "can't add platform_data\n"); - goto err; + goto put_device; } } @@ -648,21 +648,20 @@ add_numbered_child(unsigned mod_no, const char *name, int num, status = platform_device_add_resources(pdev, r, irq1 ? 2 : 1); if (status < 0) { dev_dbg(&pdev->dev, "can't add irqs\n"); - goto err; + goto put_device; } } status = platform_device_add(pdev); - if (status = 0) - device_init_wakeup(&pdev->dev, can_wakeup); + if (status) + goto put_device; -err: - if (status < 0) { - platform_device_put(pdev); - dev_err(&twl->client->dev, "can't add %s dev\n", name); - return ERR_PTR(status); - } + device_init_wakeup(&pdev->dev, can_wakeup); return &pdev->dev; +put_device: + platform_device_put(pdev); + dev_err(&twl->client->dev, "can't add %s dev\n", name); + return ERR_PTR(status); } static inline struct device *add_child(unsigned mod_no, const char *name, -- 2.8.2 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] mfd: twl-core: Refactoring for add_numbered_child() 2016-05-16 6:28 ` SF Markus Elfring @ 2016-06-08 11:14 ` Lee Jones -1 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-06-08 11:14 UTC (permalink / raw) To: SF Markus Elfring Cc: Tony Lindgren, linux-omap, LKML, kernel-janitors, Julia Lawall On Mon, 16 May 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 15 May 2016 19:50:55 +0200 > > Adjust jump targets according to the Linux coding style convention. > Another check for the variable "status" can be omitted then at the end. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/mfd/twl-core.c | 19 +++++++++---------- > 1 file changed, 9 insertions(+), 10 deletions(-) > > diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c > index dc34e69..3e4f4e4 100644 > --- a/drivers/mfd/twl-core.c > +++ b/drivers/mfd/twl-core.c > @@ -635,7 +635,7 @@ add_numbered_child(unsigned mod_no, const char *name, int num, > status = platform_device_add_data(pdev, pdata, pdata_len); > if (status < 0) { > dev_dbg(&pdev->dev, "can't add platform_data\n"); > - goto err; > + goto put_device; > } > } > > @@ -648,21 +648,20 @@ add_numbered_child(unsigned mod_no, const char *name, int num, > status = platform_device_add_resources(pdev, r, irq1 ? 2 : 1); > if (status < 0) { > dev_dbg(&pdev->dev, "can't add irqs\n"); > - goto err; > + goto put_device; > } > } > > status = platform_device_add(pdev); > - if (status == 0) > - device_init_wakeup(&pdev->dev, can_wakeup); > + if (status) > + goto put_device; > > -err: > - if (status < 0) { > - platform_device_put(pdev); > - dev_err(&twl->client->dev, "can't add %s dev\n", name); > - return ERR_PTR(status); > - } > + device_init_wakeup(&pdev->dev, can_wakeup); Nit: Place a '\n' here. > return &pdev->dev; Nit: Place a '\n' here. > +put_device: > + platform_device_put(pdev); > + dev_err(&twl->client->dev, "can't add %s dev\n", name); Nit: "failed to add device %s\n" > + return ERR_PTR(status); > } > > static inline struct device *add_child(unsigned mod_no, const char *name, Once you've fixed those, please re-submit with my: Acked-by: Lee Jones <lee.jones@linaro.org> -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] mfd: twl-core: Refactoring for add_numbered_child() @ 2016-06-08 11:14 ` Lee Jones 0 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-06-08 11:14 UTC (permalink / raw) To: SF Markus Elfring Cc: Tony Lindgren, linux-omap, LKML, kernel-janitors, Julia Lawall On Mon, 16 May 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 15 May 2016 19:50:55 +0200 > > Adjust jump targets according to the Linux coding style convention. > Another check for the variable "status" can be omitted then at the end. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/mfd/twl-core.c | 19 +++++++++---------- > 1 file changed, 9 insertions(+), 10 deletions(-) > > diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c > index dc34e69..3e4f4e4 100644 > --- a/drivers/mfd/twl-core.c > +++ b/drivers/mfd/twl-core.c > @@ -635,7 +635,7 @@ add_numbered_child(unsigned mod_no, const char *name, int num, > status = platform_device_add_data(pdev, pdata, pdata_len); > if (status < 0) { > dev_dbg(&pdev->dev, "can't add platform_data\n"); > - goto err; > + goto put_device; > } > } > > @@ -648,21 +648,20 @@ add_numbered_child(unsigned mod_no, const char *name, int num, > status = platform_device_add_resources(pdev, r, irq1 ? 2 : 1); > if (status < 0) { > dev_dbg(&pdev->dev, "can't add irqs\n"); > - goto err; > + goto put_device; > } > } > > status = platform_device_add(pdev); > - if (status = 0) > - device_init_wakeup(&pdev->dev, can_wakeup); > + if (status) > + goto put_device; > > -err: > - if (status < 0) { > - platform_device_put(pdev); > - dev_err(&twl->client->dev, "can't add %s dev\n", name); > - return ERR_PTR(status); > - } > + device_init_wakeup(&pdev->dev, can_wakeup); Nit: Place a '\n' here. > return &pdev->dev; Nit: Place a '\n' here. > +put_device: > + platform_device_put(pdev); > + dev_err(&twl->client->dev, "can't add %s dev\n", name); Nit: "failed to add device %s\n" > + return ERR_PTR(status); > } > > static inline struct device *add_child(unsigned mod_no, const char *name, Once you've fixed those, please re-submit with my: Acked-by: Lee Jones <lee.jones@linaro.org> -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/6] mfd: Fine-tuning for three function implementations 2016-06-08 11:14 ` Lee Jones @ 2016-06-26 13:34 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-06-26 13:34 UTC (permalink / raw) To: Lee Jones, Tony Lindgren, linux-omap; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 26 Jun 2016 15:25:43 +0200 Several update suggestions were taken into account from static source code analysis. Markus Elfring (6): twl-core: Return directly after a failed platform_device_alloc() in add_numbered_child() twl-core: Refactoring for add_numbered_child() dm355evm_msp: Return directly after a failed platform_device_alloc() in add_child() dm355evm_msp: Refactoring for add_child() smsc-ece1099: Delete an unnecessary variable initialisation in smsc_i2c_probe() smsc-ece1099: Return directly after a function failure in smsc_i2c_probe() drivers/mfd/dm355evm_msp.c | 25 ++++++++++++------------- drivers/mfd/smsc-ece1099.c | 11 ++++------- drivers/mfd/twl-core.c | 28 +++++++++++++--------------- 3 files changed, 29 insertions(+), 35 deletions(-) -- 2.9.0 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/6] mfd: Fine-tuning for three function implementations @ 2016-06-26 13:34 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-06-26 13:34 UTC (permalink / raw) To: Lee Jones, Tony Lindgren, linux-omap; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 26 Jun 2016 15:25:43 +0200 Several update suggestions were taken into account from static source code analysis. Markus Elfring (6): twl-core: Return directly after a failed platform_device_alloc() in add_numbered_child() twl-core: Refactoring for add_numbered_child() dm355evm_msp: Return directly after a failed platform_device_alloc() in add_child() dm355evm_msp: Refactoring for add_child() smsc-ece1099: Delete an unnecessary variable initialisation in smsc_i2c_probe() smsc-ece1099: Return directly after a function failure in smsc_i2c_probe() drivers/mfd/dm355evm_msp.c | 25 ++++++++++++------------- drivers/mfd/smsc-ece1099.c | 11 ++++------- drivers/mfd/twl-core.c | 28 +++++++++++++--------------- 3 files changed, 29 insertions(+), 35 deletions(-) -- 2.9.0 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 1/6] mfd: twl-core: Return directly after a failed platform_device_alloc() in add_numbered_child() 2016-06-26 13:34 ` SF Markus Elfring @ 2016-06-26 13:45 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-06-26 13:45 UTC (permalink / raw) To: Lee Jones, Tony Lindgren, linux-omap; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 26 Jun 2016 12:25:36 +0200 The platform_device_put() function was called in one case by the add_numbered_child() function during error handling even if the passed variable "pdev" contained a null pointer. Return directly in this case. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/mfd/twl-core.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c index 831696e..9458c6d 100644 --- a/drivers/mfd/twl-core.c +++ b/drivers/mfd/twl-core.c @@ -622,11 +622,8 @@ add_numbered_child(unsigned mod_no, const char *name, int num, twl = &twl_priv->twl_modules[sid]; pdev = platform_device_alloc(name, num); - if (!pdev) { - dev_dbg(&twl->client->dev, "can't alloc dev\n"); - status = -ENOMEM; - goto err; - } + if (!pdev) + return ERR_PTR(-ENOMEM); pdev->dev.parent = &twl->client->dev; -- 2.9.0 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 1/6] mfd: twl-core: Return directly after a failed platform_device_alloc() in add_numbered_ch @ 2016-06-26 13:45 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-06-26 13:45 UTC (permalink / raw) To: Lee Jones, Tony Lindgren, linux-omap; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 26 Jun 2016 12:25:36 +0200 The platform_device_put() function was called in one case by the add_numbered_child() function during error handling even if the passed variable "pdev" contained a null pointer. Return directly in this case. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/mfd/twl-core.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c index 831696e..9458c6d 100644 --- a/drivers/mfd/twl-core.c +++ b/drivers/mfd/twl-core.c @@ -622,11 +622,8 @@ add_numbered_child(unsigned mod_no, const char *name, int num, twl = &twl_priv->twl_modules[sid]; pdev = platform_device_alloc(name, num); - if (!pdev) { - dev_dbg(&twl->client->dev, "can't alloc dev\n"); - status = -ENOMEM; - goto err; - } + if (!pdev) + return ERR_PTR(-ENOMEM); pdev->dev.parent = &twl->client->dev; -- 2.9.0 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/6] mfd: twl-core: Return directly after a failed platform_device_alloc() in add_numbered_child() 2016-06-26 13:45 ` [PATCH 1/6] mfd: twl-core: Return directly after a failed platform_device_alloc() in add_numbered_ch SF Markus Elfring @ 2016-06-28 15:02 ` Lee Jones -1 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-06-28 15:02 UTC (permalink / raw) To: SF Markus Elfring Cc: Tony Lindgren, linux-omap, LKML, kernel-janitors, Julia Lawall On Sun, 26 Jun 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 26 Jun 2016 12:25:36 +0200 Please use `git send-email` when sending patches to the list. > The platform_device_put() function was called in one case by the > add_numbered_child() function during error handling even if the passed > variable "pdev" contained a null pointer. > Return directly in this case. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/mfd/twl-core.c | 7 ++----- > 1 file changed, 2 insertions(+), 5 deletions(-) Applied though, thanks. > diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c > index 831696e..9458c6d 100644 > --- a/drivers/mfd/twl-core.c > +++ b/drivers/mfd/twl-core.c > @@ -622,11 +622,8 @@ add_numbered_child(unsigned mod_no, const char *name, int num, > twl = &twl_priv->twl_modules[sid]; > > pdev = platform_device_alloc(name, num); > - if (!pdev) { > - dev_dbg(&twl->client->dev, "can't alloc dev\n"); > - status = -ENOMEM; > - goto err; > - } > + if (!pdev) > + return ERR_PTR(-ENOMEM); > > pdev->dev.parent = &twl->client->dev; > -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/6] mfd: twl-core: Return directly after a failed platform_device_alloc() in add_numbere @ 2016-06-28 15:02 ` Lee Jones 0 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-06-28 15:02 UTC (permalink / raw) To: SF Markus Elfring Cc: Tony Lindgren, linux-omap, LKML, kernel-janitors, Julia Lawall On Sun, 26 Jun 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 26 Jun 2016 12:25:36 +0200 Please use `git send-email` when sending patches to the list. > The platform_device_put() function was called in one case by the > add_numbered_child() function during error handling even if the passed > variable "pdev" contained a null pointer. > Return directly in this case. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/mfd/twl-core.c | 7 ++----- > 1 file changed, 2 insertions(+), 5 deletions(-) Applied though, thanks. > diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c > index 831696e..9458c6d 100644 > --- a/drivers/mfd/twl-core.c > +++ b/drivers/mfd/twl-core.c > @@ -622,11 +622,8 @@ add_numbered_child(unsigned mod_no, const char *name, int num, > twl = &twl_priv->twl_modules[sid]; > > pdev = platform_device_alloc(name, num); > - if (!pdev) { > - dev_dbg(&twl->client->dev, "can't alloc dev\n"); > - status = -ENOMEM; > - goto err; > - } > + if (!pdev) > + return ERR_PTR(-ENOMEM); > > pdev->dev.parent = &twl->client->dev; > -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 2/6] mfd: twl-core: Refactoring for add_numbered_child() 2016-06-26 13:34 ` SF Markus Elfring @ 2016-06-26 13:47 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-06-26 13:47 UTC (permalink / raw) To: Lee Jones, Tony Lindgren, linux-omap; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 26 Jun 2016 13:03:59 +0200 Adjust jump targets according to the Linux coding style convention. Another check for the variable "status" can be omitted then at the end. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Acked-by: Lee Jones <lee.jones@linaro.org> --- drivers/mfd/twl-core.c | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c index 9458c6d..a49d3db 100644 --- a/drivers/mfd/twl-core.c +++ b/drivers/mfd/twl-core.c @@ -631,7 +631,7 @@ add_numbered_child(unsigned mod_no, const char *name, int num, status = platform_device_add_data(pdev, pdata, pdata_len); if (status < 0) { dev_dbg(&pdev->dev, "can't add platform_data\n"); - goto err; + goto put_device; } } @@ -644,21 +644,22 @@ add_numbered_child(unsigned mod_no, const char *name, int num, status = platform_device_add_resources(pdev, r, irq1 ? 2 : 1); if (status < 0) { dev_dbg(&pdev->dev, "can't add irqs\n"); - goto err; + goto put_device; } } status = platform_device_add(pdev); - if (status == 0) - device_init_wakeup(&pdev->dev, can_wakeup); + if (status) + goto put_device; + + device_init_wakeup(&pdev->dev, can_wakeup); -err: - if (status < 0) { - platform_device_put(pdev); - dev_err(&twl->client->dev, "can't add %s dev\n", name); - return ERR_PTR(status); - } return &pdev->dev; + +put_device: + platform_device_put(pdev); + dev_err(&twl->client->dev, "failed to add device %s\n", name); + return ERR_PTR(status); } static inline struct device *add_child(unsigned mod_no, const char *name, -- 2.9.0 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 2/6] mfd: twl-core: Refactoring for add_numbered_child() @ 2016-06-26 13:47 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-06-26 13:47 UTC (permalink / raw) To: Lee Jones, Tony Lindgren, linux-omap; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 26 Jun 2016 13:03:59 +0200 Adjust jump targets according to the Linux coding style convention. Another check for the variable "status" can be omitted then at the end. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Acked-by: Lee Jones <lee.jones@linaro.org> --- drivers/mfd/twl-core.c | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c index 9458c6d..a49d3db 100644 --- a/drivers/mfd/twl-core.c +++ b/drivers/mfd/twl-core.c @@ -631,7 +631,7 @@ add_numbered_child(unsigned mod_no, const char *name, int num, status = platform_device_add_data(pdev, pdata, pdata_len); if (status < 0) { dev_dbg(&pdev->dev, "can't add platform_data\n"); - goto err; + goto put_device; } } @@ -644,21 +644,22 @@ add_numbered_child(unsigned mod_no, const char *name, int num, status = platform_device_add_resources(pdev, r, irq1 ? 2 : 1); if (status < 0) { dev_dbg(&pdev->dev, "can't add irqs\n"); - goto err; + goto put_device; } } status = platform_device_add(pdev); - if (status = 0) - device_init_wakeup(&pdev->dev, can_wakeup); + if (status) + goto put_device; + + device_init_wakeup(&pdev->dev, can_wakeup); -err: - if (status < 0) { - platform_device_put(pdev); - dev_err(&twl->client->dev, "can't add %s dev\n", name); - return ERR_PTR(status); - } return &pdev->dev; + +put_device: + platform_device_put(pdev); + dev_err(&twl->client->dev, "failed to add device %s\n", name); + return ERR_PTR(status); } static inline struct device *add_child(unsigned mod_no, const char *name, -- 2.9.0 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/6] mfd: twl-core: Refactoring for add_numbered_child() 2016-06-26 13:47 ` SF Markus Elfring (?) @ 2016-06-28 15:03 ` Lee Jones -1 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-06-28 15:03 UTC (permalink / raw) To: SF Markus Elfring Cc: Tony Lindgren, linux-omap, LKML, kernel-janitors, Julia Lawall On Sun, 26 Jun 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 26 Jun 2016 13:03:59 +0200 > > Adjust jump targets according to the Linux coding style convention. > Another check for the variable "status" can be omitted then at the end. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > Acked-by: Lee Jones <lee.jones@linaro.org> > --- > drivers/mfd/twl-core.c | 21 +++++++++++---------- > 1 file changed, 11 insertions(+), 10 deletions(-) Applied, thanks. > diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c > index 9458c6d..a49d3db 100644 > --- a/drivers/mfd/twl-core.c > +++ b/drivers/mfd/twl-core.c > @@ -631,7 +631,7 @@ add_numbered_child(unsigned mod_no, const char *name, int num, > status = platform_device_add_data(pdev, pdata, pdata_len); > if (status < 0) { > dev_dbg(&pdev->dev, "can't add platform_data\n"); > - goto err; > + goto put_device; > } > } > > @@ -644,21 +644,22 @@ add_numbered_child(unsigned mod_no, const char *name, int num, > status = platform_device_add_resources(pdev, r, irq1 ? 2 : 1); > if (status < 0) { > dev_dbg(&pdev->dev, "can't add irqs\n"); > - goto err; > + goto put_device; > } > } > > status = platform_device_add(pdev); > - if (status == 0) > - device_init_wakeup(&pdev->dev, can_wakeup); > + if (status) > + goto put_device; > + > + device_init_wakeup(&pdev->dev, can_wakeup); > > -err: > - if (status < 0) { > - platform_device_put(pdev); > - dev_err(&twl->client->dev, "can't add %s dev\n", name); > - return ERR_PTR(status); > - } > return &pdev->dev; > + > +put_device: > + platform_device_put(pdev); > + dev_err(&twl->client->dev, "failed to add device %s\n", name); > + return ERR_PTR(status); > } > > static inline struct device *add_child(unsigned mod_no, const char *name, -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/6] mfd: twl-core: Refactoring for add_numbered_child() @ 2016-06-28 15:03 ` Lee Jones 0 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-06-28 15:03 UTC (permalink / raw) To: SF Markus Elfring Cc: Tony Lindgren, linux-omap, LKML, kernel-janitors, Julia Lawall On Sun, 26 Jun 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 26 Jun 2016 13:03:59 +0200 > > Adjust jump targets according to the Linux coding style convention. > Another check for the variable "status" can be omitted then at the end. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > Acked-by: Lee Jones <lee.jones@linaro.org> > --- > drivers/mfd/twl-core.c | 21 +++++++++++---------- > 1 file changed, 11 insertions(+), 10 deletions(-) Applied, thanks. > diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c > index 9458c6d..a49d3db 100644 > --- a/drivers/mfd/twl-core.c > +++ b/drivers/mfd/twl-core.c > @@ -631,7 +631,7 @@ add_numbered_child(unsigned mod_no, const char *name, int num, > status = platform_device_add_data(pdev, pdata, pdata_len); > if (status < 0) { > dev_dbg(&pdev->dev, "can't add platform_data\n"); > - goto err; > + goto put_device; > } > } > > @@ -644,21 +644,22 @@ add_numbered_child(unsigned mod_no, const char *name, int num, > status = platform_device_add_resources(pdev, r, irq1 ? 2 : 1); > if (status < 0) { > dev_dbg(&pdev->dev, "can't add irqs\n"); > - goto err; > + goto put_device; > } > } > > status = platform_device_add(pdev); > - if (status == 0) > - device_init_wakeup(&pdev->dev, can_wakeup); > + if (status) > + goto put_device; > + > + device_init_wakeup(&pdev->dev, can_wakeup); > > -err: > - if (status < 0) { > - platform_device_put(pdev); > - dev_err(&twl->client->dev, "can't add %s dev\n", name); > - return ERR_PTR(status); > - } > return &pdev->dev; > + > +put_device: > + platform_device_put(pdev); > + dev_err(&twl->client->dev, "failed to add device %s\n", name); > + return ERR_PTR(status); > } > > static inline struct device *add_child(unsigned mod_no, const char *name, -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/6] mfd: twl-core: Refactoring for add_numbered_child() @ 2016-06-28 15:03 ` Lee Jones 0 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-06-28 15:03 UTC (permalink / raw) To: SF Markus Elfring Cc: Tony Lindgren, linux-omap, LKML, kernel-janitors, Julia Lawall On Sun, 26 Jun 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 26 Jun 2016 13:03:59 +0200 > > Adjust jump targets according to the Linux coding style convention. > Another check for the variable "status" can be omitted then at the end. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > Acked-by: Lee Jones <lee.jones@linaro.org> > --- > drivers/mfd/twl-core.c | 21 +++++++++++---------- > 1 file changed, 11 insertions(+), 10 deletions(-) Applied, thanks. > diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c > index 9458c6d..a49d3db 100644 > --- a/drivers/mfd/twl-core.c > +++ b/drivers/mfd/twl-core.c > @@ -631,7 +631,7 @@ add_numbered_child(unsigned mod_no, const char *name, int num, > status = platform_device_add_data(pdev, pdata, pdata_len); > if (status < 0) { > dev_dbg(&pdev->dev, "can't add platform_data\n"); > - goto err; > + goto put_device; > } > } > > @@ -644,21 +644,22 @@ add_numbered_child(unsigned mod_no, const char *name, int num, > status = platform_device_add_resources(pdev, r, irq1 ? 2 : 1); > if (status < 0) { > dev_dbg(&pdev->dev, "can't add irqs\n"); > - goto err; > + goto put_device; > } > } > > status = platform_device_add(pdev); > - if (status = 0) > - device_init_wakeup(&pdev->dev, can_wakeup); > + if (status) > + goto put_device; > + > + device_init_wakeup(&pdev->dev, can_wakeup); > > -err: > - if (status < 0) { > - platform_device_put(pdev); > - dev_err(&twl->client->dev, "can't add %s dev\n", name); > - return ERR_PTR(status); > - } > return &pdev->dev; > + > +put_device: > + platform_device_put(pdev); > + dev_err(&twl->client->dev, "failed to add device %s\n", name); > + return ERR_PTR(status); > } > > static inline struct device *add_child(unsigned mod_no, const char *name, -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 3/6] mfd: dm355evm_msp: Return directly after a failed platform_device_alloc() in add_child() 2016-06-26 13:34 ` SF Markus Elfring @ 2016-06-26 13:48 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-06-26 13:48 UTC (permalink / raw) To: Lee Jones, Tony Lindgren, linux-omap; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 26 Jun 2016 13:40:35 +0200 The platform_device_put() function was called in one case by the add_child() function during error handling even if the passed variable "pdev" contained a null pointer. Return directly in this case. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/mfd/dm355evm_msp.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/mfd/dm355evm_msp.c b/drivers/mfd/dm355evm_msp.c index 14661ec..270e19c 100644 --- a/drivers/mfd/dm355evm_msp.c +++ b/drivers/mfd/dm355evm_msp.c @@ -199,11 +199,8 @@ static struct device *add_child(struct i2c_client *client, const char *name, int status; pdev = platform_device_alloc(name, -1); - if (!pdev) { - dev_dbg(&client->dev, "can't alloc dev\n"); - status = -ENOMEM; - goto err; - } + if (!pdev) + return ERR_PTR(-ENOMEM); device_init_wakeup(&pdev->dev, can_wakeup); pdev->dev.parent = &client->dev; -- 2.9.0 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 3/6] mfd: dm355evm_msp: Return directly after a failed platform_device_alloc() in add_child() @ 2016-06-26 13:48 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-06-26 13:48 UTC (permalink / raw) To: Lee Jones, Tony Lindgren, linux-omap; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 26 Jun 2016 13:40:35 +0200 The platform_device_put() function was called in one case by the add_child() function during error handling even if the passed variable "pdev" contained a null pointer. Return directly in this case. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/mfd/dm355evm_msp.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/mfd/dm355evm_msp.c b/drivers/mfd/dm355evm_msp.c index 14661ec..270e19c 100644 --- a/drivers/mfd/dm355evm_msp.c +++ b/drivers/mfd/dm355evm_msp.c @@ -199,11 +199,8 @@ static struct device *add_child(struct i2c_client *client, const char *name, int status; pdev = platform_device_alloc(name, -1); - if (!pdev) { - dev_dbg(&client->dev, "can't alloc dev\n"); - status = -ENOMEM; - goto err; - } + if (!pdev) + return ERR_PTR(-ENOMEM); device_init_wakeup(&pdev->dev, can_wakeup); pdev->dev.parent = &client->dev; -- 2.9.0 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 3/6] mfd: dm355evm_msp: Return directly after a failed platform_device_alloc() in add_child() 2016-06-26 13:48 ` SF Markus Elfring @ 2016-06-28 15:03 ` Lee Jones -1 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-06-28 15:03 UTC (permalink / raw) To: SF Markus Elfring Cc: Tony Lindgren, linux-omap, LKML, kernel-janitors, Julia Lawall On Sun, 26 Jun 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 26 Jun 2016 13:40:35 +0200 > > The platform_device_put() function was called in one case by the > add_child() function during error handling even if the passed > variable "pdev" contained a null pointer. > Return directly in this case. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/mfd/dm355evm_msp.c | 7 ++----- > 1 file changed, 2 insertions(+), 5 deletions(-) Applied, thanks. > diff --git a/drivers/mfd/dm355evm_msp.c b/drivers/mfd/dm355evm_msp.c > index 14661ec..270e19c 100644 > --- a/drivers/mfd/dm355evm_msp.c > +++ b/drivers/mfd/dm355evm_msp.c > @@ -199,11 +199,8 @@ static struct device *add_child(struct i2c_client *client, const char *name, > int status; > > pdev = platform_device_alloc(name, -1); > - if (!pdev) { > - dev_dbg(&client->dev, "can't alloc dev\n"); > - status = -ENOMEM; > - goto err; > - } > + if (!pdev) > + return ERR_PTR(-ENOMEM); > > device_init_wakeup(&pdev->dev, can_wakeup); > pdev->dev.parent = &client->dev; -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 3/6] mfd: dm355evm_msp: Return directly after a failed platform_device_alloc() in add_chi @ 2016-06-28 15:03 ` Lee Jones 0 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-06-28 15:03 UTC (permalink / raw) To: SF Markus Elfring Cc: Tony Lindgren, linux-omap, LKML, kernel-janitors, Julia Lawall On Sun, 26 Jun 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 26 Jun 2016 13:40:35 +0200 > > The platform_device_put() function was called in one case by the > add_child() function during error handling even if the passed > variable "pdev" contained a null pointer. > Return directly in this case. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/mfd/dm355evm_msp.c | 7 ++----- > 1 file changed, 2 insertions(+), 5 deletions(-) Applied, thanks. > diff --git a/drivers/mfd/dm355evm_msp.c b/drivers/mfd/dm355evm_msp.c > index 14661ec..270e19c 100644 > --- a/drivers/mfd/dm355evm_msp.c > +++ b/drivers/mfd/dm355evm_msp.c > @@ -199,11 +199,8 @@ static struct device *add_child(struct i2c_client *client, const char *name, > int status; > > pdev = platform_device_alloc(name, -1); > - if (!pdev) { > - dev_dbg(&client->dev, "can't alloc dev\n"); > - status = -ENOMEM; > - goto err; > - } > + if (!pdev) > + return ERR_PTR(-ENOMEM); > > device_init_wakeup(&pdev->dev, can_wakeup); > pdev->dev.parent = &client->dev; -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 4/6] mfd: dm355evm_msp: Refactoring for add_child() 2016-06-26 13:34 ` SF Markus Elfring @ 2016-06-26 13:50 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-06-26 13:50 UTC (permalink / raw) To: Lee Jones, Tony Lindgren, linux-omap; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 26 Jun 2016 13:56:58 +0200 Adjust jump targets according to the Linux coding style convention. Another check for the variable "status" can be omitted then at the end. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/mfd/dm355evm_msp.c | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/drivers/mfd/dm355evm_msp.c b/drivers/mfd/dm355evm_msp.c index 270e19c..baf6075 100644 --- a/drivers/mfd/dm355evm_msp.c +++ b/drivers/mfd/dm355evm_msp.c @@ -209,7 +209,7 @@ static struct device *add_child(struct i2c_client *client, const char *name, status = platform_device_add_data(pdev, pdata, pdata_len); if (status < 0) { dev_dbg(&pdev->dev, "can't add platform_data\n"); - goto err; + goto put_device; } } @@ -222,19 +222,21 @@ static struct device *add_child(struct i2c_client *client, const char *name, status = platform_device_add_resources(pdev, &r, 1); if (status < 0) { dev_dbg(&pdev->dev, "can't add irq\n"); - goto err; + goto put_device; } } status = platform_device_add(pdev); -err: - if (status < 0) { - platform_device_put(pdev); - dev_err(&client->dev, "can't add %s dev\n", name); - return ERR_PTR(status); - } + if (status) + goto put_device; + return &pdev->dev; + +put_device: + platform_device_put(pdev); + dev_err(&client->dev, "failed to add device %s\n", name); + return ERR_PTR(status); } static int add_children(struct i2c_client *client) -- 2.9.0 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 4/6] mfd: dm355evm_msp: Refactoring for add_child() @ 2016-06-26 13:50 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-06-26 13:50 UTC (permalink / raw) To: Lee Jones, Tony Lindgren, linux-omap; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 26 Jun 2016 13:56:58 +0200 Adjust jump targets according to the Linux coding style convention. Another check for the variable "status" can be omitted then at the end. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/mfd/dm355evm_msp.c | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/drivers/mfd/dm355evm_msp.c b/drivers/mfd/dm355evm_msp.c index 270e19c..baf6075 100644 --- a/drivers/mfd/dm355evm_msp.c +++ b/drivers/mfd/dm355evm_msp.c @@ -209,7 +209,7 @@ static struct device *add_child(struct i2c_client *client, const char *name, status = platform_device_add_data(pdev, pdata, pdata_len); if (status < 0) { dev_dbg(&pdev->dev, "can't add platform_data\n"); - goto err; + goto put_device; } } @@ -222,19 +222,21 @@ static struct device *add_child(struct i2c_client *client, const char *name, status = platform_device_add_resources(pdev, &r, 1); if (status < 0) { dev_dbg(&pdev->dev, "can't add irq\n"); - goto err; + goto put_device; } } status = platform_device_add(pdev); -err: - if (status < 0) { - platform_device_put(pdev); - dev_err(&client->dev, "can't add %s dev\n", name); - return ERR_PTR(status); - } + if (status) + goto put_device; + return &pdev->dev; + +put_device: + platform_device_put(pdev); + dev_err(&client->dev, "failed to add device %s\n", name); + return ERR_PTR(status); } static int add_children(struct i2c_client *client) -- 2.9.0 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 4/6] mfd: dm355evm_msp: Refactoring for add_child() 2016-06-26 13:50 ` SF Markus Elfring (?) @ 2016-06-28 15:07 ` Lee Jones -1 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-06-28 15:07 UTC (permalink / raw) To: SF Markus Elfring Cc: Tony Lindgren, linux-omap, LKML, kernel-janitors, Julia Lawall On Sun, 26 Jun 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 26 Jun 2016 13:56:58 +0200 > > Adjust jump targets according to the Linux coding style convention. > Another check for the variable "status" can be omitted then at the end. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/mfd/dm355evm_msp.c | 18 ++++++++++-------- > 1 file changed, 10 insertions(+), 8 deletions(-) > > diff --git a/drivers/mfd/dm355evm_msp.c b/drivers/mfd/dm355evm_msp.c > index 270e19c..baf6075 100644 > --- a/drivers/mfd/dm355evm_msp.c > +++ b/drivers/mfd/dm355evm_msp.c > @@ -209,7 +209,7 @@ static struct device *add_child(struct i2c_client *client, const char *name, > status = platform_device_add_data(pdev, pdata, pdata_len); > if (status < 0) { > dev_dbg(&pdev->dev, "can't add platform_data\n"); > - goto err; > + goto put_device; > } > } > > @@ -222,19 +222,21 @@ static struct device *add_child(struct i2c_client *client, const char *name, > status = platform_device_add_resources(pdev, &r, 1); > if (status < 0) { > dev_dbg(&pdev->dev, "can't add irq\n"); > - goto err; > + goto put_device; > } > } > > status = platform_device_add(pdev); > Remove this line too. > -err: > - if (status < 0) { > - platform_device_put(pdev); > - dev_err(&client->dev, "can't add %s dev\n", name); > - return ERR_PTR(status); > - } > + if (status) > + goto put_device; > + > return &pdev->dev; > + > +put_device: > + platform_device_put(pdev); > + dev_err(&client->dev, "failed to add device %s\n", name); > + return ERR_PTR(status); > } > > static int add_children(struct i2c_client *client) -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 4/6] mfd: dm355evm_msp: Refactoring for add_child() @ 2016-06-28 15:07 ` Lee Jones 0 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-06-28 15:07 UTC (permalink / raw) To: SF Markus Elfring Cc: Tony Lindgren, linux-omap, LKML, kernel-janitors, Julia Lawall On Sun, 26 Jun 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 26 Jun 2016 13:56:58 +0200 > > Adjust jump targets according to the Linux coding style convention. > Another check for the variable "status" can be omitted then at the end. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/mfd/dm355evm_msp.c | 18 ++++++++++-------- > 1 file changed, 10 insertions(+), 8 deletions(-) > > diff --git a/drivers/mfd/dm355evm_msp.c b/drivers/mfd/dm355evm_msp.c > index 270e19c..baf6075 100644 > --- a/drivers/mfd/dm355evm_msp.c > +++ b/drivers/mfd/dm355evm_msp.c > @@ -209,7 +209,7 @@ static struct device *add_child(struct i2c_client *client, const char *name, > status = platform_device_add_data(pdev, pdata, pdata_len); > if (status < 0) { > dev_dbg(&pdev->dev, "can't add platform_data\n"); > - goto err; > + goto put_device; > } > } > > @@ -222,19 +222,21 @@ static struct device *add_child(struct i2c_client *client, const char *name, > status = platform_device_add_resources(pdev, &r, 1); > if (status < 0) { > dev_dbg(&pdev->dev, "can't add irq\n"); > - goto err; > + goto put_device; > } > } > > status = platform_device_add(pdev); > Remove this line too. > -err: > - if (status < 0) { > - platform_device_put(pdev); > - dev_err(&client->dev, "can't add %s dev\n", name); > - return ERR_PTR(status); > - } > + if (status) > + goto put_device; > + > return &pdev->dev; > + > +put_device: > + platform_device_put(pdev); > + dev_err(&client->dev, "failed to add device %s\n", name); > + return ERR_PTR(status); > } > > static int add_children(struct i2c_client *client) -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 4/6] mfd: dm355evm_msp: Refactoring for add_child() @ 2016-06-28 15:07 ` Lee Jones 0 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-06-28 15:07 UTC (permalink / raw) To: SF Markus Elfring Cc: Tony Lindgren, linux-omap, LKML, kernel-janitors, Julia Lawall On Sun, 26 Jun 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 26 Jun 2016 13:56:58 +0200 > > Adjust jump targets according to the Linux coding style convention. > Another check for the variable "status" can be omitted then at the end. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/mfd/dm355evm_msp.c | 18 ++++++++++-------- > 1 file changed, 10 insertions(+), 8 deletions(-) > > diff --git a/drivers/mfd/dm355evm_msp.c b/drivers/mfd/dm355evm_msp.c > index 270e19c..baf6075 100644 > --- a/drivers/mfd/dm355evm_msp.c > +++ b/drivers/mfd/dm355evm_msp.c > @@ -209,7 +209,7 @@ static struct device *add_child(struct i2c_client *client, const char *name, > status = platform_device_add_data(pdev, pdata, pdata_len); > if (status < 0) { > dev_dbg(&pdev->dev, "can't add platform_data\n"); > - goto err; > + goto put_device; > } > } > > @@ -222,19 +222,21 @@ static struct device *add_child(struct i2c_client *client, const char *name, > status = platform_device_add_resources(pdev, &r, 1); > if (status < 0) { > dev_dbg(&pdev->dev, "can't add irq\n"); > - goto err; > + goto put_device; > } > } > > status = platform_device_add(pdev); > Remove this line too. > -err: > - if (status < 0) { > - platform_device_put(pdev); > - dev_err(&client->dev, "can't add %s dev\n", name); > - return ERR_PTR(status); > - } > + if (status) > + goto put_device; > + > return &pdev->dev; > + > +put_device: > + platform_device_put(pdev); > + dev_err(&client->dev, "failed to add device %s\n", name); > + return ERR_PTR(status); > } > > static int add_children(struct i2c_client *client) -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 4/6] mfd: dm355evm_msp: Refactoring for add_child() 2016-06-28 15:07 ` Lee Jones @ 2016-06-28 15:40 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-06-28 15:40 UTC (permalink / raw) To: Lee Jones; +Cc: Tony Lindgren, linux-omap, LKML, kernel-janitors, Julia Lawall >> @@ -222,19 +222,21 @@ static struct device *add_child(struct i2c_client *client, const char *name, >> status = platform_device_add_resources(pdev, &r, 1); >> if (status < 0) { >> dev_dbg(&pdev->dev, "can't add irq\n"); >> - goto err; >> + goto put_device; >> } >> } >> >> status = platform_device_add(pdev); >> > > Remove this line too. Do you propose the deletion of a blank line here? Did you skip this update suggestion while the other patches were finally accepted? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 4/6] mfd: dm355evm_msp: Refactoring for add_child() @ 2016-06-28 15:40 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-06-28 15:40 UTC (permalink / raw) To: Lee Jones; +Cc: Tony Lindgren, linux-omap, LKML, kernel-janitors, Julia Lawall >> @@ -222,19 +222,21 @@ static struct device *add_child(struct i2c_client *client, const char *name, >> status = platform_device_add_resources(pdev, &r, 1); >> if (status < 0) { >> dev_dbg(&pdev->dev, "can't add irq\n"); >> - goto err; >> + goto put_device; >> } >> } >> >> status = platform_device_add(pdev); >> > > Remove this line too. Do you propose the deletion of a blank line here? Did you skip this update suggestion while the other patches were finally accepted? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 4/6] mfd: dm355evm_msp: Refactoring for add_child() 2016-06-28 15:40 ` SF Markus Elfring @ 2016-06-28 16:31 ` Lee Jones -1 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-06-28 16:31 UTC (permalink / raw) To: SF Markus Elfring Cc: Tony Lindgren, linux-omap, LKML, kernel-janitors, Julia Lawall On Tue, 28 Jun 2016, SF Markus Elfring wrote: > >> @@ -222,19 +222,21 @@ static struct device *add_child(struct i2c_client *client, const char *name, > >> status = platform_device_add_resources(pdev, &r, 1); > >> if (status < 0) { > >> dev_dbg(&pdev->dev, "can't add irq\n"); > >> - goto err; > >> + goto put_device; > >> } > >> } > >> > >> status = platform_device_add(pdev); > >> > > > > Remove this line too. > > Do you propose the deletion of a blank line here? Yes. > Did you skip this update suggestion while the other patches were finally accepted? I don't know what this means. The other patches in the set have been accepted. Please fix this one and send it again on its own. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 4/6] mfd: dm355evm_msp: Refactoring for add_child() @ 2016-06-28 16:31 ` Lee Jones 0 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-06-28 16:31 UTC (permalink / raw) To: SF Markus Elfring Cc: Tony Lindgren, linux-omap, LKML, kernel-janitors, Julia Lawall On Tue, 28 Jun 2016, SF Markus Elfring wrote: > >> @@ -222,19 +222,21 @@ static struct device *add_child(struct i2c_client *client, const char *name, > >> status = platform_device_add_resources(pdev, &r, 1); > >> if (status < 0) { > >> dev_dbg(&pdev->dev, "can't add irq\n"); > >> - goto err; > >> + goto put_device; > >> } > >> } > >> > >> status = platform_device_add(pdev); > >> > > > > Remove this line too. > > Do you propose the deletion of a blank line here? Yes. > Did you skip this update suggestion while the other patches were finally accepted? I don't know what this means. The other patches in the set have been accepted. Please fix this one and send it again on its own. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH] mfd: dm355evm_msp: Refactoring for add_child() 2016-06-28 16:31 ` Lee Jones @ 2016-06-30 20:15 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-06-30 20:15 UTC (permalink / raw) To: Lee Jones; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Thu, 30 Jun 2016 21:54:51 +0200 Adjust jump targets according to the Linux coding style convention. Another check for the variable "status" can be omitted then at the end. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/mfd/dm355evm_msp.c | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/drivers/mfd/dm355evm_msp.c b/drivers/mfd/dm355evm_msp.c index 270e19c..86eca61 100644 --- a/drivers/mfd/dm355evm_msp.c +++ b/drivers/mfd/dm355evm_msp.c @@ -209,7 +209,7 @@ static struct device *add_child(struct i2c_client *client, const char *name, status = platform_device_add_data(pdev, pdata, pdata_len); if (status < 0) { dev_dbg(&pdev->dev, "can't add platform_data\n"); - goto err; + goto put_device; } } @@ -222,19 +222,20 @@ static struct device *add_child(struct i2c_client *client, const char *name, status = platform_device_add_resources(pdev, &r, 1); if (status < 0) { dev_dbg(&pdev->dev, "can't add irq\n"); - goto err; + goto put_device; } } status = platform_device_add(pdev); + if (status) + goto put_device; -err: - if (status < 0) { - platform_device_put(pdev); - dev_err(&client->dev, "can't add %s dev\n", name); - return ERR_PTR(status); - } return &pdev->dev; + +put_device: + platform_device_put(pdev); + dev_err(&client->dev, "failed to add device %s\n", name); + return ERR_PTR(status); } static int add_children(struct i2c_client *client) -- 2.9.0 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH] mfd: dm355evm_msp: Refactoring for add_child() @ 2016-06-30 20:15 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-06-30 20:15 UTC (permalink / raw) To: Lee Jones; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Thu, 30 Jun 2016 21:54:51 +0200 Adjust jump targets according to the Linux coding style convention. Another check for the variable "status" can be omitted then at the end. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/mfd/dm355evm_msp.c | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/drivers/mfd/dm355evm_msp.c b/drivers/mfd/dm355evm_msp.c index 270e19c..86eca61 100644 --- a/drivers/mfd/dm355evm_msp.c +++ b/drivers/mfd/dm355evm_msp.c @@ -209,7 +209,7 @@ static struct device *add_child(struct i2c_client *client, const char *name, status = platform_device_add_data(pdev, pdata, pdata_len); if (status < 0) { dev_dbg(&pdev->dev, "can't add platform_data\n"); - goto err; + goto put_device; } } @@ -222,19 +222,20 @@ static struct device *add_child(struct i2c_client *client, const char *name, status = platform_device_add_resources(pdev, &r, 1); if (status < 0) { dev_dbg(&pdev->dev, "can't add irq\n"); - goto err; + goto put_device; } } status = platform_device_add(pdev); + if (status) + goto put_device; -err: - if (status < 0) { - platform_device_put(pdev); - dev_err(&client->dev, "can't add %s dev\n", name); - return ERR_PTR(status); - } return &pdev->dev; + +put_device: + platform_device_put(pdev); + dev_err(&client->dev, "failed to add device %s\n", name); + return ERR_PTR(status); } static int add_children(struct i2c_client *client) -- 2.9.0 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH] mfd: dm355evm_msp: Refactoring for add_child() 2016-06-30 20:15 ` SF Markus Elfring @ 2016-06-30 20:34 ` Joe Perches -1 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2016-06-30 20:34 UTC (permalink / raw) To: SF Markus Elfring, Lee Jones; +Cc: LKML, kernel-janitors, Julia Lawall On Thu, 2016-06-30 at 22:15 +0200, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Thu, 30 Jun 2016 21:54:51 +0200 > > Adjust jump targets according to the Linux coding style convention. > Another check for the variable "status" can be omitted then at the > end. Two headers in this email: References: <566ABCD9.1060404@users.sourceforge.net> <5682D228.7070902@users.sourceforge.net> <20160111082922.GB14104@x1> <05b7db2a-437a-60ac-d289-71d2150e7f5f@users.sourceforge.net> <de3598c4-f85a-6807-303a-55ee0ac707f2@users.sourceforge.net> <20160608111442.GB14888@dell> <e4eaf0b4-e539-b400-c8a2-70f210cee1fa@users.sourceforge.net> <75c1cc23-3a2d-db78-d0f2-b5934b18e828@users.sourceforge.net> <20160628150725.GL24982@dell> <c220895b-e56f-dc95-500d-0cf9d2f51777@users.sourceforge.net> <20160628163146.GG29166@dell> In-reply-to: <20160628163146.GG29166@dell> Can you please fix your email client to _not_ send References: and In-reply-to: headers when sending new patches? Thanks. Even better would be to use git send-email for these patches. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] mfd: dm355evm_msp: Refactoring for add_child() @ 2016-06-30 20:34 ` Joe Perches 0 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2016-06-30 20:34 UTC (permalink / raw) To: SF Markus Elfring, Lee Jones; +Cc: LKML, kernel-janitors, Julia Lawall On Thu, 2016-06-30 at 22:15 +0200, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Thu, 30 Jun 2016 21:54:51 +0200 > > Adjust jump targets according to the Linux coding style convention. > Another check for the variable "status" can be omitted then at the > end. Two headers in this email: References: <566ABCD9.1060404@users.sourceforge.net> <5682D228.7070902@users.sourceforge.net> <20160111082922.GB14104@x1> <05b7db2a-437a-60ac-d289-71d2150e7f5f@users.sourceforge.net> <de3598c4-f85a-6807-303a-55ee0ac707f2@users.sourceforge.net> <20160608111442.GB14888@dell> <e4eaf0b4-e539-b400-c8a2-70f210cee1fa@users.sourceforge.net> <75c1cc23-3a2d-db78-d0f2-b5934b18e828@users.sourceforge.net> <20160628150725.GL24982@dell> <c220895b-e56f-dc95-500d-0cf9d2f51777@users.sourceforge.net> <20160628163146.GG29166@dell> In-reply-to: <20160628163146.GG29166@dell> Can you please fix your email client to _not_ send References: and In-reply-to: headers when sending new patches? Thanks. Even better would be to use git send-email for these patches. -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] mfd: dm355evm_msp: Refactoring for add_child() 2016-06-30 20:34 ` Joe Perches @ 2016-06-30 21:00 ` Lee Jones -1 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-06-30 20:59 UTC (permalink / raw) To: Joe Perches; +Cc: SF Markus Elfring, LKML, kernel-janitors, Julia Lawall On Thu, 30 Jun 2016, Joe Perches wrote: > On Thu, 2016-06-30 at 22:15 +0200, SF Markus Elfring wrote: > > From: Markus Elfring <elfring@users.sourceforge.net> > > Date: Thu, 30 Jun 2016 21:54:51 +0200 > > > > Adjust jump targets according to the Linux coding style convention. > > Another check for the variable "status" can be omitted then at the > > end. > > Two headers in this email: > > References: <566ABCD9.1060404@users.sourceforge.net> <5682D228.7070902@users.sourceforge.net> <20160111082922.GB14104@x1> <05b7db2a-437a-60ac-d289-71d2150e7f5f@users.sourceforge.net> <de3598c4-f85a-6807-303a-55ee0ac707f2@users.sourceforge.net> <20160608111442.GB14888@dell> <e4eaf0b4-e539-b400-c8a2-70f210cee1fa@users.sourceforge.net> <75c1cc23-3a2d-db78-d0f2-b5934b18e828@users.sourceforge.net> <20160628150725.GL24982@dell> <c220895b-e56f-dc95-500d-0cf9d2f51777@users.sourceforge.net> <20160628163146.GG29166@dell> > In-reply-to: <20160628163146.GG29166@dell> > > Can you please fix your email client to _not_ send References: > and In-reply-to: headers when sending new patches? Thanks. > > Even better would be to use git send-email for these patches. Yes, I've mentioned this before. I now have a gargantuan threaded mess consisting of 53 mails in my inbox. Please submit patches using `git send-email`, not forgetting to increase your submission each time you submit i.e [PATCH v2] and send them independently i.e. not attached to previous submissions. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] mfd: dm355evm_msp: Refactoring for add_child() @ 2016-06-30 21:00 ` Lee Jones 0 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-06-30 21:00 UTC (permalink / raw) To: Joe Perches; +Cc: SF Markus Elfring, LKML, kernel-janitors, Julia Lawall On Thu, 30 Jun 2016, Joe Perches wrote: > On Thu, 2016-06-30 at 22:15 +0200, SF Markus Elfring wrote: > > From: Markus Elfring <elfring@users.sourceforge.net> > > Date: Thu, 30 Jun 2016 21:54:51 +0200 > > > > Adjust jump targets according to the Linux coding style convention. > > Another check for the variable "status" can be omitted then at the > > end. > > Two headers in this email: > > References: <566ABCD9.1060404@users.sourceforge.net> <5682D228.7070902@users.sourceforge.net> <20160111082922.GB14104@x1> <05b7db2a-437a-60ac-d289-71d2150e7f5f@users.sourceforge.net> <de3598c4-f85a-6807-303a-55ee0ac707f2@users.sourceforge.net> <20160608111442.GB14888@dell> <e4eaf0b4-e539-b400-c8a2-70f210cee1fa@users.sourceforge.net> <75c1cc23-3a2d-db78-d0f2-b5934b18e828@users.sourceforge.net> <20160628150725.GL24982@dell> <c220895b-e56f-dc95-500d-0cf9d2f51777@users.sourceforge.net> <20160628163146.GG29166@dell> > In-reply-to: <20160628163146.GG29166@dell> > > Can you please fix your email client to _not_ send References: > and In-reply-to: headers when sending new patches? Thanks. > > Even better would be to use git send-email for these patches. Yes, I've mentioned this before. I now have a gargantuan threaded mess consisting of 53 mails in my inbox. Please submit patches using `git send-email`, not forgetting to increase your submission each time you submit i.e [PATCH v2] and send them independently i.e. not attached to previous submissions. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: mfd: dm355evm_msp: Refactoring for add_child() 2016-06-30 20:34 ` Joe Perches @ 2016-07-01 14:40 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-01 14:40 UTC (permalink / raw) To: Joe Perches; +Cc: Lee Jones, LKML, kernel-janitors, Julia Lawall > Can you please fix your email client to _not_ send References: > and In-reply-to: headers when sending new patches? I prefer to associate some patches with previous relevant discussion directly. > Even better would be to use git send-email for these patches. This command can also support a parameter like "--thread", can't it? Would you like point any more views out about communication styles? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: mfd: dm355evm_msp: Refactoring for add_child() @ 2016-07-01 14:40 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-01 14:40 UTC (permalink / raw) To: Joe Perches; +Cc: Lee Jones, LKML, kernel-janitors, Julia Lawall > Can you please fix your email client to _not_ send References: > and In-reply-to: headers when sending new patches? I prefer to associate some patches with previous relevant discussion directly. > Even better would be to use git send-email for these patches. This command can also support a parameter like "--thread", can't it? Would you like point any more views out about communication styles? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: mfd: dm355evm_msp: Refactoring for add_child() 2016-07-01 14:40 ` SF Markus Elfring @ 2016-07-01 16:23 ` Joe Perches -1 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2016-07-01 16:23 UTC (permalink / raw) To: SF Markus Elfring; +Cc: Lee Jones, LKML, kernel-janitors, Julia Lawall On Fri, 2016-07-01 at 16:40 +0200, SF Markus Elfring wrote: > > > > Can you please fix your email client to _not_ send References: > > and In-reply-to: headers when sending new patches? > I prefer to associate some patches with previous relevant > discussion directly. > > > > > > Even better would be to use git send-email for these patches. > This command can also support a parameter like "--thread", can't it? yes, good to see you can read documentation. > Would you like point any more views out about communication styles? Actually, yes. Just because you've submitted a similar patch, an independent patch like this one, doesn't need to refer to those patches you've previously submitted. For instance, your "References:" for this email imply some association to a patch series you submitted "[PATCH v3 0/3] gianfar: Fine-tuning for gfar_ethflow_to_filer_table()" for no obvious reason. What is this reason? ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: mfd: dm355evm_msp: Refactoring for add_child() @ 2016-07-01 16:23 ` Joe Perches 0 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2016-07-01 16:23 UTC (permalink / raw) To: SF Markus Elfring; +Cc: Lee Jones, LKML, kernel-janitors, Julia Lawall On Fri, 2016-07-01 at 16:40 +0200, SF Markus Elfring wrote: > > > > Can you please fix your email client to _not_ send References: > > and In-reply-to: headers when sending new patches? > I prefer to associate some patches with previous relevant > discussion directly. > > > > > > Even better would be to use git send-email for these patches. > This command can also support a parameter like "--thread", can't it? yes, good to see you can read documentation. > Would you like point any more views out about communication styles? Actually, yes. Just because you've submitted a similar patch, an independent patch like this one, doesn't need to refer to those patches you've previously submitted. For instance, your "References:" for this email imply some association to a patch series you submitted "[PATCH v3 0/3] gianfar: Fine-tuning for gfar_ethflow_to_filer_table()" for no obvious reason. What is this reason? -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] mfd: dm355evm_msp: Refactoring for add_child() 2016-06-30 20:15 ` SF Markus Elfring @ 2016-07-01 9:17 ` Lee Jones -1 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-07-01 9:17 UTC (permalink / raw) To: SF Markus Elfring; +Cc: LKML, kernel-janitors, Julia Lawall On Thu, 30 Jun 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Thu, 30 Jun 2016 21:54:51 +0200 > > Adjust jump targets according to the Linux coding style convention. > Another check for the variable "status" can be omitted then at the end. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/mfd/dm355evm_msp.c | 17 +++++++++-------- > 1 file changed, 9 insertions(+), 8 deletions(-) FYI, code looks fine. ... but please take this opportunity to set-up your submission environment i.e. using `git format-patch` and `git send-email`. Once you've done that, please re-submit this patch with my: Acked-by: Lee Jones <lee.jones@linaro.org> > diff --git a/drivers/mfd/dm355evm_msp.c b/drivers/mfd/dm355evm_msp.c > index 270e19c..86eca61 100644 > --- a/drivers/mfd/dm355evm_msp.c > +++ b/drivers/mfd/dm355evm_msp.c > @@ -209,7 +209,7 @@ static struct device *add_child(struct i2c_client *client, const char *name, > status = platform_device_add_data(pdev, pdata, pdata_len); > if (status < 0) { > dev_dbg(&pdev->dev, "can't add platform_data\n"); > - goto err; > + goto put_device; > } > } > > @@ -222,19 +222,20 @@ static struct device *add_child(struct i2c_client *client, const char *name, > status = platform_device_add_resources(pdev, &r, 1); > if (status < 0) { > dev_dbg(&pdev->dev, "can't add irq\n"); > - goto err; > + goto put_device; > } > } > > status = platform_device_add(pdev); > + if (status) > + goto put_device; > > -err: > - if (status < 0) { > - platform_device_put(pdev); > - dev_err(&client->dev, "can't add %s dev\n", name); > - return ERR_PTR(status); > - } > return &pdev->dev; > + > +put_device: > + platform_device_put(pdev); > + dev_err(&client->dev, "failed to add device %s\n", name); > + return ERR_PTR(status); > } > > static int add_children(struct i2c_client *client) -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] mfd: dm355evm_msp: Refactoring for add_child() @ 2016-07-01 9:17 ` Lee Jones 0 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-07-01 9:17 UTC (permalink / raw) To: SF Markus Elfring; +Cc: LKML, kernel-janitors, Julia Lawall On Thu, 30 Jun 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Thu, 30 Jun 2016 21:54:51 +0200 > > Adjust jump targets according to the Linux coding style convention. > Another check for the variable "status" can be omitted then at the end. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/mfd/dm355evm_msp.c | 17 +++++++++-------- > 1 file changed, 9 insertions(+), 8 deletions(-) FYI, code looks fine. ... but please take this opportunity to set-up your submission environment i.e. using `git format-patch` and `git send-email`. Once you've done that, please re-submit this patch with my: Acked-by: Lee Jones <lee.jones@linaro.org> > diff --git a/drivers/mfd/dm355evm_msp.c b/drivers/mfd/dm355evm_msp.c > index 270e19c..86eca61 100644 > --- a/drivers/mfd/dm355evm_msp.c > +++ b/drivers/mfd/dm355evm_msp.c > @@ -209,7 +209,7 @@ static struct device *add_child(struct i2c_client *client, const char *name, > status = platform_device_add_data(pdev, pdata, pdata_len); > if (status < 0) { > dev_dbg(&pdev->dev, "can't add platform_data\n"); > - goto err; > + goto put_device; > } > } > > @@ -222,19 +222,20 @@ static struct device *add_child(struct i2c_client *client, const char *name, > status = platform_device_add_resources(pdev, &r, 1); > if (status < 0) { > dev_dbg(&pdev->dev, "can't add irq\n"); > - goto err; > + goto put_device; > } > } > > status = platform_device_add(pdev); > + if (status) > + goto put_device; > > -err: > - if (status < 0) { > - platform_device_put(pdev); > - dev_err(&client->dev, "can't add %s dev\n", name); > - return ERR_PTR(status); > - } > return &pdev->dev; > + > +put_device: > + platform_device_put(pdev); > + dev_err(&client->dev, "failed to add device %s\n", name); > + return ERR_PTR(status); > } > > static int add_children(struct i2c_client *client) -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: mfd: dm355evm_msp: Refactoring for add_child() 2016-07-01 9:17 ` Lee Jones @ 2016-07-01 14:54 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-01 14:54 UTC (permalink / raw) To: Lee Jones; +Cc: LKML, kernel-janitors, Julia Lawall > FYI, code looks fine. Thanks for your acknowledgement. > ... but please take this opportunity to set-up your submission > environment i.e. using `git format-patch` and `git send-email`. Would you like to see any special settings to be mentioned in a section like "15) Explicit In-Reply-To headers" from the document "SubmittingPatches"? > you've done that, please re-submit this patch with my: Does the association of this patch with a bit relevant discussion really hinder the desired commit? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: mfd: dm355evm_msp: Refactoring for add_child() @ 2016-07-01 14:54 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-01 14:54 UTC (permalink / raw) To: Lee Jones; +Cc: LKML, kernel-janitors, Julia Lawall > FYI, code looks fine. Thanks for your acknowledgement. > ... but please take this opportunity to set-up your submission > environment i.e. using `git format-patch` and `git send-email`. Would you like to see any special settings to be mentioned in a section like "15) Explicit In-Reply-To headers" from the document "SubmittingPatches"? > you've done that, please re-submit this patch with my: Does the association of this patch with a bit relevant discussion really hinder the desired commit? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 5/6] mfd: smsc-ece1099: Delete an unnecessary variable initialisation in smsc_i2c_probe() 2016-06-26 13:34 ` SF Markus Elfring @ 2016-06-26 13:51 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-06-26 13:51 UTC (permalink / raw) To: Lee Jones, Tony Lindgren, linux-omap; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 26 Jun 2016 14:14:54 +0200 The 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 <elfring@users.sourceforge.net> --- drivers/mfd/smsc-ece1099.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mfd/smsc-ece1099.c b/drivers/mfd/smsc-ece1099.c index 7f89e89..2aaf89f 100644 --- a/drivers/mfd/smsc-ece1099.c +++ b/drivers/mfd/smsc-ece1099.c @@ -36,7 +36,7 @@ static int smsc_i2c_probe(struct i2c_client *i2c, { struct smsc *smsc; int devid, rev, venid_l, venid_h; - int ret = 0; + int ret; smsc = devm_kzalloc(&i2c->dev, sizeof(struct smsc), GFP_KERNEL); -- 2.9.0 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 5/6] mfd: smsc-ece1099: Delete an unnecessary variable initialisation in smsc_i2c_probe() @ 2016-06-26 13:51 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-06-26 13:51 UTC (permalink / raw) To: Lee Jones, Tony Lindgren, linux-omap; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 26 Jun 2016 14:14:54 +0200 The 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 <elfring@users.sourceforge.net> --- drivers/mfd/smsc-ece1099.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mfd/smsc-ece1099.c b/drivers/mfd/smsc-ece1099.c index 7f89e89..2aaf89f 100644 --- a/drivers/mfd/smsc-ece1099.c +++ b/drivers/mfd/smsc-ece1099.c @@ -36,7 +36,7 @@ static int smsc_i2c_probe(struct i2c_client *i2c, { struct smsc *smsc; int devid, rev, venid_l, venid_h; - int ret = 0; + int ret; smsc = devm_kzalloc(&i2c->dev, sizeof(struct smsc), GFP_KERNEL); -- 2.9.0 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 5/6] mfd: smsc-ece1099: Delete an unnecessary variable initialisation in smsc_i2c_probe() 2016-06-26 13:51 ` SF Markus Elfring (?) @ 2016-06-28 15:07 ` Lee Jones -1 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-06-28 15:07 UTC (permalink / raw) To: SF Markus Elfring Cc: Tony Lindgren, linux-omap, LKML, kernel-janitors, Julia Lawall On Sun, 26 Jun 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 26 Jun 2016 14:14:54 +0200 > > The 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 <elfring@users.sourceforge.net> > --- > drivers/mfd/smsc-ece1099.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied, thanks. > diff --git a/drivers/mfd/smsc-ece1099.c b/drivers/mfd/smsc-ece1099.c > index 7f89e89..2aaf89f 100644 > --- a/drivers/mfd/smsc-ece1099.c > +++ b/drivers/mfd/smsc-ece1099.c > @@ -36,7 +36,7 @@ static int smsc_i2c_probe(struct i2c_client *i2c, > { > struct smsc *smsc; > int devid, rev, venid_l, venid_h; > - int ret = 0; > + int ret; > > smsc = devm_kzalloc(&i2c->dev, sizeof(struct smsc), > GFP_KERNEL); -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 5/6] mfd: smsc-ece1099: Delete an unnecessary variable initialisation in smsc_i2c_probe() @ 2016-06-28 15:07 ` Lee Jones 0 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-06-28 15:07 UTC (permalink / raw) To: SF Markus Elfring Cc: Tony Lindgren, linux-omap, LKML, kernel-janitors, Julia Lawall On Sun, 26 Jun 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 26 Jun 2016 14:14:54 +0200 > > The 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 <elfring@users.sourceforge.net> > --- > drivers/mfd/smsc-ece1099.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied, thanks. > diff --git a/drivers/mfd/smsc-ece1099.c b/drivers/mfd/smsc-ece1099.c > index 7f89e89..2aaf89f 100644 > --- a/drivers/mfd/smsc-ece1099.c > +++ b/drivers/mfd/smsc-ece1099.c > @@ -36,7 +36,7 @@ static int smsc_i2c_probe(struct i2c_client *i2c, > { > struct smsc *smsc; > int devid, rev, venid_l, venid_h; > - int ret = 0; > + int ret; > > smsc = devm_kzalloc(&i2c->dev, sizeof(struct smsc), > GFP_KERNEL); -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 5/6] mfd: smsc-ece1099: Delete an unnecessary variable initialisation in smsc_i2c_probe() @ 2016-06-28 15:07 ` Lee Jones 0 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-06-28 15:07 UTC (permalink / raw) To: SF Markus Elfring Cc: Tony Lindgren, linux-omap, LKML, kernel-janitors, Julia Lawall On Sun, 26 Jun 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 26 Jun 2016 14:14:54 +0200 > > The 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 <elfring@users.sourceforge.net> > --- > drivers/mfd/smsc-ece1099.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied, thanks. > diff --git a/drivers/mfd/smsc-ece1099.c b/drivers/mfd/smsc-ece1099.c > index 7f89e89..2aaf89f 100644 > --- a/drivers/mfd/smsc-ece1099.c > +++ b/drivers/mfd/smsc-ece1099.c > @@ -36,7 +36,7 @@ static int smsc_i2c_probe(struct i2c_client *i2c, > { > struct smsc *smsc; > int devid, rev, venid_l, venid_h; > - int ret = 0; > + int ret; > > smsc = devm_kzalloc(&i2c->dev, sizeof(struct smsc), > GFP_KERNEL); -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 6/6] mfd: smsc-ece1099: Return directly after a function failure in smsc_i2c_probe() 2016-06-26 13:34 ` SF Markus Elfring @ 2016-06-26 13:54 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-06-26 13:54 UTC (permalink / raw) To: Lee Jones, Tony Lindgren, linux-omap; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 26 Jun 2016 14:30:46 +0200 This issue was detected by using the Coccinelle software. Return directly if a call of the function "devm_regmap_init_i2c" or "regmap_write" failed. Delete the jump label "err" then. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/mfd/smsc-ece1099.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/mfd/smsc-ece1099.c b/drivers/mfd/smsc-ece1099.c index 2aaf89f..cd18c09 100644 --- a/drivers/mfd/smsc-ece1099.c +++ b/drivers/mfd/smsc-ece1099.c @@ -46,10 +46,8 @@ static int smsc_i2c_probe(struct i2c_client *i2c, } smsc->regmap = devm_regmap_init_i2c(i2c, &smsc_regmap_config); - if (IS_ERR(smsc->regmap)) { - ret = PTR_ERR(smsc->regmap); - goto err; - } + if (IS_ERR(smsc->regmap)) + return PTR_ERR(smsc->regmap); i2c_set_clientdata(i2c, smsc); smsc->dev = &i2c->dev; @@ -68,7 +66,7 @@ static int smsc_i2c_probe(struct i2c_client *i2c, ret = regmap_write(smsc->regmap, SMSC_CLK_CTRL, smsc->clk); if (ret) - goto err; + return ret; #ifdef CONFIG_OF if (i2c->dev.of_node) @@ -76,7 +74,6 @@ static int smsc_i2c_probe(struct i2c_client *i2c, NULL, NULL, &i2c->dev); #endif -err: return ret; } -- 2.9.0 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 6/6] mfd: smsc-ece1099: Return directly after a function failure in smsc_i2c_probe() @ 2016-06-26 13:54 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-06-26 13:54 UTC (permalink / raw) To: Lee Jones, Tony Lindgren, linux-omap; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 26 Jun 2016 14:30:46 +0200 This issue was detected by using the Coccinelle software. Return directly if a call of the function "devm_regmap_init_i2c" or "regmap_write" failed. Delete the jump label "err" then. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/mfd/smsc-ece1099.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/mfd/smsc-ece1099.c b/drivers/mfd/smsc-ece1099.c index 2aaf89f..cd18c09 100644 --- a/drivers/mfd/smsc-ece1099.c +++ b/drivers/mfd/smsc-ece1099.c @@ -46,10 +46,8 @@ static int smsc_i2c_probe(struct i2c_client *i2c, } smsc->regmap = devm_regmap_init_i2c(i2c, &smsc_regmap_config); - if (IS_ERR(smsc->regmap)) { - ret = PTR_ERR(smsc->regmap); - goto err; - } + if (IS_ERR(smsc->regmap)) + return PTR_ERR(smsc->regmap); i2c_set_clientdata(i2c, smsc); smsc->dev = &i2c->dev; @@ -68,7 +66,7 @@ static int smsc_i2c_probe(struct i2c_client *i2c, ret = regmap_write(smsc->regmap, SMSC_CLK_CTRL, smsc->clk); if (ret) - goto err; + return ret; #ifdef CONFIG_OF if (i2c->dev.of_node) @@ -76,7 +74,6 @@ static int smsc_i2c_probe(struct i2c_client *i2c, NULL, NULL, &i2c->dev); #endif -err: return ret; } -- 2.9.0 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 6/6] mfd: smsc-ece1099: Return directly after a function failure in smsc_i2c_probe() 2016-06-26 13:54 ` SF Markus Elfring @ 2016-06-28 15:08 ` Lee Jones -1 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-06-28 15:08 UTC (permalink / raw) To: SF Markus Elfring Cc: Tony Lindgren, linux-omap, LKML, kernel-janitors, Julia Lawall On Sun, 26 Jun 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 26 Jun 2016 14:30:46 +0200 > > This issue was detected by using the Coccinelle software. > > Return directly if a call of the function "devm_regmap_init_i2c" > or "regmap_write" failed. > > Delete the jump label "err" then. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/mfd/smsc-ece1099.c | 9 +++------ > 1 file changed, 3 insertions(+), 6 deletions(-) Applied, thanks. > diff --git a/drivers/mfd/smsc-ece1099.c b/drivers/mfd/smsc-ece1099.c > index 2aaf89f..cd18c09 100644 > --- a/drivers/mfd/smsc-ece1099.c > +++ b/drivers/mfd/smsc-ece1099.c > @@ -46,10 +46,8 @@ static int smsc_i2c_probe(struct i2c_client *i2c, > } > > smsc->regmap = devm_regmap_init_i2c(i2c, &smsc_regmap_config); > - if (IS_ERR(smsc->regmap)) { > - ret = PTR_ERR(smsc->regmap); > - goto err; > - } > + if (IS_ERR(smsc->regmap)) > + return PTR_ERR(smsc->regmap); > > i2c_set_clientdata(i2c, smsc); > smsc->dev = &i2c->dev; > @@ -68,7 +66,7 @@ static int smsc_i2c_probe(struct i2c_client *i2c, > > ret = regmap_write(smsc->regmap, SMSC_CLK_CTRL, smsc->clk); > if (ret) > - goto err; > + return ret; > > #ifdef CONFIG_OF > if (i2c->dev.of_node) > @@ -76,7 +74,6 @@ static int smsc_i2c_probe(struct i2c_client *i2c, > NULL, NULL, &i2c->dev); > #endif > > -err: > return ret; > } > -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 6/6] mfd: smsc-ece1099: Return directly after a function failure in smsc_i2c_probe() @ 2016-06-28 15:08 ` Lee Jones 0 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-06-28 15:08 UTC (permalink / raw) To: SF Markus Elfring Cc: Tony Lindgren, linux-omap, LKML, kernel-janitors, Julia Lawall On Sun, 26 Jun 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 26 Jun 2016 14:30:46 +0200 > > This issue was detected by using the Coccinelle software. > > Return directly if a call of the function "devm_regmap_init_i2c" > or "regmap_write" failed. > > Delete the jump label "err" then. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/mfd/smsc-ece1099.c | 9 +++------ > 1 file changed, 3 insertions(+), 6 deletions(-) Applied, thanks. > diff --git a/drivers/mfd/smsc-ece1099.c b/drivers/mfd/smsc-ece1099.c > index 2aaf89f..cd18c09 100644 > --- a/drivers/mfd/smsc-ece1099.c > +++ b/drivers/mfd/smsc-ece1099.c > @@ -46,10 +46,8 @@ static int smsc_i2c_probe(struct i2c_client *i2c, > } > > smsc->regmap = devm_regmap_init_i2c(i2c, &smsc_regmap_config); > - if (IS_ERR(smsc->regmap)) { > - ret = PTR_ERR(smsc->regmap); > - goto err; > - } > + if (IS_ERR(smsc->regmap)) > + return PTR_ERR(smsc->regmap); > > i2c_set_clientdata(i2c, smsc); > smsc->dev = &i2c->dev; > @@ -68,7 +66,7 @@ static int smsc_i2c_probe(struct i2c_client *i2c, > > ret = regmap_write(smsc->regmap, SMSC_CLK_CTRL, smsc->clk); > if (ret) > - goto err; > + return ret; > > #ifdef CONFIG_OF > if (i2c->dev.of_node) > @@ -76,7 +74,6 @@ static int smsc_i2c_probe(struct i2c_client *i2c, > NULL, NULL, &i2c->dev); > #endif > > -err: > return ret; > } > -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/6] mfd: Fine-tuning for three function implementations 2016-06-26 13:34 ` SF Markus Elfring (?) @ 2016-06-28 15:01 ` Lee Jones -1 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-06-28 15:01 UTC (permalink / raw) To: SF Markus Elfring Cc: Tony Lindgren, linux-omap, LKML, kernel-janitors, Julia Lawall On Sun, 26 Jun 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 26 Jun 2016 15:25:43 +0200 > > Several update suggestions were taken into account > from static source code analysis. > > Markus Elfring (6): > twl-core: Return directly after a failed platform_device_alloc() > in add_numbered_child() > twl-core: Refactoring for add_numbered_child() > dm355evm_msp: Return directly after a failed platform_device_alloc() > in add_child() > dm355evm_msp: Refactoring for add_child() > smsc-ece1099: Delete an unnecessary variable initialisation > in smsc_i2c_probe() > smsc-ece1099: Return directly after a function failure > in smsc_i2c_probe() > > drivers/mfd/dm355evm_msp.c | 25 ++++++++++++------------- > drivers/mfd/smsc-ece1099.c | 11 ++++------- > drivers/mfd/twl-core.c | 28 +++++++++++++--------------- > 3 files changed, 29 insertions(+), 35 deletions(-) What is this set? A different but related one to the set you tagged it on to? Probably best not to do that. I now have a huge entangled thread in my inbox, which is going to become out of control rather quickly (if it isn't already). -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/6] mfd: Fine-tuning for three function implementations @ 2016-06-28 15:01 ` Lee Jones 0 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-06-28 15:01 UTC (permalink / raw) To: SF Markus Elfring Cc: Tony Lindgren, linux-omap, LKML, kernel-janitors, Julia Lawall On Sun, 26 Jun 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 26 Jun 2016 15:25:43 +0200 > > Several update suggestions were taken into account > from static source code analysis. > > Markus Elfring (6): > twl-core: Return directly after a failed platform_device_alloc() > in add_numbered_child() > twl-core: Refactoring for add_numbered_child() > dm355evm_msp: Return directly after a failed platform_device_alloc() > in add_child() > dm355evm_msp: Refactoring for add_child() > smsc-ece1099: Delete an unnecessary variable initialisation > in smsc_i2c_probe() > smsc-ece1099: Return directly after a function failure > in smsc_i2c_probe() > > drivers/mfd/dm355evm_msp.c | 25 ++++++++++++------------- > drivers/mfd/smsc-ece1099.c | 11 ++++------- > drivers/mfd/twl-core.c | 28 +++++++++++++--------------- > 3 files changed, 29 insertions(+), 35 deletions(-) What is this set? A different but related one to the set you tagged it on to? Probably best not to do that. I now have a huge entangled thread in my inbox, which is going to become out of control rather quickly (if it isn't already). -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/6] mfd: Fine-tuning for three function implementations @ 2016-06-28 15:01 ` Lee Jones 0 siblings, 0 replies; 3089+ messages in thread From: Lee Jones @ 2016-06-28 15:01 UTC (permalink / raw) To: SF Markus Elfring Cc: Tony Lindgren, linux-omap, LKML, kernel-janitors, Julia Lawall On Sun, 26 Jun 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 26 Jun 2016 15:25:43 +0200 > > Several update suggestions were taken into account > from static source code analysis. > > Markus Elfring (6): > twl-core: Return directly after a failed platform_device_alloc() > in add_numbered_child() > twl-core: Refactoring for add_numbered_child() > dm355evm_msp: Return directly after a failed platform_device_alloc() > in add_child() > dm355evm_msp: Refactoring for add_child() > smsc-ece1099: Delete an unnecessary variable initialisation > in smsc_i2c_probe() > smsc-ece1099: Return directly after a function failure > in smsc_i2c_probe() > > drivers/mfd/dm355evm_msp.c | 25 ++++++++++++------------- > drivers/mfd/smsc-ece1099.c | 11 ++++------- > drivers/mfd/twl-core.c | 28 +++++++++++++--------------- > 3 files changed, 29 insertions(+), 35 deletions(-) What is this set? A different but related one to the set you tagged it on to? Probably best not to do that. I now have a huge entangled thread in my inbox, which is going to become out of control rather quickly (if it isn't already). -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH] mmc-core: One check less in mmc_select_hs200() after error detection 2015-12-11 12:08 ` SF Markus Elfring @ 2015-12-29 19:50 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-29 19:50 UTC (permalink / raw) To: linux-mmc, Ulf Hansson; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 29 Dec 2015 20:28:46 +0100 This issue was detected by using the Coccinelle software. Move the jump label directly before the desired log statement so that the variable "err" will not be checked once more after it was determined that a call of the function "__mmc_set_signal_voltage" or "__mmc_switch" failed. Use the identifier "report_failure" instead of the label "err". Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/mmc/core/mmc.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c index 549c56e..866f72b 100644 --- a/drivers/mmc/core/mmc.c +++ b/drivers/mmc/core/mmc.c @@ -1256,7 +1256,7 @@ static int mmc_select_hs200(struct mmc_card *card) /* If fails try again during next card power cycle */ if (err) - goto err; + goto report_failure; mmc_select_driver_type(card); @@ -1276,7 +1276,7 @@ static int mmc_select_hs200(struct mmc_card *card) card->ext_csd.generic_cmd6_time, true, send_status, true); if (err) - goto err; + goto report_failure; old_timing = host->ios.timing; mmc_set_timing(host, MMC_TIMING_MMC_HS200); if (!send_status) { @@ -1289,10 +1289,11 @@ static int mmc_select_hs200(struct mmc_card *card) mmc_set_timing(host, old_timing); } } -err: - if (err) + if (err) { +report_failure: pr_err("%s: %s failed, error %d\n", mmc_hostname(card->host), __func__, err); + } return err; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH] mmc-core: One check less in mmc_select_hs200() after error detection @ 2015-12-29 19:50 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-29 19:50 UTC (permalink / raw) To: linux-mmc, Ulf Hansson; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 29 Dec 2015 20:28:46 +0100 This issue was detected by using the Coccinelle software. Move the jump label directly before the desired log statement so that the variable "err" will not be checked once more after it was determined that a call of the function "__mmc_set_signal_voltage" or "__mmc_switch" failed. Use the identifier "report_failure" instead of the label "err". Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/mmc/core/mmc.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c index 549c56e..866f72b 100644 --- a/drivers/mmc/core/mmc.c +++ b/drivers/mmc/core/mmc.c @@ -1256,7 +1256,7 @@ static int mmc_select_hs200(struct mmc_card *card) /* If fails try again during next card power cycle */ if (err) - goto err; + goto report_failure; mmc_select_driver_type(card); @@ -1276,7 +1276,7 @@ static int mmc_select_hs200(struct mmc_card *card) card->ext_csd.generic_cmd6_time, true, send_status, true); if (err) - goto err; + goto report_failure; old_timing = host->ios.timing; mmc_set_timing(host, MMC_TIMING_MMC_HS200); if (!send_status) { @@ -1289,10 +1289,11 @@ static int mmc_select_hs200(struct mmc_card *card) mmc_set_timing(host, old_timing); } } -err: - if (err) + if (err) { +report_failure: pr_err("%s: %s failed, error %d\n", mmc_hostname(card->host), __func__, err); + } return err; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH] mmc-core: One check less in mmc_select_hs200() after error detection 2015-12-29 19:50 ` SF Markus Elfring @ 2016-01-12 15:07 ` Ulf Hansson -1 siblings, 0 replies; 3089+ messages in thread From: Ulf Hansson @ 2016-01-12 15:07 UTC (permalink / raw) To: SF Markus Elfring; +Cc: linux-mmc, LKML, kernel-janitors, Julia Lawall On 29 December 2015 at 20:50, SF Markus Elfring <elfring@users.sourceforge.net> wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Tue, 29 Dec 2015 20:28:46 +0100 > > This issue was detected by using the Coccinelle software. > > Move the jump label directly before the desired log statement > so that the variable "err" will not be checked once more > after it was determined that a call of the function > "__mmc_set_signal_voltage" or "__mmc_switch" failed. > Use the identifier "report_failure" instead of the label "err". I understand the report, but this unfortunate not the proper solution. Instead, the "if (err)" check should be entirely removed from the err label. To do that, mmc_select_hs200() should pre validate whether 4 or 8 -bit bus is supported which then prevents starting to switch to hs200 unless really supported. Moreover it means mmc_select_bus_width() shall return 0 to indicate success instead of as now, returning a positive value or 0. Kind regards Uffe > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/mmc/core/mmc.c | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c > index 549c56e..866f72b 100644 > --- a/drivers/mmc/core/mmc.c > +++ b/drivers/mmc/core/mmc.c > @@ -1256,7 +1256,7 @@ static int mmc_select_hs200(struct mmc_card *card) > > /* If fails try again during next card power cycle */ > if (err) > - goto err; > + goto report_failure; > > mmc_select_driver_type(card); > > @@ -1276,7 +1276,7 @@ static int mmc_select_hs200(struct mmc_card *card) > card->ext_csd.generic_cmd6_time, > true, send_status, true); > if (err) > - goto err; > + goto report_failure; > old_timing = host->ios.timing; > mmc_set_timing(host, MMC_TIMING_MMC_HS200); > if (!send_status) { > @@ -1289,10 +1289,11 @@ static int mmc_select_hs200(struct mmc_card *card) > mmc_set_timing(host, old_timing); > } > } > -err: > - if (err) > + if (err) { > +report_failure: > pr_err("%s: %s failed, error %d\n", mmc_hostname(card->host), > __func__, err); > + } > return err; > } > > -- > 2.6.3 > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] mmc-core: One check less in mmc_select_hs200() after error detection @ 2016-01-12 15:07 ` Ulf Hansson 0 siblings, 0 replies; 3089+ messages in thread From: Ulf Hansson @ 2016-01-12 15:07 UTC (permalink / raw) To: SF Markus Elfring; +Cc: linux-mmc, LKML, kernel-janitors, Julia Lawall On 29 December 2015 at 20:50, SF Markus Elfring <elfring@users.sourceforge.net> wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Tue, 29 Dec 2015 20:28:46 +0100 > > This issue was detected by using the Coccinelle software. > > Move the jump label directly before the desired log statement > so that the variable "err" will not be checked once more > after it was determined that a call of the function > "__mmc_set_signal_voltage" or "__mmc_switch" failed. > Use the identifier "report_failure" instead of the label "err". I understand the report, but this unfortunate not the proper solution. Instead, the "if (err)" check should be entirely removed from the err label. To do that, mmc_select_hs200() should pre validate whether 4 or 8 -bit bus is supported which then prevents starting to switch to hs200 unless really supported. Moreover it means mmc_select_bus_width() shall return 0 to indicate success instead of as now, returning a positive value or 0. Kind regards Uffe > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/mmc/core/mmc.c | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c > index 549c56e..866f72b 100644 > --- a/drivers/mmc/core/mmc.c > +++ b/drivers/mmc/core/mmc.c > @@ -1256,7 +1256,7 @@ static int mmc_select_hs200(struct mmc_card *card) > > /* If fails try again during next card power cycle */ > if (err) > - goto err; > + goto report_failure; > > mmc_select_driver_type(card); > > @@ -1276,7 +1276,7 @@ static int mmc_select_hs200(struct mmc_card *card) > card->ext_csd.generic_cmd6_time, > true, send_status, true); > if (err) > - goto err; > + goto report_failure; > old_timing = host->ios.timing; > mmc_set_timing(host, MMC_TIMING_MMC_HS200); > if (!send_status) { > @@ -1289,10 +1289,11 @@ static int mmc_select_hs200(struct mmc_card *card) > mmc_set_timing(host, old_timing); > } > } > -err: > - if (err) > + if (err) { > +report_failure: > pr_err("%s: %s failed, error %d\n", mmc_hostname(card->host), > __func__, err); > + } > return err; > } > > -- > 2.6.3 > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/2] mmc-host: Fine-tuning for one function 2015-12-11 12:08 ` SF Markus Elfring @ 2015-12-29 20:57 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-29 20:57 UTC (permalink / raw) To: linux-mmc, Sascha Sommer, Ulf Hansson; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 29 Dec 2015 21:54:14 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete unnecessary variable initialisations in sdricoh_init_mmc() Less checks in sdricoh_init_mmc() after error detection drivers/mmc/host/sdricoh_cs.c | 26 +++++++++++--------------- 1 file changed, 11 insertions(+), 15 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/2] mmc-host: Fine-tuning for one function @ 2015-12-29 20:57 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-29 20:57 UTC (permalink / raw) To: linux-mmc, Sascha Sommer, Ulf Hansson; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 29 Dec 2015 21:54:14 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete unnecessary variable initialisations in sdricoh_init_mmc() Less checks in sdricoh_init_mmc() after error detection drivers/mmc/host/sdricoh_cs.c | 26 +++++++++++--------------- 1 file changed, 11 insertions(+), 15 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 1/2] mmc-sdricoh_cs: Delete unnecessary variable initialisations in sdricoh_init_mmc() 2015-12-29 20:57 ` SF Markus Elfring @ 2015-12-29 21:00 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-29 21:00 UTC (permalink / raw) To: linux-mmc, Sascha Sommer, Ulf Hansson; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 29 Dec 2015 21:11:45 +0100 These variables will eventually be set to an appropriate value a bit later. * host * iobase * result Thus let us omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/mmc/host/sdricoh_cs.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/mmc/host/sdricoh_cs.c b/drivers/mmc/host/sdricoh_cs.c index b7e3057..5e57d9f 100644 --- a/drivers/mmc/host/sdricoh_cs.c +++ b/drivers/mmc/host/sdricoh_cs.c @@ -398,10 +398,10 @@ static struct mmc_host_ops sdricoh_ops = { static int sdricoh_init_mmc(struct pci_dev *pci_dev, struct pcmcia_device *pcmcia_dev) { - int result = 0; - void __iomem *iobase = NULL; + int result; + void __iomem *iobase; struct mmc_host *mmc = NULL; - struct sdricoh_host *host = NULL; + struct sdricoh_host *host; struct device *dev = &pcmcia_dev->dev; /* map iomem */ if (pci_resource_len(pci_dev, SDRICOH_PCI_REGION) != -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 1/2] mmc-sdricoh_cs: Delete unnecessary variable initialisations in sdricoh_init_mmc() @ 2015-12-29 21:00 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-29 21:00 UTC (permalink / raw) To: linux-mmc, Sascha Sommer, Ulf Hansson; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 29 Dec 2015 21:11:45 +0100 These variables will eventually be set to an appropriate value a bit later. * host * iobase * result Thus let us omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/mmc/host/sdricoh_cs.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/mmc/host/sdricoh_cs.c b/drivers/mmc/host/sdricoh_cs.c index b7e3057..5e57d9f 100644 --- a/drivers/mmc/host/sdricoh_cs.c +++ b/drivers/mmc/host/sdricoh_cs.c @@ -398,10 +398,10 @@ static struct mmc_host_ops sdricoh_ops = { static int sdricoh_init_mmc(struct pci_dev *pci_dev, struct pcmcia_device *pcmcia_dev) { - int result = 0; - void __iomem *iobase = NULL; + int result; + void __iomem *iobase; struct mmc_host *mmc = NULL; - struct sdricoh_host *host = NULL; + struct sdricoh_host *host; struct device *dev = &pcmcia_dev->dev; /* map iomem */ if (pci_resource_len(pci_dev, SDRICOH_PCI_REGION) !-- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/2] mmc-sdricoh_cs: Delete unnecessary variable initialisations in sdricoh_init_mmc() 2015-12-29 21:00 ` SF Markus Elfring @ 2016-02-21 9:11 ` Sascha Sommer -1 siblings, 0 replies; 3089+ messages in thread From: Sascha Sommer @ 2016-02-21 9:11 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-mmc, Ulf Hansson, LKML, kernel-janitors, Julia Lawall Hello, Am Tue, 29 Dec 2015 22:00:35 +0100 schrieb SF Markus Elfring <elfring@users.sourceforge.net>: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Tue, 29 Dec 2015 21:11:45 +0100 > > These variables will eventually be set to an appropriate value a bit > later. > * host > * iobase > * result > > Thus let us omit the explicit initialisation at the beginning. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Acked-by: Sascha Sommer <saschasommer@freenet.de> Best regards Sascha ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/2] mmc-sdricoh_cs: Delete unnecessary variable initialisations in sdricoh_init_mmc() @ 2016-02-21 9:11 ` Sascha Sommer 0 siblings, 0 replies; 3089+ messages in thread From: Sascha Sommer @ 2016-02-21 9:11 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-mmc, Ulf Hansson, LKML, kernel-janitors, Julia Lawall Hello, Am Tue, 29 Dec 2015 22:00:35 +0100 schrieb SF Markus Elfring <elfring@users.sourceforge.net>: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Tue, 29 Dec 2015 21:11:45 +0100 > > These variables will eventually be set to an appropriate value a bit > later. > * host > * iobase > * result > > Thus let us omit the explicit initialisation at the beginning. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Acked-by: Sascha Sommer <saschasommer@freenet.de> Best regards Sascha ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 2/2] mmc-sdricoh_cs: Less checks in sdricoh_init_mmc() after, error detection 2015-12-29 20:57 ` SF Markus Elfring @ 2015-12-29 21:02 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-29 21:02 UTC (permalink / raw) To: linux-mmc, Sascha Sommer, Ulf Hansson; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 29 Dec 2015 21:45:34 +0100 This issue was detected by using the Coccinelle software. Two pointer checks could be repeated by the sdricoh_init_mmc() function during error handling even if the relevant properties can be determined for the involved variables before by source code analysis. * This implementation detail could be improved by adjustments for jump targets according to the Linux coding style convention. * Drop an unnecessary initialisation for the variable "mmc" then. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/mmc/host/sdricoh_cs.c | 20 ++++++++------------ 1 file changed, 8 insertions(+), 12 deletions(-) diff --git a/drivers/mmc/host/sdricoh_cs.c b/drivers/mmc/host/sdricoh_cs.c index 5e57d9f..5ff26ab 100644 --- a/drivers/mmc/host/sdricoh_cs.c +++ b/drivers/mmc/host/sdricoh_cs.c @@ -400,7 +400,7 @@ static int sdricoh_init_mmc(struct pci_dev *pci_dev, { int result; void __iomem *iobase; - struct mmc_host *mmc = NULL; + struct mmc_host *mmc; struct sdricoh_host *host; struct device *dev = &pcmcia_dev->dev; /* map iomem */ @@ -419,7 +419,7 @@ static int sdricoh_init_mmc(struct pci_dev *pci_dev, if (readl(iobase + R104_VERSION) != 0x4000) { dev_dbg(dev, "no supported mmc controller found\n"); result = -ENODEV; - goto err; + goto unmap_io; } /* allocate privdata */ mmc = pcmcia_dev->priv = @@ -427,7 +427,7 @@ static int sdricoh_init_mmc(struct pci_dev *pci_dev, if (!mmc) { dev_err(dev, "mmc_alloc_host failed\n"); result = -ENOMEM; - goto err; + goto unmap_io; } host = mmc_priv(mmc); @@ -451,8 +451,7 @@ static int sdricoh_init_mmc(struct pci_dev *pci_dev, if (sdricoh_reset(host)) { dev_dbg(dev, "could not reset\n"); result = -EIO; - goto err; - + goto free_host; } result = mmc_add_host(mmc); @@ -461,13 +460,10 @@ static int sdricoh_init_mmc(struct pci_dev *pci_dev, dev_dbg(dev, "mmc host registered\n"); return 0; } - -err: - if (iobase) - pci_iounmap(pci_dev, iobase); - if (mmc) - mmc_free_host(mmc); - +free_host: + mmc_free_host(mmc); +unmap_io: + pci_iounmap(pci_dev, iobase); return result; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 2/2] mmc-sdricoh_cs: Less checks in sdricoh_init_mmc() after, error detection @ 2015-12-29 21:02 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-29 21:02 UTC (permalink / raw) To: linux-mmc, Sascha Sommer, Ulf Hansson; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 29 Dec 2015 21:45:34 +0100 This issue was detected by using the Coccinelle software. Two pointer checks could be repeated by the sdricoh_init_mmc() function during error handling even if the relevant properties can be determined for the involved variables before by source code analysis. * This implementation detail could be improved by adjustments for jump targets according to the Linux coding style convention. * Drop an unnecessary initialisation for the variable "mmc" then. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/mmc/host/sdricoh_cs.c | 20 ++++++++------------ 1 file changed, 8 insertions(+), 12 deletions(-) diff --git a/drivers/mmc/host/sdricoh_cs.c b/drivers/mmc/host/sdricoh_cs.c index 5e57d9f..5ff26ab 100644 --- a/drivers/mmc/host/sdricoh_cs.c +++ b/drivers/mmc/host/sdricoh_cs.c @@ -400,7 +400,7 @@ static int sdricoh_init_mmc(struct pci_dev *pci_dev, { int result; void __iomem *iobase; - struct mmc_host *mmc = NULL; + struct mmc_host *mmc; struct sdricoh_host *host; struct device *dev = &pcmcia_dev->dev; /* map iomem */ @@ -419,7 +419,7 @@ static int sdricoh_init_mmc(struct pci_dev *pci_dev, if (readl(iobase + R104_VERSION) != 0x4000) { dev_dbg(dev, "no supported mmc controller found\n"); result = -ENODEV; - goto err; + goto unmap_io; } /* allocate privdata */ mmc = pcmcia_dev->priv @@ -427,7 +427,7 @@ static int sdricoh_init_mmc(struct pci_dev *pci_dev, if (!mmc) { dev_err(dev, "mmc_alloc_host failed\n"); result = -ENOMEM; - goto err; + goto unmap_io; } host = mmc_priv(mmc); @@ -451,8 +451,7 @@ static int sdricoh_init_mmc(struct pci_dev *pci_dev, if (sdricoh_reset(host)) { dev_dbg(dev, "could not reset\n"); result = -EIO; - goto err; - + goto free_host; } result = mmc_add_host(mmc); @@ -461,13 +460,10 @@ static int sdricoh_init_mmc(struct pci_dev *pci_dev, dev_dbg(dev, "mmc host registered\n"); return 0; } - -err: - if (iobase) - pci_iounmap(pci_dev, iobase); - if (mmc) - mmc_free_host(mmc); - +free_host: + mmc_free_host(mmc); +unmap_io: + pci_iounmap(pci_dev, iobase); return result; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] mmc-sdricoh_cs: Less checks in sdricoh_init_mmc() after, error detection 2015-12-29 21:02 ` SF Markus Elfring @ 2016-02-21 9:15 ` Sascha Sommer -1 siblings, 0 replies; 3089+ messages in thread From: Sascha Sommer @ 2016-02-21 9:15 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-mmc, Ulf Hansson, LKML, kernel-janitors, Julia Lawall Hello, Am Tue, 29 Dec 2015 22:02:37 +0100 schrieb SF Markus Elfring <elfring@users.sourceforge.net>: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Tue, 29 Dec 2015 21:45:34 +0100 > > This issue was detected by using the Coccinelle software. > > Two pointer checks could be repeated by the sdricoh_init_mmc() > function during error handling even if the relevant properties can be > determined for the involved variables before by source code analysis. > > * This implementation detail could be improved by adjustments > for jump targets according to the Linux coding style convention. > > * Drop an unnecessary initialisation for the variable "mmc" then. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- Acked-by: Sascha Sommer <saschasommer@freenet.de> Best regards Sascha ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] mmc-sdricoh_cs: Less checks in sdricoh_init_mmc() after, error detection @ 2016-02-21 9:15 ` Sascha Sommer 0 siblings, 0 replies; 3089+ messages in thread From: Sascha Sommer @ 2016-02-21 9:15 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-mmc, Ulf Hansson, LKML, kernel-janitors, Julia Lawall Hello, Am Tue, 29 Dec 2015 22:02:37 +0100 schrieb SF Markus Elfring <elfring@users.sourceforge.net>: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Tue, 29 Dec 2015 21:45:34 +0100 > > This issue was detected by using the Coccinelle software. > > Two pointer checks could be repeated by the sdricoh_init_mmc() > function during error handling even if the relevant properties can be > determined for the involved variables before by source code analysis. > > * This implementation detail could be improved by adjustments > for jump targets according to the Linux coding style convention. > > * Drop an unnecessary initialisation for the variable "mmc" then. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- Acked-by: Sascha Sommer <saschasommer@freenet.de> Best regards Sascha ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/2] mmc-host: Fine-tuning for one function 2015-12-29 20:57 ` SF Markus Elfring @ 2016-01-27 14:15 ` Ulf Hansson -1 siblings, 0 replies; 3089+ messages in thread From: Ulf Hansson @ 2016-01-27 14:15 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-mmc, Sascha Sommer, LKML, kernel-janitors, Julia Lawall On 29 December 2015 at 21:57, SF Markus Elfring <elfring@users.sourceforge.net> wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Tue, 29 Dec 2015 21:54:14 +0100 > > A few update suggestions were taken into account > from static source code analysis. > > Markus Elfring (2): > Delete unnecessary variable initialisations in sdricoh_init_mmc() > Less checks in sdricoh_init_mmc() after error detection > > drivers/mmc/host/sdricoh_cs.c | 26 +++++++++++--------------- > 1 file changed, 11 insertions(+), 15 deletions(-) > > -- > 2.6.3 > Thanks, applied for next - with some minor change to the prefix of the commit message header. Kind regards Uffe ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/2] mmc-host: Fine-tuning for one function @ 2016-01-27 14:15 ` Ulf Hansson 0 siblings, 0 replies; 3089+ messages in thread From: Ulf Hansson @ 2016-01-27 14:15 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-mmc, Sascha Sommer, LKML, kernel-janitors, Julia Lawall On 29 December 2015 at 21:57, SF Markus Elfring <elfring@users.sourceforge.net> wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Tue, 29 Dec 2015 21:54:14 +0100 > > A few update suggestions were taken into account > from static source code analysis. > > Markus Elfring (2): > Delete unnecessary variable initialisations in sdricoh_init_mmc() > Less checks in sdricoh_init_mmc() after error detection > > drivers/mmc/host/sdricoh_cs.c | 26 +++++++++++--------------- > 1 file changed, 11 insertions(+), 15 deletions(-) > > -- > 2.6.3 > Thanks, applied for next - with some minor change to the prefix of the commit message header. Kind regards Uffe ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/3] mtd-rfd_ftl: Fine-tuning for two function implementations 2015-12-11 12:08 ` SF Markus Elfring @ 2015-12-31 20:21 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-31 20:21 UTC (permalink / raw) To: linux-mtd, Brian Norris, David Woodhouse Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Thu, 31 Dec 2015 21:15:15 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (3): Replace a variable initialisation by assignments Refactoring for move_block_contents() Refactoring for erase_block() drivers/mtd/rfd_ftl.c | 38 +++++++++++++++++--------------------- 1 file changed, 17 insertions(+), 21 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/3] mtd-rfd_ftl: Fine-tuning for two function implementations @ 2015-12-31 20:21 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-31 20:21 UTC (permalink / raw) To: linux-mtd, Brian Norris, David Woodhouse Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Thu, 31 Dec 2015 21:15:15 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (3): Replace a variable initialisation by assignments Refactoring for move_block_contents() Refactoring for erase_block() drivers/mtd/rfd_ftl.c | 38 +++++++++++++++++--------------------- 1 file changed, 17 insertions(+), 21 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 1/3] mtd-rfd_ftl: Replace a variable initialisation by assignments in move_block_contents() 2015-12-31 20:21 ` SF Markus Elfring @ 2015-12-31 20:25 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-31 20:25 UTC (permalink / raw) To: linux-mtd, Brian Norris, David Woodhouse Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Thu, 31 Dec 2015 20:34:51 +0100 Replace an explicit initialisation for the variable "rc" at the beginning by assignments that will only be performed if a memory allocation failed. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/mtd/rfd_ftl.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/rfd_ftl.c b/drivers/mtd/rfd_ftl.c index d1cbf26..2927e1b 100644 --- a/drivers/mtd/rfd_ftl.c +++ b/drivers/mtd/rfd_ftl.c @@ -359,17 +359,21 @@ static int move_block_contents(struct partition *part, int block_no, u_long *old void *sector_data; u16 *map; size_t retlen; - int i, rc = -ENOMEM; + int i, rc; part->is_reclaiming = 1; sector_data = kmalloc(SECTOR_SIZE, GFP_KERNEL); - if (!sector_data) + if (!sector_data) { + rc = -ENOMEM; goto err3; + } map = kmalloc(part->header_size, GFP_KERNEL); - if (!map) + if (!map) { + rc = -ENOMEM; goto err2; + } rc = mtd_read(part->mbd.mtd, part->blocks[block_no].offset, part->header_size, &retlen, (u_char *)map); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 1/3] mtd-rfd_ftl: Replace a variable initialisation by assignments in move_block_contents() @ 2015-12-31 20:25 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-31 20:25 UTC (permalink / raw) To: linux-mtd, Brian Norris, David Woodhouse Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Thu, 31 Dec 2015 20:34:51 +0100 Replace an explicit initialisation for the variable "rc" at the beginning by assignments that will only be performed if a memory allocation failed. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/mtd/rfd_ftl.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/rfd_ftl.c b/drivers/mtd/rfd_ftl.c index d1cbf26..2927e1b 100644 --- a/drivers/mtd/rfd_ftl.c +++ b/drivers/mtd/rfd_ftl.c @@ -359,17 +359,21 @@ static int move_block_contents(struct partition *part, int block_no, u_long *old void *sector_data; u16 *map; size_t retlen; - int i, rc = -ENOMEM; + int i, rc; part->is_reclaiming = 1; sector_data = kmalloc(SECTOR_SIZE, GFP_KERNEL); - if (!sector_data) + if (!sector_data) { + rc = -ENOMEM; goto err3; + } map = kmalloc(part->header_size, GFP_KERNEL); - if (!map) + if (!map) { + rc = -ENOMEM; goto err2; + } rc = mtd_read(part->mbd.mtd, part->blocks[block_no].offset, part->header_size, &retlen, (u_char *)map); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 2/3] mtd-rfd_ftl: Refactoring for move_block_contents() 2015-12-31 20:21 ` SF Markus Elfring @ 2015-12-31 20:26 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-31 20:26 UTC (permalink / raw) To: linux-mtd, Brian Norris, David Woodhouse Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Thu, 31 Dec 2015 20:54:50 +0100 This issue was detected by using the Coccinelle software. Rename jump labels according to the current Linux coding style convention. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/mtd/rfd_ftl.c | 22 ++++++++-------------- 1 file changed, 8 insertions(+), 14 deletions(-) diff --git a/drivers/mtd/rfd_ftl.c b/drivers/mtd/rfd_ftl.c index 2927e1b..9b59423 100644 --- a/drivers/mtd/rfd_ftl.c +++ b/drivers/mtd/rfd_ftl.c @@ -366,13 +366,13 @@ static int move_block_contents(struct partition *part, int block_no, u_long *old sector_data = kmalloc(SECTOR_SIZE, GFP_KERNEL); if (!sector_data) { rc = -ENOMEM; - goto err3; + goto reset_reclaim; } map = kmalloc(part->header_size, GFP_KERNEL); if (!map) { rc = -ENOMEM; - goto err2; + goto free_sector; } rc = mtd_read(part->mbd.mtd, part->blocks[block_no].offset, @@ -385,8 +385,7 @@ static int move_block_contents(struct partition *part, int block_no, u_long *old printk(KERN_ERR PREFIX "error reading '%s' at " "0x%lx\n", part->mbd.mtd->name, part->blocks[block_no].offset); - - goto err; + goto free_map; } for (i=0; i<part->data_sectors_per_block; i++) { @@ -417,7 +416,6 @@ static int move_block_contents(struct partition *part, int block_no, u_long *old } rc = mtd_read(part->mbd.mtd, addr, SECTOR_SIZE, &retlen, sector_data); - if (!rc && retlen != SECTOR_SIZE) rc = -EIO; @@ -425,24 +423,20 @@ static int move_block_contents(struct partition *part, int block_no, u_long *old printk(KERN_ERR PREFIX "'%s': Unable to " "read sector for relocation\n", part->mbd.mtd->name); - - goto err; + goto free_map; } rc = rfd_ftl_writesect((struct mtd_blktrans_dev*)part, entry, sector_data); - if (rc) - goto err; + goto free_map; } - -err: +free_map: kfree(map); -err2: +free_sector: kfree(sector_data); -err3: +reset_reclaim: part->is_reclaiming = 0; - return rc; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 2/3] mtd-rfd_ftl: Refactoring for move_block_contents() @ 2015-12-31 20:26 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-31 20:26 UTC (permalink / raw) To: linux-mtd, Brian Norris, David Woodhouse Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Thu, 31 Dec 2015 20:54:50 +0100 This issue was detected by using the Coccinelle software. Rename jump labels according to the current Linux coding style convention. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/mtd/rfd_ftl.c | 22 ++++++++-------------- 1 file changed, 8 insertions(+), 14 deletions(-) diff --git a/drivers/mtd/rfd_ftl.c b/drivers/mtd/rfd_ftl.c index 2927e1b..9b59423 100644 --- a/drivers/mtd/rfd_ftl.c +++ b/drivers/mtd/rfd_ftl.c @@ -366,13 +366,13 @@ static int move_block_contents(struct partition *part, int block_no, u_long *old sector_data = kmalloc(SECTOR_SIZE, GFP_KERNEL); if (!sector_data) { rc = -ENOMEM; - goto err3; + goto reset_reclaim; } map = kmalloc(part->header_size, GFP_KERNEL); if (!map) { rc = -ENOMEM; - goto err2; + goto free_sector; } rc = mtd_read(part->mbd.mtd, part->blocks[block_no].offset, @@ -385,8 +385,7 @@ static int move_block_contents(struct partition *part, int block_no, u_long *old printk(KERN_ERR PREFIX "error reading '%s' at " "0x%lx\n", part->mbd.mtd->name, part->blocks[block_no].offset); - - goto err; + goto free_map; } for (i=0; i<part->data_sectors_per_block; i++) { @@ -417,7 +416,6 @@ static int move_block_contents(struct partition *part, int block_no, u_long *old } rc = mtd_read(part->mbd.mtd, addr, SECTOR_SIZE, &retlen, sector_data); - if (!rc && retlen != SECTOR_SIZE) rc = -EIO; @@ -425,24 +423,20 @@ static int move_block_contents(struct partition *part, int block_no, u_long *old printk(KERN_ERR PREFIX "'%s': Unable to " "read sector for relocation\n", part->mbd.mtd->name); - - goto err; + goto free_map; } rc = rfd_ftl_writesect((struct mtd_blktrans_dev*)part, entry, sector_data); - if (rc) - goto err; + goto free_map; } - -err: +free_map: kfree(map); -err2: +free_sector: kfree(sector_data); -err3: +reset_reclaim: part->is_reclaiming = 0; - return rc; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 3/3] mtd-rfd_ftl: Refactoring for erase_block() 2015-12-31 20:21 ` SF Markus Elfring @ 2015-12-31 20:27 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-31 20:27 UTC (permalink / raw) To: linux-mtd, Brian Norris, David Woodhouse Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Thu, 31 Dec 2015 21:06:27 +0100 This issue was detected by using the Coccinelle software. * Return directly if a memory allocation failed. * Drop the explicit initialisation for the variable "rc" at the beginning then. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/mtd/rfd_ftl.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/mtd/rfd_ftl.c b/drivers/mtd/rfd_ftl.c index 9b59423..8379447 100644 --- a/drivers/mtd/rfd_ftl.c +++ b/drivers/mtd/rfd_ftl.c @@ -326,11 +326,11 @@ static void erase_callback(struct erase_info *erase) static int erase_block(struct partition *part, int block) { struct erase_info *erase; - int rc = -ENOMEM; + int rc; erase = kmalloc(sizeof(struct erase_info), GFP_KERNEL); if (!erase) - goto err; + return -ENOMEM; erase->mtd = part->mbd.mtd; erase->callback = erase_callback; @@ -349,8 +349,6 @@ static int erase_block(struct partition *part, int block) (unsigned long long)erase->len, part->mbd.mtd->name); kfree(erase); } - -err: return rc; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 3/3] mtd-rfd_ftl: Refactoring for erase_block() @ 2015-12-31 20:27 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-31 20:27 UTC (permalink / raw) To: linux-mtd, Brian Norris, David Woodhouse Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Thu, 31 Dec 2015 21:06:27 +0100 This issue was detected by using the Coccinelle software. * Return directly if a memory allocation failed. * Drop the explicit initialisation for the variable "rc" at the beginning then. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/mtd/rfd_ftl.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/mtd/rfd_ftl.c b/drivers/mtd/rfd_ftl.c index 9b59423..8379447 100644 --- a/drivers/mtd/rfd_ftl.c +++ b/drivers/mtd/rfd_ftl.c @@ -326,11 +326,11 @@ static void erase_callback(struct erase_info *erase) static int erase_block(struct partition *part, int block) { struct erase_info *erase; - int rc = -ENOMEM; + int rc; erase = kmalloc(sizeof(struct erase_info), GFP_KERNEL); if (!erase) - goto err; + return -ENOMEM; erase->mtd = part->mbd.mtd; erase->callback = erase_callback; @@ -349,8 +349,6 @@ static int erase_block(struct partition *part, int block) (unsigned long long)erase->len, part->mbd.mtd->name); kfree(erase); } - -err: return rc; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/3] mtd-rfd_ftl: Fine-tuning for two function implementations 2015-12-31 20:21 ` SF Markus Elfring @ 2016-01-05 0:13 ` Brian Norris -1 siblings, 0 replies; 3089+ messages in thread From: Brian Norris @ 2016-01-05 0:13 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-mtd, David Woodhouse, LKML, kernel-janitors, Julia Lawall On Thu, Dec 31, 2015 at 09:21:14PM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Thu, 31 Dec 2015 21:15:15 +0100 > > A few update suggestions were taken into account > from static source code analysis. Are you fixing anything? Have you tested your work? At the moment, I can't find any value in your patches. Brian ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/3] mtd-rfd_ftl: Fine-tuning for two function implementations @ 2016-01-05 0:13 ` Brian Norris 0 siblings, 0 replies; 3089+ messages in thread From: Brian Norris @ 2016-01-05 0:13 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-mtd, David Woodhouse, LKML, kernel-janitors, Julia Lawall On Thu, Dec 31, 2015 at 09:21:14PM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Thu, 31 Dec 2015 21:15:15 +0100 > > A few update suggestions were taken into account > from static source code analysis. Are you fixing anything? Have you tested your work? At the moment, I can't find any value in your patches. Brian ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH] net-thunder: One check less in nicvf_register_interrupts() after error detection 2015-12-11 12:08 ` SF Markus Elfring (?) (?) @ 2015-12-31 21:47 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-31 21:47 UTC (permalink / raw) To: netdev, linux-arm-kernel, Robert Richter, Sunil Goutham Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Thu, 31 Dec 2015 22:40:39 +0100 Adjust a jump target to eliminate a check before error logging. Use the identifier "report_failure" instead of "err". Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/ethernet/cavium/thunder/nicvf_main.c | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c index c24cb2a..21e1579 100644 --- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c +++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c @@ -922,7 +922,7 @@ static int nicvf_register_interrupts(struct nicvf *nic) ret = request_irq(vector, nicvf_intr_handler, 0, nic->irq_name[irq], nic->napi[irq]); if (ret) - goto err; + goto report_failure; nic->irq_allocated[irq] = true; } @@ -933,7 +933,7 @@ static int nicvf_register_interrupts(struct nicvf *nic) ret = request_irq(vector, nicvf_rbdr_intr_handler, 0, nic->irq_name[irq], nic); if (ret) - goto err; + goto report_failure; nic->irq_allocated[irq] = true; } @@ -944,13 +944,12 @@ static int nicvf_register_interrupts(struct nicvf *nic) ret = request_irq(nic->msix_entries[irq].vector, nicvf_qs_err_intr_handler, 0, nic->irq_name[irq], nic); - if (!ret) + if (!ret) { nic->irq_allocated[irq] = true; - -err: - if (ret) - netdev_err(nic->netdev, "request_irq failed, vector %d\n", irq); - + return 0; + } +report_failure: + netdev_err(nic->netdev, "request_irq failed, vector %d\n", irq); return ret; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH] net-thunder: One check less in nicvf_register_interrupts() after error detection @ 2015-12-31 21:47 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-31 21:47 UTC (permalink / raw) To: linux-arm-kernel From: Markus Elfring <elfring@users.sourceforge.net> Date: Thu, 31 Dec 2015 22:40:39 +0100 Adjust a jump target to eliminate a check before error logging. Use the identifier "report_failure" instead of "err". Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/ethernet/cavium/thunder/nicvf_main.c | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c index c24cb2a..21e1579 100644 --- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c +++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c @@ -922,7 +922,7 @@ static int nicvf_register_interrupts(struct nicvf *nic) ret = request_irq(vector, nicvf_intr_handler, 0, nic->irq_name[irq], nic->napi[irq]); if (ret) - goto err; + goto report_failure; nic->irq_allocated[irq] = true; } @@ -933,7 +933,7 @@ static int nicvf_register_interrupts(struct nicvf *nic) ret = request_irq(vector, nicvf_rbdr_intr_handler, 0, nic->irq_name[irq], nic); if (ret) - goto err; + goto report_failure; nic->irq_allocated[irq] = true; } @@ -944,13 +944,12 @@ static int nicvf_register_interrupts(struct nicvf *nic) ret = request_irq(nic->msix_entries[irq].vector, nicvf_qs_err_intr_handler, 0, nic->irq_name[irq], nic); - if (!ret) + if (!ret) { nic->irq_allocated[irq] = true; - -err: - if (ret) - netdev_err(nic->netdev, "request_irq failed, vector %d\n", irq); - + return 0; + } +report_failure: + netdev_err(nic->netdev, "request_irq failed, vector %d\n", irq); return ret; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH] net-thunder: One check less in nicvf_register_interrupts() after error detection @ 2015-12-31 21:47 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-31 21:47 UTC (permalink / raw) To: linux-arm-kernel From: Markus Elfring <elfring@users.sourceforge.net> Date: Thu, 31 Dec 2015 22:40:39 +0100 Adjust a jump target to eliminate a check before error logging. Use the identifier "report_failure" instead of "err". Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/ethernet/cavium/thunder/nicvf_main.c | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c index c24cb2a..21e1579 100644 --- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c +++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c @@ -922,7 +922,7 @@ static int nicvf_register_interrupts(struct nicvf *nic) ret = request_irq(vector, nicvf_intr_handler, 0, nic->irq_name[irq], nic->napi[irq]); if (ret) - goto err; + goto report_failure; nic->irq_allocated[irq] = true; } @@ -933,7 +933,7 @@ static int nicvf_register_interrupts(struct nicvf *nic) ret = request_irq(vector, nicvf_rbdr_intr_handler, 0, nic->irq_name[irq], nic); if (ret) - goto err; + goto report_failure; nic->irq_allocated[irq] = true; } @@ -944,13 +944,12 @@ static int nicvf_register_interrupts(struct nicvf *nic) ret = request_irq(nic->msix_entries[irq].vector, nicvf_qs_err_intr_handler, 0, nic->irq_name[irq], nic); - if (!ret) + if (!ret) { nic->irq_allocated[irq] = true; - -err: - if (ret) - netdev_err(nic->netdev, "request_irq failed, vector %d\n", irq); - + return 0; + } +report_failure: + netdev_err(nic->netdev, "request_irq failed, vector %d\n", irq); return ret; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH] net-thunder: One check less in nicvf_register_interrupts() after error detection @ 2015-12-31 21:47 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-31 21:47 UTC (permalink / raw) To: netdev, linux-arm-kernel, Robert Richter, Sunil Goutham Cc: Julia Lawall, kernel-janitors, LKML From: Markus Elfring <elfring@users.sourceforge.net> Date: Thu, 31 Dec 2015 22:40:39 +0100 Adjust a jump target to eliminate a check before error logging. Use the identifier "report_failure" instead of "err". Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/ethernet/cavium/thunder/nicvf_main.c | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c index c24cb2a..21e1579 100644 --- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c +++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c @@ -922,7 +922,7 @@ static int nicvf_register_interrupts(struct nicvf *nic) ret = request_irq(vector, nicvf_intr_handler, 0, nic->irq_name[irq], nic->napi[irq]); if (ret) - goto err; + goto report_failure; nic->irq_allocated[irq] = true; } @@ -933,7 +933,7 @@ static int nicvf_register_interrupts(struct nicvf *nic) ret = request_irq(vector, nicvf_rbdr_intr_handler, 0, nic->irq_name[irq], nic); if (ret) - goto err; + goto report_failure; nic->irq_allocated[irq] = true; } @@ -944,13 +944,12 @@ static int nicvf_register_interrupts(struct nicvf *nic) ret = request_irq(nic->msix_entries[irq].vector, nicvf_qs_err_intr_handler, 0, nic->irq_name[irq], nic); - if (!ret) + if (!ret) { nic->irq_allocated[irq] = true; - -err: - if (ret) - netdev_err(nic->netdev, "request_irq failed, vector %d\n", irq); - + return 0; + } +report_failure: + netdev_err(nic->netdev, "request_irq failed, vector %d\n", irq); return ret; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH] net-thunder: One check less in nicvf_register_interrupts() after error detection 2015-12-31 21:47 ` SF Markus Elfring (?) @ 2016-01-07 11:07 ` Robert Richter -1 siblings, 0 replies; 3089+ messages in thread From: Robert Richter @ 2016-01-07 11:07 UTC (permalink / raw) To: SF Markus Elfring Cc: netdev, linux-arm-kernel, Sunil Goutham, LKML, kernel-janitors, Julia Lawall On 31.12.15 22:47:31, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Thu, 31 Dec 2015 22:40:39 +0100 > > Adjust a jump target to eliminate a check before error logging. > Use the identifier "report_failure" instead of "err". I don't see much value in those changes. Using the 'err' label is ok as it is not misleading and common use. And, there is no need to optimize the check since this is not the fast path and will be compiler optimized anyway. So let's keep the code as it is with the flavor of the original author. -Robert > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/net/ethernet/cavium/thunder/nicvf_main.c | 15 +++++++-------- > 1 file changed, 7 insertions(+), 8 deletions(-) > > diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c > index c24cb2a..21e1579 100644 > --- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c > +++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c > @@ -922,7 +922,7 @@ static int nicvf_register_interrupts(struct nicvf *nic) > ret = request_irq(vector, nicvf_intr_handler, > 0, nic->irq_name[irq], nic->napi[irq]); > if (ret) > - goto err; > + goto report_failure; > nic->irq_allocated[irq] = true; > } > > @@ -933,7 +933,7 @@ static int nicvf_register_interrupts(struct nicvf *nic) > ret = request_irq(vector, nicvf_rbdr_intr_handler, > 0, nic->irq_name[irq], nic); > if (ret) > - goto err; > + goto report_failure; > nic->irq_allocated[irq] = true; > } > > @@ -944,13 +944,12 @@ static int nicvf_register_interrupts(struct nicvf *nic) > ret = request_irq(nic->msix_entries[irq].vector, > nicvf_qs_err_intr_handler, > 0, nic->irq_name[irq], nic); > - if (!ret) > + if (!ret) { > nic->irq_allocated[irq] = true; > - > -err: > - if (ret) > - netdev_err(nic->netdev, "request_irq failed, vector %d\n", irq); > - > + return 0; > + } > +report_failure: > + netdev_err(nic->netdev, "request_irq failed, vector %d\n", irq); > return ret; > } ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH] net-thunder: One check less in nicvf_register_interrupts() after error detection @ 2016-01-07 11:07 ` Robert Richter 0 siblings, 0 replies; 3089+ messages in thread From: Robert Richter @ 2016-01-07 11:07 UTC (permalink / raw) To: linux-arm-kernel On 31.12.15 22:47:31, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Thu, 31 Dec 2015 22:40:39 +0100 > > Adjust a jump target to eliminate a check before error logging. > Use the identifier "report_failure" instead of "err". I don't see much value in those changes. Using the 'err' label is ok as it is not misleading and common use. And, there is no need to optimize the check since this is not the fast path and will be compiler optimized anyway. So let's keep the code as it is with the flavor of the original author. -Robert > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/net/ethernet/cavium/thunder/nicvf_main.c | 15 +++++++-------- > 1 file changed, 7 insertions(+), 8 deletions(-) > > diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c > index c24cb2a..21e1579 100644 > --- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c > +++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c > @@ -922,7 +922,7 @@ static int nicvf_register_interrupts(struct nicvf *nic) > ret = request_irq(vector, nicvf_intr_handler, > 0, nic->irq_name[irq], nic->napi[irq]); > if (ret) > - goto err; > + goto report_failure; > nic->irq_allocated[irq] = true; > } > > @@ -933,7 +933,7 @@ static int nicvf_register_interrupts(struct nicvf *nic) > ret = request_irq(vector, nicvf_rbdr_intr_handler, > 0, nic->irq_name[irq], nic); > if (ret) > - goto err; > + goto report_failure; > nic->irq_allocated[irq] = true; > } > > @@ -944,13 +944,12 @@ static int nicvf_register_interrupts(struct nicvf *nic) > ret = request_irq(nic->msix_entries[irq].vector, > nicvf_qs_err_intr_handler, > 0, nic->irq_name[irq], nic); > - if (!ret) > + if (!ret) { > nic->irq_allocated[irq] = true; > - > -err: > - if (ret) > - netdev_err(nic->netdev, "request_irq failed, vector %d\n", irq); > - > + return 0; > + } > +report_failure: > + netdev_err(nic->netdev, "request_irq failed, vector %d\n", irq); > return ret; > } ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] net-thunder: One check less in nicvf_register_interrupts() after error detection @ 2016-01-07 11:07 ` Robert Richter 0 siblings, 0 replies; 3089+ messages in thread From: Robert Richter @ 2016-01-07 11:07 UTC (permalink / raw) To: linux-arm-kernel On 31.12.15 22:47:31, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Thu, 31 Dec 2015 22:40:39 +0100 > > Adjust a jump target to eliminate a check before error logging. > Use the identifier "report_failure" instead of "err". I don't see much value in those changes. Using the 'err' label is ok as it is not misleading and common use. And, there is no need to optimize the check since this is not the fast path and will be compiler optimized anyway. So let's keep the code as it is with the flavor of the original author. -Robert > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/net/ethernet/cavium/thunder/nicvf_main.c | 15 +++++++-------- > 1 file changed, 7 insertions(+), 8 deletions(-) > > diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c > index c24cb2a..21e1579 100644 > --- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c > +++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c > @@ -922,7 +922,7 @@ static int nicvf_register_interrupts(struct nicvf *nic) > ret = request_irq(vector, nicvf_intr_handler, > 0, nic->irq_name[irq], nic->napi[irq]); > if (ret) > - goto err; > + goto report_failure; > nic->irq_allocated[irq] = true; > } > > @@ -933,7 +933,7 @@ static int nicvf_register_interrupts(struct nicvf *nic) > ret = request_irq(vector, nicvf_rbdr_intr_handler, > 0, nic->irq_name[irq], nic); > if (ret) > - goto err; > + goto report_failure; > nic->irq_allocated[irq] = true; > } > > @@ -944,13 +944,12 @@ static int nicvf_register_interrupts(struct nicvf *nic) > ret = request_irq(nic->msix_entries[irq].vector, > nicvf_qs_err_intr_handler, > 0, nic->irq_name[irq], nic); > - if (!ret) > + if (!ret) { > nic->irq_allocated[irq] = true; > - > -err: > - if (ret) > - netdev_err(nic->netdev, "request_irq failed, vector %d\n", irq); > - > + return 0; > + } > +report_failure: > + netdev_err(nic->netdev, "request_irq failed, vector %d\n", irq); > return ret; > } ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] net-thunder: One check less in nicvf_register_interrupts() after error detection 2016-01-07 11:07 ` Robert Richter (?) @ 2016-01-07 19:30 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-07 19:30 UTC (permalink / raw) To: Robert Richter Cc: netdev, linux-arm-kernel, Sunil Goutham, LKML, kernel-janitors, Julia Lawall >> Adjust a jump target to eliminate a check before error logging. >> Use the identifier "report_failure" instead of "err". > > I don't see much value in those changes. Thanks for your feedback. > Using the 'err' label is ok as it is not misleading and common use. Is such a short jump label enough explanation for the information "what" and "why"? > And, there is no need to optimize the check since this is not the fast path Really? - Is it a bit more efficient to avoid a double check for the variable "ret" at the end of the current implementation for the discussed function? https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/net/ethernet/cavium/thunder/nicvf_main.c?id=40fb5f8a60f33133d36afde35a9ad865d35e4423#n940 > and will be compiler optimized anyway. How sure are you about automatic software optimisations? Can it occasionally help to jump to the really intended source code location directly? >> @@ -944,13 +944,12 @@ static int nicvf_register_interrupts(struct nicvf *nic) >> ret = request_irq(nic->msix_entries[irq].vector, >> nicvf_qs_err_intr_handler, >> 0, nic->irq_name[irq], nic); >> - if (!ret) >> + if (!ret) { >> nic->irq_allocated[irq] = true; >> - >> -err: >> - if (ret) >> - netdev_err(nic->netdev, "request_irq failed, vector %d\n", irq); >> - >> + return 0; >> + } >> +report_failure: >> + netdev_err(nic->netdev, "request_irq failed, vector %d\n", irq); >> return ret; >> } ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH] net-thunder: One check less in nicvf_register_interrupts() after error detection @ 2016-01-07 19:30 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-07 19:30 UTC (permalink / raw) To: linux-arm-kernel >> Adjust a jump target to eliminate a check before error logging. >> Use the identifier "report_failure" instead of "err". > > I don't see much value in those changes. Thanks for your feedback. > Using the 'err' label is ok as it is not misleading and common use. Is such a short jump label enough explanation for the information "what" and "why"? > And, there is no need to optimize the check since this is not the fast path Really? - Is it a bit more efficient to avoid a double check for the variable "ret" at the end of the current implementation for the discussed function? https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/net/ethernet/cavium/thunder/nicvf_main.c?id=40fb5f8a60f33133d36afde35a9ad865d35e4423#n940 > and will be compiler optimized anyway. How sure are you about automatic software optimisations? Can it occasionally help to jump to the really intended source code location directly? >> @@ -944,13 +944,12 @@ static int nicvf_register_interrupts(struct nicvf *nic) >> ret = request_irq(nic->msix_entries[irq].vector, >> nicvf_qs_err_intr_handler, >> 0, nic->irq_name[irq], nic); >> - if (!ret) >> + if (!ret) { >> nic->irq_allocated[irq] = true; >> - >> -err: >> - if (ret) >> - netdev_err(nic->netdev, "request_irq failed, vector %d\n", irq); >> - >> + return 0; >> + } >> +report_failure: >> + netdev_err(nic->netdev, "request_irq failed, vector %d\n", irq); >> return ret; >> } ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] net-thunder: One check less in nicvf_register_interrupts() after error detection @ 2016-01-07 19:30 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-07 19:30 UTC (permalink / raw) To: linux-arm-kernel >> Adjust a jump target to eliminate a check before error logging. >> Use the identifier "report_failure" instead of "err". > > I don't see much value in those changes. Thanks for your feedback. > Using the 'err' label is ok as it is not misleading and common use. Is such a short jump label enough explanation for the information "what" and "why"? > And, there is no need to optimize the check since this is not the fast path Really? - Is it a bit more efficient to avoid a double check for the variable "ret" at the end of the current implementation for the discussed function? https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/net/ethernet/cavium/thunder/nicvf_main.c?id@fb5f8a60f33133d36afde35a9ad865d35e4423#n940 > and will be compiler optimized anyway. How sure are you about automatic software optimisations? Can it occasionally help to jump to the really intended source code location directly? >> @@ -944,13 +944,12 @@ static int nicvf_register_interrupts(struct nicvf *nic) >> ret = request_irq(nic->msix_entries[irq].vector, >> nicvf_qs_err_intr_handler, >> 0, nic->irq_name[irq], nic); >> - if (!ret) >> + if (!ret) { >> nic->irq_allocated[irq] = true; >> - >> -err: >> - if (ret) >> - netdev_err(nic->netdev, "request_irq failed, vector %d\n", irq); >> - >> + return 0; >> + } >> +report_failure: >> + netdev_err(nic->netdev, "request_irq failed, vector %d\n", irq); >> return ret; >> } ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] net-thunder: One check less in nicvf_register_interrupts() after error detection 2016-01-07 19:30 ` SF Markus Elfring (?) @ 2016-01-07 19:44 ` Joe Perches -1 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2016-01-07 19:44 UTC (permalink / raw) To: SF Markus Elfring, Robert Richter Cc: netdev, linux-arm-kernel, Sunil Goutham, LKML, kernel-janitors, Julia Lawall On Thu, 2016-01-07 at 20:30 +0100, SF Markus Elfring wrote: > > > Adjust a jump target to eliminate a check before error logging. > > > Use the identifier "report_failure" instead of "err". > > I don't see much value in those changes > Thanks for your feedback. > > Using the 'err' label is ok as it is not misleading and common use. > Is such a short jump label enough explanation for the information > "what" and "why"? When there is only one type of error possible, yes. > > And, there is no need to optimize the check since this is not the > > fast path > Really? - Is it a bit more efficient to avoid a double check for the > variable "ret" at the end of the current implementation for the > discussed function? Before asking questions you could answer yourself, please look at object code produced by the compiler before and after your proposed changes. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH] net-thunder: One check less in nicvf_register_interrupts() after error detection @ 2016-01-07 19:44 ` Joe Perches 0 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2016-01-07 19:44 UTC (permalink / raw) To: linux-arm-kernel On Thu, 2016-01-07 at 20:30 +0100, SF Markus Elfring wrote: > > > Adjust a jump target to eliminate a check before error logging. > > > Use the identifier "report_failure" instead of "err". > > I don't see much value in those changes > Thanks for your feedback. > > Using the 'err' label is ok as it is not misleading and common use. > Is such a short jump label enough explanation for the information > "what" and "why"? When there is only one type of error possible, yes. > > And, there is no need to optimize the check since this is not the > > fast path > Really? - Is it a bit more efficient to avoid a double check for the > variable "ret" at the end of the current implementation for the > discussed function? Before asking questions you could answer yourself, please look at object code produced by the compiler before and after your proposed changes. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] net-thunder: One check less in nicvf_register_interrupts() after error detection @ 2016-01-07 19:44 ` Joe Perches 0 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2016-01-07 19:44 UTC (permalink / raw) To: linux-arm-kernel On Thu, 2016-01-07 at 20:30 +0100, SF Markus Elfring wrote: > > > Adjust a jump target to eliminate a check before error logging. > > > Use the identifier "report_failure" instead of "err". > > I don't see much value in those changes > Thanks for your feedback. > > Using the 'err' label is ok as it is not misleading and common use. > Is such a short jump label enough explanation for the information > "what" and "why"? When there is only one type of error possible, yes. > > And, there is no need to optimize the check since this is not the > > fast path > Really? - Is it a bit more efficient to avoid a double check for the > variable "ret" at the end of the current implementation for the > discussed function? Before asking questions you could answer yourself, please look at object code produced by the compiler before and after your proposed changes. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: net-thunder: One check less in nicvf_register_interrupts() after error detection 2016-01-07 19:44 ` Joe Perches (?) @ 2016-01-07 19:56 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-07 19:56 UTC (permalink / raw) To: Joe Perches Cc: Robert Richter, netdev, linux-arm-kernel, Sunil Goutham, LKML, kernel-janitors, Julia Lawall >> Is it a bit more efficient to avoid a double check for the >> variable "ret" at the end of the current implementation for the >> discussed function? > > Before asking questions you could answer yourself, > please look at object code produced by the compiler > before and after your proposed changes. * Do any more source code reviewers wonder about the need for such a double check? * Which object code representations would you find representative for a further constructive discussion around this software component? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* net-thunder: One check less in nicvf_register_interrupts() after error detection @ 2016-01-07 19:56 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-07 19:56 UTC (permalink / raw) To: linux-arm-kernel >> Is it a bit more efficient to avoid a double check for the >> variable "ret" at the end of the current implementation for the >> discussed function? > > Before asking questions you could answer yourself, > please look at object code produced by the compiler > before and after your proposed changes. * Do any more source code reviewers wonder about the need for such a double check? * Which object code representations would you find representative for a further constructive discussion around this software component? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: net-thunder: One check less in nicvf_register_interrupts() after error detection @ 2016-01-07 19:56 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-07 19:56 UTC (permalink / raw) To: linux-arm-kernel >> Is it a bit more efficient to avoid a double check for the >> variable "ret" at the end of the current implementation for the >> discussed function? > > Before asking questions you could answer yourself, > please look at object code produced by the compiler > before and after your proposed changes. * Do any more source code reviewers wonder about the need for such a double check? * Which object code representations would you find representative for a further constructive discussion around this software component? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: net-thunder: One check less in nicvf_register_interrupts() after error detection 2016-01-07 19:56 ` SF Markus Elfring (?) @ 2016-01-07 19:59 ` Joe Perches -1 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2016-01-07 19:59 UTC (permalink / raw) To: SF Markus Elfring Cc: Robert Richter, netdev, linux-arm-kernel, Sunil Goutham, LKML, kernel-janitors, Julia Lawall On Thu, 2016-01-07 at 20:56 +0100, SF Markus Elfring wrote: > > > Is it a bit more efficient to avoid a double check for the > > > variable "ret" at the end of the current implementation for the > > > discussed function? > > > > Before asking questions you could answer yourself, > > please look at object code produced by the compiler > > before and after your proposed changes. > > * Do any more source code reviewers wonder about the need > for such a double check? Given the feedback you've already received, it seems so. > * Which object code representations would you find representative > for a further constructive discussion around this > software component? Evidence of actual object code improvement when with compiled with optimizations. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* net-thunder: One check less in nicvf_register_interrupts() after error detection @ 2016-01-07 19:59 ` Joe Perches 0 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2016-01-07 19:59 UTC (permalink / raw) To: linux-arm-kernel On Thu, 2016-01-07 at 20:56 +0100, SF Markus Elfring wrote: > > > Is it a bit more efficient to avoid a double check for the > > > variable "ret" at the end of the current implementation for the > > > discussed function? > > > > Before asking questions you could answer yourself, > > please look at object code produced by the compiler > > before and after your proposed changes. > > * Do any more source code reviewers wonder about the need > ? for such a double check? Given the feedback you've already received, it seems so. > * Which object code representations would you find representative > ? for a further constructive discussion around this > ? software component? Evidence of actual object code improvement when with compiled with optimizations. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: net-thunder: One check less in nicvf_register_interrupts() after error detection @ 2016-01-07 19:59 ` Joe Perches 0 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2016-01-07 19:59 UTC (permalink / raw) To: linux-arm-kernel On Thu, 2016-01-07 at 20:56 +0100, SF Markus Elfring wrote: > > > Is it a bit more efficient to avoid a double check for the > > > variable "ret" at the end of the current implementation for the > > > discussed function? > > > > Before asking questions you could answer yourself, > > please look at object code produced by the compiler > > before and after your proposed changes. > > * Do any more source code reviewers wonder about the need > for such a double check? Given the feedback you've already received, it seems so. > * Which object code representations would you find representative > for a further constructive discussion around this > software component? Evidence of actual object code improvement when with compiled with optimizations. -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: net-thunder: One check less in nicvf_register_interrupts() after error detection 2016-01-07 19:59 ` Joe Perches (?) @ 2016-01-07 20:07 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-07 20:07 UTC (permalink / raw) To: Joe Perches Cc: Robert Richter, netdev, linux-arm-kernel, Sunil Goutham, LKML, kernel-janitors, Julia Lawall >> * Which object code representations would you find representative >> for a further constructive discussion around this >> software component? > > Evidence of actual object code improvement How do you think about to provide a function implementation which looks a bit more efficient by default? > when with compiled with optimizations. Which combinations of hardware and software would you recommend for corresponding system checks? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* net-thunder: One check less in nicvf_register_interrupts() after error detection @ 2016-01-07 20:07 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-07 20:07 UTC (permalink / raw) To: linux-arm-kernel >> * Which object code representations would you find representative >> for a further constructive discussion around this >> software component? > > Evidence of actual object code improvement How do you think about to provide a function implementation which looks a bit more efficient by default? > when with compiled with optimizations. Which combinations of hardware and software would you recommend for corresponding system checks? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: net-thunder: One check less in nicvf_register_interrupts() after error detection @ 2016-01-07 20:07 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-07 20:07 UTC (permalink / raw) To: linux-arm-kernel >> * Which object code representations would you find representative >> for a further constructive discussion around this >> software component? > > Evidence of actual object code improvement How do you think about to provide a function implementation which looks a bit more efficient by default? > when with compiled with optimizations. Which combinations of hardware and software would you recommend for corresponding system checks? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: net-thunder: One check less in nicvf_register_interrupts() after error detection 2016-01-07 20:07 ` SF Markus Elfring (?) @ 2016-01-07 20:28 ` Joe Perches -1 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2016-01-07 20:28 UTC (permalink / raw) To: SF Markus Elfring Cc: Robert Richter, netdev, linux-arm-kernel, Sunil Goutham, LKML, kernel-janitors, Julia Lawall On Thu, 2016-01-07 at 21:07 +0100, SF Markus Elfring wrote: > > > * Which object code representations would you find representative > > > for a further constructive discussion around this > > > software component? > > > > Evidence of actual object code improvement > > How do you think about to provide a function implementation > which looks a bit more efficient by default? It's not a matter of "looks a bit more efficient". it's taste, style, and repetition for various functions. Some prefer that source code be "templatized" regardless of the number of exit points that any particular use of a specific function type. Some of your patches are converting these templatized functions to a different form for no added value. These patches make the local source code inconsistent and generally goes against the authors preferred style. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* net-thunder: One check less in nicvf_register_interrupts() after error detection @ 2016-01-07 20:28 ` Joe Perches 0 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2016-01-07 20:28 UTC (permalink / raw) To: linux-arm-kernel On Thu, 2016-01-07 at 21:07 +0100, SF Markus Elfring wrote: > > > * Which object code representations would you find representative > > > ? for a further constructive discussion around this > > > ? software component? > > > > Evidence of actual object code improvement > > How do you think about to provide a function implementation > which looks a bit more efficient by default? It's not a matter of "looks a bit more efficient". it's taste, style, and repetition for various functions. Some prefer that source code be "templatized" regardless of the number of exit points that any particular use of a specific function type. Some of your patches are converting these templatized functions to a different form for no added value. These patches make the local source code inconsistent and generally goes against the authors preferred style. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: net-thunder: One check less in nicvf_register_interrupts() after error detection @ 2016-01-07 20:28 ` Joe Perches 0 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2016-01-07 20:28 UTC (permalink / raw) To: linux-arm-kernel On Thu, 2016-01-07 at 21:07 +0100, SF Markus Elfring wrote: > > > * Which object code representations would you find representative > > > for a further constructive discussion around this > > > software component? > > > > Evidence of actual object code improvement > > How do you think about to provide a function implementation > which looks a bit more efficient by default? It's not a matter of "looks a bit more efficient". it's taste, style, and repetition for various functions. Some prefer that source code be "templatized" regardless of the number of exit points that any particular use of a specific function type. Some of your patches are converting these templatized functions to a different form for no added value. These patches make the local source code inconsistent and generally goes against the authors preferred style. -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: net-thunder: One check less in nicvf_register_interrupts() after error detection 2016-01-07 20:28 ` Joe Perches (?) @ 2016-01-07 20:38 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-07 20:38 UTC (permalink / raw) To: Joe Perches Cc: Robert Richter, netdev, linux-arm-kernel, Sunil Goutham, LKML, kernel-janitors, Julia Lawall > Some prefer that source code be "templatized" regardless > of the number of exit points that any particular use of a > specific function type. This is another interesting view on involved implementation details. > Some of your patches are converting these templatized > functions to a different form for no added value. Would you like to distinguish a bit more between my evolving collection of update suggestions and the concrete proposal for the function "nicvf_register_interrupts"? > These patches make the local source code inconsistent > and generally goes against the authors preferred style. Which programming approach will be the leading one here finally? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* net-thunder: One check less in nicvf_register_interrupts() after error detection @ 2016-01-07 20:38 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-07 20:38 UTC (permalink / raw) To: linux-arm-kernel > Some prefer that source code be "templatized" regardless > of the number of exit points that any particular use of a > specific function type. This is another interesting view on involved implementation details. > Some of your patches are converting these templatized > functions to a different form for no added value. Would you like to distinguish a bit more between my evolving collection of update suggestions and the concrete proposal for the function "nicvf_register_interrupts"? > These patches make the local source code inconsistent > and generally goes against the authors preferred style. Which programming approach will be the leading one here finally? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: net-thunder: One check less in nicvf_register_interrupts() after error detection @ 2016-01-07 20:38 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-07 20:38 UTC (permalink / raw) To: linux-arm-kernel > Some prefer that source code be "templatized" regardless > of the number of exit points that any particular use of a > specific function type. This is another interesting view on involved implementation details. > Some of your patches are converting these templatized > functions to a different form for no added value. Would you like to distinguish a bit more between my evolving collection of update suggestions and the concrete proposal for the function "nicvf_register_interrupts"? > These patches make the local source code inconsistent > and generally goes against the authors preferred style. Which programming approach will be the leading one here finally? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: net-thunder: One check less in nicvf_register_interrupts() after error detection 2016-01-07 20:38 ` SF Markus Elfring (?) @ 2016-01-07 20:42 ` Joe Perches -1 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2016-01-07 20:42 UTC (permalink / raw) To: SF Markus Elfring Cc: Robert Richter, netdev, linux-arm-kernel, Sunil Goutham, LKML, kernel-janitors, Julia Lawall On Thu, 2016-01-07 at 21:38 +0100, SF Markus Elfring wrote: > > Some prefer that source code be "templatized" regardless > > of the number of exit points that any particular use of a > > specific function type. [] > > Some of your patches are converting these templatized > > functions to a different form for no added value. > > Would you like to distinguish a bit more between my evolving > collection of update suggestions and the concrete proposal > for the function "nicvf_register_interrupts"? No. > > These patches make the local source code inconsistent > > and generally goes against the authors preferred style. > > Which programming approach will be the leading one here finally? Whatever the developer wants. There is no _best_ or _only_ style for this. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* net-thunder: One check less in nicvf_register_interrupts() after error detection @ 2016-01-07 20:42 ` Joe Perches 0 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2016-01-07 20:42 UTC (permalink / raw) To: linux-arm-kernel On Thu, 2016-01-07 at 21:38 +0100, SF Markus Elfring wrote: > > Some prefer that source code be "templatized" regardless > > of the number of exit points that any particular use of a > > specific function type. [] > > Some of your patches are converting these templatized > > functions to a different form for no added value. > > Would you like to distinguish a bit more between my evolving > collection of update suggestions and the concrete proposal > for the function "nicvf_register_interrupts"? No. > > These patches make the local source code inconsistent > > and generally goes against the authors preferred style. > > Which programming approach will be the leading one here finally? Whatever the developer wants. There is no _best_ or _only_ style for this. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: net-thunder: One check less in nicvf_register_interrupts() after error detection @ 2016-01-07 20:42 ` Joe Perches 0 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2016-01-07 20:42 UTC (permalink / raw) To: linux-arm-kernel On Thu, 2016-01-07 at 21:38 +0100, SF Markus Elfring wrote: > > Some prefer that source code be "templatized" regardless > > of the number of exit points that any particular use of a > > specific function type. [] > > Some of your patches are converting these templatized > > functions to a different form for no added value. > > Would you like to distinguish a bit more between my evolving > collection of update suggestions and the concrete proposal > for the function "nicvf_register_interrupts"? No. > > These patches make the local source code inconsistent > > and generally goes against the authors preferred style. > > Which programming approach will be the leading one here finally? Whatever the developer wants. There is no _best_ or _only_ style for this. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH] be2net: Delete an unnecessary check in two functions 2015-12-11 12:08 ` SF Markus Elfring @ 2015-12-31 23:22 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-31 23:22 UTC (permalink / raw) To: netdev, Ajit Khaparde, Padmanabh Ratnakar, Sathya Perla, Sriharsha Basavapatna Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 00:11:57 +0100 Remove two checks for null pointers which would be handled by usual error detection before. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/ethernet/emulex/benet/be_cmds.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c b/drivers/net/ethernet/emulex/benet/be_cmds.c index b63d8ad..ba98297 100644 --- a/drivers/net/ethernet/emulex/benet/be_cmds.c +++ b/drivers/net/ethernet/emulex/benet/be_cmds.c @@ -4366,9 +4366,7 @@ int be_cmd_get_profile_config(struct be_adapter *adapter, if (vf_res) res->vf_if_cap_flags = vf_res->cap_flags; err: - if (cmd.va) - dma_free_coherent(&adapter->pdev->dev, cmd.size, cmd.va, - cmd.dma); + dma_free_coherent(&adapter->pdev->dev, cmd.size, cmd.va, cmd.dma); return status; } @@ -4398,10 +4396,7 @@ static int be_cmd_set_profile_config(struct be_adapter *adapter, void *desc, memcpy(req->desc, desc, size); status = be_cmd_notify_wait(adapter, &wrb); - - if (cmd.va) - dma_free_coherent(&adapter->pdev->dev, cmd.size, cmd.va, - cmd.dma); + dma_free_coherent(&adapter->pdev->dev, cmd.size, cmd.va, cmd.dma); return status; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH] be2net: Delete an unnecessary check in two functions @ 2015-12-31 23:22 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2015-12-31 23:22 UTC (permalink / raw) To: netdev, Ajit Khaparde, Padmanabh Ratnakar, Sathya Perla, Sriharsha Basavapatna Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 00:11:57 +0100 Remove two checks for null pointers which would be handled by usual error detection before. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/ethernet/emulex/benet/be_cmds.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c b/drivers/net/ethernet/emulex/benet/be_cmds.c index b63d8ad..ba98297 100644 --- a/drivers/net/ethernet/emulex/benet/be_cmds.c +++ b/drivers/net/ethernet/emulex/benet/be_cmds.c @@ -4366,9 +4366,7 @@ int be_cmd_get_profile_config(struct be_adapter *adapter, if (vf_res) res->vf_if_cap_flags = vf_res->cap_flags; err: - if (cmd.va) - dma_free_coherent(&adapter->pdev->dev, cmd.size, cmd.va, - cmd.dma); + dma_free_coherent(&adapter->pdev->dev, cmd.size, cmd.va, cmd.dma); return status; } @@ -4398,10 +4396,7 @@ static int be_cmd_set_profile_config(struct be_adapter *adapter, void *desc, memcpy(req->desc, desc, size); status = be_cmd_notify_wait(adapter, &wrb); - - if (cmd.va) - dma_free_coherent(&adapter->pdev->dev, cmd.size, cmd.va, - cmd.dma); + dma_free_coherent(&adapter->pdev->dev, cmd.size, cmd.va, cmd.dma); return status; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH] be2net: Delete an unnecessary check in two functions 2015-12-31 23:22 ` SF Markus Elfring @ 2016-01-06 6:37 ` Sathya Perla -1 siblings, 0 replies; 3089+ messages in thread From: Sathya Perla @ 2016-01-06 6:25 UTC (permalink / raw) To: SF Markus Elfring Cc: netdev, Ajit Khaparde, Padmanabh Ratnakar, Sriharsha Basavapatna, kernel-janitors, Julia Lawall On Fri, Jan 1, 2016 at 4:52 AM, SF Markus Elfring <elfring@users.sourceforge.net> wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 00:11:57 +0100 > > Remove two checks for null pointers which would be handled by usual > error detection before. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Acked-by: Sathya Perla <sathya.perla@avagotech.com> This patch is suitable for the net-next tree. Thanks! ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] be2net: Delete an unnecessary check in two functions @ 2016-01-06 6:37 ` Sathya Perla 0 siblings, 0 replies; 3089+ messages in thread From: Sathya Perla @ 2016-01-06 6:37 UTC (permalink / raw) To: SF Markus Elfring Cc: netdev, Ajit Khaparde, Padmanabh Ratnakar, Sriharsha Basavapatna, kernel-janitors, Julia Lawall On Fri, Jan 1, 2016 at 4:52 AM, SF Markus Elfring <elfring@users.sourceforge.net> wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 00:11:57 +0100 > > Remove two checks for null pointers which would be handled by usual > error detection before. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Acked-by: Sathya Perla <sathya.perla@avagotech.com> This patch is suitable for the net-next tree. Thanks! ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/3] net-gianfar: Fine-tuning for gfar_ethflow_to_filer_table() 2015-12-11 12:08 ` SF Markus Elfring @ 2016-01-01 12:18 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 12:18 UTC (permalink / raw) To: netdev, Claudiu Manoil; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 13:15:34 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (3): Less function calls after error detection Delete unnecessary variable initialisations Extend an initialisation clause of a for loop drivers/net/ethernet/freescale/gianfar_ethtool.c | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/3] net-gianfar: Fine-tuning for gfar_ethflow_to_filer_table() @ 2016-01-01 12:18 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 12:18 UTC (permalink / raw) To: netdev, Claudiu Manoil; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 13:15:34 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (3): Less function calls after error detection Delete unnecessary variable initialisations Extend an initialisation clause of a for loop drivers/net/ethernet/freescale/gianfar_ethtool.c | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 1/3] net-gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detection 2016-01-01 12:18 ` SF Markus Elfring @ 2016-01-01 12:22 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 12:22 UTC (permalink / raw) To: netdev, Claudiu Manoil; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 11:16:04 +0100 The kfree() function was called in one case by the gfar_ethflow_to_filer_table() function during error handling even if a passed variable contained a null pointer. * Return directly if a memory allocation failed at the beginning. * Adjust jump targets according to the Linux coding style convention. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/ethernet/freescale/gianfar_ethtool.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/net/ethernet/freescale/gianfar_ethtool.c b/drivers/net/ethernet/freescale/gianfar_ethtool.c index 4b0ee85..be4941e 100644 --- a/drivers/net/ethernet/freescale/gianfar_ethtool.c +++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c @@ -778,11 +778,13 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, local_rqfpr = kmalloc_array(MAX_FILER_IDX + 1, sizeof(unsigned int), GFP_KERNEL); + if (!local_rqfpr) + return 1; local_rqfcr = kmalloc_array(MAX_FILER_IDX + 1, sizeof(unsigned int), GFP_KERNEL); - if (!local_rqfpr || !local_rqfcr) { + if (!local_rqfcr) { ret = 0; - goto err; + goto free_fpr; } switch (class) { @@ -802,7 +804,7 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, netdev_err(priv->ndev, "Right now this class is not supported\n"); ret = 0; - goto err; + goto free_fcr; } for (i = 0; i < MAX_FILER_IDX + 1; i++) { @@ -819,7 +821,7 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, netdev_err(priv->ndev, "No parse rule found, can't create hash rules\n"); ret = 0; - goto err; + goto free_fcr; } /* If a match was found, then it begins the starting of a cluster rule @@ -862,9 +864,9 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, break; priv->cur_filer_idx = priv->cur_filer_idx - 1; } - -err: +free_fcr: kfree(local_rqfcr); +free_fpr: kfree(local_rqfpr); return ret; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 1/3] net-gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detection @ 2016-01-01 12:22 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 12:22 UTC (permalink / raw) To: netdev, Claudiu Manoil; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 11:16:04 +0100 The kfree() function was called in one case by the gfar_ethflow_to_filer_table() function during error handling even if a passed variable contained a null pointer. * Return directly if a memory allocation failed at the beginning. * Adjust jump targets according to the Linux coding style convention. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/ethernet/freescale/gianfar_ethtool.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/net/ethernet/freescale/gianfar_ethtool.c b/drivers/net/ethernet/freescale/gianfar_ethtool.c index 4b0ee85..be4941e 100644 --- a/drivers/net/ethernet/freescale/gianfar_ethtool.c +++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c @@ -778,11 +778,13 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, local_rqfpr = kmalloc_array(MAX_FILER_IDX + 1, sizeof(unsigned int), GFP_KERNEL); + if (!local_rqfpr) + return 1; local_rqfcr = kmalloc_array(MAX_FILER_IDX + 1, sizeof(unsigned int), GFP_KERNEL); - if (!local_rqfpr || !local_rqfcr) { + if (!local_rqfcr) { ret = 0; - goto err; + goto free_fpr; } switch (class) { @@ -802,7 +804,7 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, netdev_err(priv->ndev, "Right now this class is not supported\n"); ret = 0; - goto err; + goto free_fcr; } for (i = 0; i < MAX_FILER_IDX + 1; i++) { @@ -819,7 +821,7 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, netdev_err(priv->ndev, "No parse rule found, can't create hash rules\n"); ret = 0; - goto err; + goto free_fcr; } /* If a match was found, then it begins the starting of a cluster rule @@ -862,9 +864,9 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, break; priv->cur_filer_idx = priv->cur_filer_idx - 1; } - -err: +free_fcr: kfree(local_rqfcr); +free_fpr: kfree(local_rqfpr); return ret; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/3] net-gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detection 2016-01-01 12:22 ` SF Markus Elfring @ 2016-01-01 12:35 ` Julia Lawall -1 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2016-01-01 12:35 UTC (permalink / raw) To: SF Markus Elfring; +Cc: netdev, Claudiu Manoil, LKML, kernel-janitors On Fri, 1 Jan 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 11:16:04 +0100 > > The kfree() function was called in one case by the > gfar_ethflow_to_filer_table() function during error handling > even if a passed variable contained a null pointer. > > * Return directly if a memory allocation failed at the beginning. > > * Adjust jump targets according to the Linux coding style convention. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/net/ethernet/freescale/gianfar_ethtool.c | 14 ++++++++------ > 1 file changed, 8 insertions(+), 6 deletions(-) > > diff --git a/drivers/net/ethernet/freescale/gianfar_ethtool.c b/drivers/net/ethernet/freescale/gianfar_ethtool.c > index 4b0ee85..be4941e 100644 > --- a/drivers/net/ethernet/freescale/gianfar_ethtool.c > +++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c > @@ -778,11 +778,13 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, > > local_rqfpr = kmalloc_array(MAX_FILER_IDX + 1, sizeof(unsigned int), > GFP_KERNEL); > + if (!local_rqfpr) > + return 1; Why return 1? Previously 0 was returned. Normally, one returns -ENOMEM for this case, but it looks like this function is returning 0 on failure. julia > local_rqfcr = kmalloc_array(MAX_FILER_IDX + 1, sizeof(unsigned int), > GFP_KERNEL); > - if (!local_rqfpr || !local_rqfcr) { > + if (!local_rqfcr) { > ret = 0; > - goto err; > + goto free_fpr; > } > > switch (class) { > @@ -802,7 +804,7 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, > netdev_err(priv->ndev, > "Right now this class is not supported\n"); > ret = 0; > - goto err; > + goto free_fcr; > } > > for (i = 0; i < MAX_FILER_IDX + 1; i++) { > @@ -819,7 +821,7 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, > netdev_err(priv->ndev, > "No parse rule found, can't create hash rules\n"); > ret = 0; > - goto err; > + goto free_fcr; > } > > /* If a match was found, then it begins the starting of a cluster rule > @@ -862,9 +864,9 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, > break; > priv->cur_filer_idx = priv->cur_filer_idx - 1; > } > - > -err: > +free_fcr: > kfree(local_rqfcr); > +free_fpr: > kfree(local_rqfpr); > return ret; > } > -- > 2.6.3 > > -- > To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/3] net-gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detect @ 2016-01-01 12:35 ` Julia Lawall 0 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2016-01-01 12:35 UTC (permalink / raw) To: SF Markus Elfring; +Cc: netdev, Claudiu Manoil, LKML, kernel-janitors On Fri, 1 Jan 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 11:16:04 +0100 > > The kfree() function was called in one case by the > gfar_ethflow_to_filer_table() function during error handling > even if a passed variable contained a null pointer. > > * Return directly if a memory allocation failed at the beginning. > > * Adjust jump targets according to the Linux coding style convention. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/net/ethernet/freescale/gianfar_ethtool.c | 14 ++++++++------ > 1 file changed, 8 insertions(+), 6 deletions(-) > > diff --git a/drivers/net/ethernet/freescale/gianfar_ethtool.c b/drivers/net/ethernet/freescale/gianfar_ethtool.c > index 4b0ee85..be4941e 100644 > --- a/drivers/net/ethernet/freescale/gianfar_ethtool.c > +++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c > @@ -778,11 +778,13 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, > > local_rqfpr = kmalloc_array(MAX_FILER_IDX + 1, sizeof(unsigned int), > GFP_KERNEL); > + if (!local_rqfpr) > + return 1; Why return 1? Previously 0 was returned. Normally, one returns -ENOMEM for this case, but it looks like this function is returning 0 on failure. julia > local_rqfcr = kmalloc_array(MAX_FILER_IDX + 1, sizeof(unsigned int), > GFP_KERNEL); > - if (!local_rqfpr || !local_rqfcr) { > + if (!local_rqfcr) { > ret = 0; > - goto err; > + goto free_fpr; > } > > switch (class) { > @@ -802,7 +804,7 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, > netdev_err(priv->ndev, > "Right now this class is not supported\n"); > ret = 0; > - goto err; > + goto free_fcr; > } > > for (i = 0; i < MAX_FILER_IDX + 1; i++) { > @@ -819,7 +821,7 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, > netdev_err(priv->ndev, > "No parse rule found, can't create hash rules\n"); > ret = 0; > - goto err; > + goto free_fcr; > } > > /* If a match was found, then it begins the starting of a cluster rule > @@ -862,9 +864,9 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, > break; > priv->cur_filer_idx = priv->cur_filer_idx - 1; > } > - > -err: > +free_fcr: > kfree(local_rqfcr); > +free_fpr: > kfree(local_rqfpr); > return ret; > } > -- > 2.6.3 > > -- > To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/3] net-gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detection 2016-01-01 12:35 ` [PATCH 1/3] net-gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detect Julia Lawall @ 2016-01-01 12:50 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 12:50 UTC (permalink / raw) To: Julia Lawall; +Cc: netdev, Claudiu Manoil, LKML, kernel-janitors >> +++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c >> @@ -778,11 +778,13 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, >> >> local_rqfpr = kmalloc_array(MAX_FILER_IDX + 1, sizeof(unsigned int), >> GFP_KERNEL); >> + if (!local_rqfpr) >> + return 1; > > Why return 1? Previously 0 was returned. You are right. - Unfortunately, I made a mistake at this place of my update suggestion. > Normally, one returns -ENOMEM for this case, but it looks like this > function is returning 0 on failure. Should a symbol like "false" be used instead of such a special number? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/3] net-gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detect @ 2016-01-01 12:50 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 12:50 UTC (permalink / raw) To: Julia Lawall; +Cc: netdev, Claudiu Manoil, LKML, kernel-janitors >> +++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c >> @@ -778,11 +778,13 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, >> >> local_rqfpr = kmalloc_array(MAX_FILER_IDX + 1, sizeof(unsigned int), >> GFP_KERNEL); >> + if (!local_rqfpr) >> + return 1; > > Why return 1? Previously 0 was returned. You are right. - Unfortunately, I made a mistake at this place of my update suggestion. > Normally, one returns -ENOMEM for this case, but it looks like this > function is returning 0 on failure. Should a symbol like "false" be used instead of such a special number? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/3] net-gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detection 2016-01-01 12:50 ` [PATCH 1/3] net-gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detect SF Markus Elfring @ 2016-01-01 13:05 ` Julia Lawall -1 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2016-01-01 13:05 UTC (permalink / raw) To: SF Markus Elfring Cc: Julia Lawall, netdev, Claudiu Manoil, LKML, kernel-janitors On Fri, 1 Jan 2016, SF Markus Elfring wrote: > >> +++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c > >> @@ -778,11 +778,13 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, > >> > >> local_rqfpr = kmalloc_array(MAX_FILER_IDX + 1, sizeof(unsigned int), > >> GFP_KERNEL); > >> + if (!local_rqfpr) > >> + return 1; > > > > Why return 1? Previously 0 was returned. > > You are right. - Unfortunately, I made a mistake at this place > of my update suggestion. > > > > Normally, one returns -ENOMEM for this case, but it looks like this > > function is returning 0 on failure. > > Should a symbol like "false" be used instead of such a special number? Maybe it's better than 0 and 1... julia ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/3] net-gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detect @ 2016-01-01 13:05 ` Julia Lawall 0 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2016-01-01 13:05 UTC (permalink / raw) To: SF Markus Elfring Cc: Julia Lawall, netdev, Claudiu Manoil, LKML, kernel-janitors On Fri, 1 Jan 2016, SF Markus Elfring wrote: > >> +++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c > >> @@ -778,11 +778,13 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, > >> > >> local_rqfpr = kmalloc_array(MAX_FILER_IDX + 1, sizeof(unsigned int), > >> GFP_KERNEL); > >> + if (!local_rqfpr) > >> + return 1; > > > > Why return 1? Previously 0 was returned. > > You are right. - Unfortunately, I made a mistake at this place > of my update suggestion. > > > > Normally, one returns -ENOMEM for this case, but it looks like this > > function is returning 0 on failure. > > Should a symbol like "false" be used instead of such a special number? Maybe it's better than 0 and 1... julia ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/3] net-gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detection 2016-01-01 13:05 ` [PATCH 1/3] net-gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detect Julia Lawall @ 2016-01-01 14:45 ` Francois Romieu -1 siblings, 0 replies; 3089+ messages in thread From: Francois Romieu @ 2016-01-01 14:45 UTC (permalink / raw) To: Julia Lawall Cc: SF Markus Elfring, netdev, Claudiu Manoil, LKML, kernel-janitors Julia Lawall <julia.lawall@lip6.fr> : > On Fri, 1 Jan 2016, SF Markus Elfring wrote: [...] > > > Normally, one returns -ENOMEM for this case, but it looks like this > > > function is returning 0 on failure. > > > > Should a symbol like "false" be used instead of such a special number? > > Maybe it's better than 0 and 1... Your suggestion about -ENOMEM is consistent with the callchain. Nothing else is needed. Btw: 1. kfree does not care about NULL parameter, especially in this hardly timing sensitive path. 2. kmalloc_array for small kernel controlled arrays of integers (see drivers/net/ethernet/freescale/gianfar.h), seriously ? I'd suggest the janitor to introduce a dedicated struct to embed both gfar_private.ftp_rqf{p, c}r then use a single, plain kmalloc in gfar_ethflow_to_filer_table. Happy tasteful 2016 :o) -- Ueimor ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/3] net-gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detect @ 2016-01-01 14:45 ` Francois Romieu 0 siblings, 0 replies; 3089+ messages in thread From: Francois Romieu @ 2016-01-01 14:45 UTC (permalink / raw) To: Julia Lawall Cc: SF Markus Elfring, netdev, Claudiu Manoil, LKML, kernel-janitors Julia Lawall <julia.lawall@lip6.fr> : > On Fri, 1 Jan 2016, SF Markus Elfring wrote: [...] > > > Normally, one returns -ENOMEM for this case, but it looks like this > > > function is returning 0 on failure. > > > > Should a symbol like "false" be used instead of such a special number? > > Maybe it's better than 0 and 1... Your suggestion about -ENOMEM is consistent with the callchain. Nothing else is needed. Btw: 1. kfree does not care about NULL parameter, especially in this hardly timing sensitive path. 2. kmalloc_array for small kernel controlled arrays of integers (see drivers/net/ethernet/freescale/gianfar.h), seriously ? I'd suggest the janitor to introduce a dedicated struct to embed both gfar_private.ftp_rqf{p, c}r then use a single, plain kmalloc in gfar_ethflow_to_filer_table. Happy tasteful 2016 :o) -- Ueimor ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH v2 1/3] net-gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detection 2016-01-01 12:35 ` [PATCH 1/3] net-gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detect Julia Lawall @ 2016-01-01 13:04 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 13:04 UTC (permalink / raw) To: netdev, Claudiu Manoil; +Cc: Julia Lawall, LKML, kernel-janitors From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 13:56:09 +0100 The kfree() function was called in one case by the gfar_ethflow_to_filer_table() function during error handling even if a passed variable contained a null pointer. * Return directly if a memory allocation failed at the beginning. * Adjust jump targets according to the Linux coding style convention. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/ethernet/freescale/gianfar_ethtool.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/net/ethernet/freescale/gianfar_ethtool.c b/drivers/net/ethernet/freescale/gianfar_ethtool.c index 4b0ee85..825b051 100644 --- a/drivers/net/ethernet/freescale/gianfar_ethtool.c +++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c @@ -778,11 +778,13 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, local_rqfpr = kmalloc_array(MAX_FILER_IDX + 1, sizeof(unsigned int), GFP_KERNEL); + if (!local_rqfpr) + return 0; local_rqfcr = kmalloc_array(MAX_FILER_IDX + 1, sizeof(unsigned int), GFP_KERNEL); - if (!local_rqfpr || !local_rqfcr) { + if (!local_rqfcr) { ret = 0; - goto err; + goto free_fpr; } switch (class) { @@ -802,7 +804,7 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, netdev_err(priv->ndev, "Right now this class is not supported\n"); ret = 0; - goto err; + goto free_fcr; } for (i = 0; i < MAX_FILER_IDX + 1; i++) { @@ -819,7 +821,7 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, netdev_err(priv->ndev, "No parse rule found, can't create hash rules\n"); ret = 0; - goto err; + goto free_fcr; } /* If a match was found, then it begins the starting of a cluster rule @@ -862,9 +864,9 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, break; priv->cur_filer_idx = priv->cur_filer_idx - 1; } - -err: +free_fcr: kfree(local_rqfcr); +free_fpr: kfree(local_rqfpr); return ret; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH v2 1/3] net-gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detecti @ 2016-01-01 13:04 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 13:04 UTC (permalink / raw) To: netdev, Claudiu Manoil; +Cc: Julia Lawall, LKML, kernel-janitors From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 13:56:09 +0100 The kfree() function was called in one case by the gfar_ethflow_to_filer_table() function during error handling even if a passed variable contained a null pointer. * Return directly if a memory allocation failed at the beginning. * Adjust jump targets according to the Linux coding style convention. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/ethernet/freescale/gianfar_ethtool.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/net/ethernet/freescale/gianfar_ethtool.c b/drivers/net/ethernet/freescale/gianfar_ethtool.c index 4b0ee85..825b051 100644 --- a/drivers/net/ethernet/freescale/gianfar_ethtool.c +++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c @@ -778,11 +778,13 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, local_rqfpr = kmalloc_array(MAX_FILER_IDX + 1, sizeof(unsigned int), GFP_KERNEL); + if (!local_rqfpr) + return 0; local_rqfcr = kmalloc_array(MAX_FILER_IDX + 1, sizeof(unsigned int), GFP_KERNEL); - if (!local_rqfpr || !local_rqfcr) { + if (!local_rqfcr) { ret = 0; - goto err; + goto free_fpr; } switch (class) { @@ -802,7 +804,7 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, netdev_err(priv->ndev, "Right now this class is not supported\n"); ret = 0; - goto err; + goto free_fcr; } for (i = 0; i < MAX_FILER_IDX + 1; i++) { @@ -819,7 +821,7 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, netdev_err(priv->ndev, "No parse rule found, can't create hash rules\n"); ret = 0; - goto err; + goto free_fcr; } /* If a match was found, then it begins the starting of a cluster rule @@ -862,9 +864,9 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, break; priv->cur_filer_idx = priv->cur_filer_idx - 1; } - -err: +free_fcr: kfree(local_rqfcr); +free_fpr: kfree(local_rqfpr); return ret; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH v2 1/3] net-gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detection 2016-01-01 13:04 ` [PATCH v2 1/3] net-gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detecti SF Markus Elfring @ 2016-01-02 3:16 ` David Miller -1 siblings, 0 replies; 3089+ messages in thread From: David Miller @ 2016-01-02 3:16 UTC (permalink / raw) To: elfring Cc: netdev, claudiu.manoil, julia.lawall, linux-kernel, kernel-janitors This is not the proper way to resubmit patches when you are asked to make changes to some portion of a multi-patch series. You must always resubmit the entire series when this happens, not just the patch that changes. And in the revised cover "0/N" posting you list the revisions that were made. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH v2 1/3] net-gianfar: Less function calls in gfar_ethflow_to_filer_table() after error det @ 2016-01-02 3:16 ` David Miller 0 siblings, 0 replies; 3089+ messages in thread From: David Miller @ 2016-01-02 3:16 UTC (permalink / raw) To: elfring Cc: netdev, claudiu.manoil, julia.lawall, linux-kernel, kernel-janitors This is not the proper way to resubmit patches when you are asked to make changes to some portion of a multi-patch series. You must always resubmit the entire series when this happens, not just the patch that changes. And in the revised cover "0/N" posting you list the revisions that were made. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 2/3] net-gianfar: Delete unnecessary variable initialisations in gfar_ethflow_to_filer_table() 2016-01-01 12:18 ` SF Markus Elfring @ 2016-01-01 12:23 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 12:23 UTC (permalink / raw) To: netdev, Claudiu Manoil; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 12:56:23 +0100 Omit explicit initialisation at the beginning for four local variables which are redefined before their first use. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/ethernet/freescale/gianfar_ethtool.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/freescale/gianfar_ethtool.c b/drivers/net/ethernet/freescale/gianfar_ethtool.c index be4941e..508be89 100644 --- a/drivers/net/ethernet/freescale/gianfar_ethtool.c +++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c @@ -768,12 +768,12 @@ static void ethflow_to_filer_rules (struct gfar_private *priv, u64 ethflow) static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, u64 class) { - unsigned int last_rule_idx = priv->cur_filer_idx; + unsigned int last_rule_idx; unsigned int cmp_rqfpr; unsigned int *local_rqfpr; unsigned int *local_rqfcr; - int i = 0x0, k = 0x0; - int j = MAX_FILER_IDX, l = 0x0; + int i, k, l; + int j = MAX_FILER_IDX; int ret = 1; local_rqfpr = kmalloc_array(MAX_FILER_IDX + 1, sizeof(unsigned int), -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 2/3] net-gianfar: Delete unnecessary variable initialisations in gfar_ethflow_to_filer_table( @ 2016-01-01 12:23 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 12:23 UTC (permalink / raw) To: netdev, Claudiu Manoil; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 12:56:23 +0100 Omit explicit initialisation at the beginning for four local variables which are redefined before their first use. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/ethernet/freescale/gianfar_ethtool.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/freescale/gianfar_ethtool.c b/drivers/net/ethernet/freescale/gianfar_ethtool.c index be4941e..508be89 100644 --- a/drivers/net/ethernet/freescale/gianfar_ethtool.c +++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c @@ -768,12 +768,12 @@ static void ethflow_to_filer_rules (struct gfar_private *priv, u64 ethflow) static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, u64 class) { - unsigned int last_rule_idx = priv->cur_filer_idx; + unsigned int last_rule_idx; unsigned int cmp_rqfpr; unsigned int *local_rqfpr; unsigned int *local_rqfcr; - int i = 0x0, k = 0x0; - int j = MAX_FILER_IDX, l = 0x0; + int i, k, l; + int j = MAX_FILER_IDX; int ret = 1; local_rqfpr = kmalloc_array(MAX_FILER_IDX + 1, sizeof(unsigned int), -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 3/3] net-gianfar: Extend an initialisation clause of a for loop in gfar_ethflow_to_filer_table() 2016-01-01 12:18 ` SF Markus Elfring @ 2016-01-01 12:24 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 12:24 UTC (permalink / raw) To: netdev, Claudiu Manoil; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 13:00:06 +0100 Move the assignment for the variable "j" from the beginning into an initialisation clause of a for loop. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/ethernet/freescale/gianfar_ethtool.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/freescale/gianfar_ethtool.c b/drivers/net/ethernet/freescale/gianfar_ethtool.c index 508be89..6a7b035 100644 --- a/drivers/net/ethernet/freescale/gianfar_ethtool.c +++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c @@ -772,8 +772,7 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, unsigned int cmp_rqfpr; unsigned int *local_rqfpr; unsigned int *local_rqfcr; - int i, k, l; - int j = MAX_FILER_IDX; + int i, j, k, l; int ret = 1; local_rqfpr = kmalloc_array(MAX_FILER_IDX + 1, sizeof(unsigned int), @@ -807,7 +806,7 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, goto free_fcr; } - for (i = 0; i < MAX_FILER_IDX + 1; i++) { + for (i = 0, j = MAX_FILER_IDX; i < MAX_FILER_IDX + 1; i++) { local_rqfpr[j] = priv->ftp_rqfpr[i]; local_rqfcr[j] = priv->ftp_rqfcr[i]; j--; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 3/3] net-gianfar: Extend an initialisation clause of a for loop in gfar_ethflow_to_filer_tabl @ 2016-01-01 12:24 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 12:24 UTC (permalink / raw) To: netdev, Claudiu Manoil; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 13:00:06 +0100 Move the assignment for the variable "j" from the beginning into an initialisation clause of a for loop. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/ethernet/freescale/gianfar_ethtool.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/freescale/gianfar_ethtool.c b/drivers/net/ethernet/freescale/gianfar_ethtool.c index 508be89..6a7b035 100644 --- a/drivers/net/ethernet/freescale/gianfar_ethtool.c +++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c @@ -772,8 +772,7 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, unsigned int cmp_rqfpr; unsigned int *local_rqfpr; unsigned int *local_rqfcr; - int i, k, l; - int j = MAX_FILER_IDX; + int i, j, k, l; int ret = 1; local_rqfpr = kmalloc_array(MAX_FILER_IDX + 1, sizeof(unsigned int), @@ -807,7 +806,7 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, goto free_fcr; } - for (i = 0; i < MAX_FILER_IDX + 1; i++) { + for (i = 0, j = MAX_FILER_IDX; i < MAX_FILER_IDX + 1; i++) { local_rqfpr[j] = priv->ftp_rqfpr[i]; local_rqfcr[j] = priv->ftp_rqfcr[i]; j--; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH v3 0/3] gianfar: Fine-tuning for gfar_ethflow_to_filer_table() 2016-01-01 12:18 ` SF Markus Elfring @ 2016-01-15 10:09 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-15 10:09 UTC (permalink / raw) To: netdev, Claudiu Manoil; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 15 Jan 2016 11:05:43 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (3): Less function calls after error detection Delete unnecessary variable initialisations Extend an initialisation clause of a for loop --- v3: Rebase proposed changes on the source files for the software "Linux next-20160114". v2: Unfortunately, an inappropriate return code was selected in the first update step from this series. Thus fix that. drivers/net/ethernet/freescale/gianfar_ethtool.c | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH v3 0/3] gianfar: Fine-tuning for gfar_ethflow_to_filer_table() @ 2016-01-15 10:09 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-15 10:09 UTC (permalink / raw) To: netdev, Claudiu Manoil; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 15 Jan 2016 11:05:43 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (3): Less function calls after error detection Delete unnecessary variable initialisations Extend an initialisation clause of a for loop --- v3: Rebase proposed changes on the source files for the software "Linux next-20160114". v2: Unfortunately, an inappropriate return code was selected in the first update step from this series. Thus fix that. drivers/net/ethernet/freescale/gianfar_ethtool.c | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH v3 1/3] gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detection 2016-01-15 10:09 ` SF Markus Elfring @ 2016-01-15 10:11 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-15 10:11 UTC (permalink / raw) To: netdev, Claudiu Manoil; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 15 Jan 2016 10:30:37 +0100 The kfree() function was called in one case by the gfar_ethflow_to_filer_table() function during error handling even if a passed variable contained a null pointer. * Return directly if a memory allocation failed at the beginning. * Adjust jump targets according to the Linux coding style convention. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/ethernet/freescale/gianfar_ethtool.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/net/ethernet/freescale/gianfar_ethtool.c b/drivers/net/ethernet/freescale/gianfar_ethtool.c index 4b0ee85..825b051 100644 --- a/drivers/net/ethernet/freescale/gianfar_ethtool.c +++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c @@ -778,11 +778,13 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, local_rqfpr = kmalloc_array(MAX_FILER_IDX + 1, sizeof(unsigned int), GFP_KERNEL); + if (!local_rqfpr) + return 0; local_rqfcr = kmalloc_array(MAX_FILER_IDX + 1, sizeof(unsigned int), GFP_KERNEL); - if (!local_rqfpr || !local_rqfcr) { + if (!local_rqfcr) { ret = 0; - goto err; + goto free_fpr; } switch (class) { @@ -802,7 +804,7 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, netdev_err(priv->ndev, "Right now this class is not supported\n"); ret = 0; - goto err; + goto free_fcr; } for (i = 0; i < MAX_FILER_IDX + 1; i++) { @@ -819,7 +821,7 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, netdev_err(priv->ndev, "No parse rule found, can't create hash rules\n"); ret = 0; - goto err; + goto free_fcr; } /* If a match was found, then it begins the starting of a cluster rule @@ -862,9 +864,9 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, break; priv->cur_filer_idx = priv->cur_filer_idx - 1; } - -err: +free_fcr: kfree(local_rqfcr); +free_fpr: kfree(local_rqfpr); return ret; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH v3 1/3] gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detection @ 2016-01-15 10:11 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-15 10:11 UTC (permalink / raw) To: netdev, Claudiu Manoil; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 15 Jan 2016 10:30:37 +0100 The kfree() function was called in one case by the gfar_ethflow_to_filer_table() function during error handling even if a passed variable contained a null pointer. * Return directly if a memory allocation failed at the beginning. * Adjust jump targets according to the Linux coding style convention. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/ethernet/freescale/gianfar_ethtool.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/net/ethernet/freescale/gianfar_ethtool.c b/drivers/net/ethernet/freescale/gianfar_ethtool.c index 4b0ee85..825b051 100644 --- a/drivers/net/ethernet/freescale/gianfar_ethtool.c +++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c @@ -778,11 +778,13 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, local_rqfpr = kmalloc_array(MAX_FILER_IDX + 1, sizeof(unsigned int), GFP_KERNEL); + if (!local_rqfpr) + return 0; local_rqfcr = kmalloc_array(MAX_FILER_IDX + 1, sizeof(unsigned int), GFP_KERNEL); - if (!local_rqfpr || !local_rqfcr) { + if (!local_rqfcr) { ret = 0; - goto err; + goto free_fpr; } switch (class) { @@ -802,7 +804,7 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, netdev_err(priv->ndev, "Right now this class is not supported\n"); ret = 0; - goto err; + goto free_fcr; } for (i = 0; i < MAX_FILER_IDX + 1; i++) { @@ -819,7 +821,7 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, netdev_err(priv->ndev, "No parse rule found, can't create hash rules\n"); ret = 0; - goto err; + goto free_fcr; } /* If a match was found, then it begins the starting of a cluster rule @@ -862,9 +864,9 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, break; priv->cur_filer_idx = priv->cur_filer_idx - 1; } - -err: +free_fcr: kfree(local_rqfcr); +free_fpr: kfree(local_rqfpr); return ret; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH v3 1/3] gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detection 2016-01-15 10:11 ` SF Markus Elfring @ 2016-01-15 10:37 ` Joe Perches -1 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2016-01-15 10:37 UTC (permalink / raw) To: SF Markus Elfring, netdev, Claudiu Manoil Cc: LKML, kernel-janitors, Julia Lawall On Fri, 2016-01-15 at 11:11 +0100, SF Markus Elfring wrote: > The kfree() function was called in one case by the > gfar_ethflow_to_filer_table() function during error handling > even if a passed variable contained a null pointer. > > * Return directly if a memory allocation failed at the beginning. > > * Adjust jump targets according to the Linux coding style convention. > > This issue was detected by using the Coccinelle software. Is this really better? Perhaps this particular static analysis isn't too useful. Why not just allocate once and assign a second pointer? local_rqfpr = kmalloc_array(2 * (MAX_FILER_IDX + 1), sizeof(unsigned int), GFP_KERNEL); if (!local_rqfpr) goto err; local_rqfcr = &local_rqfpr[MAX_FILER_IDX + 1]; Perhaps this would be better removing the ret variable and using something like: int gfar_ethflow_to_filer_table(...) { ... return 0; err: kfree(local_rqfpt); return 1; } ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH v3 1/3] gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detecti @ 2016-01-15 10:37 ` Joe Perches 0 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2016-01-15 10:37 UTC (permalink / raw) To: SF Markus Elfring, netdev, Claudiu Manoil Cc: LKML, kernel-janitors, Julia Lawall On Fri, 2016-01-15 at 11:11 +0100, SF Markus Elfring wrote: > The kfree() function was called in one case by the > gfar_ethflow_to_filer_table() function during error handling > even if a passed variable contained a null pointer. > > * Return directly if a memory allocation failed at the beginning. > > * Adjust jump targets according to the Linux coding style convention. > > This issue was detected by using the Coccinelle software. Is this really better? Perhaps this particular static analysis isn't too useful. Why not just allocate once and assign a second pointer? local_rqfpr = kmalloc_array(2 * (MAX_FILER_IDX + 1), sizeof(unsigned int), GFP_KERNEL); if (!local_rqfpr) goto err; local_rqfcr = &local_rqfpr[MAX_FILER_IDX + 1]; Perhaps this would be better removing the ret variable and using something like: int gfar_ethflow_to_filer_table(...) { ... return 0; err: kfree(local_rqfpt); return 1; } -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detection 2016-01-15 10:37 ` [PATCH v3 1/3] gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detecti Joe Perches @ 2016-01-15 11:47 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-15 11:47 UTC (permalink / raw) To: Joe Perches, netdev; +Cc: Claudiu Manoil, LKML, kernel-janitors, Julia Lawall >> * Return directly if a memory allocation failed at the beginning. >> >> * Adjust jump targets according to the Linux coding style convention. >> >> This issue was detected by using the Coccinelle software. > > Is this really better? > > Perhaps this particular static analysis isn't too useful. The opinions are still evolving for such a kind of search pattern. > Why not just allocate once and assign a second pointer? > > local_rqfpr = kmalloc_array(2 * (MAX_FILER_IDX + 1), > sizeof(unsigned int), GFP_KERNEL); > if (!local_rqfpr) > goto err; > > local_rqfcr = &local_rqfpr[MAX_FILER_IDX + 1]; Do you suggest to use only one array (instead of two as before) here? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detection @ 2016-01-15 11:47 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-15 11:47 UTC (permalink / raw) To: Joe Perches, netdev; +Cc: Claudiu Manoil, LKML, kernel-janitors, Julia Lawall >> * Return directly if a memory allocation failed at the beginning. >> >> * Adjust jump targets according to the Linux coding style convention. >> >> This issue was detected by using the Coccinelle software. > > Is this really better? > > Perhaps this particular static analysis isn't too useful. The opinions are still evolving for such a kind of search pattern. > Why not just allocate once and assign a second pointer? > > local_rqfpr = kmalloc_array(2 * (MAX_FILER_IDX + 1), > sizeof(unsigned int), GFP_KERNEL); > if (!local_rqfpr) > goto err; > > local_rqfcr = &local_rqfpr[MAX_FILER_IDX + 1]; Do you suggest to use only one array (instead of two as before) here? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detection 2016-01-15 11:47 ` SF Markus Elfring (?) @ 2016-01-15 12:03 ` Joe Perches -1 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2016-01-15 12:03 UTC (permalink / raw) To: SF Markus Elfring, netdev Cc: Claudiu Manoil, LKML, kernel-janitors, Julia Lawall On Fri, 2016-01-15 at 12:47 +0100, SF Markus Elfring wrote: > > > * Return directly if a memory allocation failed at the beginning. > > > > > > * Adjust jump targets according to the Linux coding style > > > convention. > > > > > > This issue was detected by using the Coccinelle software. > > > > Is this really better? > > > > Perhaps this particular static analysis isn't too useful. > > The opinions are still evolving for such a kind of search pattern. > > > > Why not just allocate once and assign a second pointer? > > > > local_rqfpr = kmalloc_array(2 * (MAX_FILER_IDX + 1), > > sizeof(unsigned int), GFP_KERNEL); > > if (!local_rqfpr) > > goto err; > > > > local_rqfcr = &local_rqfpr[MAX_FILER_IDX + 1]; > > Do you suggest to use only one array (instead of two as before) here? That's a possibility. If, as your title suggests, you really want fewer function calls, (which as far as I saw, you didn't do) that could be a mechanism to remove both an allocation and a free. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detection @ 2016-01-15 12:03 ` Joe Perches 0 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2016-01-15 12:03 UTC (permalink / raw) To: SF Markus Elfring, netdev Cc: Claudiu Manoil, LKML, kernel-janitors, Julia Lawall On Fri, 2016-01-15 at 12:47 +0100, SF Markus Elfring wrote: > > > * Return directly if a memory allocation failed at the beginning. > > > > > > * Adjust jump targets according to the Linux coding style > > > convention. > > > > > > This issue was detected by using the Coccinelle software. > > > > Is this really better? > > > > Perhaps this particular static analysis isn't too useful. > > The opinions are still evolving for such a kind of search pattern. > > > > Why not just allocate once and assign a second pointer? > > > > local_rqfpr = kmalloc_array(2 * (MAX_FILER_IDX + 1), > > sizeof(unsigned int), GFP_KERNEL); > > if (!local_rqfpr) > > goto err; > > > > local_rqfcr = &local_rqfpr[MAX_FILER_IDX + 1]; > > Do you suggest to use only one array (instead of two as before) here? That's a possibility. If, as your title suggests, you really want fewer function calls, (which as far as I saw, you didn't do) that could be a mechanism to remove both an allocation and a free. -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detection @ 2016-01-15 12:03 ` Joe Perches 0 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2016-01-15 12:03 UTC (permalink / raw) To: SF Markus Elfring, netdev Cc: Claudiu Manoil, LKML, kernel-janitors, Julia Lawall On Fri, 2016-01-15 at 12:47 +0100, SF Markus Elfring wrote: > > > * Return directly if a memory allocation failed at the beginning. > > > > > > * Adjust jump targets according to the Linux coding style > > > convention. > > > > > > This issue was detected by using the Coccinelle software. > > > > Is this really better? > > > > Perhaps this particular static analysis isn't too useful. > > The opinions are still evolving for such a kind of search pattern. > > > > Why not just allocate once and assign a second pointer? > > > > local_rqfpr = kmalloc_array(2 * (MAX_FILER_IDX + 1), > > sizeof(unsigned int), GFP_KERNEL); > > if (!local_rqfpr) > > goto err; > > > > local_rqfcr = &local_rqfpr[MAX_FILER_IDX + 1]; > > Do you suggest to use only one array (instead of two as before) here? That's a possibility. If, as your title suggests, you really want fewer function calls, (which as far as I saw, you didn't do) that could be a mechanism to remove both an allocation and a free. -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detection 2016-01-15 12:03 ` Joe Perches @ 2016-01-15 17:32 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-15 17:32 UTC (permalink / raw) To: Joe Perches, netdev; +Cc: Claudiu Manoil, LKML, kernel-janitors, Julia Lawall >>> local_rqfpr = kmalloc_array(2 * (MAX_FILER_IDX + 1), >>> sizeof(unsigned int), GFP_KERNEL); >>> if (!local_rqfpr) >>> goto err; >>> >>> local_rqfcr = &local_rqfpr[MAX_FILER_IDX + 1]; >> >> Do you suggest to use only one array (instead of two as before) here? > > That's a possibility. Thanks for your clarification. > If, as your title suggests, you really want fewer function calls, I am unsure at the moment if more changes will make sense in this function implementation. > (which as far as I saw, you didn't do) Is my wording "after error detection" insufficient eventually? > that could be a mechanism to remove both an allocation and a free. Would any more software developers or source code reviewers like to share their opinions in such a direction? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detection @ 2016-01-15 17:32 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-15 17:32 UTC (permalink / raw) To: Joe Perches, netdev; +Cc: Claudiu Manoil, LKML, kernel-janitors, Julia Lawall >>> local_rqfpr = kmalloc_array(2 * (MAX_FILER_IDX + 1), >>> sizeof(unsigned int), GFP_KERNEL); >>> if (!local_rqfpr) >>> goto err; >>> >>> local_rqfcr = &local_rqfpr[MAX_FILER_IDX + 1]; >> >> Do you suggest to use only one array (instead of two as before) here? > > That's a possibility. Thanks for your clarification. > If, as your title suggests, you really want fewer function calls, I am unsure at the moment if more changes will make sense in this function implementation. > (which as far as I saw, you didn't do) Is my wording "after error detection" insufficient eventually? > that could be a mechanism to remove both an allocation and a free. Would any more software developers or source code reviewers like to share their opinions in such a direction? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* RE: gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detection 2016-01-15 17:32 ` SF Markus Elfring (?) @ 2016-01-18 13:11 ` Claudiu Manoil -1 siblings, 0 replies; 3089+ messages in thread From: Claudiu Manoil @ 2016-01-18 13:11 UTC (permalink / raw) To: SF Markus Elfring; +Cc: Claudiu Manoil, LKML, kernel-janitors, netdev >-----Original Message----- >From: SF Markus Elfring [mailto:elfring@users.sourceforge.net] >Sent: Friday, January 15, 2016 7:33 PM >To: Joe Perches <joe@perches.com>; netdev@vger.kernel.org >Cc: Claudiu Manoil <claudiu.manoil@freescale.com>; LKML <linux- >kernel@vger.kernel.org>; kernel-janitors@vger.kernel.org; Julia Lawall ><julia.lawall@lip6.fr> >Subject: Re: gianfar: Less function calls in gfar_ethflow_to_filer_table() after >error detection > >>>> local_rqfpr = kmalloc_array(2 * (MAX_FILER_IDX + 1), >>>> sizeof(unsigned int), GFP_KERNEL); >>>> if (!local_rqfpr) >>>> goto err; >>>> >>>> local_rqfcr = &local_rqfpr[MAX_FILER_IDX + 1]; >>> >>> Do you suggest to use only one array (instead of two as before) here? >> >> That's a possibility. > >Thanks for your clarification. > > >> If, as your title suggests, you really want fewer function calls, > >I am unsure at the moment if more changes will make sense in >this function implementation. > > >> (which as far as I saw, you didn't do) > >Is my wording "after error detection" insufficient eventually? > > >> that could be a mechanism to remove both an allocation and a free. > >Would any more software developers or source code reviewers like >to share their opinions in such a direction? > Hi, This kind of fixes are net-next stuff at best, no need to push them into the net tree right now. So please wait with these submissions until net-next re-opens at least. Thanks. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH v3 2/3] gianfar: Delete unnecessary variable initialisations in gfar_ethflow_to_filer_table() 2016-01-15 10:09 ` SF Markus Elfring @ 2016-01-15 10:12 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-15 10:12 UTC (permalink / raw) To: netdev, Claudiu Manoil; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 15 Jan 2016 10:40:24 +0100 Omit explicit initialisation at the beginning for four local variables which are redefined before their first use. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/ethernet/freescale/gianfar_ethtool.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/freescale/gianfar_ethtool.c b/drivers/net/ethernet/freescale/gianfar_ethtool.c index 825b051..8302f7d 100644 --- a/drivers/net/ethernet/freescale/gianfar_ethtool.c +++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c @@ -768,12 +768,12 @@ static void ethflow_to_filer_rules (struct gfar_private *priv, u64 ethflow) static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, u64 class) { - unsigned int last_rule_idx = priv->cur_filer_idx; + unsigned int last_rule_idx; unsigned int cmp_rqfpr; unsigned int *local_rqfpr; unsigned int *local_rqfcr; - int i = 0x0, k = 0x0; - int j = MAX_FILER_IDX, l = 0x0; + int i, k, l; + int j = MAX_FILER_IDX; int ret = 1; local_rqfpr = kmalloc_array(MAX_FILER_IDX + 1, sizeof(unsigned int), -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH v3 2/3] gianfar: Delete unnecessary variable initialisations in gfar_ethflow_to_filer_table() @ 2016-01-15 10:12 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-15 10:12 UTC (permalink / raw) To: netdev, Claudiu Manoil; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 15 Jan 2016 10:40:24 +0100 Omit explicit initialisation at the beginning for four local variables which are redefined before their first use. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/ethernet/freescale/gianfar_ethtool.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/freescale/gianfar_ethtool.c b/drivers/net/ethernet/freescale/gianfar_ethtool.c index 825b051..8302f7d 100644 --- a/drivers/net/ethernet/freescale/gianfar_ethtool.c +++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c @@ -768,12 +768,12 @@ static void ethflow_to_filer_rules (struct gfar_private *priv, u64 ethflow) static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, u64 class) { - unsigned int last_rule_idx = priv->cur_filer_idx; + unsigned int last_rule_idx; unsigned int cmp_rqfpr; unsigned int *local_rqfpr; unsigned int *local_rqfcr; - int i = 0x0, k = 0x0; - int j = MAX_FILER_IDX, l = 0x0; + int i, k, l; + int j = MAX_FILER_IDX; int ret = 1; local_rqfpr = kmalloc_array(MAX_FILER_IDX + 1, sizeof(unsigned int), -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH v3 2/3] gianfar: Delete unnecessary variable initialisations in gfar_ethflow_to_filer_table() 2016-01-15 10:12 ` SF Markus Elfring @ 2016-01-15 10:29 ` Dan Carpenter -1 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2016-01-15 10:29 UTC (permalink / raw) To: SF Markus Elfring Cc: netdev, Claudiu Manoil, LKML, kernel-janitors, Julia Lawall On Fri, Jan 15, 2016 at 11:12:42AM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 15 Jan 2016 10:40:24 +0100 > > Omit explicit initialisation at the beginning for four local variables > which are redefined before their first use. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/net/ethernet/freescale/gianfar_ethtool.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/net/ethernet/freescale/gianfar_ethtool.c b/drivers/net/ethernet/freescale/gianfar_ethtool.c > index 825b051..8302f7d 100644 > --- a/drivers/net/ethernet/freescale/gianfar_ethtool.c > +++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c > @@ -768,12 +768,12 @@ static void ethflow_to_filer_rules (struct gfar_private *priv, u64 ethflow) > static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, > u64 class) > { > - unsigned int last_rule_idx = priv->cur_filer_idx; > + unsigned int last_rule_idx; This is a write only variable. We can just remove it. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH v3 2/3] gianfar: Delete unnecessary variable initialisations in gfar_ethflow_to_filer_tab @ 2016-01-15 10:29 ` Dan Carpenter 0 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2016-01-15 10:29 UTC (permalink / raw) To: SF Markus Elfring Cc: netdev, Claudiu Manoil, LKML, kernel-janitors, Julia Lawall On Fri, Jan 15, 2016 at 11:12:42AM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 15 Jan 2016 10:40:24 +0100 > > Omit explicit initialisation at the beginning for four local variables > which are redefined before their first use. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/net/ethernet/freescale/gianfar_ethtool.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/net/ethernet/freescale/gianfar_ethtool.c b/drivers/net/ethernet/freescale/gianfar_ethtool.c > index 825b051..8302f7d 100644 > --- a/drivers/net/ethernet/freescale/gianfar_ethtool.c > +++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c > @@ -768,12 +768,12 @@ static void ethflow_to_filer_rules (struct gfar_private *priv, u64 ethflow) > static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, > u64 class) > { > - unsigned int last_rule_idx = priv->cur_filer_idx; > + unsigned int last_rule_idx; This is a write only variable. We can just remove it. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH v3 2/3] gianfar: Delete unnecessary variable initialisations in gfar_ethflow_to_filer_table() 2016-01-15 10:29 ` [PATCH v3 2/3] gianfar: Delete unnecessary variable initialisations in gfar_ethflow_to_filer_tab Dan Carpenter @ 2016-01-15 11:34 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-15 11:34 UTC (permalink / raw) To: Dan Carpenter, netdev; +Cc: Claudiu Manoil, LKML, kernel-janitors, Julia Lawall >> +++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c >> @@ -768,12 +768,12 @@ static void ethflow_to_filer_rules (struct gfar_private *priv, u64 ethflow) >> static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, >> u64 class) >> { >> - unsigned int last_rule_idx = priv->cur_filer_idx; >> + unsigned int last_rule_idx; > > This is a write only variable. We can just remove it. Can a static source code analysis tool like the software "http://smatch.sourceforge.net/" detect that such a variable is not read by this function implementation so far? https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/net/ethernet/freescale/gianfar_ethtool.c?id=b75ec3af27bf011a760e2f44eb25a99b6fbb0fb3#n850 Does this place indicate an unwanted value assignment as a leftover, or are there any other actions missing? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH v3 2/3] gianfar: Delete unnecessary variable initialisations in gfar_ethflow_to_filer_tab @ 2016-01-15 11:34 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-15 11:34 UTC (permalink / raw) To: Dan Carpenter, netdev; +Cc: Claudiu Manoil, LKML, kernel-janitors, Julia Lawall >> +++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c >> @@ -768,12 +768,12 @@ static void ethflow_to_filer_rules (struct gfar_private *priv, u64 ethflow) >> static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, >> u64 class) >> { >> - unsigned int last_rule_idx = priv->cur_filer_idx; >> + unsigned int last_rule_idx; > > This is a write only variable. We can just remove it. Can a static source code analysis tool like the software "http://smatch.sourceforge.net/" detect that such a variable is not read by this function implementation so far? https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/net/ethernet/freescale/gianfar_ethtool.c?id·5ec3af27bf011a760e2f44eb25a99b6fbb0fb3#n850 Does this place indicate an unwanted value assignment as a leftover, or are there any other actions missing? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH v3 2/3] gianfar: Delete unnecessary variable initialisations in gfar_ethflow_to_filer_table() 2016-01-15 11:34 ` [PATCH v3 2/3] gianfar: Delete unnecessary variable initialisations in gfar_ethflow_to_filer_tab SF Markus Elfring @ 2016-01-15 12:15 ` Dan Carpenter -1 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2016-01-15 12:15 UTC (permalink / raw) To: SF Markus Elfring Cc: netdev, Claudiu Manoil, LKML, kernel-janitors, Julia Lawall On Fri, Jan 15, 2016 at 12:34:33PM +0100, SF Markus Elfring wrote: > >> +++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c > >> @@ -768,12 +768,12 @@ static void ethflow_to_filer_rules (struct gfar_private *priv, u64 ethflow) > >> static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, > >> u64 class) > >> { > >> - unsigned int last_rule_idx = priv->cur_filer_idx; > >> + unsigned int last_rule_idx; > > > > This is a write only variable. We can just remove it. > > Can a static source code analysis tool like the software "http://smatch.sourceforge.net/" > detect that such a variable is not read by this function implementation so far? Yeah. That's a good idea. I will do that. > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/net/ethernet/freescale/gianfar_ethtool.c?id=b75ec3af27bf011a760e2f44eb25a99b6fbb0fb3#n850 > > Does this place indicate an unwanted value assignment as a leftover, > or are there any other actions missing? I think it's just an extra variable and you can just delete it. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH v3 2/3] gianfar: Delete unnecessary variable initialisations in gfar_ethflow_to_filer_tab @ 2016-01-15 12:15 ` Dan Carpenter 0 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2016-01-15 12:15 UTC (permalink / raw) To: SF Markus Elfring Cc: netdev, Claudiu Manoil, LKML, kernel-janitors, Julia Lawall On Fri, Jan 15, 2016 at 12:34:33PM +0100, SF Markus Elfring wrote: > >> +++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c > >> @@ -768,12 +768,12 @@ static void ethflow_to_filer_rules (struct gfar_private *priv, u64 ethflow) > >> static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, > >> u64 class) > >> { > >> - unsigned int last_rule_idx = priv->cur_filer_idx; > >> + unsigned int last_rule_idx; > > > > This is a write only variable. We can just remove it. > > Can a static source code analysis tool like the software "http://smatch.sourceforge.net/" > detect that such a variable is not read by this function implementation so far? Yeah. That's a good idea. I will do that. > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/net/ethernet/freescale/gianfar_ethtool.c?id·5ec3af27bf011a760e2f44eb25a99b6fbb0fb3#n850 > > Does this place indicate an unwanted value assignment as a leftover, > or are there any other actions missing? I think it's just an extra variable and you can just delete it. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH v3 2/3] gianfar: Delete unnecessary variable initialisations in gfar_ethflow_to_filer_table() 2016-01-15 11:34 ` [PATCH v3 2/3] gianfar: Delete unnecessary variable initialisations in gfar_ethflow_to_filer_tab SF Markus Elfring @ 2016-01-15 16:42 ` David Miller -1 siblings, 0 replies; 3089+ messages in thread From: David Miller @ 2016-01-15 16:42 UTC (permalink / raw) To: elfring Cc: dan.carpenter, netdev, claudiu.manoil, linux-kernel, kernel-janitors, julia.lawall From: SF Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 15 Jan 2016 12:34:33 +0100 >>> +++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c >>> @@ -768,12 +768,12 @@ static void ethflow_to_filer_rules (struct gfar_private *priv, u64 ethflow) >>> static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, >>> u64 class) >>> { >>> - unsigned int last_rule_idx = priv->cur_filer_idx; >>> + unsigned int last_rule_idx; >> >> This is a write only variable. We can just remove it. > > Can a static source code analysis tool like the software "http://smatch.sourceforge.net/" > detect that such a variable is not read by this function implementation so far? No, but a human can. And a human should fully analyze any change he writes based upon static analysis tool results. I am going to be honest, and say that I am completely ignoring most of your static checker patches. You don't put enough care and consideration into them, and I really don't have time to waste on looking at something like that. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH v3 2/3] gianfar: Delete unnecessary variable initialisations in gfar_ethflow_to_filer_tab @ 2016-01-15 16:42 ` David Miller 0 siblings, 0 replies; 3089+ messages in thread From: David Miller @ 2016-01-15 16:42 UTC (permalink / raw) To: elfring Cc: dan.carpenter, netdev, claudiu.manoil, linux-kernel, kernel-janitors, julia.lawall From: SF Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 15 Jan 2016 12:34:33 +0100 >>> +++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c >>> @@ -768,12 +768,12 @@ static void ethflow_to_filer_rules (struct gfar_private *priv, u64 ethflow) >>> static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, >>> u64 class) >>> { >>> - unsigned int last_rule_idx = priv->cur_filer_idx; >>> + unsigned int last_rule_idx; >> >> This is a write only variable. We can just remove it. > > Can a static source code analysis tool like the software "http://smatch.sourceforge.net/" > detect that such a variable is not read by this function implementation so far? No, but a human can. And a human should fully analyze any change he writes based upon static analysis tool results. I am going to be honest, and say that I am completely ignoring most of your static checker patches. You don't put enough care and consideration into them, and I really don't have time to waste on looking at something like that. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: gianfar: Delete unnecessary variable initialisations in gfar_ethflow_to_filer_table() 2016-01-15 16:42 ` [PATCH v3 2/3] gianfar: Delete unnecessary variable initialisations in gfar_ethflow_to_filer_tab David Miller @ 2016-01-15 17:15 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-15 17:15 UTC (permalink / raw) To: David Miller, Dan Carpenter Cc: netdev, Claudiu Manoil, linux-kernel, kernel-janitors, Julia Lawall >>> This is a write only variable. We can just remove it. >> >> Can a static source code analysis tool like the software "http://smatch.sourceforge.net/" >> detect that such a variable is not read by this function implementation so far? > > No, I imagine that there are a few tools available which can point such update candidates out. There are various software development challenges to consider. > but a human can. Some software developers and source code reviewers are struggling with mentioned implementation details as usual. Do they also wonder how the discussed variable assignment was left over in a specific function? > I am going to be honest, and say that I am completely ignoring most of > your static checker patches. I am curious if you would reconsider the affected source code places once more when you will be notified about related issues by other tools or persons. > You don't put enough care and consideration into them, Would you like to explain this impression a bit more? > and I really don't have time to waste on looking at something like that. Thanks for your feedback. Various open issues are competing for our attention as usual. Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: gianfar: Delete unnecessary variable initialisations in gfar_ethflow_to_filer_table() @ 2016-01-15 17:15 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-15 17:15 UTC (permalink / raw) To: David Miller, Dan Carpenter Cc: netdev, Claudiu Manoil, linux-kernel, kernel-janitors, Julia Lawall >>> This is a write only variable. We can just remove it. >> >> Can a static source code analysis tool like the software "http://smatch.sourceforge.net/" >> detect that such a variable is not read by this function implementation so far? > > No, I imagine that there are a few tools available which can point such update candidates out. There are various software development challenges to consider. > but a human can. Some software developers and source code reviewers are struggling with mentioned implementation details as usual. Do they also wonder how the discussed variable assignment was left over in a specific function? > I am going to be honest, and say that I am completely ignoring most of > your static checker patches. I am curious if you would reconsider the affected source code places once more when you will be notified about related issues by other tools or persons. > You don't put enough care and consideration into them, Would you like to explain this impression a bit more? > and I really don't have time to waste on looking at something like that. Thanks for your feedback. Various open issues are competing for our attention as usual. Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH v3 3/3] gianfar: Extend an initialisation clause of a for loop in gfar_ethflow_to_filer_table() 2016-01-15 10:09 ` SF Markus Elfring @ 2016-01-15 10:14 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-15 10:14 UTC (permalink / raw) To: netdev, Claudiu Manoil; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 15 Jan 2016 10:50:34 +0100 Move the assignment for the variable "j" from the beginning into an initialisation clause of a for loop. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/ethernet/freescale/gianfar_ethtool.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/freescale/gianfar_ethtool.c b/drivers/net/ethernet/freescale/gianfar_ethtool.c index 8302f7d..2162adc 100644 --- a/drivers/net/ethernet/freescale/gianfar_ethtool.c +++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c @@ -772,8 +772,7 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, unsigned int cmp_rqfpr; unsigned int *local_rqfpr; unsigned int *local_rqfcr; - int i, k, l; - int j = MAX_FILER_IDX; + int i, j, k, l; int ret = 1; local_rqfpr = kmalloc_array(MAX_FILER_IDX + 1, sizeof(unsigned int), @@ -807,7 +806,7 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, goto free_fcr; } - for (i = 0; i < MAX_FILER_IDX + 1; i++) { + for (i = 0, j = MAX_FILER_IDX; i < MAX_FILER_IDX + 1; i++) { local_rqfpr[j] = priv->ftp_rqfpr[i]; local_rqfcr[j] = priv->ftp_rqfcr[i]; j--; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH v3 3/3] gianfar: Extend an initialisation clause of a for loop in gfar_ethflow_to_filer_table @ 2016-01-15 10:14 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-15 10:14 UTC (permalink / raw) To: netdev, Claudiu Manoil; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 15 Jan 2016 10:50:34 +0100 Move the assignment for the variable "j" from the beginning into an initialisation clause of a for loop. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/ethernet/freescale/gianfar_ethtool.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/freescale/gianfar_ethtool.c b/drivers/net/ethernet/freescale/gianfar_ethtool.c index 8302f7d..2162adc 100644 --- a/drivers/net/ethernet/freescale/gianfar_ethtool.c +++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c @@ -772,8 +772,7 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, unsigned int cmp_rqfpr; unsigned int *local_rqfpr; unsigned int *local_rqfcr; - int i, k, l; - int j = MAX_FILER_IDX; + int i, j, k, l; int ret = 1; local_rqfpr = kmalloc_array(MAX_FILER_IDX + 1, sizeof(unsigned int), @@ -807,7 +806,7 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, goto free_fcr; } - for (i = 0; i < MAX_FILER_IDX + 1; i++) { + for (i = 0, j = MAX_FILER_IDX; i < MAX_FILER_IDX + 1; i++) { local_rqfpr[j] = priv->ftp_rqfpr[i]; local_rqfcr[j] = priv->ftp_rqfcr[i]; j--; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH] net-i40e: Replace variable initialisations by assignments in i40e_vc_get_vf_resources_msg() 2015-12-11 12:08 ` SF Markus Elfring (?) @ 2016-01-01 14:32 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 14:32 UTC (permalink / raw) To: netdev, intel-wired-lan, Bruce Allan, Carolyn Wyborny, Don Skidmore, Jeff Kirsher, Jesse Brandeburg, John Ronciak, Mitch Williams, Shannon Nelson Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 15:11:09 +0100 Replace explicit initialisations for four local variables at the beginning by assignments that will only be performed if the corresponding code will really be executed. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c index aa58a49..e0874f5 100644 --- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c +++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c @@ -1172,16 +1172,18 @@ static int i40e_vc_get_version_msg(struct i40e_vf *vf, u8 *msg) **/ static int i40e_vc_get_vf_resources_msg(struct i40e_vf *vf, u8 *msg) { - struct i40e_virtchnl_vf_resource *vfres = NULL; - struct i40e_pf *pf = vf->pf; - i40e_status aq_ret = 0; + struct i40e_virtchnl_vf_resource *vfres; + struct i40e_pf *pf; + i40e_status aq_ret; struct i40e_vsi *vsi; - int i = 0, len = 0; + int i = 0; int num_vsis = 1; - int ret; + int len, ret; if (!test_bit(I40E_VF_STAT_INIT, &vf->vf_states)) { aq_ret = I40E_ERR_PARAM; + vfres = NULL; + len = 0; goto err; } @@ -1202,6 +1204,7 @@ static int i40e_vc_get_vf_resources_msg(struct i40e_vf *vf, u8 *msg) I40E_VIRTCHNL_VF_OFFLOAD_VLAN; vfres->vf_offload_flags = I40E_VIRTCHNL_VF_OFFLOAD_L2; + pf = vf->pf; vsi = pf->vsi[vf->lan_vsi_idx]; if (!vsi->info.pvid) vfres->vf_offload_flags |= I40E_VIRTCHNL_VF_OFFLOAD_VLAN; @@ -1231,7 +1234,7 @@ static int i40e_vc_get_vf_resources_msg(struct i40e_vf *vf, u8 *msg) i++; } set_bit(I40E_VF_STAT_ACTIVE, &vf->vf_states); - + aq_ret = 0; err: /* send the response back to the VF */ ret = i40e_vc_send_msg_to_vf(vf, I40E_VIRTCHNL_OP_GET_VF_RESOURCES, -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [Intel-wired-lan] [PATCH] net-i40e: Replace variable initialisations by assignments in i40e_vc_get_vf_resources_msg() @ 2016-01-01 14:32 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 14:32 UTC (permalink / raw) To: intel-wired-lan From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 15:11:09 +0100 Replace explicit initialisations for four local variables at the beginning by assignments that will only be performed if the corresponding code will really be executed. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c index aa58a49..e0874f5 100644 --- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c +++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c @@ -1172,16 +1172,18 @@ static int i40e_vc_get_version_msg(struct i40e_vf *vf, u8 *msg) **/ static int i40e_vc_get_vf_resources_msg(struct i40e_vf *vf, u8 *msg) { - struct i40e_virtchnl_vf_resource *vfres = NULL; - struct i40e_pf *pf = vf->pf; - i40e_status aq_ret = 0; + struct i40e_virtchnl_vf_resource *vfres; + struct i40e_pf *pf; + i40e_status aq_ret; struct i40e_vsi *vsi; - int i = 0, len = 0; + int i = 0; int num_vsis = 1; - int ret; + int len, ret; if (!test_bit(I40E_VF_STAT_INIT, &vf->vf_states)) { aq_ret = I40E_ERR_PARAM; + vfres = NULL; + len = 0; goto err; } @@ -1202,6 +1204,7 @@ static int i40e_vc_get_vf_resources_msg(struct i40e_vf *vf, u8 *msg) I40E_VIRTCHNL_VF_OFFLOAD_VLAN; vfres->vf_offload_flags = I40E_VIRTCHNL_VF_OFFLOAD_L2; + pf = vf->pf; vsi = pf->vsi[vf->lan_vsi_idx]; if (!vsi->info.pvid) vfres->vf_offload_flags |= I40E_VIRTCHNL_VF_OFFLOAD_VLAN; @@ -1231,7 +1234,7 @@ static int i40e_vc_get_vf_resources_msg(struct i40e_vf *vf, u8 *msg) i++; } set_bit(I40E_VF_STAT_ACTIVE, &vf->vf_states); - + aq_ret = 0; err: /* send the response back to the VF */ ret = i40e_vc_send_msg_to_vf(vf, I40E_VIRTCHNL_OP_GET_VF_RESOURCES, -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH] net-i40e: Replace variable initialisations by assignments in i40e_vc_get_vf_resources_msg() @ 2016-01-01 14:32 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 14:32 UTC (permalink / raw) To: netdev, intel-wired-lan, Bruce Allan, Carolyn Wyborny, Don Skidmore, Jeff Kirsher, Jesse Brandeburg, John Ronciak, Mitch Williams, Shannon Nelson Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 15:11:09 +0100 Replace explicit initialisations for four local variables at the beginning by assignments that will only be performed if the corresponding code will really be executed. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c index aa58a49..e0874f5 100644 --- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c +++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c @@ -1172,16 +1172,18 @@ static int i40e_vc_get_version_msg(struct i40e_vf *vf, u8 *msg) **/ static int i40e_vc_get_vf_resources_msg(struct i40e_vf *vf, u8 *msg) { - struct i40e_virtchnl_vf_resource *vfres = NULL; - struct i40e_pf *pf = vf->pf; - i40e_status aq_ret = 0; + struct i40e_virtchnl_vf_resource *vfres; + struct i40e_pf *pf; + i40e_status aq_ret; struct i40e_vsi *vsi; - int i = 0, len = 0; + int i = 0; int num_vsis = 1; - int ret; + int len, ret; if (!test_bit(I40E_VF_STAT_INIT, &vf->vf_states)) { aq_ret = I40E_ERR_PARAM; + vfres = NULL; + len = 0; goto err; } @@ -1202,6 +1204,7 @@ static int i40e_vc_get_vf_resources_msg(struct i40e_vf *vf, u8 *msg) I40E_VIRTCHNL_VF_OFFLOAD_VLAN; vfres->vf_offload_flags = I40E_VIRTCHNL_VF_OFFLOAD_L2; + pf = vf->pf; vsi = pf->vsi[vf->lan_vsi_idx]; if (!vsi->info.pvid) vfres->vf_offload_flags |= I40E_VIRTCHNL_VF_OFFLOAD_VLAN; @@ -1231,7 +1234,7 @@ static int i40e_vc_get_vf_resources_msg(struct i40e_vf *vf, u8 *msg) i++; } set_bit(I40E_VF_STAT_ACTIVE, &vf->vf_states); - + aq_ret = 0; err: /* send the response back to the VF */ ret = i40e_vc_send_msg_to_vf(vf, I40E_VIRTCHNL_OP_GET_VF_RESOURCES, -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* net-i40e: Reconsider further usage of variable "i" in i40e_vc_get_vf_resources_msg() 2016-01-01 14:32 ` SF Markus Elfring (?) @ 2016-01-01 14:51 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 14:51 UTC (permalink / raw) To: netdev, intel-wired-lan, Bruce Allan, Carolyn Wyborny, Don Skidmore, Jeff Kirsher, Jesse Brandeburg, John Ronciak, Mitch Williams, Shannon Nelson Cc: kernel-janitors Hello, I have taken another look at the implementation of the function "i40e_vc_get_vf_resources_msg". I find the use of the variable "i" strange there. It seems that the value from the increment operation in an if branch is not reused so far. I would appreciate a further clarification. Can this variable be eventually deleted? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [Intel-wired-lan] net-i40e: Reconsider further usage of variable "i" in i40e_vc_get_vf_resources_msg() @ 2016-01-01 14:51 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 14:51 UTC (permalink / raw) To: intel-wired-lan Hello, I have taken another look at the implementation of the function "i40e_vc_get_vf_resources_msg". I find the use of the variable "i" strange there. It seems that the value from the increment operation in an if branch is not reused so far. I would appreciate a further clarification. Can this variable be eventually deleted? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* net-i40e: Reconsider further usage of variable "i" in i40e_vc_get_vf_resources_msg() @ 2016-01-01 14:51 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 14:51 UTC (permalink / raw) To: netdev, intel-wired-lan, Bruce Allan, Carolyn Wyborny, Don Skidmore, Jeff Kirsher, Jesse Brandeburg, John Ronciak, Mitch Williams, Shannon Nelson Cc: kernel-janitors Hello, I have taken another look at the implementation of the function "i40e_vc_get_vf_resources_msg". I find the use of the variable "i" strange there. It seems that the value from the increment operation in an if branch is not reused so far. I would appreciate a further clarification. Can this variable be eventually deleted? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* RE: net-i40e: Reconsider further usage of variable "i" in i40e_vc_get_vf_resources_msg() 2016-01-01 14:51 ` SF Markus Elfring (?) @ 2016-01-08 20:51 ` Nelson, Shannon -1 siblings, 0 replies; 3089+ messages in thread From: Nelson, Shannon @ 2016-01-08 20:51 UTC (permalink / raw) To: SF Markus Elfring, netdev, intel-wired-lan, Allan, Bruce W, Wyborny, Carolyn, Skidmore, Donald C, Kirsher, Jeffrey T, Brandeburg, Jesse, Ronciak, John, Williams, Mitch A Cc: kernel-janitors > From: SF Markus Elfring [mailto:elfring@users.sourceforge.net] > > Hello, > > I have taken another look at the implementation of the > function "i40e_vc_get_vf_resources_msg". I find the use of the variable > "i" > strange there. It seems that the value from the increment operation in > an > if branch is not reused so far. > > I would appreciate a further clarification. > Can this variable be eventually deleted? Thanks for pointing this out. We've got an internal patch coming that will address this. Cheers, sln ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [Intel-wired-lan] net-i40e: Reconsider further usage of variable "i" in i40e_vc_get_vf_resources_msg() @ 2016-01-08 20:51 ` Nelson, Shannon 0 siblings, 0 replies; 3089+ messages in thread From: Nelson, Shannon @ 2016-01-08 20:51 UTC (permalink / raw) To: intel-wired-lan > From: SF Markus Elfring [mailto:elfring at users.sourceforge.net] > > Hello, > > I have taken another look at the implementation of the > function "i40e_vc_get_vf_resources_msg". I find the use of the variable > "i" > strange there. It seems that the value from the increment operation in > an > if branch is not reused so far. > > I would appreciate a further clarification. > Can this variable be eventually deleted? Thanks for pointing this out. We've got an internal patch coming that will address this. Cheers, sln ^ permalink raw reply [flat|nested] 3089+ messages in thread
* RE: net-i40e: Reconsider further usage of variable "i" in i40e_vc_get_vf_resources_msg() @ 2016-01-08 20:51 ` Nelson, Shannon 0 siblings, 0 replies; 3089+ messages in thread From: Nelson, Shannon @ 2016-01-08 20:51 UTC (permalink / raw) To: SF Markus Elfring, netdev, intel-wired-lan, Allan, Bruce W, Wyborny, Carolyn, Skidmore, Donald C, Kirsher, Jeffrey T, Brandeburg, Jesse, Ronciak, John, Williams, Mitch A Cc: kernel-janitors PiBGcm9tOiBTRiBNYXJrdXMgRWxmcmluZyBbbWFpbHRvOmVsZnJpbmdAdXNlcnMuc291cmNlZm9y Z2UubmV0XQ0KPiANCj4gSGVsbG8sDQo+IA0KPiBJIGhhdmUgdGFrZW4gYW5vdGhlciBsb29rIGF0 IHRoZSBpbXBsZW1lbnRhdGlvbiBvZiB0aGUNCj4gZnVuY3Rpb24gImk0MGVfdmNfZ2V0X3ZmX3Jl c291cmNlc19tc2ciLiBJIGZpbmQgdGhlIHVzZSBvZiB0aGUgdmFyaWFibGUNCj4gImkiDQo+IHN0 cmFuZ2UgdGhlcmUuIEl0IHNlZW1zIHRoYXQgdGhlIHZhbHVlIGZyb20gdGhlIGluY3JlbWVudCBv cGVyYXRpb24gaW4NCj4gYW4NCj4gaWYgYnJhbmNoIGlzIG5vdCByZXVzZWQgc28gZmFyLg0KPiAN Cj4gSSB3b3VsZCBhcHByZWNpYXRlIGEgZnVydGhlciBjbGFyaWZpY2F0aW9uLg0KPiBDYW4gdGhp cyB2YXJpYWJsZSBiZSBldmVudHVhbGx5IGRlbGV0ZWQ/DQoNClRoYW5rcyBmb3IgcG9pbnRpbmcg dGhpcyBvdXQuICBXZSd2ZSBnb3QgYW4gaW50ZXJuYWwgcGF0Y2ggY29taW5nIHRoYXQgd2lsbCBh ZGRyZXNzIHRoaXMuDQoNCkNoZWVycywNCnNsbg0K ^ permalink raw reply [flat|nested] 3089+ messages in thread
* RE: [PATCH] net-i40e: Replace variable initialisations by assignments in i40e_vc_get_vf_resources_msg() 2016-01-01 14:32 ` SF Markus Elfring (?) @ 2016-01-07 22:43 ` Nelson, Shannon -1 siblings, 0 replies; 3089+ messages in thread From: Nelson, Shannon @ 2016-01-07 22:43 UTC (permalink / raw) To: SF Markus Elfring, netdev, intel-wired-lan, Allan, Bruce W, Wyborny, Carolyn, Skidmore, Donald C, Kirsher, Jeffrey T, Brandeburg, Jesse, Ronciak, John, Williams, Mitch A Cc: LKML, kernel-janitors, Julia Lawall > From: SF Markus Elfring [mailto:elfring@users.sourceforge.net] > Sent: Friday, January 01, 2016 6:33 AM > > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 15:11:09 +0100 > > Replace explicit initialisations for four local variables at the beginning > by assignments that will only be performed if the corresponding code > will really be executed. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- This seems to me to be unnecessary fussing with the code. sln ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [Intel-wired-lan] [PATCH] net-i40e: Replace variable initialisations by assignments in i40e_vc_get_vf_resources_msg() @ 2016-01-07 22:43 ` Nelson, Shannon 0 siblings, 0 replies; 3089+ messages in thread From: Nelson, Shannon @ 2016-01-07 22:43 UTC (permalink / raw) To: intel-wired-lan > From: SF Markus Elfring [mailto:elfring at users.sourceforge.net] > Sent: Friday, January 01, 2016 6:33 AM > > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 15:11:09 +0100 > > Replace explicit initialisations for four local variables at the beginning > by assignments that will only be performed if the corresponding code > will really be executed. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- This seems to me to be unnecessary fussing with the code. sln ^ permalink raw reply [flat|nested] 3089+ messages in thread
* RE: [PATCH] net-i40e: Replace variable initialisations by assignments in i40e_vc_get_vf_resources_ms @ 2016-01-07 22:43 ` Nelson, Shannon 0 siblings, 0 replies; 3089+ messages in thread From: Nelson, Shannon @ 2016-01-07 22:43 UTC (permalink / raw) To: SF Markus Elfring, netdev, intel-wired-lan, Allan, Bruce W, Wyborny, Carolyn, Skidmore, Donald C, Kirsher, Jeffrey T, Brandeburg, Jesse, Ronciak, John, Williams, Mitch A Cc: LKML, kernel-janitors, Julia Lawall PiBGcm9tOiBTRiBNYXJrdXMgRWxmcmluZyBbbWFpbHRvOmVsZnJpbmdAdXNlcnMuc291cmNlZm9y Z2UubmV0XQ0KPiBTZW50OiBGcmlkYXksIEphbnVhcnkgMDEsIDIwMTYgNjozMyBBTQ0KPiANCj4g RnJvbTogTWFya3VzIEVsZnJpbmcgPGVsZnJpbmdAdXNlcnMuc291cmNlZm9yZ2UubmV0Pg0KPiBE YXRlOiBGcmksIDEgSmFuIDIwMTYgMTU6MTE6MDkgKzAxMDANCj4gDQo+IFJlcGxhY2UgZXhwbGlj aXQgaW5pdGlhbGlzYXRpb25zIGZvciBmb3VyIGxvY2FsIHZhcmlhYmxlcyBhdCB0aGUgYmVnaW5u aW5nDQo+IGJ5IGFzc2lnbm1lbnRzIHRoYXQgd2lsbCBvbmx5IGJlIHBlcmZvcm1lZCBpZiB0aGUg Y29ycmVzcG9uZGluZyBjb2RlDQo+IHdpbGwgcmVhbGx5IGJlIGV4ZWN1dGVkLg0KPiANCj4gU2ln bmVkLW9mZi1ieTogTWFya3VzIEVsZnJpbmcgPGVsZnJpbmdAdXNlcnMuc291cmNlZm9yZ2UubmV0 Pg0KPiAtLS0NCg0KVGhpcyBzZWVtcyB0byBtZSB0byBiZSB1bm5lY2Vzc2FyeSBmdXNzaW5nIHdp dGggdGhlIGNvZGUuDQoNCnNsbg0KDQo ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] net-i40e: Replace variable initialisations by assignments in i40e_vc_get_vf_resources_msg() 2016-01-01 14:32 ` SF Markus Elfring (?) @ 2016-01-08 10:42 ` Jeff Kirsher -1 siblings, 0 replies; 3089+ messages in thread From: Jeff Kirsher @ 2016-01-08 10:42 UTC (permalink / raw) To: SF Markus Elfring, netdev, intel-wired-lan, Bruce Allan, Carolyn Wyborny, Don Skidmore, Jesse Brandeburg, John Ronciak, Mitch Williams, Shannon Nelson Cc: LKML, kernel-janitors, Julia Lawall [-- Attachment #1: Type: text/plain, Size: 605 bytes --] On Fri, 2016-01-01 at 15:32 +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 15:11:09 +0100 > > Replace explicit initialisations for four local variables at the > beginning > by assignments that will only be performed if the corresponding code > will really be executed. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 15 +++++++++--- > --- > 1 file changed, 9 insertions(+), 6 deletions(-) Dropping this patch based on feedback from Shannon. [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [Intel-wired-lan] [PATCH] net-i40e: Replace variable initialisations by assignments in i40e_vc_get_vf_resources_msg() @ 2016-01-08 10:42 ` Jeff Kirsher 0 siblings, 0 replies; 3089+ messages in thread From: Jeff Kirsher @ 2016-01-08 10:42 UTC (permalink / raw) To: intel-wired-lan On Fri, 2016-01-01 at 15:32 +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 15:11:09 +0100 > > Replace explicit initialisations for four local variables at the > beginning > by assignments that will only be performed if the corresponding code > will really be executed. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > ?drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 15 +++++++++--- > --- > ?1 file changed, 9 insertions(+), 6 deletions(-) Dropping this patch based on feedback from Shannon. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20160108/d5613803/attachment.asc> ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] net-i40e: Replace variable initialisations by assignments in i40e_vc_get_vf_resources_ms @ 2016-01-08 10:42 ` Jeff Kirsher 0 siblings, 0 replies; 3089+ messages in thread From: Jeff Kirsher @ 2016-01-08 10:42 UTC (permalink / raw) To: SF Markus Elfring, netdev, intel-wired-lan, Bruce Allan, Carolyn Wyborny, Don Skidmore, Jesse Brandeburg, John Ronciak, Mitch Williams, Shannon Nelson Cc: LKML, kernel-janitors, Julia Lawall [-- Attachment #1: Type: text/plain, Size: 605 bytes --] On Fri, 2016-01-01 at 15:32 +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 15:11:09 +0100 > > Replace explicit initialisations for four local variables at the > beginning > by assignments that will only be performed if the corresponding code > will really be executed. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 15 +++++++++--- > --- > 1 file changed, 9 insertions(+), 6 deletions(-) Dropping this patch based on feedback from Shannon. [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH] net-huawei_cdc_ncm: Delete an unnecessary variable initialisation in huawei_cdc_ncm_bind() 2015-12-11 12:08 ` SF Markus Elfring @ 2016-01-01 15:57 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 15:57 UTC (permalink / raw) To: linux-usb, netdev; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 16:54:13 +0100 Omit explicit initialisation at the beginning for one local variable that is redefined before its first use. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/usb/huawei_cdc_ncm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/usb/huawei_cdc_ncm.c b/drivers/net/usb/huawei_cdc_ncm.c index 2680a65..53caeb3 100644 --- a/drivers/net/usb/huawei_cdc_ncm.c +++ b/drivers/net/usb/huawei_cdc_ncm.c @@ -71,7 +71,7 @@ static int huawei_cdc_ncm_bind(struct usbnet *usbnet_dev, { struct cdc_ncm_ctx *ctx; struct usb_driver *subdriver = ERR_PTR(-ENODEV); - int ret = -ENODEV; + int ret; struct huawei_cdc_ncm_state *drvstate = (void *)&usbnet_dev->data; int drvflags = 0; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH] net-huawei_cdc_ncm: Delete an unnecessary variable initialisation in huawei_cdc_ncm_bind() @ 2016-01-01 15:57 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 15:57 UTC (permalink / raw) To: linux-usb, netdev; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 16:54:13 +0100 Omit explicit initialisation at the beginning for one local variable that is redefined before its first use. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/usb/huawei_cdc_ncm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/usb/huawei_cdc_ncm.c b/drivers/net/usb/huawei_cdc_ncm.c index 2680a65..53caeb3 100644 --- a/drivers/net/usb/huawei_cdc_ncm.c +++ b/drivers/net/usb/huawei_cdc_ncm.c @@ -71,7 +71,7 @@ static int huawei_cdc_ncm_bind(struct usbnet *usbnet_dev, { struct cdc_ncm_ctx *ctx; struct usb_driver *subdriver = ERR_PTR(-ENODEV); - int ret = -ENODEV; + int ret; struct huawei_cdc_ncm_state *drvstate = (void *)&usbnet_dev->data; int drvflags = 0; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 0/2] net-qmi_wwan: Fine-tuning for two function implementations @ 2016-01-01 16:50 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 16:50 UTC (permalink / raw) To: linux-usb, netdev, Bjørn Mork; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 17:47:46 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (2): Refactoring for qmi_wwan_bind() Delete an unnecessary variable initialisation in qmi_wwan_register_subdriver() drivers/net/usb/qmi_wwan.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/2] net-qmi_wwan: Fine-tuning for two function implementations @ 2016-01-01 16:50 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 16:50 UTC (permalink / raw) To: linux-usb, netdev, Bjørn Mork; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 17:47:46 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (2): Refactoring for qmi_wwan_bind() Delete an unnecessary variable initialisation in qmi_wwan_register_subdriver() drivers/net/usb/qmi_wwan.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/2] net-qmi_wwan: Fine-tuning for two function implementations @ 2016-01-01 16:50 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 16:50 UTC (permalink / raw) To: linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA, Bjørn Mork Cc: LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall From: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> Date: Fri, 1 Jan 2016 17:47:46 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (2): Refactoring for qmi_wwan_bind() Delete an unnecessary variable initialisation in qmi_wwan_register_subdriver() drivers/net/usb/qmi_wwan.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) -- 2.6.3 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 1/2] net-qmi_wwan: Refactoring for qmi_wwan_bind() @ 2016-01-01 16:54 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 16:54 UTC (permalink / raw) To: linux-usb, netdev, Bjørn Mork; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 17:32:07 +0100 Reduce the scope for the local variable "desc" to one branch of an if statement. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/usb/qmi_wwan.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c index d0b2973..5b8af06 100644 --- a/drivers/net/usb/qmi_wwan.c +++ b/drivers/net/usb/qmi_wwan.c @@ -345,7 +345,6 @@ static int qmi_wwan_bind(struct usbnet *dev, struct usb_interface *intf) int status = -1; u8 *buf = intf->cur_altsetting->extra; int len = intf->cur_altsetting->extralen; - struct usb_interface_descriptor *desc = &intf->cur_altsetting->desc; struct usb_cdc_union_desc *cdc_union; struct usb_cdc_ether_desc *cdc_ether; struct usb_driver *driver = driver_of(intf); @@ -366,6 +365,8 @@ static int qmi_wwan_bind(struct usbnet *dev, struct usb_interface *intf) /* Use separate control and data interfaces if we found a CDC Union */ if (cdc_union) { + struct usb_interface_descriptor *desc = &intf->cur_altsetting->desc; + info->data = usb_ifnum_to_if(dev->udev, cdc_union->bSlaveInterface0); if (desc->bInterfaceNumber != cdc_union->bMasterInterface0 || -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 1/2] net-qmi_wwan: Refactoring for qmi_wwan_bind() @ 2016-01-01 16:54 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 16:54 UTC (permalink / raw) To: linux-usb, netdev, Bjørn Mork; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 17:32:07 +0100 Reduce the scope for the local variable "desc" to one branch of an if statement. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/usb/qmi_wwan.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c index d0b2973..5b8af06 100644 --- a/drivers/net/usb/qmi_wwan.c +++ b/drivers/net/usb/qmi_wwan.c @@ -345,7 +345,6 @@ static int qmi_wwan_bind(struct usbnet *dev, struct usb_interface *intf) int status = -1; u8 *buf = intf->cur_altsetting->extra; int len = intf->cur_altsetting->extralen; - struct usb_interface_descriptor *desc = &intf->cur_altsetting->desc; struct usb_cdc_union_desc *cdc_union; struct usb_cdc_ether_desc *cdc_ether; struct usb_driver *driver = driver_of(intf); @@ -366,6 +365,8 @@ static int qmi_wwan_bind(struct usbnet *dev, struct usb_interface *intf) /* Use separate control and data interfaces if we found a CDC Union */ if (cdc_union) { + struct usb_interface_descriptor *desc = &intf->cur_altsetting->desc; + info->data = usb_ifnum_to_if(dev->udev, cdc_union->bSlaveInterface0); if (desc->bInterfaceNumber != cdc_union->bMasterInterface0 || -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 1/2] net-qmi_wwan: Refactoring for qmi_wwan_bind() @ 2016-01-01 16:54 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 16:54 UTC (permalink / raw) To: linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA, Bjørn Mork Cc: LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall From: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> Date: Fri, 1 Jan 2016 17:32:07 +0100 Reduce the scope for the local variable "desc" to one branch of an if statement. Signed-off-by: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> --- drivers/net/usb/qmi_wwan.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c index d0b2973..5b8af06 100644 --- a/drivers/net/usb/qmi_wwan.c +++ b/drivers/net/usb/qmi_wwan.c @@ -345,7 +345,6 @@ static int qmi_wwan_bind(struct usbnet *dev, struct usb_interface *intf) int status = -1; u8 *buf = intf->cur_altsetting->extra; int len = intf->cur_altsetting->extralen; - struct usb_interface_descriptor *desc = &intf->cur_altsetting->desc; struct usb_cdc_union_desc *cdc_union; struct usb_cdc_ether_desc *cdc_ether; struct usb_driver *driver = driver_of(intf); @@ -366,6 +365,8 @@ static int qmi_wwan_bind(struct usbnet *dev, struct usb_interface *intf) /* Use separate control and data interfaces if we found a CDC Union */ if (cdc_union) { + struct usb_interface_descriptor *desc = &intf->cur_altsetting->desc; + info->data = usb_ifnum_to_if(dev->udev, cdc_union->bSlaveInterface0); if (desc->bInterfaceNumber != cdc_union->bMasterInterface0 || -- 2.6.3 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/2] net-qmi_wwan: Refactoring for qmi_wwan_bind() 2016-01-01 16:54 ` SF Markus Elfring (?) @ 2016-01-02 21:38 ` Bjørn Mork -1 siblings, 0 replies; 3089+ messages in thread From: Bjørn Mork @ 2016-01-02 21:38 UTC (permalink / raw) To: SF Markus Elfring; +Cc: linux-usb, netdev, LKML, kernel-janitors, Julia Lawall SF Markus Elfring <elfring@users.sourceforge.net> writes: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 17:32:07 +0100 > > Reduce the scope for the local variable "desc" to one branch > of an if statement. This patch is harmless. But is also pointless. You could at least try to explain why this must be changed. I'm not interested in why you think it is better this way - I might agree with that. what I am interested in is the advantage changing the code gives us. Some analysis of the risk and work involved would also be nice. Is this change really worth it? Personally I am convinced that I wasted any time I used writing this, and you wasted any time you used reading it. Sorry. Note: This patch would have been fine if it was a natural part of some *improvement* of the driver, i.e. a bugfix or feaure addition. As a standalone patch I see it as noise. Please stop the noise and start writing something useful. I'm sure you can fix bugs instead. Wouldn't that be more interesting? More challenging? These mindless robotic code refactoring patches are really best left for robots. Bjørn ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/2] net-qmi_wwan: Refactoring for qmi_wwan_bind() @ 2016-01-02 21:38 ` Bjørn Mork 0 siblings, 0 replies; 3089+ messages in thread From: Bjørn Mork @ 2016-01-02 21:38 UTC (permalink / raw) To: SF Markus Elfring; +Cc: linux-usb, netdev, LKML, kernel-janitors, Julia Lawall SF Markus Elfring <elfring@users.sourceforge.net> writes: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 17:32:07 +0100 > > Reduce the scope for the local variable "desc" to one branch > of an if statement. This patch is harmless. But is also pointless. You could at least try to explain why this must be changed. I'm not interested in why you think it is better this way - I might agree with that. what I am interested in is the advantage changing the code gives us. Some analysis of the risk and work involved would also be nice. Is this change really worth it? Personally I am convinced that I wasted any time I used writing this, and you wasted any time you used reading it. Sorry. Note: This patch would have been fine if it was a natural part of some *improvement* of the driver, i.e. a bugfix or feaure addition. As a standalone patch I see it as noise. Please stop the noise and start writing something useful. I'm sure you can fix bugs instead. Wouldn't that be more interesting? More challenging? These mindless robotic code refactoring patches are really best left for robots. Bjørn -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/2] net-qmi_wwan: Refactoring for qmi_wwan_bind() @ 2016-01-02 21:38 ` Bjørn Mork 0 siblings, 0 replies; 3089+ messages in thread From: Bjørn Mork @ 2016-01-02 21:38 UTC (permalink / raw) To: SF Markus Elfring; +Cc: linux-usb, netdev, LKML, kernel-janitors, Julia Lawall SF Markus Elfring <elfring@users.sourceforge.net> writes: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 17:32:07 +0100 > > Reduce the scope for the local variable "desc" to one branch > of an if statement. This patch is harmless. But is also pointless. You could at least try to explain why this must be changed. I'm not interested in why you think it is better this way - I might agree with that. what I am interested in is the advantage changing the code gives us. Some analysis of the risk and work involved would also be nice. Is this change really worth it? Personally I am convinced that I wasted any time I used writing this, and you wasted any time you used reading it. Sorry. Note: This patch would have been fine if it was a natural part of some *improvement* of the driver, i.e. a bugfix or feaure addition. As a standalone patch I see it as noise. Please stop the noise and start writing something useful. I'm sure you can fix bugs instead. Wouldn't that be more interesting? More challenging? These mindless robotic code refactoring patches are really best left for robots. Bjørn -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 2/2] net-qmi_wwan: Delete an unnecessary variable initialisation in qmi_wwan_register_subdriver() 2016-01-01 16:50 ` SF Markus Elfring @ 2016-01-01 16:56 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 16:56 UTC (permalink / raw) To: linux-usb, netdev, Bjørn Mork; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 17:35:03 +0100 Omit explicit initialisation at the beginning for one local variable that is redefined before its first use. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/usb/qmi_wwan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c index 5b8af06..5962099 100644 --- a/drivers/net/usb/qmi_wwan.c +++ b/drivers/net/usb/qmi_wwan.c @@ -286,7 +286,7 @@ static int qmi_wwan_cdc_wdm_manage_power(struct usb_interface *intf, int on) static int qmi_wwan_register_subdriver(struct usbnet *dev) { int rv; - struct usb_driver *subdriver = NULL; + struct usb_driver *subdriver; struct qmi_wwan_state *info = (void *)&dev->data; /* collect bulk endpoints */ -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 2/2] net-qmi_wwan: Delete an unnecessary variable initialisation in qmi_wwan_register_subdriv @ 2016-01-01 16:56 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 16:56 UTC (permalink / raw) To: linux-usb, netdev, Bjørn Mork; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 17:35:03 +0100 Omit explicit initialisation at the beginning for one local variable that is redefined before its first use. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/usb/qmi_wwan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c index 5b8af06..5962099 100644 --- a/drivers/net/usb/qmi_wwan.c +++ b/drivers/net/usb/qmi_wwan.c @@ -286,7 +286,7 @@ static int qmi_wwan_cdc_wdm_manage_power(struct usb_interface *intf, int on) static int qmi_wwan_register_subdriver(struct usbnet *dev) { int rv; - struct usb_driver *subdriver = NULL; + struct usb_driver *subdriver; struct qmi_wwan_state *info = (void *)&dev->data; /* collect bulk endpoints */ -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] net-qmi_wwan: Delete an unnecessary variable initialisation in qmi_wwan_register_subdriver() 2016-01-01 16:56 ` [PATCH 2/2] net-qmi_wwan: Delete an unnecessary variable initialisation in qmi_wwan_register_subdriv SF Markus Elfring (?) @ 2016-01-02 21:30 ` Bjørn Mork -1 siblings, 0 replies; 3089+ messages in thread From: Bjørn Mork @ 2016-01-02 21:30 UTC (permalink / raw) To: SF Markus Elfring; +Cc: linux-usb, netdev, LKML, kernel-janitors, Julia Lawall SF Markus Elfring <elfring@users.sourceforge.net> writes: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 17:35:03 +0100 > > Omit explicit initialisation at the beginning for one local variable > that is redefined before its first use. This patch is unnecessary. The variable initialisation is redundant. See the difference? Sending an unnecessary patch causes unnecessary load on reviewers and maintainers. Keeping redundant code has no measurable cost, and can save the same maintainers a lot of trouble later. I'd like to keep this particular redundant initialisation as a safe guard against future code refactoring, causing for example the err label to move up. Yes, I do understand that any patch with such a bug should be rejected, but I do know what happens in the real world and how easy it is for something like that to slip through in a stream of unnecessary "cleanup" patches. Reducing redundancy in the kernel is only making the code less robust. It is harmful. Please stop. Thanks. Bjørn ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] net-qmi_wwan: Delete an unnecessary variable initialisation in qmi_wwan_register_sub @ 2016-01-02 21:30 ` Bjørn Mork 0 siblings, 0 replies; 3089+ messages in thread From: Bjørn Mork @ 2016-01-02 21:30 UTC (permalink / raw) To: SF Markus Elfring; +Cc: linux-usb, netdev, LKML, kernel-janitors, Julia Lawall SF Markus Elfring <elfring@users.sourceforge.net> writes: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 17:35:03 +0100 > > Omit explicit initialisation at the beginning for one local variable > that is redefined before its first use. This patch is unnecessary. The variable initialisation is redundant. See the difference? Sending an unnecessary patch causes unnecessary load on reviewers and maintainers. Keeping redundant code has no measurable cost, and can save the same maintainers a lot of trouble later. I'd like to keep this particular redundant initialisation as a safe guard against future code refactoring, causing for example the err label to move up. Yes, I do understand that any patch with such a bug should be rejected, but I do know what happens in the real world and how easy it is for something like that to slip through in a stream of unnecessary "cleanup" patches. Reducing redundancy in the kernel is only making the code less robust. It is harmful. Please stop. Thanks. Bjørn -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] net-qmi_wwan: Delete an unnecessary variable initialisation in qmi_wwan_register_subdriver() @ 2016-01-02 21:30 ` Bjørn Mork 0 siblings, 0 replies; 3089+ messages in thread From: Bjørn Mork @ 2016-01-02 21:30 UTC (permalink / raw) To: SF Markus Elfring; +Cc: linux-usb, netdev, LKML, kernel-janitors, Julia Lawall SF Markus Elfring <elfring@users.sourceforge.net> writes: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 17:35:03 +0100 > > Omit explicit initialisation at the beginning for one local variable > that is redefined before its first use. This patch is unnecessary. The variable initialisation is redundant. See the difference? Sending an unnecessary patch causes unnecessary load on reviewers and maintainers. Keeping redundant code has no measurable cost, and can save the same maintainers a lot of trouble later. I'd like to keep this particular redundant initialisation as a safe guard against future code refactoring, causing for example the err label to move up. Yes, I do understand that any patch with such a bug should be rejected, but I do know what happens in the real world and how easy it is for something like that to slip through in a stream of unnecessary "cleanup" patches. Reducing redundancy in the kernel is only making the code less robust. It is harmful. Please stop. Thanks. Bjørn -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] net-qmi_wwan: Delete an unnecessary variable initialisation in qmi_wwan_register_subdriver() @ 2016-01-03 1:45 ` David Miller 0 siblings, 0 replies; 3089+ messages in thread From: David Miller @ 2016-01-03 1:45 UTC (permalink / raw) To: bjorn Cc: elfring, linux-usb, netdev, linux-kernel, kernel-janitors, julia.lawall From: Bjørn Mork <bjorn@mork.no> Date: Sat, 02 Jan 2016 22:30:48 +0100 > SF Markus Elfring <elfring@users.sourceforge.net> writes: > >> From: Markus Elfring <elfring@users.sourceforge.net> >> Date: Fri, 1 Jan 2016 17:35:03 +0100 >> >> Omit explicit initialisation at the beginning for one local variable >> that is redefined before its first use. > > > This patch is unnecessary. The variable initialisation is redundant. > See the difference? Sending an unnecessary patch causes unnecessary > load on reviewers and maintainers. Keeping redundant code has no > measurable cost, and can save the same maintainers a lot of trouble > later. +1 I'm getting really tired of these changes. And a lot of them are coming in right now... ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] net-qmi_wwan: Delete an unnecessary variable initialisation in qmi_wwan_register_sub @ 2016-01-03 1:45 ` David Miller 0 siblings, 0 replies; 3089+ messages in thread From: David Miller @ 2016-01-03 1:45 UTC (permalink / raw) To: bjorn Cc: elfring, linux-usb, netdev, linux-kernel, kernel-janitors, julia.lawall From: Bjørn Mork <bjorn@mork.no> Date: Sat, 02 Jan 2016 22:30:48 +0100 > SF Markus Elfring <elfring@users.sourceforge.net> writes: > >> From: Markus Elfring <elfring@users.sourceforge.net> >> Date: Fri, 1 Jan 2016 17:35:03 +0100 >> >> Omit explicit initialisation at the beginning for one local variable >> that is redefined before its first use. > > > This patch is unnecessary. The variable initialisation is redundant. > See the difference? Sending an unnecessary patch causes unnecessary > load on reviewers and maintainers. Keeping redundant code has no > measurable cost, and can save the same maintainers a lot of trouble > later. +1 I'm getting really tired of these changes. And a lot of them are coming in right now... -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] net-qmi_wwan: Delete an unnecessary variable initialisation in qmi_wwan_register_subdriver() @ 2016-01-03 1:45 ` David Miller 0 siblings, 0 replies; 3089+ messages in thread From: David Miller @ 2016-01-03 1:45 UTC (permalink / raw) To: bjorn-yOkvZcmFvRU Cc: elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f, linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, julia.lawall-L2FTfq7BK8M From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> Date: Sat, 02 Jan 2016 22:30:48 +0100 > SF Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> writes: > >> From: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> >> Date: Fri, 1 Jan 2016 17:35:03 +0100 >> >> Omit explicit initialisation at the beginning for one local variable >> that is redefined before its first use. > > > This patch is unnecessary. The variable initialisation is redundant. > See the difference? Sending an unnecessary patch causes unnecessary > load on reviewers and maintainers. Keeping redundant code has no > measurable cost, and can save the same maintainers a lot of trouble > later. +1 I'm getting really tired of these changes. And a lot of them are coming in right now... -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/2] net-ath9k_htc: Fine-tuning for two function implementations 2015-12-11 12:08 ` SF Markus Elfring ` (2 preceding siblings ...) (?) @ 2016-01-01 18:21 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 18:21 UTC (permalink / raw) To: ath9k-devel, linux-wireless, netdev, ath9k-devel, Kalle Valo Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 19:16:05 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an unnecessary variable initialisation in ath9k_hif_usb_rx_stream() Replace a variable initialisation by an assignment in ath9k_htc_set_channel() drivers/net/wireless/ath/ath9k/hif_usb.c | 2 +- drivers/net/wireless/ath/ath9k/htc_drv_main.c | 7 ++----- 2 files changed, 3 insertions(+), 6 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [ath9k-devel] [PATCH 0/2] net-ath9k_htc: Fine-tuning for two function implementations @ 2016-01-01 18:21 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 18:21 UTC (permalink / raw) To: ath9k-devel From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 19:16:05 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an unnecessary variable initialisation in ath9k_hif_usb_rx_stream() Replace a variable initialisation by an assignment in ath9k_htc_set_channel() drivers/net/wireless/ath/ath9k/hif_usb.c | 2 +- drivers/net/wireless/ath/ath9k/htc_drv_main.c | 7 ++----- 2 files changed, 3 insertions(+), 6 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/2] net-ath9k_htc: Fine-tuning for two function implementations @ 2016-01-01 18:21 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 18:21 UTC (permalink / raw) To: ath9k-devel, linux-wireless, netdev, ath9k-devel, Kalle Valo Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 19:16:05 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an unnecessary variable initialisation in ath9k_hif_usb_rx_stream() Replace a variable initialisation by an assignment in ath9k_htc_set_channel() drivers/net/wireless/ath/ath9k/hif_usb.c | 2 +- drivers/net/wireless/ath/ath9k/htc_drv_main.c | 7 ++----- 2 files changed, 3 insertions(+), 6 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/2] net-ath9k_htc: Fine-tuning for two function implementations @ 2016-01-01 18:21 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 18:21 UTC (permalink / raw) To: ath9k-devel-xDcbHBWguxHbcTqmT+pZeQ, linux-wireless-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA, ath9k-devel-A+ZNKFmMK5xy9aJCnZT0Uw, Kalle Valo Cc: LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall From: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> Date: Fri, 1 Jan 2016 19:16:05 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an unnecessary variable initialisation in ath9k_hif_usb_rx_stream() Replace a variable initialisation by an assignment in ath9k_htc_set_channel() drivers/net/wireless/ath/ath9k/hif_usb.c | 2 +- drivers/net/wireless/ath/ath9k/htc_drv_main.c | 7 ++----- 2 files changed, 3 insertions(+), 6 deletions(-) -- 2.6.3 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/2] net-ath9k_htc: Fine-tuning for two function implementations @ 2016-01-01 18:21 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 18:21 UTC (permalink / raw) To: ath9k-devel, linux-wireless, netdev, ath9k-devel, Kalle Valo Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 19:16:05 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an unnecessary variable initialisation in ath9k_hif_usb_rx_stream() Replace a variable initialisation by an assignment in ath9k_htc_set_channel() drivers/net/wireless/ath/ath9k/hif_usb.c | 2 +- drivers/net/wireless/ath/ath9k/htc_drv_main.c | 7 ++----- 2 files changed, 3 insertions(+), 6 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 1/2] net-ath9k_htc: Delete an unnecessary variable initialisation in ath9k_hif_usb_rx_stream() 2016-01-01 18:21 ` SF Markus Elfring (?) (?) @ 2016-01-01 18:23 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 18:23 UTC (permalink / raw) To: ath9k-devel, linux-wireless, netdev, ath9k-devel, Kalle Valo Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 19:00:53 +0100 Omit explicit initialisation at the beginning for one local variable that is redefined before its first use. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/wireless/ath/ath9k/hif_usb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c index 165dd20..51bd61b 100644 --- a/drivers/net/wireless/ath/ath9k/hif_usb.c +++ b/drivers/net/wireless/ath/ath9k/hif_usb.c @@ -525,7 +525,7 @@ static void ath9k_hif_usb_rx_stream(struct hif_device_usb *hif_dev, struct sk_buff *skb) { struct sk_buff *nskb, *skb_pool[MAX_PKT_NUM_IN_TRANSFER]; - int index = 0, i = 0, len = skb->len; + int index = 0, i, len = skb->len; int rx_remain_len, rx_pkt_len; u16 pool_index = 0; u8 *ptr; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [ath9k-devel] [PATCH 1/2] net-ath9k_htc: Delete an unnecessary variable initialisation in ath9k_hif_usb_rx_stream() @ 2016-01-01 18:23 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 18:23 UTC (permalink / raw) To: ath9k-devel From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 19:00:53 +0100 Omit explicit initialisation at the beginning for one local variable that is redefined before its first use. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/wireless/ath/ath9k/hif_usb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c index 165dd20..51bd61b 100644 --- a/drivers/net/wireless/ath/ath9k/hif_usb.c +++ b/drivers/net/wireless/ath/ath9k/hif_usb.c @@ -525,7 +525,7 @@ static void ath9k_hif_usb_rx_stream(struct hif_device_usb *hif_dev, struct sk_buff *skb) { struct sk_buff *nskb, *skb_pool[MAX_PKT_NUM_IN_TRANSFER]; - int index = 0, i = 0, len = skb->len; + int index = 0, i, len = skb->len; int rx_remain_len, rx_pkt_len; u16 pool_index = 0; u8 *ptr; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 1/2] net-ath9k_htc: Delete an unnecessary variable initialisation in ath9k_hif_usb_rx_stream( @ 2016-01-01 18:23 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 18:23 UTC (permalink / raw) To: ath9k-devel, linux-wireless, netdev, ath9k-devel, Kalle Valo Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 19:00:53 +0100 Omit explicit initialisation at the beginning for one local variable that is redefined before its first use. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/wireless/ath/ath9k/hif_usb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c index 165dd20..51bd61b 100644 --- a/drivers/net/wireless/ath/ath9k/hif_usb.c +++ b/drivers/net/wireless/ath/ath9k/hif_usb.c @@ -525,7 +525,7 @@ static void ath9k_hif_usb_rx_stream(struct hif_device_usb *hif_dev, struct sk_buff *skb) { struct sk_buff *nskb, *skb_pool[MAX_PKT_NUM_IN_TRANSFER]; - int index = 0, i = 0, len = skb->len; + int index = 0, i, len = skb->len; int rx_remain_len, rx_pkt_len; u16 pool_index = 0; u8 *ptr; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 1/2] net-ath9k_htc: Delete an unnecessary variable initialisation in ath9k_hif_usb_rx_stream() @ 2016-01-01 18:23 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 18:23 UTC (permalink / raw) To: ath9k-devel, linux-wireless, netdev, ath9k-devel, Kalle Valo Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 19:00:53 +0100 Omit explicit initialisation at the beginning for one local variable that is redefined before its first use. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/wireless/ath/ath9k/hif_usb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c index 165dd20..51bd61b 100644 --- a/drivers/net/wireless/ath/ath9k/hif_usb.c +++ b/drivers/net/wireless/ath/ath9k/hif_usb.c @@ -525,7 +525,7 @@ static void ath9k_hif_usb_rx_stream(struct hif_device_usb *hif_dev, struct sk_buff *skb) { struct sk_buff *nskb, *skb_pool[MAX_PKT_NUM_IN_TRANSFER]; - int index = 0, i = 0, len = skb->len; + int index = 0, i, len = skb->len; int rx_remain_len, rx_pkt_len; u16 pool_index = 0; u8 *ptr; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/2] net-ath9k_htc: Delete an unnecessary variable initialisation in ath9k_hif_usb_rx_stream() 2016-01-01 18:23 ` [PATCH 1/2] net-ath9k_htc: Delete an unnecessary variable initialisation in ath9k_hif_usb_rx_stream() SF Markus Elfring ` (2 preceding siblings ...) (?) @ 2016-01-01 19:14 ` Oleksij Rempel -1 siblings, 0 replies; 3089+ messages in thread From: Oleksij Rempel @ 2016-01-01 19:14 UTC (permalink / raw) To: SF Markus Elfring, ath9k-devel, linux-wireless, netdev, ath9k-devel, Kalle Valo Cc: LKML, kernel-janitors, Julia Lawall [-- Attachment #1: Type: text/plain, Size: 1121 bytes --] Am 01.01.2016 um 19:23 schrieb SF Markus Elfring: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 19:00:53 +0100 > > Omit explicit initialisation at the beginning for one local variable > that is redefined before its first use. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/net/wireless/ath/ath9k/hif_usb.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c > index 165dd20..51bd61b 100644 > --- a/drivers/net/wireless/ath/ath9k/hif_usb.c > +++ b/drivers/net/wireless/ath/ath9k/hif_usb.c > @@ -525,7 +525,7 @@ static void ath9k_hif_usb_rx_stream(struct hif_device_usb *hif_dev, > struct sk_buff *skb) > { > struct sk_buff *nskb, *skb_pool[MAX_PKT_NUM_IN_TRANSFER]; > - int index = 0, i = 0, len = skb->len; > + int index = 0, i, len = skb->len; > int rx_remain_len, rx_pkt_len; > u16 pool_index = 0; > u8 *ptr; > Reviewed-by: Oleksij Rempel <linux@rempel-privat.de> -- Regards, Oleksij [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 213 bytes --] ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [ath9k-devel] [PATCH 1/2] net-ath9k_htc: Delete an unnecessary variable initialisation in ath9k_hif_usb_rx_stream() @ 2016-01-01 19:14 ` Oleksij Rempel 0 siblings, 0 replies; 3089+ messages in thread From: Oleksij Rempel @ 2016-01-01 19:14 UTC (permalink / raw) To: ath9k-devel Am 01.01.2016 um 19:23 schrieb SF Markus Elfring: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 19:00:53 +0100 > > Omit explicit initialisation at the beginning for one local variable > that is redefined before its first use. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/net/wireless/ath/ath9k/hif_usb.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c > index 165dd20..51bd61b 100644 > --- a/drivers/net/wireless/ath/ath9k/hif_usb.c > +++ b/drivers/net/wireless/ath/ath9k/hif_usb.c > @@ -525,7 +525,7 @@ static void ath9k_hif_usb_rx_stream(struct hif_device_usb *hif_dev, > struct sk_buff *skb) > { > struct sk_buff *nskb, *skb_pool[MAX_PKT_NUM_IN_TRANSFER]; > - int index = 0, i = 0, len = skb->len; > + int index = 0, i, len = skb->len; > int rx_remain_len, rx_pkt_len; > u16 pool_index = 0; > u8 *ptr; > Reviewed-by: Oleksij Rempel <linux@rempel-privat.de> -- Regards, Oleksij -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: OpenPGP digital signature Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20160101/9f7764b8/attachment.pgp ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/2] net-ath9k_htc: Delete an unnecessary variable initialisation in ath9k_hif_usb_rx_str @ 2016-01-01 19:14 ` Oleksij Rempel 0 siblings, 0 replies; 3089+ messages in thread From: Oleksij Rempel @ 2016-01-01 19:14 UTC (permalink / raw) To: SF Markus Elfring, ath9k-devel, linux-wireless, netdev, ath9k-devel, Kalle Valo Cc: LKML, kernel-janitors, Julia Lawall [-- Attachment #1: Type: text/plain, Size: 1121 bytes --] Am 01.01.2016 um 19:23 schrieb SF Markus Elfring: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 19:00:53 +0100 > > Omit explicit initialisation at the beginning for one local variable > that is redefined before its first use. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/net/wireless/ath/ath9k/hif_usb.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c > index 165dd20..51bd61b 100644 > --- a/drivers/net/wireless/ath/ath9k/hif_usb.c > +++ b/drivers/net/wireless/ath/ath9k/hif_usb.c > @@ -525,7 +525,7 @@ static void ath9k_hif_usb_rx_stream(struct hif_device_usb *hif_dev, > struct sk_buff *skb) > { > struct sk_buff *nskb, *skb_pool[MAX_PKT_NUM_IN_TRANSFER]; > - int index = 0, i = 0, len = skb->len; > + int index = 0, i, len = skb->len; > int rx_remain_len, rx_pkt_len; > u16 pool_index = 0; > u8 *ptr; > Reviewed-by: Oleksij Rempel <linux@rempel-privat.de> -- Regards, Oleksij [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 213 bytes --] ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/2] net-ath9k_htc: Delete an unnecessary variable initialisation in ath9k_hif_usb_rx_stream() @ 2016-01-01 19:14 ` Oleksij Rempel 0 siblings, 0 replies; 3089+ messages in thread From: Oleksij Rempel @ 2016-01-01 19:14 UTC (permalink / raw) To: SF Markus Elfring, ath9k-devel-xDcbHBWguxHbcTqmT+pZeQ, linux-wireless-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA, ath9k-devel-A+ZNKFmMK5xy9aJCnZT0Uw, Kalle Valo Cc: LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall [-- Attachment #1: Type: text/plain, Size: 1200 bytes --] Am 01.01.2016 um 19:23 schrieb SF Markus Elfring: > From: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> > Date: Fri, 1 Jan 2016 19:00:53 +0100 > > Omit explicit initialisation at the beginning for one local variable > that is redefined before its first use. > > Signed-off-by: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> > --- > drivers/net/wireless/ath/ath9k/hif_usb.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c > index 165dd20..51bd61b 100644 > --- a/drivers/net/wireless/ath/ath9k/hif_usb.c > +++ b/drivers/net/wireless/ath/ath9k/hif_usb.c > @@ -525,7 +525,7 @@ static void ath9k_hif_usb_rx_stream(struct hif_device_usb *hif_dev, > struct sk_buff *skb) > { > struct sk_buff *nskb, *skb_pool[MAX_PKT_NUM_IN_TRANSFER]; > - int index = 0, i = 0, len = skb->len; > + int index = 0, i, len = skb->len; > int rx_remain_len, rx_pkt_len; > u16 pool_index = 0; > u8 *ptr; > Reviewed-by: Oleksij Rempel <linux-YEK0n+YFykbzxQdaRaTXBw@public.gmane.org> -- Regards, Oleksij [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 213 bytes --] ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/2] net-ath9k_htc: Delete an unnecessary variable initialisation in ath9k_hif_usb_rx_stream() @ 2016-01-01 19:14 ` Oleksij Rempel 0 siblings, 0 replies; 3089+ messages in thread From: Oleksij Rempel @ 2016-01-01 19:14 UTC (permalink / raw) To: SF Markus Elfring, ath9k-devel, linux-wireless, netdev, ath9k-devel, Kalle Valo Cc: LKML, kernel-janitors, Julia Lawall [-- Attachment #1: Type: text/plain, Size: 1121 bytes --] Am 01.01.2016 um 19:23 schrieb SF Markus Elfring: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 19:00:53 +0100 > > Omit explicit initialisation at the beginning for one local variable > that is redefined before its first use. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/net/wireless/ath/ath9k/hif_usb.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c > index 165dd20..51bd61b 100644 > --- a/drivers/net/wireless/ath/ath9k/hif_usb.c > +++ b/drivers/net/wireless/ath/ath9k/hif_usb.c > @@ -525,7 +525,7 @@ static void ath9k_hif_usb_rx_stream(struct hif_device_usb *hif_dev, > struct sk_buff *skb) > { > struct sk_buff *nskb, *skb_pool[MAX_PKT_NUM_IN_TRANSFER]; > - int index = 0, i = 0, len = skb->len; > + int index = 0, i, len = skb->len; > int rx_remain_len, rx_pkt_len; > u16 pool_index = 0; > u8 *ptr; > Reviewed-by: Oleksij Rempel <linux@rempel-privat.de> -- Regards, Oleksij [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 213 bytes --] ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() 2016-01-01 18:21 ` SF Markus Elfring (?) (?) @ 2016-01-01 18:25 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 18:25 UTC (permalink / raw) To: ath9k-devel, linux-wireless, netdev, ath9k-devel, Kalle Valo Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 19:09:32 +0100 Replace an explicit initialisation for one local variable at the beginning by a conditional assignment. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/wireless/ath/ath9k/htc_drv_main.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c index a680a97..30bd59e 100644 --- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c +++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c @@ -246,7 +246,7 @@ static int ath9k_htc_set_channel(struct ath9k_htc_priv *priv, struct ieee80211_conf *conf = &common->hw->conf; bool fastcc; struct ieee80211_channel *channel = hw->conf.chandef.chan; - struct ath9k_hw_cal_data *caldata = NULL; + struct ath9k_hw_cal_data *caldata; enum htc_phymode mode; __be16 htc_mode; u8 cmd_rsp; @@ -274,10 +274,7 @@ static int ath9k_htc_set_channel(struct ath9k_htc_priv *priv, priv->ah->curchan->channel, channel->center_freq, conf_is_ht(conf), conf_is_ht40(conf), fastcc); - - if (!fastcc) - caldata = &priv->caldata; - + caldata = fastcc ? NULL : &priv->caldata; ret = ath9k_hw_reset(ah, hchan, caldata, fastcc); if (ret) { ath_err(common, -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [ath9k-devel] [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() @ 2016-01-01 18:25 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 18:25 UTC (permalink / raw) To: ath9k-devel From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 19:09:32 +0100 Replace an explicit initialisation for one local variable at the beginning by a conditional assignment. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/wireless/ath/ath9k/htc_drv_main.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c index a680a97..30bd59e 100644 --- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c +++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c @@ -246,7 +246,7 @@ static int ath9k_htc_set_channel(struct ath9k_htc_priv *priv, struct ieee80211_conf *conf = &common->hw->conf; bool fastcc; struct ieee80211_channel *channel = hw->conf.chandef.chan; - struct ath9k_hw_cal_data *caldata = NULL; + struct ath9k_hw_cal_data *caldata; enum htc_phymode mode; __be16 htc_mode; u8 cmd_rsp; @@ -274,10 +274,7 @@ static int ath9k_htc_set_channel(struct ath9k_htc_priv *priv, priv->ah->curchan->channel, channel->center_freq, conf_is_ht(conf), conf_is_ht40(conf), fastcc); - - if (!fastcc) - caldata = &priv->caldata; - + caldata = fastcc ? NULL : &priv->caldata; ret = ath9k_hw_reset(ah, hchan, caldata, fastcc); if (ret) { ath_err(common, -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_chann @ 2016-01-01 18:25 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 18:25 UTC (permalink / raw) To: ath9k-devel, linux-wireless, netdev, ath9k-devel, Kalle Valo Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 19:09:32 +0100 Replace an explicit initialisation for one local variable at the beginning by a conditional assignment. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/wireless/ath/ath9k/htc_drv_main.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c index a680a97..30bd59e 100644 --- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c +++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c @@ -246,7 +246,7 @@ static int ath9k_htc_set_channel(struct ath9k_htc_priv *priv, struct ieee80211_conf *conf = &common->hw->conf; bool fastcc; struct ieee80211_channel *channel = hw->conf.chandef.chan; - struct ath9k_hw_cal_data *caldata = NULL; + struct ath9k_hw_cal_data *caldata; enum htc_phymode mode; __be16 htc_mode; u8 cmd_rsp; @@ -274,10 +274,7 @@ static int ath9k_htc_set_channel(struct ath9k_htc_priv *priv, priv->ah->curchan->channel, channel->center_freq, conf_is_ht(conf), conf_is_ht40(conf), fastcc); - - if (!fastcc) - caldata = &priv->caldata; - + caldata = fastcc ? NULL : &priv->caldata; ret = ath9k_hw_reset(ah, hchan, caldata, fastcc); if (ret) { ath_err(common, -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() @ 2016-01-01 18:25 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 18:25 UTC (permalink / raw) To: ath9k-devel, linux-wireless, netdev, ath9k-devel, Kalle Valo Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 19:09:32 +0100 Replace an explicit initialisation for one local variable at the beginning by a conditional assignment. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/wireless/ath/ath9k/htc_drv_main.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c index a680a97..30bd59e 100644 --- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c +++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c @@ -246,7 +246,7 @@ static int ath9k_htc_set_channel(struct ath9k_htc_priv *priv, struct ieee80211_conf *conf = &common->hw->conf; bool fastcc; struct ieee80211_channel *channel = hw->conf.chandef.chan; - struct ath9k_hw_cal_data *caldata = NULL; + struct ath9k_hw_cal_data *caldata; enum htc_phymode mode; __be16 htc_mode; u8 cmd_rsp; @@ -274,10 +274,7 @@ static int ath9k_htc_set_channel(struct ath9k_htc_priv *priv, priv->ah->curchan->channel, channel->center_freq, conf_is_ht(conf), conf_is_ht40(conf), fastcc); - - if (!fastcc) - caldata = &priv->caldata; - + caldata = fastcc ? NULL : &priv->caldata; ret = ath9k_hw_reset(ah, hchan, caldata, fastcc); if (ret) { ath_err(common, -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() 2016-01-01 18:25 ` [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() SF Markus Elfring (?) (?) @ 2016-01-01 19:14 ` Oleksij Rempel -1 siblings, 0 replies; 3089+ messages in thread From: Oleksij Rempel @ 2016-01-01 19:14 UTC (permalink / raw) To: SF Markus Elfring, ath9k-devel, linux-wireless, netdev, ath9k-devel, Kalle Valo Cc: LKML, kernel-janitors, Julia Lawall [-- Attachment #1: Type: text/plain, Size: 1572 bytes --] Am 01.01.2016 um 19:25 schrieb SF Markus Elfring: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 19:09:32 +0100 > > Replace an explicit initialisation for one local variable at the beginning > by a conditional assignment. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/net/wireless/ath/ath9k/htc_drv_main.c | 7 ++----- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c > index a680a97..30bd59e 100644 > --- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c > +++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c > @@ -246,7 +246,7 @@ static int ath9k_htc_set_channel(struct ath9k_htc_priv *priv, > struct ieee80211_conf *conf = &common->hw->conf; > bool fastcc; > struct ieee80211_channel *channel = hw->conf.chandef.chan; > - struct ath9k_hw_cal_data *caldata = NULL; > + struct ath9k_hw_cal_data *caldata; > enum htc_phymode mode; > __be16 htc_mode; > u8 cmd_rsp; > @@ -274,10 +274,7 @@ static int ath9k_htc_set_channel(struct ath9k_htc_priv *priv, > priv->ah->curchan->channel, > channel->center_freq, conf_is_ht(conf), conf_is_ht40(conf), > fastcc); > - > - if (!fastcc) > - caldata = &priv->caldata; > - > + caldata = fastcc ? NULL : &priv->caldata; > ret = ath9k_hw_reset(ah, hchan, caldata, fastcc); > if (ret) { > ath_err(common, > Reviewed-by: Oleksij Rempel <linux@rempel-privat.de> -- Regards, Oleksij [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 213 bytes --] ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [ath9k-devel] [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() @ 2016-01-01 19:14 ` Oleksij Rempel 0 siblings, 0 replies; 3089+ messages in thread From: Oleksij Rempel @ 2016-01-01 19:14 UTC (permalink / raw) To: ath9k-devel Am 01.01.2016 um 19:25 schrieb SF Markus Elfring: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 19:09:32 +0100 > > Replace an explicit initialisation for one local variable at the beginning > by a conditional assignment. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/net/wireless/ath/ath9k/htc_drv_main.c | 7 ++----- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c > index a680a97..30bd59e 100644 > --- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c > +++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c > @@ -246,7 +246,7 @@ static int ath9k_htc_set_channel(struct ath9k_htc_priv *priv, > struct ieee80211_conf *conf = &common->hw->conf; > bool fastcc; > struct ieee80211_channel *channel = hw->conf.chandef.chan; > - struct ath9k_hw_cal_data *caldata = NULL; > + struct ath9k_hw_cal_data *caldata; > enum htc_phymode mode; > __be16 htc_mode; > u8 cmd_rsp; > @@ -274,10 +274,7 @@ static int ath9k_htc_set_channel(struct ath9k_htc_priv *priv, > priv->ah->curchan->channel, > channel->center_freq, conf_is_ht(conf), conf_is_ht40(conf), > fastcc); > - > - if (!fastcc) > - caldata = &priv->caldata; > - > + caldata = fastcc ? NULL : &priv->caldata; > ret = ath9k_hw_reset(ah, hchan, caldata, fastcc); > if (ret) { > ath_err(common, > Reviewed-by: Oleksij Rempel <linux@rempel-privat.de> -- Regards, Oleksij -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: OpenPGP digital signature Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20160101/a7f6d86e/attachment.pgp ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_c @ 2016-01-01 19:14 ` Oleksij Rempel 0 siblings, 0 replies; 3089+ messages in thread From: Oleksij Rempel @ 2016-01-01 19:14 UTC (permalink / raw) To: SF Markus Elfring, ath9k-devel, linux-wireless, netdev, ath9k-devel, Kalle Valo Cc: LKML, kernel-janitors, Julia Lawall [-- Attachment #1: Type: text/plain, Size: 1572 bytes --] Am 01.01.2016 um 19:25 schrieb SF Markus Elfring: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 19:09:32 +0100 > > Replace an explicit initialisation for one local variable at the beginning > by a conditional assignment. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/net/wireless/ath/ath9k/htc_drv_main.c | 7 ++----- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c > index a680a97..30bd59e 100644 > --- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c > +++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c > @@ -246,7 +246,7 @@ static int ath9k_htc_set_channel(struct ath9k_htc_priv *priv, > struct ieee80211_conf *conf = &common->hw->conf; > bool fastcc; > struct ieee80211_channel *channel = hw->conf.chandef.chan; > - struct ath9k_hw_cal_data *caldata = NULL; > + struct ath9k_hw_cal_data *caldata; > enum htc_phymode mode; > __be16 htc_mode; > u8 cmd_rsp; > @@ -274,10 +274,7 @@ static int ath9k_htc_set_channel(struct ath9k_htc_priv *priv, > priv->ah->curchan->channel, > channel->center_freq, conf_is_ht(conf), conf_is_ht40(conf), > fastcc); > - > - if (!fastcc) > - caldata = &priv->caldata; > - > + caldata = fastcc ? NULL : &priv->caldata; > ret = ath9k_hw_reset(ah, hchan, caldata, fastcc); > if (ret) { > ath_err(common, > Reviewed-by: Oleksij Rempel <linux@rempel-privat.de> -- Regards, Oleksij [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 213 bytes --] ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() @ 2016-01-01 19:14 ` Oleksij Rempel 0 siblings, 0 replies; 3089+ messages in thread From: Oleksij Rempel @ 2016-01-01 19:14 UTC (permalink / raw) To: SF Markus Elfring, ath9k-devel, linux-wireless, netdev, ath9k-devel, Kalle Valo Cc: LKML, kernel-janitors, Julia Lawall [-- Attachment #1: Type: text/plain, Size: 1572 bytes --] Am 01.01.2016 um 19:25 schrieb SF Markus Elfring: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 19:09:32 +0100 > > Replace an explicit initialisation for one local variable at the beginning > by a conditional assignment. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/net/wireless/ath/ath9k/htc_drv_main.c | 7 ++----- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c > index a680a97..30bd59e 100644 > --- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c > +++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c > @@ -246,7 +246,7 @@ static int ath9k_htc_set_channel(struct ath9k_htc_priv *priv, > struct ieee80211_conf *conf = &common->hw->conf; > bool fastcc; > struct ieee80211_channel *channel = hw->conf.chandef.chan; > - struct ath9k_hw_cal_data *caldata = NULL; > + struct ath9k_hw_cal_data *caldata; > enum htc_phymode mode; > __be16 htc_mode; > u8 cmd_rsp; > @@ -274,10 +274,7 @@ static int ath9k_htc_set_channel(struct ath9k_htc_priv *priv, > priv->ah->curchan->channel, > channel->center_freq, conf_is_ht(conf), conf_is_ht40(conf), > fastcc); > - > - if (!fastcc) > - caldata = &priv->caldata; > - > + caldata = fastcc ? NULL : &priv->caldata; > ret = ath9k_hw_reset(ah, hchan, caldata, fastcc); > if (ret) { > ath_err(common, > Reviewed-by: Oleksij Rempel <linux@rempel-privat.de> -- Regards, Oleksij [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 213 bytes --] ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() 2016-01-01 18:25 ` [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() SF Markus Elfring (?) (?) @ 2016-04-08 1:40 ` Julian Calaby -1 siblings, 0 replies; 3089+ messages in thread From: Julian Calaby @ 2016-04-08 1:40 UTC (permalink / raw) To: Kalle Valo Cc: ath9k-devel, linux-wireless, netdev, QCA ath9k Development, LKML, SF Markus Elfring, kernel-janitors, Julia Lawall Hi Kalle, On Sat, Jan 2, 2016 at 5:25 AM, SF Markus Elfring <elfring@users.sourceforge.net> wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 19:09:32 +0100 > > Replace an explicit initialisation for one local variable at the beginning > by a conditional assignment. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> This looks sane to me. Reviewed-by: Julian Calaby <julian.calaby@gmail.com> Thanks, Julian Calaby > --- > drivers/net/wireless/ath/ath9k/htc_drv_main.c | 7 ++----- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c > index a680a97..30bd59e 100644 > --- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c > +++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c > @@ -246,7 +246,7 @@ static int ath9k_htc_set_channel(struct ath9k_htc_priv *priv, > struct ieee80211_conf *conf = &common->hw->conf; > bool fastcc; > struct ieee80211_channel *channel = hw->conf.chandef.chan; > - struct ath9k_hw_cal_data *caldata = NULL; > + struct ath9k_hw_cal_data *caldata; > enum htc_phymode mode; > __be16 htc_mode; > u8 cmd_rsp; > @@ -274,10 +274,7 @@ static int ath9k_htc_set_channel(struct ath9k_htc_priv *priv, > priv->ah->curchan->channel, > channel->center_freq, conf_is_ht(conf), conf_is_ht40(conf), > fastcc); > - > - if (!fastcc) > - caldata = &priv->caldata; > - > + caldata = fastcc ? NULL : &priv->caldata; > ret = ath9k_hw_reset(ah, hchan, caldata, fastcc); > if (ret) { > ath_err(common, > -- > 2.6.3 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Julian Calaby Email: julian.calaby@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [ath9k-devel] [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() @ 2016-04-08 1:40 ` Julian Calaby 0 siblings, 0 replies; 3089+ messages in thread From: Julian Calaby @ 2016-04-08 1:40 UTC (permalink / raw) To: ath9k-devel Hi Kalle, On Sat, Jan 2, 2016 at 5:25 AM, SF Markus Elfring <elfring@users.sourceforge.net> wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 19:09:32 +0100 > > Replace an explicit initialisation for one local variable at the beginning > by a conditional assignment. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> This looks sane to me. Reviewed-by: Julian Calaby <julian.calaby@gmail.com> Thanks, Julian Calaby > --- > drivers/net/wireless/ath/ath9k/htc_drv_main.c | 7 ++----- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c > index a680a97..30bd59e 100644 > --- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c > +++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c > @@ -246,7 +246,7 @@ static int ath9k_htc_set_channel(struct ath9k_htc_priv *priv, > struct ieee80211_conf *conf = &common->hw->conf; > bool fastcc; > struct ieee80211_channel *channel = hw->conf.chandef.chan; > - struct ath9k_hw_cal_data *caldata = NULL; > + struct ath9k_hw_cal_data *caldata; > enum htc_phymode mode; > __be16 htc_mode; > u8 cmd_rsp; > @@ -274,10 +274,7 @@ static int ath9k_htc_set_channel(struct ath9k_htc_priv *priv, > priv->ah->curchan->channel, > channel->center_freq, conf_is_ht(conf), conf_is_ht40(conf), > fastcc); > - > - if (!fastcc) > - caldata = &priv->caldata; > - > + caldata = fastcc ? NULL : &priv->caldata; > ret = ath9k_hw_reset(ah, hchan, caldata, fastcc); > if (ret) { > ath_err(common, > -- > 2.6.3 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Julian Calaby Email: julian.calaby at gmail.com Profile: http://www.google.com/profiles/julian.calaby/ ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_c @ 2016-04-08 1:40 ` Julian Calaby 0 siblings, 0 replies; 3089+ messages in thread From: Julian Calaby @ 2016-04-08 1:40 UTC (permalink / raw) To: Kalle Valo Cc: ath9k-devel, linux-wireless, netdev, QCA ath9k Development, LKML, SF Markus Elfring, kernel-janitors, Julia Lawall Hi Kalle, On Sat, Jan 2, 2016 at 5:25 AM, SF Markus Elfring <elfring@users.sourceforge.net> wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 19:09:32 +0100 > > Replace an explicit initialisation for one local variable at the beginning > by a conditional assignment. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> This looks sane to me. Reviewed-by: Julian Calaby <julian.calaby@gmail.com> Thanks, Julian Calaby > --- > drivers/net/wireless/ath/ath9k/htc_drv_main.c | 7 ++----- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c > index a680a97..30bd59e 100644 > --- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c > +++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c > @@ -246,7 +246,7 @@ static int ath9k_htc_set_channel(struct ath9k_htc_priv *priv, > struct ieee80211_conf *conf = &common->hw->conf; > bool fastcc; > struct ieee80211_channel *channel = hw->conf.chandef.chan; > - struct ath9k_hw_cal_data *caldata = NULL; > + struct ath9k_hw_cal_data *caldata; > enum htc_phymode mode; > __be16 htc_mode; > u8 cmd_rsp; > @@ -274,10 +274,7 @@ static int ath9k_htc_set_channel(struct ath9k_htc_priv *priv, > priv->ah->curchan->channel, > channel->center_freq, conf_is_ht(conf), conf_is_ht40(conf), > fastcc); > - > - if (!fastcc) > - caldata = &priv->caldata; > - > + caldata = fastcc ? NULL : &priv->caldata; > ret = ath9k_hw_reset(ah, hchan, caldata, fastcc); > if (ret) { > ath_err(common, > -- > 2.6.3 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Julian Calaby Email: julian.calaby@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() @ 2016-04-08 1:40 ` Julian Calaby 0 siblings, 0 replies; 3089+ messages in thread From: Julian Calaby @ 2016-04-08 1:40 UTC (permalink / raw) To: Kalle Valo Cc: ath9k-devel, linux-wireless, netdev, QCA ath9k Development, LKML, SF Markus Elfring, kernel-janitors, Julia Lawall Hi Kalle, On Sat, Jan 2, 2016 at 5:25 AM, SF Markus Elfring <elfring@users.sourceforge.net> wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 19:09:32 +0100 > > Replace an explicit initialisation for one local variable at the beginning > by a conditional assignment. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> This looks sane to me. Reviewed-by: Julian Calaby <julian.calaby@gmail.com> Thanks, Julian Calaby > --- > drivers/net/wireless/ath/ath9k/htc_drv_main.c | 7 ++----- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c > index a680a97..30bd59e 100644 > --- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c > +++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c > @@ -246,7 +246,7 @@ static int ath9k_htc_set_channel(struct ath9k_htc_priv *priv, > struct ieee80211_conf *conf = &common->hw->conf; > bool fastcc; > struct ieee80211_channel *channel = hw->conf.chandef.chan; > - struct ath9k_hw_cal_data *caldata = NULL; > + struct ath9k_hw_cal_data *caldata; > enum htc_phymode mode; > __be16 htc_mode; > u8 cmd_rsp; > @@ -274,10 +274,7 @@ static int ath9k_htc_set_channel(struct ath9k_htc_priv *priv, > priv->ah->curchan->channel, > channel->center_freq, conf_is_ht(conf), conf_is_ht40(conf), > fastcc); > - > - if (!fastcc) > - caldata = &priv->caldata; > - > + caldata = fastcc ? NULL : &priv->caldata; > ret = ath9k_hw_reset(ah, hchan, caldata, fastcc); > if (ret) { > ath_err(common, > -- > 2.6.3 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Julian Calaby Email: julian.calaby@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() 2016-04-08 1:40 ` [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() Julian Calaby (?) (?) @ 2016-04-15 12:09 ` Kalle Valo -1 siblings, 0 replies; 3089+ messages in thread From: Kalle Valo @ 2016-04-15 12:09 UTC (permalink / raw) To: Julian Calaby Cc: ath9k-devel, linux-wireless, netdev, QCA ath9k Development, LKML, SF Markus Elfring, kernel-janitors, Julia Lawall Julian Calaby <julian.calaby@gmail.com> writes: > Hi Kalle, > > On Sat, Jan 2, 2016 at 5:25 AM, SF Markus Elfring > <elfring@users.sourceforge.net> wrote: >> From: Markus Elfring <elfring@users.sourceforge.net> >> Date: Fri, 1 Jan 2016 19:09:32 +0100 >> >> Replace an explicit initialisation for one local variable at the beginning >> by a conditional assignment. >> >> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > > This looks sane to me. > > Reviewed-by: Julian Calaby <julian.calaby@gmail.com> Before I commit I'll just change the commit title to: ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() -- Kalle Valo ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [ath9k-devel] [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() @ 2016-04-15 12:09 ` Kalle Valo 0 siblings, 0 replies; 3089+ messages in thread From: Kalle Valo @ 2016-04-15 12:09 UTC (permalink / raw) To: ath9k-devel Julian Calaby <julian.calaby@gmail.com> writes: > Hi Kalle, > > On Sat, Jan 2, 2016 at 5:25 AM, SF Markus Elfring > <elfring@users.sourceforge.net> wrote: >> From: Markus Elfring <elfring@users.sourceforge.net> >> Date: Fri, 1 Jan 2016 19:09:32 +0100 >> >> Replace an explicit initialisation for one local variable at the beginning >> by a conditional assignment. >> >> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > > This looks sane to me. > > Reviewed-by: Julian Calaby <julian.calaby@gmail.com> Before I commit I'll just change the commit title to: ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() -- Kalle Valo ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_c @ 2016-04-15 12:09 ` Kalle Valo 0 siblings, 0 replies; 3089+ messages in thread From: Kalle Valo @ 2016-04-15 12:09 UTC (permalink / raw) To: Julian Calaby Cc: ath9k-devel, linux-wireless, netdev, QCA ath9k Development, LKML, SF Markus Elfring, kernel-janitors, Julia Lawall Julian Calaby <julian.calaby@gmail.com> writes: > Hi Kalle, > > On Sat, Jan 2, 2016 at 5:25 AM, SF Markus Elfring > <elfring@users.sourceforge.net> wrote: >> From: Markus Elfring <elfring@users.sourceforge.net> >> Date: Fri, 1 Jan 2016 19:09:32 +0100 >> >> Replace an explicit initialisation for one local variable at the beginning >> by a conditional assignment. >> >> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > > This looks sane to me. > > Reviewed-by: Julian Calaby <julian.calaby@gmail.com> Before I commit I'll just change the commit title to: ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() -- Kalle Valo ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() @ 2016-04-15 12:09 ` Kalle Valo 0 siblings, 0 replies; 3089+ messages in thread From: Kalle Valo @ 2016-04-15 12:09 UTC (permalink / raw) To: Julian Calaby Cc: ath9k-devel, linux-wireless, netdev, QCA ath9k Development, LKML, SF Markus Elfring, kernel-janitors, Julia Lawall Julian Calaby <julian.calaby@gmail.com> writes: > Hi Kalle, > > On Sat, Jan 2, 2016 at 5:25 AM, SF Markus Elfring > <elfring@users.sourceforge.net> wrote: >> From: Markus Elfring <elfring@users.sourceforge.net> >> Date: Fri, 1 Jan 2016 19:09:32 +0100 >> >> Replace an explicit initialisation for one local variable at the beginning >> by a conditional assignment. >> >> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > > This looks sane to me. > > Reviewed-by: Julian Calaby <julian.calaby@gmail.com> Before I commit I'll just change the commit title to: ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() -- Kalle Valo ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() 2016-04-15 12:09 ` [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() Kalle Valo (?) (?) @ 2016-04-15 14:34 ` Julian Calaby -1 siblings, 0 replies; 3089+ messages in thread From: Julian Calaby @ 2016-04-15 14:34 UTC (permalink / raw) To: Kalle Valo Cc: ath9k-devel, linux-wireless, netdev, QCA ath9k Development, LKML, SF Markus Elfring, kernel-janitors, Julia Lawall Hi Kalle, On Fri, Apr 15, 2016 at 10:09 PM, Kalle Valo <kvalo@codeaurora.org> wrote: > Julian Calaby <julian.calaby@gmail.com> writes: > >> Hi Kalle, >> >> On Sat, Jan 2, 2016 at 5:25 AM, SF Markus Elfring >> <elfring@users.sourceforge.net> wrote: >>> From: Markus Elfring <elfring@users.sourceforge.net> >>> Date: Fri, 1 Jan 2016 19:09:32 +0100 >>> >>> Replace an explicit initialisation for one local variable at the beginning >>> by a conditional assignment. >>> >>> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> >> >> This looks sane to me. >> >> Reviewed-by: Julian Calaby <julian.calaby@gmail.com> > > Before I commit I'll just change the commit title to: > > ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() Sounds good to me. Thanks, -- Julian Calaby Email: julian.calaby@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [ath9k-devel] [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() @ 2016-04-15 14:34 ` Julian Calaby 0 siblings, 0 replies; 3089+ messages in thread From: Julian Calaby @ 2016-04-15 14:34 UTC (permalink / raw) To: ath9k-devel Hi Kalle, On Fri, Apr 15, 2016 at 10:09 PM, Kalle Valo <kvalo@codeaurora.org> wrote: > Julian Calaby <julian.calaby@gmail.com> writes: > >> Hi Kalle, >> >> On Sat, Jan 2, 2016 at 5:25 AM, SF Markus Elfring >> <elfring@users.sourceforge.net> wrote: >>> From: Markus Elfring <elfring@users.sourceforge.net> >>> Date: Fri, 1 Jan 2016 19:09:32 +0100 >>> >>> Replace an explicit initialisation for one local variable at the beginning >>> by a conditional assignment. >>> >>> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> >> >> This looks sane to me. >> >> Reviewed-by: Julian Calaby <julian.calaby@gmail.com> > > Before I commit I'll just change the commit title to: > > ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() Sounds good to me. Thanks, -- Julian Calaby Email: julian.calaby at gmail.com Profile: http://www.google.com/profiles/julian.calaby/ ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_c @ 2016-04-15 14:34 ` Julian Calaby 0 siblings, 0 replies; 3089+ messages in thread From: Julian Calaby @ 2016-04-15 14:34 UTC (permalink / raw) To: Kalle Valo Cc: ath9k-devel, linux-wireless, netdev, QCA ath9k Development, LKML, SF Markus Elfring, kernel-janitors, Julia Lawall Hi Kalle, On Fri, Apr 15, 2016 at 10:09 PM, Kalle Valo <kvalo@codeaurora.org> wrote: > Julian Calaby <julian.calaby@gmail.com> writes: > >> Hi Kalle, >> >> On Sat, Jan 2, 2016 at 5:25 AM, SF Markus Elfring >> <elfring@users.sourceforge.net> wrote: >>> From: Markus Elfring <elfring@users.sourceforge.net> >>> Date: Fri, 1 Jan 2016 19:09:32 +0100 >>> >>> Replace an explicit initialisation for one local variable at the beginning >>> by a conditional assignment. >>> >>> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> >> >> This looks sane to me. >> >> Reviewed-by: Julian Calaby <julian.calaby@gmail.com> > > Before I commit I'll just change the commit title to: > > ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() Sounds good to me. Thanks, -- Julian Calaby Email: julian.calaby@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() @ 2016-04-15 14:34 ` Julian Calaby 0 siblings, 0 replies; 3089+ messages in thread From: Julian Calaby @ 2016-04-15 14:34 UTC (permalink / raw) To: Kalle Valo Cc: ath9k-devel, linux-wireless, netdev, QCA ath9k Development, LKML, SF Markus Elfring, kernel-janitors, Julia Lawall Hi Kalle, On Fri, Apr 15, 2016 at 10:09 PM, Kalle Valo <kvalo@codeaurora.org> wrote: > Julian Calaby <julian.calaby@gmail.com> writes: > >> Hi Kalle, >> >> On Sat, Jan 2, 2016 at 5:25 AM, SF Markus Elfring >> <elfring@users.sourceforge.net> wrote: >>> From: Markus Elfring <elfring@users.sourceforge.net> >>> Date: Fri, 1 Jan 2016 19:09:32 +0100 >>> >>> Replace an explicit initialisation for one local variable at the beginning >>> by a conditional assignment. >>> >>> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> >> >> This looks sane to me. >> >> Reviewed-by: Julian Calaby <julian.calaby@gmail.com> > > Before I commit I'll just change the commit title to: > > ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() Sounds good to me. Thanks, -- Julian Calaby Email: julian.calaby@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() 2016-04-08 1:40 ` [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() Julian Calaby (?) (?) @ 2016-04-19 16:13 ` Kalle Valo -1 siblings, 0 replies; 3089+ messages in thread From: Kalle Valo @ 2016-04-19 16:13 UTC (permalink / raw) To: Julian Calaby Cc: ath9k-devel, linux-wireless, netdev, QCA ath9k Development, LKML, SF Markus Elfring, kernel-janitors, Julia Lawall Julian Calaby <julian.calaby@gmail.com> writes: > On Sat, Jan 2, 2016 at 5:25 AM, SF Markus Elfring > <elfring@users.sourceforge.net> wrote: >> From: Markus Elfring <elfring@users.sourceforge.net> >> Date: Fri, 1 Jan 2016 19:09:32 +0100 >> >> Replace an explicit initialisation for one local variable at the beginning >> by a conditional assignment. >> >> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > > This looks sane to me. > > Reviewed-by: Julian Calaby <julian.calaby@gmail.com> Applied, thanks. -- Kalle Valo ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [ath9k-devel] [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() @ 2016-04-19 16:13 ` Kalle Valo 0 siblings, 0 replies; 3089+ messages in thread From: Kalle Valo @ 2016-04-19 16:13 UTC (permalink / raw) To: ath9k-devel Julian Calaby <julian.calaby@gmail.com> writes: > On Sat, Jan 2, 2016 at 5:25 AM, SF Markus Elfring > <elfring@users.sourceforge.net> wrote: >> From: Markus Elfring <elfring@users.sourceforge.net> >> Date: Fri, 1 Jan 2016 19:09:32 +0100 >> >> Replace an explicit initialisation for one local variable at the beginning >> by a conditional assignment. >> >> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > > This looks sane to me. > > Reviewed-by: Julian Calaby <julian.calaby@gmail.com> Applied, thanks. -- Kalle Valo ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_c @ 2016-04-19 16:13 ` Kalle Valo 0 siblings, 0 replies; 3089+ messages in thread From: Kalle Valo @ 2016-04-19 16:13 UTC (permalink / raw) To: Julian Calaby Cc: ath9k-devel, linux-wireless, netdev, QCA ath9k Development, LKML, SF Markus Elfring, kernel-janitors, Julia Lawall Julian Calaby <julian.calaby@gmail.com> writes: > On Sat, Jan 2, 2016 at 5:25 AM, SF Markus Elfring > <elfring@users.sourceforge.net> wrote: >> From: Markus Elfring <elfring@users.sourceforge.net> >> Date: Fri, 1 Jan 2016 19:09:32 +0100 >> >> Replace an explicit initialisation for one local variable at the beginning >> by a conditional assignment. >> >> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > > This looks sane to me. > > Reviewed-by: Julian Calaby <julian.calaby@gmail.com> Applied, thanks. -- Kalle Valo ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() @ 2016-04-19 16:13 ` Kalle Valo 0 siblings, 0 replies; 3089+ messages in thread From: Kalle Valo @ 2016-04-19 16:13 UTC (permalink / raw) To: Julian Calaby Cc: ath9k-devel, linux-wireless, netdev, QCA ath9k Development, LKML, SF Markus Elfring, kernel-janitors, Julia Lawall Julian Calaby <julian.calaby@gmail.com> writes: > On Sat, Jan 2, 2016 at 5:25 AM, SF Markus Elfring > <elfring@users.sourceforge.net> wrote: >> From: Markus Elfring <elfring@users.sourceforge.net> >> Date: Fri, 1 Jan 2016 19:09:32 +0100 >> >> Replace an explicit initialisation for one local variable at the beginning >> by a conditional assignment. >> >> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > > This looks sane to me. > > Reviewed-by: Julian Calaby <julian.calaby@gmail.com> Applied, thanks. -- Kalle Valo ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH] net-brcmfmac: Delete an unnecessary variable initialisation in brcmf_sdio_download_firmware() 2015-12-11 12:08 ` SF Markus Elfring @ 2016-01-01 19:26 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 19:26 UTC (permalink / raw) To: brcm80211-dev-list, linux-wireless, netdev, Arend van Spriel, Brett Rudley, Franky (Zhenhui) Lin, Hante Meuleman, Kalle Valo Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 20:20:15 +0100 Omit explicit initialisation at the beginning for one local variable that is redefined before its first use. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c index ceb2a75..c21eeb1 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c @@ -3260,7 +3260,7 @@ static int brcmf_sdio_download_firmware(struct brcmf_sdio *bus, const struct firmware *fw, void *nvram, u32 nvlen) { - int bcmerror = -EFAULT; + int bcmerror; u32 rstvec; sdio_claim_host(bus->sdiodev->func[1]); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH] net-brcmfmac: Delete an unnecessary variable initialisation in brcmf_sdio_download_firmware( @ 2016-01-01 19:26 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 19:26 UTC (permalink / raw) To: brcm80211-dev-list, linux-wireless, netdev, Arend van Spriel, Brett Rudley, Franky (Zhenhui) Lin, Hante Meuleman, Kalle Valo Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 20:20:15 +0100 Omit explicit initialisation at the beginning for one local variable that is redefined before its first use. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c index ceb2a75..c21eeb1 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c @@ -3260,7 +3260,7 @@ static int brcmf_sdio_download_firmware(struct brcmf_sdio *bus, const struct firmware *fw, void *nvram, u32 nvlen) { - int bcmerror = -EFAULT; + int bcmerror; u32 rstvec; sdio_claim_host(bus->sdiodev->func[1]); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH] net-brcmfmac: Delete an unnecessary variable initialisation in brcmf_sdio_download_firmware() @ 2016-01-02 8:50 ` Arend van Spriel 0 siblings, 0 replies; 3089+ messages in thread From: Arend van Spriel @ 2016-01-02 8:50 UTC (permalink / raw) To: SF Markus Elfring, brcm80211-dev-list, linux-wireless, netdev, Brett Rudley, Franky (Zhenhui) Lin, Hante Meuleman, Kalle Valo Cc: LKML, kernel-janitors, Julia Lawall On 01/01/2016 08:26 PM, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 20:20:15 +0100 I think it has been said over and over, but please use driver name only as prefix. I don't see value to prepend it with 'net-'. > Omit explicit initialisation at the beginning for one local variable > that is redefined before its first use. > That being said here is my.... Acked-by: Arend van Spriel <arend@broadcom.com> > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c > index ceb2a75..c21eeb1 100644 > --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c > +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c > @@ -3260,7 +3260,7 @@ static int brcmf_sdio_download_firmware(struct brcmf_sdio *bus, > const struct firmware *fw, > void *nvram, u32 nvlen) > { > - int bcmerror = -EFAULT; > + int bcmerror; > u32 rstvec; > > sdio_claim_host(bus->sdiodev->func[1]); > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] net-brcmfmac: Delete an unnecessary variable initialisation in brcmf_sdio_download_firmw @ 2016-01-02 8:50 ` Arend van Spriel 0 siblings, 0 replies; 3089+ messages in thread From: Arend van Spriel @ 2016-01-02 8:50 UTC (permalink / raw) To: SF Markus Elfring, brcm80211-dev-list, linux-wireless, netdev, Brett Rudley, Franky (Zhenhui) Lin, Hante Meuleman, Kalle Valo Cc: LKML, kernel-janitors, Julia Lawall On 01/01/2016 08:26 PM, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 20:20:15 +0100 I think it has been said over and over, but please use driver name only as prefix. I don't see value to prepend it with 'net-'. > Omit explicit initialisation at the beginning for one local variable > that is redefined before its first use. > That being said here is my.... Acked-by: Arend van Spriel <arend@broadcom.com> > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c > index ceb2a75..c21eeb1 100644 > --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c > +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c > @@ -3260,7 +3260,7 @@ static int brcmf_sdio_download_firmware(struct brcmf_sdio *bus, > const struct firmware *fw, > void *nvram, u32 nvlen) > { > - int bcmerror = -EFAULT; > + int bcmerror; > u32 rstvec; > > sdio_claim_host(bus->sdiodev->func[1]); > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] net-brcmfmac: Delete an unnecessary variable initialisation in brcmf_sdio_download_firmware() @ 2016-01-02 8:50 ` Arend van Spriel 0 siblings, 0 replies; 3089+ messages in thread From: Arend van Spriel @ 2016-01-02 8:50 UTC (permalink / raw) To: SF Markus Elfring, brcm80211-dev-list-dY08KVG/lbpWk0Htik3J/w, linux-wireless-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA, Brett Rudley, Franky (Zhenhui) Lin, Hante Meuleman, Kalle Valo Cc: LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall On 01/01/2016 08:26 PM, SF Markus Elfring wrote: > From: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> > Date: Fri, 1 Jan 2016 20:20:15 +0100 I think it has been said over and over, but please use driver name only as prefix. I don't see value to prepend it with 'net-'. > Omit explicit initialisation at the beginning for one local variable > that is redefined before its first use. > That being said here is my.... Acked-by: Arend van Spriel <arend-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> > Signed-off-by: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> > --- > drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c > index ceb2a75..c21eeb1 100644 > --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c > +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c > @@ -3260,7 +3260,7 @@ static int brcmf_sdio_download_firmware(struct brcmf_sdio *bus, > const struct firmware *fw, > void *nvram, u32 nvlen) > { > - int bcmerror = -EFAULT; > + int bcmerror; > u32 rstvec; > > sdio_claim_host(bus->sdiodev->func[1]); > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] net-brcmfmac: Delete an unnecessary variable initialisation in brcmf_sdio_download_firmware() 2016-01-02 8:50 ` [PATCH] net-brcmfmac: Delete an unnecessary variable initialisation in brcmf_sdio_download_firmware() Arend van Spriel @ 2016-01-14 6:58 ` Kalle Valo -1 siblings, 0 replies; 3089+ messages in thread From: Kalle Valo @ 2016-01-14 6:58 UTC (permalink / raw) To: Arend van Spriel Cc: SF Markus Elfring, brcm80211-dev-list, linux-wireless, netdev, Brett Rudley, Franky (Zhenhui) Lin, Hante Meuleman, LKML, kernel-janitors, Julia Lawall Arend van Spriel <arend@broadcom.com> writes: > On 01/01/2016 08:26 PM, SF Markus Elfring wrote: >> From: Markus Elfring <elfring@users.sourceforge.net> >> Date: Fri, 1 Jan 2016 20:20:15 +0100 > > I think it has been said over and over, but please use driver name > only as prefix. I don't see value to prepend it with 'net-'. Yes, please use existing naming schemes. This time I can fix it before I commit the patch, but in the future please use correct prefixes. It's easy to check what has been used previously: $ git log --oneline --no-merges --follow drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | head -10 63ce3d5db093 brcmfmac: use msecs_to_jiffies() in macro definitions 4011fc499690 brcmfmac: change brcmf_sdio_wd_timer() prototype a7decc44a002 brcmfmac: fix waitqueue_active without memory barrier in brcmfmac driver 46d703a77539 brcmfmac: Unify methods to define and map firmware files. 64d66c30c37e brcmfmac: no retries on rxglom superframe errors 6866a64a0f9b brcmfmac: constify brcmf_bus_ops structures 05491d2ccf20 brcm80211: move under broadcom vendor directory ff4445a8502c brcmfmac: expose device memory to devcoredump subsystem a32be0177252 brcmfmac: include linux/atomic.h 9d6c1dc4f913 brcmfmac: add dedicated debug level for firmware console logging $ -- Kalle Valo ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] net-brcmfmac: Delete an unnecessary variable initialisation in brcmf_sdio_download_firmw @ 2016-01-14 6:58 ` Kalle Valo 0 siblings, 0 replies; 3089+ messages in thread From: Kalle Valo @ 2016-01-14 6:58 UTC (permalink / raw) To: Arend van Spriel Cc: SF Markus Elfring, brcm80211-dev-list, linux-wireless, netdev, Brett Rudley, Franky (Zhenhui) Lin, Hante Meuleman, LKML, kernel-janitors, Julia Lawall Arend van Spriel <arend@broadcom.com> writes: > On 01/01/2016 08:26 PM, SF Markus Elfring wrote: >> From: Markus Elfring <elfring@users.sourceforge.net> >> Date: Fri, 1 Jan 2016 20:20:15 +0100 > > I think it has been said over and over, but please use driver name > only as prefix. I don't see value to prepend it with 'net-'. Yes, please use existing naming schemes. This time I can fix it before I commit the patch, but in the future please use correct prefixes. It's easy to check what has been used previously: $ git log --oneline --no-merges --follow drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | head -10 63ce3d5db093 brcmfmac: use msecs_to_jiffies() in macro definitions 4011fc499690 brcmfmac: change brcmf_sdio_wd_timer() prototype a7decc44a002 brcmfmac: fix waitqueue_active without memory barrier in brcmfmac driver 46d703a77539 brcmfmac: Unify methods to define and map firmware files. 64d66c30c37e brcmfmac: no retries on rxglom superframe errors 6866a64a0f9b brcmfmac: constify brcmf_bus_ops structures 05491d2ccf20 brcm80211: move under broadcom vendor directory ff4445a8502c brcmfmac: expose device memory to devcoredump subsystem a32be0177252 brcmfmac: include linux/atomic.h 9d6c1dc4f913 brcmfmac: add dedicated debug level for firmware console logging $ -- Kalle Valo ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/3] net-iwlegacy: Fine-tuning for il_eeprom_init() 2015-12-11 12:08 ` SF Markus Elfring @ 2016-01-01 20:27 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 20:27 UTC (permalink / raw) To: linux-wireless, netdev, Kalle Valo, Stanislaw Gruszka Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 21:25:43 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (3): Refactoring One check less after error detection Another refactoring drivers/net/wireless/intel/iwlegacy/common.c | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/3] net-iwlegacy: Fine-tuning for il_eeprom_init() @ 2016-01-01 20:27 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 20:27 UTC (permalink / raw) To: linux-wireless, netdev, Kalle Valo, Stanislaw Gruszka Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 21:25:43 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (3): Refactoring One check less after error detection Another refactoring drivers/net/wireless/intel/iwlegacy/common.c | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 1/3] net-iwlegacy: Refactoring for il_eeprom_init() 2016-01-01 20:27 ` SF Markus Elfring @ 2016-01-01 20:30 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 20:30 UTC (permalink / raw) To: linux-wireless, netdev, Kalle Valo, Stanislaw Gruszka Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 20:54:25 +0100 Return directly if a memory allocation failed at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/wireless/intel/iwlegacy/common.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/net/wireless/intel/iwlegacy/common.c b/drivers/net/wireless/intel/iwlegacy/common.c index eb5cb60..c3afaf7 100644 --- a/drivers/net/wireless/intel/iwlegacy/common.c +++ b/drivers/net/wireless/intel/iwlegacy/common.c @@ -723,10 +723,9 @@ il_eeprom_init(struct il_priv *il) sz = il->cfg->eeprom_size; D_EEPROM("NVM size = %d\n", sz); il->eeprom = kzalloc(sz, GFP_KERNEL); - if (!il->eeprom) { - ret = -ENOMEM; - goto alloc_err; - } + if (!il->eeprom) + return -ENOMEM; + e = (__le16 *) il->eeprom; il->ops->apm_init(il); @@ -778,7 +777,6 @@ err: il_eeprom_free(il); /* Reset chip to save power until we load uCode during "up". */ il_apm_stop(il); -alloc_err: return ret; } EXPORT_SYMBOL(il_eeprom_init); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 1/3] net-iwlegacy: Refactoring for il_eeprom_init() @ 2016-01-01 20:30 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 20:30 UTC (permalink / raw) To: linux-wireless, netdev, Kalle Valo, Stanislaw Gruszka Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 20:54:25 +0100 Return directly if a memory allocation failed at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/wireless/intel/iwlegacy/common.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/net/wireless/intel/iwlegacy/common.c b/drivers/net/wireless/intel/iwlegacy/common.c index eb5cb60..c3afaf7 100644 --- a/drivers/net/wireless/intel/iwlegacy/common.c +++ b/drivers/net/wireless/intel/iwlegacy/common.c @@ -723,10 +723,9 @@ il_eeprom_init(struct il_priv *il) sz = il->cfg->eeprom_size; D_EEPROM("NVM size = %d\n", sz); il->eeprom = kzalloc(sz, GFP_KERNEL); - if (!il->eeprom) { - ret = -ENOMEM; - goto alloc_err; - } + if (!il->eeprom) + return -ENOMEM; + e = (__le16 *) il->eeprom; il->ops->apm_init(il); @@ -778,7 +777,6 @@ err: il_eeprom_free(il); /* Reset chip to save power until we load uCode during "up". */ il_apm_stop(il); -alloc_err: return ret; } EXPORT_SYMBOL(il_eeprom_init); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/3] net-iwlegacy: Refactoring for il_eeprom_init() @ 2016-01-04 9:33 ` Stanislaw Gruszka 0 siblings, 0 replies; 3089+ messages in thread From: Stanislaw Gruszka @ 2016-01-04 9:33 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors, Julia Lawall On Fri, Jan 01, 2016 at 09:30:10PM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 20:54:25 +0100 > > Return directly if a memory allocation failed at the beginning. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com> ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/3] net-iwlegacy: Refactoring for il_eeprom_init() @ 2016-01-04 9:33 ` Stanislaw Gruszka 0 siblings, 0 replies; 3089+ messages in thread From: Stanislaw Gruszka @ 2016-01-04 9:33 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors, Julia Lawall On Fri, Jan 01, 2016 at 09:30:10PM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 20:54:25 +0100 > > Return directly if a memory allocation failed at the beginning. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com> ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/3] net-iwlegacy: Refactoring for il_eeprom_init() @ 2016-01-04 9:33 ` Stanislaw Gruszka 0 siblings, 0 replies; 3089+ messages in thread From: Stanislaw Gruszka @ 2016-01-04 9:33 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA, Kalle Valo, LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall On Fri, Jan 01, 2016 at 09:30:10PM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> > Date: Fri, 1 Jan 2016 20:54:25 +0100 > > Return directly if a memory allocation failed at the beginning. > > Signed-off-by: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> Acked-by: Stanislaw Gruszka <sgruszka-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 2/3] net-iwlegacy: One check less in il_eeprom_init() after error detection 2016-01-01 20:27 ` SF Markus Elfring @ 2016-01-01 20:31 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 20:31 UTC (permalink / raw) To: linux-wireless, netdev, Kalle Valo, Stanislaw Gruszka Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 21:12:29 +0100 This issue was detected by using the Coccinelle software. Adjust a jump target to avoid a check repetition before the function call "il_eeprom_free". Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/wireless/intel/iwlegacy/common.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/intel/iwlegacy/common.c b/drivers/net/wireless/intel/iwlegacy/common.c index c3afaf7..ae45fd3 100644 --- a/drivers/net/wireless/intel/iwlegacy/common.c +++ b/drivers/net/wireless/intel/iwlegacy/common.c @@ -734,7 +734,7 @@ il_eeprom_init(struct il_priv *il) if (ret < 0) { IL_ERR("EEPROM not found, EEPROM_GP=0x%08x\n", gp); ret = -ENOENT; - goto err; + goto free_eeprom; } /* Make sure driver (instead of uCode) is allowed to read EEPROM */ @@ -742,7 +742,7 @@ il_eeprom_init(struct il_priv *il) if (ret < 0) { IL_ERR("Failed to acquire EEPROM semaphore.\n"); ret = -ENOENT; - goto err; + goto free_eeprom; } /* eeprom is an array of 16bit values */ @@ -772,9 +772,11 @@ il_eeprom_init(struct il_priv *il) done: il->ops->eeprom_release_semaphore(il); -err: - if (ret) + if (ret) { +free_eeprom: il_eeprom_free(il); + } + /* Reset chip to save power until we load uCode during "up". */ il_apm_stop(il); return ret; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 2/3] net-iwlegacy: One check less in il_eeprom_init() after error detection @ 2016-01-01 20:31 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 20:31 UTC (permalink / raw) To: linux-wireless, netdev, Kalle Valo, Stanislaw Gruszka Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 21:12:29 +0100 This issue was detected by using the Coccinelle software. Adjust a jump target to avoid a check repetition before the function call "il_eeprom_free". Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/wireless/intel/iwlegacy/common.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/intel/iwlegacy/common.c b/drivers/net/wireless/intel/iwlegacy/common.c index c3afaf7..ae45fd3 100644 --- a/drivers/net/wireless/intel/iwlegacy/common.c +++ b/drivers/net/wireless/intel/iwlegacy/common.c @@ -734,7 +734,7 @@ il_eeprom_init(struct il_priv *il) if (ret < 0) { IL_ERR("EEPROM not found, EEPROM_GP=0x%08x\n", gp); ret = -ENOENT; - goto err; + goto free_eeprom; } /* Make sure driver (instead of uCode) is allowed to read EEPROM */ @@ -742,7 +742,7 @@ il_eeprom_init(struct il_priv *il) if (ret < 0) { IL_ERR("Failed to acquire EEPROM semaphore.\n"); ret = -ENOENT; - goto err; + goto free_eeprom; } /* eeprom is an array of 16bit values */ @@ -772,9 +772,11 @@ il_eeprom_init(struct il_priv *il) done: il->ops->eeprom_release_semaphore(il); -err: - if (ret) + if (ret) { +free_eeprom: il_eeprom_free(il); + } + /* Reset chip to save power until we load uCode during "up". */ il_apm_stop(il); return ret; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/3] net-iwlegacy: One check less in il_eeprom_init() after error detection 2016-01-01 20:31 ` SF Markus Elfring @ 2016-01-01 23:13 ` Sergei Shtylyov -1 siblings, 0 replies; 3089+ messages in thread From: Sergei Shtylyov @ 2016-01-01 23:13 UTC (permalink / raw) To: SF Markus Elfring, linux-wireless, netdev, Kalle Valo, Stanislaw Gruszka Cc: LKML, kernel-janitors, Julia Lawall Hello. On 1/1/2016 11:31 PM, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 21:12:29 +0100 > > This issue was detected by using the Coccinelle software. > > Adjust a jump target to avoid a check repetition before the function > call "il_eeprom_free". One question: why? > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/net/wireless/intel/iwlegacy/common.c | 10 ++++++---- > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/drivers/net/wireless/intel/iwlegacy/common.c b/drivers/net/wireless/intel/iwlegacy/common.c > index c3afaf7..ae45fd3 100644 > --- a/drivers/net/wireless/intel/iwlegacy/common.c > +++ b/drivers/net/wireless/intel/iwlegacy/common.c [...] > @@ -772,9 +772,11 @@ il_eeprom_init(struct il_priv *il) > done: > il->ops->eeprom_release_semaphore(il); > > -err: > - if (ret) > + if (ret) { > +free_eeprom: This is ugly, I'd say. [...] MBR, Sergei ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/3] net-iwlegacy: One check less in il_eeprom_init() after error detection @ 2016-01-01 23:13 ` Sergei Shtylyov 0 siblings, 0 replies; 3089+ messages in thread From: Sergei Shtylyov @ 2016-01-01 23:13 UTC (permalink / raw) To: SF Markus Elfring, linux-wireless, netdev, Kalle Valo, Stanislaw Gruszka Cc: LKML, kernel-janitors, Julia Lawall Hello. On 1/1/2016 11:31 PM, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 21:12:29 +0100 > > This issue was detected by using the Coccinelle software. > > Adjust a jump target to avoid a check repetition before the function > call "il_eeprom_free". One question: why? > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/net/wireless/intel/iwlegacy/common.c | 10 ++++++---- > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/drivers/net/wireless/intel/iwlegacy/common.c b/drivers/net/wireless/intel/iwlegacy/common.c > index c3afaf7..ae45fd3 100644 > --- a/drivers/net/wireless/intel/iwlegacy/common.c > +++ b/drivers/net/wireless/intel/iwlegacy/common.c [...] > @@ -772,9 +772,11 @@ il_eeprom_init(struct il_priv *il) > done: > il->ops->eeprom_release_semaphore(il); > > -err: > - if (ret) > + if (ret) { > +free_eeprom: This is ugly, I'd say. [...] MBR, Sergei ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 3/3] net-iwlegacy: Another refactoring for il_eeprom_init() 2016-01-01 20:27 ` SF Markus Elfring @ 2016-01-01 20:32 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 20:32 UTC (permalink / raw) To: linux-wireless, netdev, Kalle Valo, Stanislaw Gruszka Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 21:16:01 +0100 Rename a jump label according to the current Linux coding style convention. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/wireless/intel/iwlegacy/common.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/intel/iwlegacy/common.c b/drivers/net/wireless/intel/iwlegacy/common.c index ae45fd3..660ab2b 100644 --- a/drivers/net/wireless/intel/iwlegacy/common.c +++ b/drivers/net/wireless/intel/iwlegacy/common.c @@ -759,7 +759,7 @@ il_eeprom_init(struct il_priv *il) IL_EEPROM_ACCESS_TIMEOUT); if (ret < 0) { IL_ERR("Time out reading EEPROM[%d]\n", addr); - goto done; + goto release_semaphore; } r = _il_rd(il, CSR_EEPROM_REG); e[addr / 2] = cpu_to_le16(r >> 16); @@ -769,7 +769,7 @@ il_eeprom_init(struct il_priv *il) il_eeprom_query16(il, EEPROM_VERSION)); ret = 0; -done: +release_semaphore: il->ops->eeprom_release_semaphore(il); if (ret) { -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 3/3] net-iwlegacy: Another refactoring for il_eeprom_init() @ 2016-01-01 20:32 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 20:32 UTC (permalink / raw) To: linux-wireless, netdev, Kalle Valo, Stanislaw Gruszka Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 21:16:01 +0100 Rename a jump label according to the current Linux coding style convention. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/wireless/intel/iwlegacy/common.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/intel/iwlegacy/common.c b/drivers/net/wireless/intel/iwlegacy/common.c index ae45fd3..660ab2b 100644 --- a/drivers/net/wireless/intel/iwlegacy/common.c +++ b/drivers/net/wireless/intel/iwlegacy/common.c @@ -759,7 +759,7 @@ il_eeprom_init(struct il_priv *il) IL_EEPROM_ACCESS_TIMEOUT); if (ret < 0) { IL_ERR("Time out reading EEPROM[%d]\n", addr); - goto done; + goto release_semaphore; } r = _il_rd(il, CSR_EEPROM_REG); e[addr / 2] = cpu_to_le16(r >> 16); @@ -769,7 +769,7 @@ il_eeprom_init(struct il_priv *il) il_eeprom_query16(il, EEPROM_VERSION)); ret = 0; -done: +release_semaphore: il->ops->eeprom_release_semaphore(il); if (ret) { -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 3/3] net-iwlegacy: Another refactoring for il_eeprom_init() 2016-01-01 20:32 ` SF Markus Elfring @ 2016-01-02 18:30 ` Souptick Joarder -1 siblings, 0 replies; 3089+ messages in thread From: Souptick Joarder @ 2016-01-02 18:18 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-wireless, netdev, Kalle Valo, Stanislaw Gruszka, LKML, kernel-janitors, Julia Lawall On Sat, Jan 2, 2016 at 2:02 AM, SF Markus Elfring <elfring@users.sourceforge.net> wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 21:16:01 +0100 > > Rename a jump label according to the current Linux coding style convention. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/net/wireless/intel/iwlegacy/common.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/wireless/intel/iwlegacy/common.c b/drivers/net/wireless/intel/iwlegacy/common.c > index ae45fd3..660ab2b 100644 > --- a/drivers/net/wireless/intel/iwlegacy/common.c > +++ b/drivers/net/wireless/intel/iwlegacy/common.c > @@ -759,7 +759,7 @@ il_eeprom_init(struct il_priv *il) > IL_EEPROM_ACCESS_TIMEOUT); > if (ret < 0) { > IL_ERR("Time out reading EEPROM[%d]\n", addr); > - goto done; > + goto release_semaphore; Current code looks good. > } > r = _il_rd(il, CSR_EEPROM_REG); > e[addr / 2] = cpu_to_le16(r >> 16); > @@ -769,7 +769,7 @@ il_eeprom_init(struct il_priv *il) > il_eeprom_query16(il, EEPROM_VERSION)); > > ret = 0; > -done: > +release_semaphore: > il->ops->eeprom_release_semaphore(il); > > if (ret) { > -- > 2.6.3 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -Souptick ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 3/3] net-iwlegacy: Another refactoring for il_eeprom_init() @ 2016-01-02 18:30 ` Souptick Joarder 0 siblings, 0 replies; 3089+ messages in thread From: Souptick Joarder @ 2016-01-02 18:30 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-wireless, netdev, Kalle Valo, Stanislaw Gruszka, LKML, kernel-janitors, Julia Lawall On Sat, Jan 2, 2016 at 2:02 AM, SF Markus Elfring <elfring@users.sourceforge.net> wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 21:16:01 +0100 > > Rename a jump label according to the current Linux coding style convention. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/net/wireless/intel/iwlegacy/common.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/wireless/intel/iwlegacy/common.c b/drivers/net/wireless/intel/iwlegacy/common.c > index ae45fd3..660ab2b 100644 > --- a/drivers/net/wireless/intel/iwlegacy/common.c > +++ b/drivers/net/wireless/intel/iwlegacy/common.c > @@ -759,7 +759,7 @@ il_eeprom_init(struct il_priv *il) > IL_EEPROM_ACCESS_TIMEOUT); > if (ret < 0) { > IL_ERR("Time out reading EEPROM[%d]\n", addr); > - goto done; > + goto release_semaphore; Current code looks good. > } > r = _il_rd(il, CSR_EEPROM_REG); > e[addr / 2] = cpu_to_le16(r >> 16); > @@ -769,7 +769,7 @@ il_eeprom_init(struct il_priv *il) > il_eeprom_query16(il, EEPROM_VERSION)); > > ret = 0; > -done: > +release_semaphore: > il->ops->eeprom_release_semaphore(il); > > if (ret) { > -- > 2.6.3 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -Souptick ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH] net-libertas: Better exception handling in if_spi_host_to_card_worker() 2015-12-11 12:08 ` SF Markus Elfring @ 2016-01-01 21:33 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 21:33 UTC (permalink / raw) To: libertas-dev, linux-wireless, netdev, Kalle Valo Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 22:27:20 +0100 This issue was detected by using the Coccinelle software. Move the jump label directly before the desired log statement so that the variable "err" will not be checked once more after it was determined that a function call failed. Use the identifier "report_failure" instead of the label "err". Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/wireless/marvell/libertas/if_spi.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/net/wireless/marvell/libertas/if_spi.c b/drivers/net/wireless/marvell/libertas/if_spi.c index 82c0796..c9ae27e 100644 --- a/drivers/net/wireless/marvell/libertas/if_spi.c +++ b/drivers/net/wireless/marvell/libertas/if_spi.c @@ -880,18 +880,18 @@ static void if_spi_host_to_card_worker(struct work_struct *work) &hiStatus); if (err) { netdev_err(priv->dev, "I/O error\n"); - goto err; + goto report_failure; } if (hiStatus & IF_SPI_HIST_CMD_UPLOAD_RDY) { err = if_spi_c2h_cmd(card); if (err) - goto err; + goto report_failure; } if (hiStatus & IF_SPI_HIST_RX_UPLOAD_RDY) { err = if_spi_c2h_data(card); if (err) - goto err; + goto report_failure; } /* @@ -940,9 +940,10 @@ static void if_spi_host_to_card_worker(struct work_struct *work) if (hiStatus & IF_SPI_HIST_CARD_EVENT) if_spi_e2h(card); -err: - if (err) + if (err) { +report_failure: netdev_err(priv->dev, "%s: got error %d\n", __func__, err); + } lbs_deb_leave(LBS_DEB_SPI); } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH] net-libertas: Better exception handling in if_spi_host_to_card_worker() @ 2016-01-01 21:33 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-01 21:33 UTC (permalink / raw) To: libertas-dev, linux-wireless, netdev, Kalle Valo Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 1 Jan 2016 22:27:20 +0100 This issue was detected by using the Coccinelle software. Move the jump label directly before the desired log statement so that the variable "err" will not be checked once more after it was determined that a function call failed. Use the identifier "report_failure" instead of the label "err". Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/wireless/marvell/libertas/if_spi.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/net/wireless/marvell/libertas/if_spi.c b/drivers/net/wireless/marvell/libertas/if_spi.c index 82c0796..c9ae27e 100644 --- a/drivers/net/wireless/marvell/libertas/if_spi.c +++ b/drivers/net/wireless/marvell/libertas/if_spi.c @@ -880,18 +880,18 @@ static void if_spi_host_to_card_worker(struct work_struct *work) &hiStatus); if (err) { netdev_err(priv->dev, "I/O error\n"); - goto err; + goto report_failure; } if (hiStatus & IF_SPI_HIST_CMD_UPLOAD_RDY) { err = if_spi_c2h_cmd(card); if (err) - goto err; + goto report_failure; } if (hiStatus & IF_SPI_HIST_RX_UPLOAD_RDY) { err = if_spi_c2h_data(card); if (err) - goto err; + goto report_failure; } /* @@ -940,9 +940,10 @@ static void if_spi_host_to_card_worker(struct work_struct *work) if (hiStatus & IF_SPI_HIST_CARD_EVENT) if_spi_e2h(card); -err: - if (err) + if (err) { +report_failure: netdev_err(priv->dev, "%s: got error %d\n", __func__, err); + } lbs_deb_leave(LBS_DEB_SPI); } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH] net-libertas: Better exception handling in if_spi_host_to_card_worker() 2016-01-01 21:33 ` SF Markus Elfring @ 2016-01-01 21:41 ` Julia Lawall -1 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2016-01-01 21:41 UTC (permalink / raw) To: SF Markus Elfring Cc: libertas-dev, linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors On Fri, 1 Jan 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 22:27:20 +0100 > > This issue was detected by using the Coccinelle software. > > Move the jump label directly before the desired log statement > so that the variable "err" will not be checked once more > after it was determined that a function call failed. Putting a label inside an if is ugly. julia > Use the identifier "report_failure" instead of the label "err". > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/net/wireless/marvell/libertas/if_spi.c | 11 ++++++----- > 1 file changed, 6 insertions(+), 5 deletions(-) > > diff --git a/drivers/net/wireless/marvell/libertas/if_spi.c b/drivers/net/wireless/marvell/libertas/if_spi.c > index 82c0796..c9ae27e 100644 > --- a/drivers/net/wireless/marvell/libertas/if_spi.c > +++ b/drivers/net/wireless/marvell/libertas/if_spi.c > @@ -880,18 +880,18 @@ static void if_spi_host_to_card_worker(struct work_struct *work) > &hiStatus); > if (err) { > netdev_err(priv->dev, "I/O error\n"); > - goto err; > + goto report_failure; > } > > if (hiStatus & IF_SPI_HIST_CMD_UPLOAD_RDY) { > err = if_spi_c2h_cmd(card); > if (err) > - goto err; > + goto report_failure; > } > if (hiStatus & IF_SPI_HIST_RX_UPLOAD_RDY) { > err = if_spi_c2h_data(card); > if (err) > - goto err; > + goto report_failure; > } > > /* > @@ -940,9 +940,10 @@ static void if_spi_host_to_card_worker(struct work_struct *work) > if (hiStatus & IF_SPI_HIST_CARD_EVENT) > if_spi_e2h(card); > > -err: > - if (err) > + if (err) { > +report_failure: > netdev_err(priv->dev, "%s: got error %d\n", __func__, err); > + } > > lbs_deb_leave(LBS_DEB_SPI); > } > -- > 2.6.3 > > -- > To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] net-libertas: Better exception handling in if_spi_host_to_card_worker() @ 2016-01-01 21:41 ` Julia Lawall 0 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2016-01-01 21:41 UTC (permalink / raw) To: SF Markus Elfring Cc: libertas-dev, linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors On Fri, 1 Jan 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 22:27:20 +0100 > > This issue was detected by using the Coccinelle software. > > Move the jump label directly before the desired log statement > so that the variable "err" will not be checked once more > after it was determined that a function call failed. Putting a label inside an if is ugly. julia > Use the identifier "report_failure" instead of the label "err". > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/net/wireless/marvell/libertas/if_spi.c | 11 ++++++----- > 1 file changed, 6 insertions(+), 5 deletions(-) > > diff --git a/drivers/net/wireless/marvell/libertas/if_spi.c b/drivers/net/wireless/marvell/libertas/if_spi.c > index 82c0796..c9ae27e 100644 > --- a/drivers/net/wireless/marvell/libertas/if_spi.c > +++ b/drivers/net/wireless/marvell/libertas/if_spi.c > @@ -880,18 +880,18 @@ static void if_spi_host_to_card_worker(struct work_struct *work) > &hiStatus); > if (err) { > netdev_err(priv->dev, "I/O error\n"); > - goto err; > + goto report_failure; > } > > if (hiStatus & IF_SPI_HIST_CMD_UPLOAD_RDY) { > err = if_spi_c2h_cmd(card); > if (err) > - goto err; > + goto report_failure; > } > if (hiStatus & IF_SPI_HIST_RX_UPLOAD_RDY) { > err = if_spi_c2h_data(card); > if (err) > - goto err; > + goto report_failure; > } > > /* > @@ -940,9 +940,10 @@ static void if_spi_host_to_card_worker(struct work_struct *work) > if (hiStatus & IF_SPI_HIST_CARD_EVENT) > if_spi_e2h(card); > > -err: > - if (err) > + if (err) { > +report_failure: > netdev_err(priv->dev, "%s: got error %d\n", __func__, err); > + } > > lbs_deb_leave(LBS_DEB_SPI); > } > -- > 2.6.3 > > -- > To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] net-libertas: Better exception handling in if_spi_host_to_card_worker() 2016-01-01 21:33 ` SF Markus Elfring @ 2016-01-01 23:14 ` Sergei Shtylyov -1 siblings, 0 replies; 3089+ messages in thread From: Sergei Shtylyov @ 2016-01-01 23:14 UTC (permalink / raw) To: SF Markus Elfring, libertas-dev, linux-wireless, netdev, Kalle Valo Cc: LKML, kernel-janitors, Julia Lawall Hello On 1/2/2016 12:33 AM, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 22:27:20 +0100 > > This issue was detected by using the Coccinelle software. > > Move the jump label directly before the desired log statement > so that the variable "err" will not be checked once more > after it was determined that a function call failed. > Use the identifier "report_failure" instead of the label "err". Why? The code was smart enough and you're making it uglier that it needs to be. > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> MBR, Sergei ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] net-libertas: Better exception handling in if_spi_host_to_card_worker() @ 2016-01-01 23:14 ` Sergei Shtylyov 0 siblings, 0 replies; 3089+ messages in thread From: Sergei Shtylyov @ 2016-01-01 23:14 UTC (permalink / raw) To: SF Markus Elfring, libertas-dev, linux-wireless, netdev, Kalle Valo Cc: LKML, kernel-janitors, Julia Lawall Hello On 1/2/2016 12:33 AM, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Fri, 1 Jan 2016 22:27:20 +0100 > > This issue was detected by using the Coccinelle software. > > Move the jump label directly before the desired log statement > so that the variable "err" will not be checked once more > after it was determined that a function call failed. > Use the identifier "report_failure" instead of the label "err". Why? The code was smart enough and you're making it uglier that it needs to be. > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> MBR, Sergei ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] net-libertas: Better exception handling in if_spi_host_to_card_worker() 2016-01-01 23:14 ` Sergei Shtylyov @ 2016-01-02 8:09 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 8:09 UTC (permalink / raw) To: Sergei Shtylyov, libertas-dev, linux-wireless, netdev, Kalle Valo Cc: LKML, kernel-janitors, Julia Lawall >> Move the jump label directly before the desired log statement >> so that the variable "err" will not be checked once more >> after it was determined that a function call failed. >> Use the identifier "report_failure" instead of the label "err". > > Why? I suggest to reconsider the places with which such a jump label is connected. > The code was smart enough Which action should really be performed after a failure was detected and handled a bit already? * Another condition check * Just additional error logging > and you're making it uglier that it needs to be. I assume that a software development taste can evolve, can't it? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] net-libertas: Better exception handling in if_spi_host_to_card_worker() @ 2016-01-02 8:09 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 8:09 UTC (permalink / raw) To: Sergei Shtylyov, libertas-dev, linux-wireless, netdev, Kalle Valo Cc: LKML, kernel-janitors, Julia Lawall >> Move the jump label directly before the desired log statement >> so that the variable "err" will not be checked once more >> after it was determined that a function call failed. >> Use the identifier "report_failure" instead of the label "err". > > Why? I suggest to reconsider the places with which such a jump label is connected. > The code was smart enough Which action should really be performed after a failure was detected and handled a bit already? * Another condition check * Just additional error logging > and you're making it uglier that it needs to be. I assume that a software development taste can evolve, can't it? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] net-libertas: Better exception handling in if_spi_host_to_card_worker() @ 2016-01-02 8:21 ` Julia Lawall 0 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2016-01-02 8:21 UTC (permalink / raw) To: SF Markus Elfring Cc: Sergei Shtylyov, libertas-dev, linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors On Sat, 2 Jan 2016, SF Markus Elfring wrote: > >> Move the jump label directly before the desired log statement > >> so that the variable "err" will not be checked once more > >> after it was determined that a function call failed. > >> Use the identifier "report_failure" instead of the label "err". > > > > Why? > > I suggest to reconsider the places with which such a jump label > is connected. > > > > The code was smart enough > > Which action should really be performed after a failure was detected > and handled a bit already? > > * Another condition check > > * Just additional error logging > > > > and you're making it uglier that it needs to be. > > I assume that a software development taste can evolve, can't it? So far, you have gotten several down votes for this kind of change, and no enthusiasm. Admittedly, this is a trivial case, because there are no local variables, but do you actually know the semantics in C of a jump into a block? And if you do know, do you think that this semantics is common knowledge? And do you really think that introducing poorly understandable code is really worth saving an if test of a single variable on a non-critical path? Most of the kernel code is not performance critical at the level of a single if test. So the goal should be for the code to be easy to understand and robust to change. The code that is performance critical, you should probably not touch, ever. The people who wrote it knew what was important and what was not. julia ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] net-libertas: Better exception handling in if_spi_host_to_card_worker() @ 2016-01-02 8:21 ` Julia Lawall 0 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2016-01-02 8:21 UTC (permalink / raw) To: SF Markus Elfring Cc: Sergei Shtylyov, libertas-dev, linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors On Sat, 2 Jan 2016, SF Markus Elfring wrote: > >> Move the jump label directly before the desired log statement > >> so that the variable "err" will not be checked once more > >> after it was determined that a function call failed. > >> Use the identifier "report_failure" instead of the label "err". > > > > Why? > > I suggest to reconsider the places with which such a jump label > is connected. > > > > The code was smart enough > > Which action should really be performed after a failure was detected > and handled a bit already? > > * Another condition check > > * Just additional error logging > > > > and you're making it uglier that it needs to be. > > I assume that a software development taste can evolve, can't it? So far, you have gotten several down votes for this kind of change, and no enthusiasm. Admittedly, this is a trivial case, because there are no local variables, but do you actually know the semantics in C of a jump into a block? And if you do know, do you think that this semantics is common knowledge? And do you really think that introducing poorly understandable code is really worth saving an if test of a single variable on a non-critical path? Most of the kernel code is not performance critical at the level of a single if test. So the goal should be for the code to be easy to understand and robust to change. The code that is performance critical, you should probably not touch, ever. The people who wrote it knew what was important and what was not. julia ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] net-libertas: Better exception handling in if_spi_host_to_card_worker() @ 2016-01-02 8:21 ` Julia Lawall 0 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2016-01-02 8:21 UTC (permalink / raw) To: SF Markus Elfring Cc: Sergei Shtylyov, libertas-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-wireless-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA, Kalle Valo, LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA On Sat, 2 Jan 2016, SF Markus Elfring wrote: > >> Move the jump label directly before the desired log statement > >> so that the variable "err" will not be checked once more > >> after it was determined that a function call failed. > >> Use the identifier "report_failure" instead of the label "err". > > > > Why? > > I suggest to reconsider the places with which such a jump label > is connected. > > > > The code was smart enough > > Which action should really be performed after a failure was detected > and handled a bit already? > > * Another condition check > > * Just additional error logging > > > > and you're making it uglier that it needs to be. > > I assume that a software development taste can evolve, can't it? So far, you have gotten several down votes for this kind of change, and no enthusiasm. Admittedly, this is a trivial case, because there are no local variables, but do you actually know the semantics in C of a jump into a block? And if you do know, do you think that this semantics is common knowledge? And do you really think that introducing poorly understandable code is really worth saving an if test of a single variable on a non-critical path? Most of the kernel code is not performance critical at the level of a single if test. So the goal should be for the code to be easy to understand and robust to change. The code that is performance critical, you should probably not touch, ever. The people who wrote it knew what was important and what was not. julia -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: net-libertas: Better exception handling in if_spi_host_to_card_worker() 2016-01-02 8:21 ` Julia Lawall @ 2016-01-02 9:08 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 9:08 UTC (permalink / raw) To: Julia Lawall Cc: Sergei Shtylyov, libertas-dev, linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors >> I assume that a software development taste can evolve, can't it? > > So far, you have gotten several down votes for this kind of change, I am curious when more contributors will share corresponding opinions. > and no enthusiasm. How many software designers and developers can become enthusiastic about better exception handling to some degree? > The code that is performance critical, you should probably not touch, ever. I imagine that technical evolution will result in further considerations so that "unchangeable" components can be adjusted once more. > The people who wrote it knew what was important and what was not. I might come along at some places where the affected knowledge will also evolve. Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: net-libertas: Better exception handling in if_spi_host_to_card_worker() @ 2016-01-02 9:08 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 9:08 UTC (permalink / raw) To: Julia Lawall Cc: Sergei Shtylyov, libertas-dev, linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors >> I assume that a software development taste can evolve, can't it? > > So far, you have gotten several down votes for this kind of change, I am curious when more contributors will share corresponding opinions. > and no enthusiasm. How many software designers and developers can become enthusiastic about better exception handling to some degree? > The code that is performance critical, you should probably not touch, ever. I imagine that technical evolution will result in further considerations so that "unchangeable" components can be adjusted once more. > The people who wrote it knew what was important and what was not. I might come along at some places where the affected knowledge will also evolve. Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: net-libertas: Better exception handling in if_spi_host_to_card_worker() 2016-01-02 9:08 ` SF Markus Elfring @ 2016-01-02 10:13 ` Arend van Spriel -1 siblings, 0 replies; 3089+ messages in thread From: Arend van Spriel @ 2016-01-02 10:13 UTC (permalink / raw) To: SF Markus Elfring, Julia Lawall Cc: Sergei Shtylyov, libertas-dev, linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors On 02-01-16 10:08, SF Markus Elfring wrote: >>> I assume that a software development taste can evolve, can't it? >> >> So far, you have gotten several down votes for this kind of change, > > I am curious when more contributors will share corresponding opinions. Let's burn some cycles on this while the holidays give me time to do so. "software development taste" is another term for "coding style". In every project battles are fought over this between friends and foes. I have never seen much evolution going on in this area. >> and no enthusiasm. > > How many software designers and developers can become enthusiastic > about better exception handling to some degree? I had to take a look at this particular patch and I have to say that I don't see, using your favorite term, evolution at work. It looks more like the result of inbred. What the patch tries to do is avoid the extra 'if (err)'. Setting coding style aside, the question is whether there is a good metric for the patch. So does it really safe processing time? Did you look at the resulting assembly code for different target architectures? You got pushed back on the change so you have to come up with solid arguments for your change instead of spewing ideas about evolution in software development. Running Coccinelle is one thing, but understanding the results and what you are ultimately proposing to be changed is more important. Regards, Arend >> The code that is performance critical, you should probably not touch, ever. > > I imagine that technical evolution will result in further considerations > so that "unchangeable" components can be adjusted once more. > > >> The people who wrote it knew what was important and what was not. > > I might come along at some places where the affected knowledge will also evolve. > > Regards, > Markus > -- > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: net-libertas: Better exception handling in if_spi_host_to_card_worker() @ 2016-01-02 10:13 ` Arend van Spriel 0 siblings, 0 replies; 3089+ messages in thread From: Arend van Spriel @ 2016-01-02 10:13 UTC (permalink / raw) To: SF Markus Elfring, Julia Lawall Cc: Sergei Shtylyov, libertas-dev, linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors On 02-01-16 10:08, SF Markus Elfring wrote: >>> I assume that a software development taste can evolve, can't it? >> >> So far, you have gotten several down votes for this kind of change, > > I am curious when more contributors will share corresponding opinions. Let's burn some cycles on this while the holidays give me time to do so. "software development taste" is another term for "coding style". In every project battles are fought over this between friends and foes. I have never seen much evolution going on in this area. >> and no enthusiasm. > > How many software designers and developers can become enthusiastic > about better exception handling to some degree? I had to take a look at this particular patch and I have to say that I don't see, using your favorite term, evolution at work. It looks more like the result of inbred. What the patch tries to do is avoid the extra 'if (err)'. Setting coding style aside, the question is whether there is a good metric for the patch. So does it really safe processing time? Did you look at the resulting assembly code for different target architectures? You got pushed back on the change so you have to come up with solid arguments for your change instead of spewing ideas about evolution in software development. Running Coccinelle is one thing, but understanding the results and what you are ultimately proposing to be changed is more important. Regards, Arend >> The code that is performance critical, you should probably not touch, ever. > > I imagine that technical evolution will result in further considerations > so that "unchangeable" components can be adjusted once more. > > >> The people who wrote it knew what was important and what was not. > > I might come along at some places where the affected knowledge will also evolve. > > Regards, > Markus > -- > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: net-libertas: Better exception handling in if_spi_host_to_card_worker() 2016-01-02 10:13 ` Arend van Spriel @ 2016-01-02 11:21 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 11:21 UTC (permalink / raw) To: Arend van Spriel Cc: Julia Lawall, Sergei Shtylyov, libertas-dev, linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors > I have never seen much evolution going on in this area. I can get an other impression from a specific document for example. https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/Documentation/CodingStyle > What the patch tries to do is avoid the extra 'if (err)'. Yes. - I propose to look at related consequences together with the usage of a popular short jump label once more. > Setting coding style aside, the question is whether there is > a good metric for the patch. A software development challenge is to accept changes also around a topic like "error handling". My update suggestion for the source file "drivers/net/wireless/marvell/libertas/if_spi.c" should only improve exception handling. (I came along other source files where more improvements will eventually be possible.) When will the run-time behaviour matter also for exceptional situations? > Did you look at the resulting assembly code for different target architectures? Not yet. - Which execution system variants would you recommend for further comparisons? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: net-libertas: Better exception handling in if_spi_host_to_card_worker() @ 2016-01-02 11:21 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 11:21 UTC (permalink / raw) To: Arend van Spriel Cc: Julia Lawall, Sergei Shtylyov, libertas-dev, linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors > I have never seen much evolution going on in this area. I can get an other impression from a specific document for example. https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/Documentation/CodingStyle > What the patch tries to do is avoid the extra 'if (err)'. Yes. - I propose to look at related consequences together with the usage of a popular short jump label once more. > Setting coding style aside, the question is whether there is > a good metric for the patch. A software development challenge is to accept changes also around a topic like "error handling". My update suggestion for the source file "drivers/net/wireless/marvell/libertas/if_spi.c" should only improve exception handling. (I came along other source files where more improvements will eventually be possible.) When will the run-time behaviour matter also for exceptional situations? > Did you look at the resulting assembly code for different target architectures? Not yet. - Which execution system variants would you recommend for further comparisons? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: net-libertas: Better exception handling in if_spi_host_to_card_worker() 2016-01-02 11:21 ` SF Markus Elfring @ 2016-01-03 9:36 ` Arend van Spriel -1 siblings, 0 replies; 3089+ messages in thread From: Arend van Spriel @ 2016-01-03 9:36 UTC (permalink / raw) To: SF Markus Elfring Cc: Julia Lawall, Sergei Shtylyov, libertas-dev, linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors On 02-01-16 12:21, SF Markus Elfring wrote: >> I have never seen much evolution going on in this area. > > I can get an other impression from a specific document for example. > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/Documentation/CodingStyle > > >> What the patch tries to do is avoid the extra 'if (err)'. > > Yes. - I propose to look at related consequences together with the usage > of a popular short jump label once more. When I read a subject saying "Better exception handling" it sounds like a functional improvement. Your change does not change anything functionally and may or may not save a bit of execution time depending on how smart the compiler is. What you change does is confuse people reading the code. So please explain why your update improves exception handling here. I don't see it. The code is not making the driver more robust against failures in this function, which is what I think of reading "better exception handling". >> Setting coding style aside, the question is whether there is >> a good metric for the patch. > > A software development challenge is to accept changes also around a topic > like "error handling". My update suggestion for the source file > "drivers/net/wireless/marvell/libertas/if_spi.c" should only improve > exception handling. (I came along other source files where more improvements > will eventually be possible.) > > When will the run-time behaviour matter also for exceptional situations? > > >> Did you look at the resulting assembly code for different target architectures? > > Not yet. - Which execution system variants would you recommend for > further comparisons? Guess x86{,_64} and arm would be good candidates, ie. CISC vs. RISC. Regards, Arend ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: net-libertas: Better exception handling in if_spi_host_to_card_worker() @ 2016-01-03 9:36 ` Arend van Spriel 0 siblings, 0 replies; 3089+ messages in thread From: Arend van Spriel @ 2016-01-03 9:36 UTC (permalink / raw) To: SF Markus Elfring Cc: Julia Lawall, Sergei Shtylyov, libertas-dev, linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors On 02-01-16 12:21, SF Markus Elfring wrote: >> I have never seen much evolution going on in this area. > > I can get an other impression from a specific document for example. > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/Documentation/CodingStyle > > >> What the patch tries to do is avoid the extra 'if (err)'. > > Yes. - I propose to look at related consequences together with the usage > of a popular short jump label once more. When I read a subject saying "Better exception handling" it sounds like a functional improvement. Your change does not change anything functionally and may or may not save a bit of execution time depending on how smart the compiler is. What you change does is confuse people reading the code. So please explain why your update improves exception handling here. I don't see it. The code is not making the driver more robust against failures in this function, which is what I think of reading "better exception handling". >> Setting coding style aside, the question is whether there is >> a good metric for the patch. > > A software development challenge is to accept changes also around a topic > like "error handling". My update suggestion for the source file > "drivers/net/wireless/marvell/libertas/if_spi.c" should only improve > exception handling. (I came along other source files where more improvements > will eventually be possible.) > > When will the run-time behaviour matter also for exceptional situations? > > >> Did you look at the resulting assembly code for different target architectures? > > Not yet. - Which execution system variants would you recommend for > further comparisons? Guess x86{,_64} and arm would be good candidates, ie. CISC vs. RISC. Regards, Arend ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: net-libertas: Better exception handling in if_spi_host_to_card_worker() @ 2016-01-03 12:13 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 12:13 UTC (permalink / raw) To: Arend van Spriel Cc: Julia Lawall, Sergei Shtylyov, libertas-dev, linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors >>> What the patch tries to do is avoid the extra 'if (err)'. >> >> Yes. - I propose to look at related consequences together with the usage >> of a popular short jump label once more. > > When I read a subject saying "Better exception handling" it sounds like > a functional improvement. Your change does not change anything > functionally and may or may not save a bit of execution time depending > on how smart the compiler is. Can it eventually matter to skip another condition check in three cases? > What you change does is confuse people reading the code. A few software developers might find this proposal unusual. > So please explain why your update improves exception handling here. > I don't see it. How does this feedback fit to the mentioned check avoidance? > The code is not making the driver more robust against failures That's true for this update suggestion. > in this function, which is what I think of reading "better exception handling". Other implementation details are affected by the shown fine-tuning. Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: net-libertas: Better exception handling in if_spi_host_to_card_worker() @ 2016-01-03 12:13 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 12:13 UTC (permalink / raw) To: Arend van Spriel Cc: Julia Lawall, Sergei Shtylyov, libertas-dev, linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors >>> What the patch tries to do is avoid the extra 'if (err)'. >> >> Yes. - I propose to look at related consequences together with the usage >> of a popular short jump label once more. > > When I read a subject saying "Better exception handling" it sounds like > a functional improvement. Your change does not change anything > functionally and may or may not save a bit of execution time depending > on how smart the compiler is. Can it eventually matter to skip another condition check in three cases? > What you change does is confuse people reading the code. A few software developers might find this proposal unusual. > So please explain why your update improves exception handling here. > I don't see it. How does this feedback fit to the mentioned check avoidance? > The code is not making the driver more robust against failures That's true for this update suggestion. > in this function, which is what I think of reading "better exception handling". Other implementation details are affected by the shown fine-tuning. Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: net-libertas: Better exception handling in if_spi_host_to_card_worker() @ 2016-01-03 12:13 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 12:13 UTC (permalink / raw) To: Arend van Spriel Cc: Julia Lawall, Sergei Shtylyov, libertas-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-wireless-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA, Kalle Valo, LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA >>> What the patch tries to do is avoid the extra 'if (err)'. >> >> Yes. - I propose to look at related consequences together with the usage >> of a popular short jump label once more. > > When I read a subject saying "Better exception handling" it sounds like > a functional improvement. Your change does not change anything > functionally and may or may not save a bit of execution time depending > on how smart the compiler is. Can it eventually matter to skip another condition check in three cases? > What you change does is confuse people reading the code. A few software developers might find this proposal unusual. > So please explain why your update improves exception handling here. > I don't see it. How does this feedback fit to the mentioned check avoidance? > The code is not making the driver more robust against failures That's true for this update suggestion. > in this function, which is what I think of reading "better exception handling". Other implementation details are affected by the shown fine-tuning. Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: net-libertas: Better exception handling in if_spi_host_to_card_worker() @ 2016-01-03 15:18 ` Rafał Miłecki 0 siblings, 0 replies; 3089+ messages in thread From: Rafał Miłecki @ 2016-01-03 15:18 UTC (permalink / raw) To: Arend van Spriel Cc: SF Markus Elfring, Julia Lawall, Sergei Shtylyov, libertas-dev, linux-wireless, Network Development, Kalle Valo, LKML, kernel-janitors On 3 January 2016 at 10:36, Arend van Spriel <aspriel@gmail.com> wrote: > On 02-01-16 12:21, SF Markus Elfring wrote: >>> Did you look at the resulting assembly code for different target architectures? >> >> Not yet. - Which execution system variants would you recommend for >> further comparisons? > > Guess x86{,_64} and arm would be good candidates, ie. CISC vs. RISC. Oh, don't forget about MIPS with its fancy branches handling. You know about it, don't you? I'm against this patch as well. -- Rafał ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: net-libertas: Better exception handling in if_spi_host_to_card_worker() @ 2016-01-03 15:18 ` Rafał Miłecki 0 siblings, 0 replies; 3089+ messages in thread From: Rafał Miłecki @ 2016-01-03 15:18 UTC (permalink / raw) To: Arend van Spriel Cc: SF Markus Elfring, Julia Lawall, Sergei Shtylyov, libertas-dev, linux-wireless, Network Development, Kalle Valo, LKML, kernel-janitors On 3 January 2016 at 10:36, Arend van Spriel <aspriel@gmail.com> wrote: > On 02-01-16 12:21, SF Markus Elfring wrote: >>> Did you look at the resulting assembly code for different target architectures? >> >> Not yet. - Which execution system variants would you recommend for >> further comparisons? > > Guess x86{,_64} and arm would be good candidates, ie. CISC vs. RISC. Oh, don't forget about MIPS with its fancy branches handling. You know about it, don't you? I'm against this patch as well. -- RafaÅ‚ -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: net-libertas: Better exception handling in if_spi_host_to_card_worker() @ 2016-01-03 15:18 ` Rafał Miłecki 0 siblings, 0 replies; 3089+ messages in thread From: Rafał Miłecki @ 2016-01-03 15:18 UTC (permalink / raw) To: Arend van Spriel Cc: SF Markus Elfring, Julia Lawall, Sergei Shtylyov, libertas-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-wireless-u79uwXL29TY76Z2rM5mHXA, Network Development, Kalle Valo, LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA On 3 January 2016 at 10:36, Arend van Spriel <aspriel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > On 02-01-16 12:21, SF Markus Elfring wrote: >>> Did you look at the resulting assembly code for different target architectures? >> >> Not yet. - Which execution system variants would you recommend for >> further comparisons? > > Guess x86{,_64} and arm would be good candidates, ie. CISC vs. RISC. Oh, don't forget about MIPS with its fancy branches handling. You know about it, don't you? I'm against this patch as well. -- Rafał -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: net-libertas: Better exception handling in if_spi_host_to_card_worker() 2016-01-03 15:18 ` Rafał Miłecki (?) @ 2016-01-04 10:05 ` Arend van Spriel -1 siblings, 0 replies; 3089+ messages in thread From: Arend van Spriel @ 2016-01-04 10:05 UTC (permalink / raw) To: Rafał Miłecki Cc: SF Markus Elfring, Julia Lawall, Sergei Shtylyov, libertas-dev, linux-wireless, Network Development, Kalle Valo, LKML, kernel-janitors On 03-01-16 16:18, Rafał Miłecki wrote: > On 3 January 2016 at 10:36, Arend van Spriel <aspriel@gmail.com> wrote: >> On 02-01-16 12:21, SF Markus Elfring wrote: >>>> Did you look at the resulting assembly code for different target architectures? >>> >>> Not yet. - Which execution system variants would you recommend for >>> further comparisons? >> >> Guess x86{,_64} and arm would be good candidates, ie. CISC vs. RISC. > > Oh, don't forget about MIPS with its fancy branches handling. You know > about it, don't you? You are asking me, right ;-) ? I have come across my share of MIPS platforms here at Broadcom, but I still try to avoid them as much as possible. > I'm against this patch as well. and counting... :-p Regards, Arend ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: net-libertas: Better exception handling in if_spi_host_to_card_worker() @ 2016-01-04 10:05 ` Arend van Spriel 0 siblings, 0 replies; 3089+ messages in thread From: Arend van Spriel @ 2016-01-04 10:05 UTC (permalink / raw) To: Rafał Miłecki Cc: SF Markus Elfring, Julia Lawall, Sergei Shtylyov, libertas-dev, linux-wireless, Network Development, Kalle Valo, LKML, kernel-janitors On 03-01-16 16:18, Rafał Miłecki wrote: > On 3 January 2016 at 10:36, Arend van Spriel <aspriel@gmail.com> wrote: >> On 02-01-16 12:21, SF Markus Elfring wrote: >>>> Did you look at the resulting assembly code for different target architectures? >>> >>> Not yet. - Which execution system variants would you recommend for >>> further comparisons? >> >> Guess x86{,_64} and arm would be good candidates, ie. CISC vs. RISC. > > Oh, don't forget about MIPS with its fancy branches handling. You know > about it, don't you? You are asking me, right ;-) ? I have come across my share of MIPS platforms here at Broadcom, but I still try to avoid them as much as possible. > I'm against this patch as well. and counting... :-p Regards, Arend ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: net-libertas: Better exception handling in if_spi_host_to_card_worker() @ 2016-01-04 10:05 ` Arend van Spriel 0 siblings, 0 replies; 3089+ messages in thread From: Arend van Spriel @ 2016-01-04 10:05 UTC (permalink / raw) To: Rafał Miłecki Cc: SF Markus Elfring, Julia Lawall, Sergei Shtylyov, libertas-dev, linux-wireless, Network Development, Kalle Valo, LKML, kernel-janitors On 03-01-16 16:18, Rafał Miłecki wrote: > On 3 January 2016 at 10:36, Arend van Spriel <aspriel@gmail.com> wrote: >> On 02-01-16 12:21, SF Markus Elfring wrote: >>>> Did you look at the resulting assembly code for different target architectures? >>> >>> Not yet. - Which execution system variants would you recommend for >>> further comparisons? >> >> Guess x86{,_64} and arm would be good candidates, ie. CISC vs. RISC. > > Oh, don't forget about MIPS with its fancy branches handling. You know > about it, don't you? You are asking me, right ;-) ? I have come across my share of MIPS platforms here at Broadcom, but I still try to avoid them as much as possible. > I'm against this patch as well. and counting... :-p Regards, Arend -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: net-libertas: Better exception handling in if_spi_host_to_card_worker() 2016-01-04 10:05 ` Arend van Spriel (?) @ 2016-01-04 11:18 ` Rafał Miłecki -1 siblings, 0 replies; 3089+ messages in thread From: Rafał Miłecki @ 2016-01-04 11:18 UTC (permalink / raw) To: Arend van Spriel Cc: SF Markus Elfring, Julia Lawall, Sergei Shtylyov, libertas-dev, linux-wireless, Network Development, Kalle Valo, LKML, kernel-janitors On 4 January 2016 at 11:05, Arend van Spriel <aspriel@gmail.com> wrote: > On 03-01-16 16:18, Rafał Miłecki wrote: >> On 3 January 2016 at 10:36, Arend van Spriel <aspriel@gmail.com> wrote: >>> On 02-01-16 12:21, SF Markus Elfring wrote: >>>>> Did you look at the resulting assembly code for different target architectures? >>>> >>>> Not yet. - Which execution system variants would you recommend for >>>> further comparisons? >>> >>> Guess x86{,_64} and arm would be good candidates, ie. CISC vs. RISC. >> >> Oh, don't forget about MIPS with its fancy branches handling. You know >> about it, don't you? > > You are asking me, right ;-) ? I have come across my share of MIPS > platforms here at Broadcom, but I still try to avoid them as much as > possible. I was more thinking about author on this patch. But it's indeed an interesting thing, just to know, how MIPS CPU handles branches ;) -- Rafał ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: net-libertas: Better exception handling in if_spi_host_to_card_worker() @ 2016-01-04 11:18 ` Rafał Miłecki 0 siblings, 0 replies; 3089+ messages in thread From: Rafał Miłecki @ 2016-01-04 11:18 UTC (permalink / raw) To: Arend van Spriel Cc: SF Markus Elfring, Julia Lawall, Sergei Shtylyov, libertas-dev, linux-wireless, Network Development, Kalle Valo, LKML, kernel-janitors On 4 January 2016 at 11:05, Arend van Spriel <aspriel@gmail.com> wrote: > On 03-01-16 16:18, Rafał Miłecki wrote: >> On 3 January 2016 at 10:36, Arend van Spriel <aspriel@gmail.com> wrote: >>> On 02-01-16 12:21, SF Markus Elfring wrote: >>>>> Did you look at the resulting assembly code for different target architectures? >>>> >>>> Not yet. - Which execution system variants would you recommend for >>>> further comparisons? >>> >>> Guess x86{,_64} and arm would be good candidates, ie. CISC vs. RISC. >> >> Oh, don't forget about MIPS with its fancy branches handling. You know >> about it, don't you? > > You are asking me, right ;-) ? I have come across my share of MIPS > platforms here at Broadcom, but I still try to avoid them as much as > possible. I was more thinking about author on this patch. But it's indeed an interesting thing, just to know, how MIPS CPU handles branches ;) -- Rafał ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: net-libertas: Better exception handling in if_spi_host_to_card_worker() @ 2016-01-04 11:18 ` Rafał Miłecki 0 siblings, 0 replies; 3089+ messages in thread From: Rafał Miłecki @ 2016-01-04 11:18 UTC (permalink / raw) To: Arend van Spriel Cc: SF Markus Elfring, Julia Lawall, Sergei Shtylyov, libertas-dev, linux-wireless, Network Development, Kalle Valo, LKML, kernel-janitors On 4 January 2016 at 11:05, Arend van Spriel <aspriel@gmail.com> wrote: > On 03-01-16 16:18, Rafał Miłecki wrote: >> On 3 January 2016 at 10:36, Arend van Spriel <aspriel@gmail.com> wrote: >>> On 02-01-16 12:21, SF Markus Elfring wrote: >>>>> Did you look at the resulting assembly code for different target architectures? >>>> >>>> Not yet. - Which execution system variants would you recommend for >>>> further comparisons? >>> >>> Guess x86{,_64} and arm would be good candidates, ie. CISC vs. RISC. >> >> Oh, don't forget about MIPS with its fancy branches handling. You know >> about it, don't you? > > You are asking me, right ;-) ? I have come across my share of MIPS > platforms here at Broadcom, but I still try to avoid them as much as > possible. I was more thinking about author on this patch. But it's indeed an interesting thing, just to know, how MIPS CPU handles branches ;) -- Rafał -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] net-libertas: Better exception handling in if_spi_host_to_card_worker() 2016-01-02 8:21 ` Julia Lawall @ 2016-01-21 15:07 ` Kalle Valo -1 siblings, 0 replies; 3089+ messages in thread From: Kalle Valo @ 2016-01-21 15:07 UTC (permalink / raw) To: Julia Lawall Cc: SF Markus Elfring, Sergei Shtylyov, libertas-dev, linux-wireless, netdev, LKML, kernel-janitors Julia Lawall <julia.lawall@lip6.fr> writes: > On Sat, 2 Jan 2016, SF Markus Elfring wrote: > >> >> Move the jump label directly before the desired log statement >> >> so that the variable "err" will not be checked once more >> >> after it was determined that a function call failed. >> >> Use the identifier "report_failure" instead of the label "err". >> > >> > Why? >> >> I suggest to reconsider the places with which such a jump label >> is connected. >> >> >> > The code was smart enough >> >> Which action should really be performed after a failure was detected >> and handled a bit already? >> >> * Another condition check >> >> * Just additional error logging >> >> >> > and you're making it uglier that it needs to be. >> >> I assume that a software development taste can evolve, can't it? > > So far, you have gotten several down votes for this kind of change, and no > enthusiasm. > > Admittedly, this is a trivial case, because there are no local variables, > but do you actually know the semantics in C of a jump into a block? And > if you do know, do you think that this semantics is common knowledge? And > do you really think that introducing poorly understandable code is really > worth saving an if test of a single variable on a non-critical path? > > Most of the kernel code is not performance critical at the level of a > single if test. So the goal should be for the code to be easy to > understand and robust to change. The code that is performance critical, > you should probably not touch, ever. The people who wrote it knew what > was important and what was not. Very well said! Only optimise something you can measure. I'm dropping this patch. -- Kalle Valo ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] net-libertas: Better exception handling in if_spi_host_to_card_worker() @ 2016-01-21 15:07 ` Kalle Valo 0 siblings, 0 replies; 3089+ messages in thread From: Kalle Valo @ 2016-01-21 15:07 UTC (permalink / raw) To: Julia Lawall Cc: SF Markus Elfring, Sergei Shtylyov, libertas-dev, linux-wireless, netdev, LKML, kernel-janitors Julia Lawall <julia.lawall@lip6.fr> writes: > On Sat, 2 Jan 2016, SF Markus Elfring wrote: > >> >> Move the jump label directly before the desired log statement >> >> so that the variable "err" will not be checked once more >> >> after it was determined that a function call failed. >> >> Use the identifier "report_failure" instead of the label "err". >> > >> > Why? >> >> I suggest to reconsider the places with which such a jump label >> is connected. >> >> >> > The code was smart enough >> >> Which action should really be performed after a failure was detected >> and handled a bit already? >> >> * Another condition check >> >> * Just additional error logging >> >> >> > and you're making it uglier that it needs to be. >> >> I assume that a software development taste can evolve, can't it? > > So far, you have gotten several down votes for this kind of change, and no > enthusiasm. > > Admittedly, this is a trivial case, because there are no local variables, > but do you actually know the semantics in C of a jump into a block? And > if you do know, do you think that this semantics is common knowledge? And > do you really think that introducing poorly understandable code is really > worth saving an if test of a single variable on a non-critical path? > > Most of the kernel code is not performance critical at the level of a > single if test. So the goal should be for the code to be easy to > understand and robust to change. The code that is performance critical, > you should probably not touch, ever. The people who wrote it knew what > was important and what was not. Very well said! Only optimise something you can measure. I'm dropping this patch. -- Kalle Valo ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/3] net-rsi: Fine-tuning for two function implementations 2015-12-11 12:08 ` SF Markus Elfring @ 2016-01-02 14:40 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 14:40 UTC (permalink / raw) To: linux-wireless, netdev, Kalle Valo; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jan 2016 15:36:25 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (3): Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() Delete unnecessary variable initialisations in rsi_send_data_pkt() Replace variable initialisations by assignments in rsi_send_data_pkt() drivers/net/wireless/rsi/rsi_91x_pkt.c | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/3] net-rsi: Fine-tuning for two function implementations @ 2016-01-02 14:40 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 14:40 UTC (permalink / raw) To: linux-wireless, netdev, Kalle Valo; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jan 2016 15:36:25 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (3): Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() Delete unnecessary variable initialisations in rsi_send_data_pkt() Replace variable initialisations by assignments in rsi_send_data_pkt() drivers/net/wireless/rsi/rsi_91x_pkt.c | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 1/3] rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() 2016-01-02 14:40 ` SF Markus Elfring @ 2016-01-02 14:43 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 14:43 UTC (permalink / raw) To: linux-wireless, netdev, Kalle Valo; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jan 2016 14:54:30 +0100 Omit explicit initialisation at the beginning for five local variables which are redefined before their first use. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/wireless/rsi/rsi_91x_pkt.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/net/wireless/rsi/rsi_91x_pkt.c b/drivers/net/wireless/rsi/rsi_91x_pkt.c index 702593f..ee98f5b 100644 --- a/drivers/net/wireless/rsi/rsi_91x_pkt.c +++ b/drivers/net/wireless/rsi/rsi_91x_pkt.c @@ -123,15 +123,15 @@ int rsi_send_mgmt_pkt(struct rsi_common *common, struct sk_buff *skb) { struct rsi_hw *adapter = common->priv; - struct ieee80211_hdr *wh = NULL; + struct ieee80211_hdr *wh; struct ieee80211_tx_info *info; - struct ieee80211_bss_conf *bss = NULL; + struct ieee80211_bss_conf *bss; struct ieee80211_hw *hw = adapter->hw; struct ieee80211_conf *conf = &hw->conf; struct skb_info *tx_params; - int status = -E2BIG; - __le16 *msg = NULL; - u8 extnd_size = 0; + int status; + __le16 *msg; + u8 extnd_size; u8 vap_id = 0; info = IEEE80211_SKB_CB(skb); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 1/3] rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() @ 2016-01-02 14:43 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 14:43 UTC (permalink / raw) To: linux-wireless, netdev, Kalle Valo; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jan 2016 14:54:30 +0100 Omit explicit initialisation at the beginning for five local variables which are redefined before their first use. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/wireless/rsi/rsi_91x_pkt.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/net/wireless/rsi/rsi_91x_pkt.c b/drivers/net/wireless/rsi/rsi_91x_pkt.c index 702593f..ee98f5b 100644 --- a/drivers/net/wireless/rsi/rsi_91x_pkt.c +++ b/drivers/net/wireless/rsi/rsi_91x_pkt.c @@ -123,15 +123,15 @@ int rsi_send_mgmt_pkt(struct rsi_common *common, struct sk_buff *skb) { struct rsi_hw *adapter = common->priv; - struct ieee80211_hdr *wh = NULL; + struct ieee80211_hdr *wh; struct ieee80211_tx_info *info; - struct ieee80211_bss_conf *bss = NULL; + struct ieee80211_bss_conf *bss; struct ieee80211_hw *hw = adapter->hw; struct ieee80211_conf *conf = &hw->conf; struct skb_info *tx_params; - int status = -E2BIG; - __le16 *msg = NULL; - u8 extnd_size = 0; + int status; + __le16 *msg; + u8 extnd_size; u8 vap_id = 0; info = IEEE80211_SKB_CB(skb); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* net-rsi: Reconsider usage of variable "vap_id" in rsi_send_mgmt_pkt() 2016-01-02 14:43 ` SF Markus Elfring @ 2016-01-02 15:12 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 15:12 UTC (permalink / raw) To: linux-wireless, netdev, Kalle Valo; +Cc: LKML, kernel-janitors, Julia Lawall Hello, I have taken another look at the implementation of the function "rsi_send_mgmt_pkt". https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/net/wireless/rsi/rsi_91x_pkt.c?id=e8c58e7a5a106c3d557fccd01cd4d1128f9bab38#n114 I find the following statement combination interesting there. … u8 vap_id = 0; … msg[7] |= cpu_to_le16(vap_id << 8); … I would appreciate a further clarification. Does a shift operation for a variable which contains zero indicate an open issue? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* net-rsi: Reconsider usage of variable "vap_id" in rsi_send_mgmt_pkt() @ 2016-01-02 15:12 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 15:12 UTC (permalink / raw) To: linux-wireless, netdev, Kalle Valo; +Cc: LKML, kernel-janitors, Julia Lawall Hello, I have taken another look at the implementation of the function "rsi_send_mgmt_pkt". https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/net/wireless/rsi/rsi_91x_pkt.c?idèc58e7a5a106c3d557fccd01cd4d1128f9bab38#n114 I find the following statement combination interesting there. … u8 vap_id = 0; … msg[7] |= cpu_to_le16(vap_id << 8); … I would appreciate a further clarification. Does a shift operation for a variable which contains zero indicate an open issue? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/3] rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() 2016-01-02 14:43 ` SF Markus Elfring @ 2016-01-02 16:32 ` kbuild test robot -1 siblings, 0 replies; 3089+ messages in thread From: kbuild test robot @ 2016-01-02 16:32 UTC (permalink / raw) To: SF Markus Elfring Cc: kbuild-all, linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors, Julia Lawall [-- Attachment #1: Type: text/plain, Size: 2786 bytes --] Hi Markus, [auto build test WARNING on wireless-drivers-next/master] [also build test WARNING on v4.4-rc7 next-20151231] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/SF-Markus-Elfring/net-rsi-Fine-tuning-for-two-function-implementations/20160102-224740 base: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git master config: x86_64-randconfig-s2-01030012 (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=x86_64 Note: it may well be a FALSE warning. FWIW you are at least aware of it now. http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings All warnings (new ones prefixed by >>): drivers/net/wireless/rsi/rsi_91x_pkt.c: In function 'rsi_send_mgmt_pkt': >> drivers/net/wireless/rsi/rsi_91x_pkt.c:211:2: warning: 'status' may be used uninitialized in this function [-Wmaybe-uninitialized] rsi_indicate_tx_status(common->priv, skb, status); ^ vim +/status +211 drivers/net/wireless/rsi/rsi_91x_pkt.c dad0d04f Fariya Fatima 2014-03-16 195 /* Indicate to firmware to give cfm */ dad0d04f Fariya Fatima 2014-03-16 196 if ((skb->data[16] == IEEE80211_STYPE_PROBE_REQ) && (!bss->assoc)) { dad0d04f Fariya Fatima 2014-03-16 197 msg[1] |= cpu_to_le16(BIT(10)); dad0d04f Fariya Fatima 2014-03-16 198 msg[7] = cpu_to_le16(PROBEREQ_CONFIRM); dad0d04f Fariya Fatima 2014-03-16 199 common->mgmt_q_block = true; dad0d04f Fariya Fatima 2014-03-16 200 } dad0d04f Fariya Fatima 2014-03-16 201 dad0d04f Fariya Fatima 2014-03-16 202 msg[7] |= cpu_to_le16(vap_id << 8); dad0d04f Fariya Fatima 2014-03-16 203 dad0d04f Fariya Fatima 2014-03-16 204 status = adapter->host_intf_write_pkt(common->priv, dad0d04f Fariya Fatima 2014-03-16 205 (u8 *)msg, dad0d04f Fariya Fatima 2014-03-16 206 skb->len); dad0d04f Fariya Fatima 2014-03-16 207 if (status) dad0d04f Fariya Fatima 2014-03-16 208 rsi_dbg(ERR_ZONE, "%s: Failed to write the packet\n", __func__); dad0d04f Fariya Fatima 2014-03-16 209 dad0d04f Fariya Fatima 2014-03-16 210 err: dad0d04f Fariya Fatima 2014-03-16 @211 rsi_indicate_tx_status(common->priv, skb, status); dad0d04f Fariya Fatima 2014-03-16 212 return status; dad0d04f Fariya Fatima 2014-03-16 213 } :::::: The code at line 211 was first introduced by commit :::::: dad0d04fa7ba41ce603a01e8e64967650303e9a2 rsi: Add RS9113 wireless driver :::::: TO: Fariya Fatima <fariyaf@gmail.com> :::::: CC: John W. Linville <linville@tuxdriver.com> --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation [-- Attachment #2: .config.gz --] [-- Type: application/octet-stream, Size: 27399 bytes --] ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/3] rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() @ 2016-01-02 16:32 ` kbuild test robot 0 siblings, 0 replies; 3089+ messages in thread From: kbuild test robot @ 2016-01-02 16:32 UTC (permalink / raw) To: kernel-janitors [-- Attachment #1: Type: text/plain, Size: 2786 bytes --] Hi Markus, [auto build test WARNING on wireless-drivers-next/master] [also build test WARNING on v4.4-rc7 next-20151231] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/SF-Markus-Elfring/net-rsi-Fine-tuning-for-two-function-implementations/20160102-224740 base: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git master config: x86_64-randconfig-s2-01030012 (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=x86_64 Note: it may well be a FALSE warning. FWIW you are at least aware of it now. http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings All warnings (new ones prefixed by >>): drivers/net/wireless/rsi/rsi_91x_pkt.c: In function 'rsi_send_mgmt_pkt': >> drivers/net/wireless/rsi/rsi_91x_pkt.c:211:2: warning: 'status' may be used uninitialized in this function [-Wmaybe-uninitialized] rsi_indicate_tx_status(common->priv, skb, status); ^ vim +/status +211 drivers/net/wireless/rsi/rsi_91x_pkt.c dad0d04f Fariya Fatima 2014-03-16 195 /* Indicate to firmware to give cfm */ dad0d04f Fariya Fatima 2014-03-16 196 if ((skb->data[16] == IEEE80211_STYPE_PROBE_REQ) && (!bss->assoc)) { dad0d04f Fariya Fatima 2014-03-16 197 msg[1] |= cpu_to_le16(BIT(10)); dad0d04f Fariya Fatima 2014-03-16 198 msg[7] = cpu_to_le16(PROBEREQ_CONFIRM); dad0d04f Fariya Fatima 2014-03-16 199 common->mgmt_q_block = true; dad0d04f Fariya Fatima 2014-03-16 200 } dad0d04f Fariya Fatima 2014-03-16 201 dad0d04f Fariya Fatima 2014-03-16 202 msg[7] |= cpu_to_le16(vap_id << 8); dad0d04f Fariya Fatima 2014-03-16 203 dad0d04f Fariya Fatima 2014-03-16 204 status = adapter->host_intf_write_pkt(common->priv, dad0d04f Fariya Fatima 2014-03-16 205 (u8 *)msg, dad0d04f Fariya Fatima 2014-03-16 206 skb->len); dad0d04f Fariya Fatima 2014-03-16 207 if (status) dad0d04f Fariya Fatima 2014-03-16 208 rsi_dbg(ERR_ZONE, "%s: Failed to write the packet\n", __func__); dad0d04f Fariya Fatima 2014-03-16 209 dad0d04f Fariya Fatima 2014-03-16 210 err: dad0d04f Fariya Fatima 2014-03-16 @211 rsi_indicate_tx_status(common->priv, skb, status); dad0d04f Fariya Fatima 2014-03-16 212 return status; dad0d04f Fariya Fatima 2014-03-16 213 } :::::: The code at line 211 was first introduced by commit :::::: dad0d04fa7ba41ce603a01e8e64967650303e9a2 rsi: Add RS9113 wireless driver :::::: TO: Fariya Fatima <fariyaf@gmail.com> :::::: CC: John W. Linville <linville@tuxdriver.com> --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation [-- Attachment #2: .config.gz --] [-- Type: application/octet-stream, Size: 27399 bytes --] ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH v2 1/3] rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() 2016-01-02 16:32 ` kbuild test robot @ 2016-01-02 18:27 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 18:27 UTC (permalink / raw) To: linux-wireless, netdev, Kalle Valo Cc: kbuild-all, LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jan 2016 19:22:36 +0100 Omit explicit initialisation at the beginning for four local variables which are redefined before their first use. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/wireless/rsi/rsi_91x_pkt.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/rsi/rsi_91x_pkt.c b/drivers/net/wireless/rsi/rsi_91x_pkt.c index 702593f..571eaba 100644 --- a/drivers/net/wireless/rsi/rsi_91x_pkt.c +++ b/drivers/net/wireless/rsi/rsi_91x_pkt.c @@ -123,15 +123,15 @@ int rsi_send_mgmt_pkt(struct rsi_common *common, struct sk_buff *skb) { struct rsi_hw *adapter = common->priv; - struct ieee80211_hdr *wh = NULL; + struct ieee80211_hdr *wh; struct ieee80211_tx_info *info; - struct ieee80211_bss_conf *bss = NULL; + struct ieee80211_bss_conf *bss; struct ieee80211_hw *hw = adapter->hw; struct ieee80211_conf *conf = &hw->conf; struct skb_info *tx_params; int status = -E2BIG; - __le16 *msg = NULL; - u8 extnd_size = 0; + __le16 *msg; + u8 extnd_size; u8 vap_id = 0; info = IEEE80211_SKB_CB(skb); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH v2 1/3] rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() @ 2016-01-02 18:27 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 18:27 UTC (permalink / raw) To: linux-wireless, netdev, Kalle Valo Cc: kbuild-all, LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jan 2016 19:22:36 +0100 Omit explicit initialisation at the beginning for four local variables which are redefined before their first use. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/wireless/rsi/rsi_91x_pkt.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/rsi/rsi_91x_pkt.c b/drivers/net/wireless/rsi/rsi_91x_pkt.c index 702593f..571eaba 100644 --- a/drivers/net/wireless/rsi/rsi_91x_pkt.c +++ b/drivers/net/wireless/rsi/rsi_91x_pkt.c @@ -123,15 +123,15 @@ int rsi_send_mgmt_pkt(struct rsi_common *common, struct sk_buff *skb) { struct rsi_hw *adapter = common->priv; - struct ieee80211_hdr *wh = NULL; + struct ieee80211_hdr *wh; struct ieee80211_tx_info *info; - struct ieee80211_bss_conf *bss = NULL; + struct ieee80211_bss_conf *bss; struct ieee80211_hw *hw = adapter->hw; struct ieee80211_conf *conf = &hw->conf; struct skb_info *tx_params; int status = -E2BIG; - __le16 *msg = NULL; - u8 extnd_size = 0; + __le16 *msg; + u8 extnd_size; u8 vap_id = 0; info = IEEE80211_SKB_CB(skb); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/3] rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() 2016-01-02 14:43 ` SF Markus Elfring @ 2016-01-04 9:28 ` Dan Carpenter -1 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2016-01-04 9:28 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors, Julia Lawall These patches are labour intensive to review because you can't just do it in the email client. Also you were not able to review it properly yourself and introduced a bug. I am often remove initializers but it's normally because I am changing something else which makes it worthwhile. This patch is the correct thing but it's not "worthwhile". It is not a good use of my time. Please stop sending cleanup patches, Markus. Just send fixes. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/3] rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() @ 2016-01-04 9:28 ` Dan Carpenter 0 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2016-01-04 9:28 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors, Julia Lawall These patches are labour intensive to review because you can't just do it in the email client. Also you were not able to review it properly yourself and introduced a bug. I am often remove initializers but it's normally because I am changing something else which makes it worthwhile. This patch is the correct thing but it's not "worthwhile". It is not a good use of my time. Please stop sending cleanup patches, Markus. Just send fixes. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/3] rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() 2016-01-04 9:28 ` Dan Carpenter @ 2016-01-04 9:38 ` Dan Carpenter -1 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2016-01-04 9:38 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors, Julia Lawall Btw, GCC misses a lot of uninitialized variable bugs. I have a Smatch check which sometimes catches the bugs that GCC misses but you should not rely on the tools here. These patches need to be reviewed manually. And the "goto err" before the initialization makes everything more complicated (that's actually what caused the bug in this patch, in fact). regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/3] rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() @ 2016-01-04 9:38 ` Dan Carpenter 0 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2016-01-04 9:38 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors, Julia Lawall Btw, GCC misses a lot of uninitialized variable bugs. I have a Smatch check which sometimes catches the bugs that GCC misses but you should not rely on the tools here. These patches need to be reviewed manually. And the "goto err" before the initialization makes everything more complicated (that's actually what caused the bug in this patch, in fact). regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/3] rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() 2016-01-04 9:28 ` Dan Carpenter @ 2016-01-04 10:44 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-04 10:44 UTC (permalink / raw) To: Dan Carpenter Cc: linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors, Julia Lawall > These patches are labour intensive to review because you can't just do > it in the email client. Thanks for your general interest. > Also you were not able to review it properly yourself and introduced > a bug. I admit that it can happen during my software development that I overlook implementation details somehow. > I am often remove initializers but it's normally because I am changing > something else which makes it worthwhile. It is nice to hear that you are also occasionally looking for similar update candidates. > This patch is the correct thing but it's not "worthwhile". I find this view interesting. > Please stop sending cleanup patches, Markus. Just send fixes. How often will source code clean-up fix something? May I resend a consistent patch series for the source file "drivers/net/wireless/rsi/rsi_91x_pkt.c" in the near future? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/3] rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() @ 2016-01-04 10:44 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-04 10:44 UTC (permalink / raw) To: Dan Carpenter Cc: linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors, Julia Lawall > These patches are labour intensive to review because you can't just do > it in the email client. Thanks for your general interest. > Also you were not able to review it properly yourself and introduced > a bug. I admit that it can happen during my software development that I overlook implementation details somehow. > I am often remove initializers but it's normally because I am changing > something else which makes it worthwhile. It is nice to hear that you are also occasionally looking for similar update candidates. > This patch is the correct thing but it's not "worthwhile". I find this view interesting. > Please stop sending cleanup patches, Markus. Just send fixes. How often will source code clean-up fix something? May I resend a consistent patch series for the source file "drivers/net/wireless/rsi/rsi_91x_pkt.c" in the near future? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/3] rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() 2016-01-04 10:44 ` SF Markus Elfring @ 2016-01-04 11:48 ` Dan Carpenter -1 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2016-01-04 11:48 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors, Julia Lawall On Mon, Jan 04, 2016 at 11:44:15AM +0100, SF Markus Elfring wrote: > > Please stop sending cleanup patches, Markus. Just send fixes. > > How often will source code clean-up fix something? > > > May I resend a consistent patch series for the source file > "drivers/net/wireless/rsi/rsi_91x_pkt.c" in the near future? If you were sending checkpatch.pl fixes that would be easier to deal with but you are sending hundreds of "controversial" cleanups. They are controversial in the sense that they don't fix anything against official kernel style and they go against the author's original intention. I tend to agree that useless initializers are bad and disable GCCs uninitialized variable warnings but just because I agree with you doesn't make it official kernel style. It's slightly rude to go against the author's intention. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/3] rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() @ 2016-01-04 11:48 ` Dan Carpenter 0 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2016-01-04 11:48 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors, Julia Lawall On Mon, Jan 04, 2016 at 11:44:15AM +0100, SF Markus Elfring wrote: > > Please stop sending cleanup patches, Markus. Just send fixes. > > How often will source code clean-up fix something? > > > May I resend a consistent patch series for the source file > "drivers/net/wireless/rsi/rsi_91x_pkt.c" in the near future? If you were sending checkpatch.pl fixes that would be easier to deal with but you are sending hundreds of "controversial" cleanups. They are controversial in the sense that they don't fix anything against official kernel style and they go against the author's original intention. I tend to agree that useless initializers are bad and disable GCCs uninitialized variable warnings but just because I agree with you doesn't make it official kernel style. It's slightly rude to go against the author's intention. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() 2016-01-04 11:48 ` Dan Carpenter @ 2016-01-04 12:33 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-04 12:33 UTC (permalink / raw) To: Dan Carpenter Cc: linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors, Julia Lawall >> May I resend a consistent patch series for the source file >> "drivers/net/wireless/rsi/rsi_91x_pkt.c" in the near future? > > If you were sending checkpatch.pl fixes that would be easier to deal with Does this feedback mean that you would accept any more suggestions around source code updates which are derived from recommendations of this script? > but you are sending hundreds of "controversial" cleanups. It depends on the time range you look at for my proposals. > They are controversial in the sense that they don't fix anything > against official kernel style I find that I suggested also few changes that fit to this aspect. > and they go against the author's original intention. Can it occasionally help to reconsider the "first approach"? > I tend to agree that useless initializers are bad Would any more software developers like to share their opinions on this detail? > and disable GCCs uninitialized variable warnings I hope that this software area can be also improved. > but just because I agree with you doesn't make it official kernel style. That is fine. - Will it become useful to clarify any extensions to a document like "CodingStyle"? > It's slightly rude to go against the author's intention. I just dare to propose further special changes. Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() @ 2016-01-04 12:33 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-04 12:33 UTC (permalink / raw) To: Dan Carpenter Cc: linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors, Julia Lawall >> May I resend a consistent patch series for the source file >> "drivers/net/wireless/rsi/rsi_91x_pkt.c" in the near future? > > If you were sending checkpatch.pl fixes that would be easier to deal with Does this feedback mean that you would accept any more suggestions around source code updates which are derived from recommendations of this script? > but you are sending hundreds of "controversial" cleanups. It depends on the time range you look at for my proposals. > They are controversial in the sense that they don't fix anything > against official kernel style I find that I suggested also few changes that fit to this aspect. > and they go against the author's original intention. Can it occasionally help to reconsider the "first approach"? > I tend to agree that useless initializers are bad Would any more software developers like to share their opinions on this detail? > and disable GCCs uninitialized variable warnings I hope that this software area can be also improved. > but just because I agree with you doesn't make it official kernel style. That is fine. - Will it become useful to clarify any extensions to a document like "CodingStyle"? > It's slightly rude to go against the author's intention. I just dare to propose further special changes. Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() @ 2016-01-04 23:54 ` Julian Calaby 0 siblings, 0 replies; 3089+ messages in thread From: Julian Calaby @ 2016-01-04 23:54 UTC (permalink / raw) To: SF Markus Elfring Cc: Dan Carpenter, linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors, Julia Lawall Hi Markus, On Mon, Jan 4, 2016 at 11:33 PM, SF Markus Elfring <elfring@users.sourceforge.net> wrote: >>> May I resend a consistent patch series for the source file >>> "drivers/net/wireless/rsi/rsi_91x_pkt.c" in the near future? >> >> If you were sending checkpatch.pl fixes that would be easier to deal with > > Does this feedback mean that you would accept any more suggestions around > source code updates which are derived from recommendations of this script? A good rule of thumb here would be that if people start complaining about a particular type of change, stop sending them. Another good rule of thumb is to try to "rock the boat" on coding style and conventions as little as possible. Just because it's possible doesn't mean that people want to do it. That said, if you figure out some change that produces significant reductions in code or binary size on multiple architectures without making things more complicated, less readable or making the code or binary size larger, then by all means propose it. "This makes things smaller" carries much more weight than "I think this is better". Almost all of the changes you've proposed that have seen any discussion whatsoever fall into the latter category. Thanks, -- Julian Calaby Email: julian.calaby@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() @ 2016-01-04 23:54 ` Julian Calaby 0 siblings, 0 replies; 3089+ messages in thread From: Julian Calaby @ 2016-01-04 23:54 UTC (permalink / raw) To: SF Markus Elfring Cc: Dan Carpenter, linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors, Julia Lawall Hi Markus, On Mon, Jan 4, 2016 at 11:33 PM, SF Markus Elfring <elfring@users.sourceforge.net> wrote: >>> May I resend a consistent patch series for the source file >>> "drivers/net/wireless/rsi/rsi_91x_pkt.c" in the near future? >> >> If you were sending checkpatch.pl fixes that would be easier to deal with > > Does this feedback mean that you would accept any more suggestions around > source code updates which are derived from recommendations of this script? A good rule of thumb here would be that if people start complaining about a particular type of change, stop sending them. Another good rule of thumb is to try to "rock the boat" on coding style and conventions as little as possible. Just because it's possible doesn't mean that people want to do it. That said, if you figure out some change that produces significant reductions in code or binary size on multiple architectures without making things more complicated, less readable or making the code or binary size larger, then by all means propose it. "This makes things smaller" carries much more weight than "I think this is better". Almost all of the changes you've proposed that have seen any discussion whatsoever fall into the latter category. Thanks, -- Julian Calaby Email: julian.calaby@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() @ 2016-01-04 23:54 ` Julian Calaby 0 siblings, 0 replies; 3089+ messages in thread From: Julian Calaby @ 2016-01-04 23:54 UTC (permalink / raw) To: SF Markus Elfring Cc: Dan Carpenter, linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall Hi Markus, On Mon, Jan 4, 2016 at 11:33 PM, SF Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> wrote: >>> May I resend a consistent patch series for the source file >>> "drivers/net/wireless/rsi/rsi_91x_pkt.c" in the near future? >> >> If you were sending checkpatch.pl fixes that would be easier to deal with > > Does this feedback mean that you would accept any more suggestions around > source code updates which are derived from recommendations of this script? A good rule of thumb here would be that if people start complaining about a particular type of change, stop sending them. Another good rule of thumb is to try to "rock the boat" on coding style and conventions as little as possible. Just because it's possible doesn't mean that people want to do it. That said, if you figure out some change that produces significant reductions in code or binary size on multiple architectures without making things more complicated, less readable or making the code or binary size larger, then by all means propose it. "This makes things smaller" carries much more weight than "I think this is better". Almost all of the changes you've proposed that have seen any discussion whatsoever fall into the latter category. Thanks, -- Julian Calaby Email: julian.calaby-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org Profile: http://www.google.com/profiles/julian.calaby/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() 2016-01-04 23:54 ` Julian Calaby @ 2016-01-05 8:29 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-05 8:29 UTC (permalink / raw) To: Julian Calaby Cc: Dan Carpenter, linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors, Julia Lawall > That said, if you figure out some change that produces significant > reductions in code or binary size on multiple architectures without > making things more complicated, less readable or making the code or > binary size larger, then by all means propose it. Are you looking also for "a proof" that such changes are worthwhile? > "This makes things smaller" carries much more weight than > "I think this is better". Can the discussed implementation of a function like "rsi_send_mgmt_pkt" become a bit smaller by the deletion of extra variable initialisations > Almost all of the changes you've proposed that have seen any > discussion whatsoever fall into the latter category. Thanks for your interesting feedback. Can a further constructive dialogue evolve from the presented information? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() @ 2016-01-05 8:29 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-05 8:29 UTC (permalink / raw) To: Julian Calaby Cc: Dan Carpenter, linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors, Julia Lawall > That said, if you figure out some change that produces significant > reductions in code or binary size on multiple architectures without > making things more complicated, less readable or making the code or > binary size larger, then by all means propose it. Are you looking also for "a proof" that such changes are worthwhile? > "This makes things smaller" carries much more weight than > "I think this is better". Can the discussed implementation of a function like "rsi_send_mgmt_pkt" become a bit smaller by the deletion of extra variable initialisations > Almost all of the changes you've proposed that have seen any > discussion whatsoever fall into the latter category. Thanks for your interesting feedback. Can a further constructive dialogue evolve from the presented information? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() 2016-01-05 8:29 ` SF Markus Elfring @ 2016-01-05 9:47 ` Julian Calaby -1 siblings, 0 replies; 3089+ messages in thread From: Julian Calaby @ 2016-01-05 9:47 UTC (permalink / raw) To: SF Markus Elfring Cc: Dan Carpenter, linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors, Julia Lawall Hi Markus, On Tue, Jan 5, 2016 at 7:29 PM, SF Markus Elfring <elfring@users.sourceforge.net> wrote: >> That said, if you figure out some change that produces significant >> reductions in code or binary size on multiple architectures without >> making things more complicated, less readable or making the code or >> binary size larger, then by all means propose it. > > Are you looking also for "a proof" that such changes are worthwhile? It'd be better than "I think doing things this way is better", which is the hallmark of most of your patch sets. (Admittedly not this one, but this one is where the discussion is now, so that's where we're discussing it.) >> "This makes things smaller" carries much more weight than >> "I think this is better". > > Can the discussed implementation of a function like "rsi_send_mgmt_pkt" > become a bit smaller by the deletion of extra variable initialisations I'm talking in general. In this case you're asking people to review a patch which requires a lot of careful review for a fairly minor improvement. I must also note that you haven't CC'd the people who wrote this driver, so it's possible that the only people who have reviewed it aren't experts in the code. The patches you sent recently which moved labels into if statements were a clear case of "I think this is better" where any actual benefit from the changes was eclipsed by the style and readability issues they introduced. >> Almost all of the changes you've proposed that have seen any >> discussion whatsoever fall into the latter category. > > Thanks for your interesting feedback. No problem. > Can a further constructive dialogue evolve from the presented information? Part of the issue here is that you don't seem to be listening to the discussion of your patches, or if you are, you're not significantly changing your approach or attitude in response. Every time you send a set of patches, there are legitimate issues which people raise, and every time they are discussed, you assert that your patches improve things and seem to ignore the concerns people raise. I've seen this same pattern of discussion here with these patches, with your patches to move labels into if statements, with the patches you sent late June last year, your patches to remove conditions before kfree() and friends, etc. You need to change you attitude: just because you can see some benefit from your patches doesn't mean others do and it doesn't mean that they're willing to accept them. Thanks, -- Julian Calaby Email: julian.calaby@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() @ 2016-01-05 9:47 ` Julian Calaby 0 siblings, 0 replies; 3089+ messages in thread From: Julian Calaby @ 2016-01-05 9:47 UTC (permalink / raw) To: SF Markus Elfring Cc: Dan Carpenter, linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors, Julia Lawall Hi Markus, On Tue, Jan 5, 2016 at 7:29 PM, SF Markus Elfring <elfring@users.sourceforge.net> wrote: >> That said, if you figure out some change that produces significant >> reductions in code or binary size on multiple architectures without >> making things more complicated, less readable or making the code or >> binary size larger, then by all means propose it. > > Are you looking also for "a proof" that such changes are worthwhile? It'd be better than "I think doing things this way is better", which is the hallmark of most of your patch sets. (Admittedly not this one, but this one is where the discussion is now, so that's where we're discussing it.) >> "This makes things smaller" carries much more weight than >> "I think this is better". > > Can the discussed implementation of a function like "rsi_send_mgmt_pkt" > become a bit smaller by the deletion of extra variable initialisations I'm talking in general. In this case you're asking people to review a patch which requires a lot of careful review for a fairly minor improvement. I must also note that you haven't CC'd the people who wrote this driver, so it's possible that the only people who have reviewed it aren't experts in the code. The patches you sent recently which moved labels into if statements were a clear case of "I think this is better" where any actual benefit from the changes was eclipsed by the style and readability issues they introduced. >> Almost all of the changes you've proposed that have seen any >> discussion whatsoever fall into the latter category. > > Thanks for your interesting feedback. No problem. > Can a further constructive dialogue evolve from the presented information? Part of the issue here is that you don't seem to be listening to the discussion of your patches, or if you are, you're not significantly changing your approach or attitude in response. Every time you send a set of patches, there are legitimate issues which people raise, and every time they are discussed, you assert that your patches improve things and seem to ignore the concerns people raise. I've seen this same pattern of discussion here with these patches, with your patches to move labels into if statements, with the patches you sent late June last year, your patches to remove conditions before kfree() and friends, etc. You need to change you attitude: just because you can see some benefit from your patches doesn't mean others do and it doesn't mean that they're willing to accept them. Thanks, -- Julian Calaby Email: julian.calaby@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() 2016-01-05 9:47 ` Julian Calaby @ 2016-01-05 16:23 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-05 16:23 UTC (permalink / raw) To: Julian Calaby Cc: Dan Carpenter, linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors, Julia Lawall > Every time you send a set of patches, I suggested some updates for Linux source files since October 2014. > there are legitimate issues which people raise, There was usual feedback. > and every time they are discussed, The discussion results were mixed between acceptance and usual disagreement. > you assert that your patches improve things I guess that should be the default intention of every patch, shouldn't it? > and seem to ignore the concerns people raise. I hope not. - But I can imagine that you might understand some responses from contributors in this way. Are you waiting for another clarification on a specific issue? > I've seen this same pattern of discussion here with these patches, > with your patches to move labels into if statements, with the patches > you sent late June last year, your patches to remove conditions before > kfree() and friends, etc. It seems that communication difficulties come partly from the fact that I chose search patterns from static source code analysis so far which belong to an error category that gets a lower priority. > You need to change you attitude: just because you can see some benefit > from your patches doesn't mean others do and it doesn't mean that > they're willing to accept them. I understand your advice. Further update suggestions with higher importance might follow for various software areas in the future. Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() @ 2016-01-05 16:23 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-05 16:23 UTC (permalink / raw) To: Julian Calaby Cc: Dan Carpenter, linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors, Julia Lawall > Every time you send a set of patches, I suggested some updates for Linux source files since October 2014. > there are legitimate issues which people raise, There was usual feedback. > and every time they are discussed, The discussion results were mixed between acceptance and usual disagreement. > you assert that your patches improve things I guess that should be the default intention of every patch, shouldn't it? > and seem to ignore the concerns people raise. I hope not. - But I can imagine that you might understand some responses from contributors in this way. Are you waiting for another clarification on a specific issue? > I've seen this same pattern of discussion here with these patches, > with your patches to move labels into if statements, with the patches > you sent late June last year, your patches to remove conditions before > kfree() and friends, etc. It seems that communication difficulties come partly from the fact that I chose search patterns from static source code analysis so far which belong to an error category that gets a lower priority. > You need to change you attitude: just because you can see some benefit > from your patches doesn't mean others do and it doesn't mean that > they're willing to accept them. I understand your advice. Further update suggestions with higher importance might follow for various software areas in the future. Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/3] rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() 2016-01-04 9:28 ` Dan Carpenter (?) @ 2016-01-04 13:17 ` Bjørn Mork -1 siblings, 0 replies; 3089+ messages in thread From: Bjørn Mork @ 2016-01-04 13:17 UTC (permalink / raw) To: Dan Carpenter Cc: SF Markus Elfring, linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors, Julia Lawall Dan Carpenter <dan.carpenter@oracle.com> writes: > Please stop sending cleanup patches, Markus. Just send fixes. Thanks for your continued but unwarranted belief in AI. Do you mind if I remind you of https://lkml.org/lkml/2014/11/3/162 ? I am sure there are lots and lots of other examples. There is no reason to believe this will ever stop. He just goes into Eliza mode. Bjørn ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/3] rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() @ 2016-01-04 13:17 ` Bjørn Mork 0 siblings, 0 replies; 3089+ messages in thread From: Bjørn Mork @ 2016-01-04 13:17 UTC (permalink / raw) To: Dan Carpenter Cc: SF Markus Elfring, linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors, Julia Lawall Dan Carpenter <dan.carpenter@oracle.com> writes: > Please stop sending cleanup patches, Markus. Just send fixes. Thanks for your continued but unwarranted belief in AI. Do you mind if I remind you of https://lkml.org/lkml/2014/11/3/162 ? I am sure there are lots and lots of other examples. There is no reason to believe this will ever stop. He just goes into Eliza mode. Bjørn -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/3] rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() @ 2016-01-04 13:17 ` Bjørn Mork 0 siblings, 0 replies; 3089+ messages in thread From: Bjørn Mork @ 2016-01-04 13:17 UTC (permalink / raw) To: Dan Carpenter Cc: SF Markus Elfring, linux-wireless-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA, Kalle Valo, LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall Dan Carpenter <dan.carpenter-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> writes: > Please stop sending cleanup patches, Markus. Just send fixes. Thanks for your continued but unwarranted belief in AI. Do you mind if I remind you of https://lkml.org/lkml/2014/11/3/162 ? I am sure there are lots and lots of other examples. There is no reason to believe this will ever stop. He just goes into Eliza mode. Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/3] rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() @ 2016-01-04 14:25 ` Dan Carpenter 0 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2016-01-04 14:25 UTC (permalink / raw) To: Bjørn Mork Cc: SF Markus Elfring, linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors, Julia Lawall On Mon, Jan 04, 2016 at 02:17:40PM +0100, Bjørn Mork wrote: > Dan Carpenter <dan.carpenter@oracle.com> writes: > > > Please stop sending cleanup patches, Markus. Just send fixes. > > Thanks for your continued but unwarranted belief in AI. > I always tell people that I am very mechanical and you can rely on me to send predictable responses... > Do you mind if I remind you of https://lkml.org/lkml/2014/11/3/162 ? > I am sure there are lots and lots of other examples. There is no reason > to believe this will ever stop. He just goes into Eliza mode. Yup. I feel some sense of responsibility for any patches where kernel-janitors is on the CC but I'm having a hard time dealing with all of Markus's patches. Normally you just respond to the first patch and people change the later patches but, as you put it, Markus just goes into ELIZA mode. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/3] rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() @ 2016-01-04 14:25 ` Dan Carpenter 0 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2016-01-04 14:25 UTC (permalink / raw) To: Bjørn Mork Cc: SF Markus Elfring, linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors, Julia Lawall On Mon, Jan 04, 2016 at 02:17:40PM +0100, Bjørn Mork wrote: > Dan Carpenter <dan.carpenter@oracle.com> writes: > > > Please stop sending cleanup patches, Markus. Just send fixes. > > Thanks for your continued but unwarranted belief in AI. > I always tell people that I am very mechanical and you can rely on me to send predictable responses... > Do you mind if I remind you of https://lkml.org/lkml/2014/11/3/162 ? > I am sure there are lots and lots of other examples. There is no reason > to believe this will ever stop. He just goes into Eliza mode. Yup. I feel some sense of responsibility for any patches where kernel-janitors is on the CC but I'm having a hard time dealing with all of Markus's patches. Normally you just respond to the first patch and people change the later patches but, as you put it, Markus just goes into ELIZA mode. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/3] rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() @ 2016-01-04 14:25 ` Dan Carpenter 0 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2016-01-04 14:25 UTC (permalink / raw) To: Bjørn Mork Cc: SF Markus Elfring, linux-wireless-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA, Kalle Valo, LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall On Mon, Jan 04, 2016 at 02:17:40PM +0100, Bjørn Mork wrote: > Dan Carpenter <dan.carpenter-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> writes: > > > Please stop sending cleanup patches, Markus. Just send fixes. > > Thanks for your continued but unwarranted belief in AI. > I always tell people that I am very mechanical and you can rely on me to send predictable responses... > Do you mind if I remind you of https://lkml.org/lkml/2014/11/3/162 ? > I am sure there are lots and lots of other examples. There is no reason > to believe this will ever stop. He just goes into Eliza mode. Yup. I feel some sense of responsibility for any patches where kernel-janitors is on the CC but I'm having a hard time dealing with all of Markus's patches. Normally you just respond to the first patch and people change the later patches but, as you put it, Markus just goes into ELIZA mode. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/3] rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() 2016-01-04 9:28 ` Dan Carpenter @ 2016-01-04 17:14 ` David Miller -1 siblings, 0 replies; 3089+ messages in thread From: David Miller @ 2016-01-04 17:14 UTC (permalink / raw) To: dan.carpenter Cc: elfring, linux-wireless, netdev, kvalo, linux-kernel, kernel-janitors, julia.lawall From: Dan Carpenter <dan.carpenter@oracle.com> Date: Mon, 4 Jan 2016 12:28:57 +0300 > Please stop sending cleanup patches, Markus. Just send fixes. +1 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/3] rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() @ 2016-01-04 17:14 ` David Miller 0 siblings, 0 replies; 3089+ messages in thread From: David Miller @ 2016-01-04 17:14 UTC (permalink / raw) To: dan.carpenter Cc: elfring, linux-wireless, netdev, kvalo, linux-kernel, kernel-janitors, julia.lawall From: Dan Carpenter <dan.carpenter@oracle.com> Date: Mon, 4 Jan 2016 12:28:57 +0300 > Please stop sending cleanup patches, Markus. Just send fixes. +1 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 2/3] rsi: Delete unnecessary variable initialisations in rsi_send_data_pkt() 2016-01-02 14:40 ` SF Markus Elfring @ 2016-01-02 14:44 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 14:44 UTC (permalink / raw) To: linux-wireless, netdev, Kalle Valo; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jan 2016 15:15:12 +0100 Omit explicit initialisation at the beginning for four local variables which are redefined before their first use. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/wireless/rsi/rsi_91x_pkt.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/rsi/rsi_91x_pkt.c b/drivers/net/wireless/rsi/rsi_91x_pkt.c index ee98f5b..ec65e1c 100644 --- a/drivers/net/wireless/rsi/rsi_91x_pkt.c +++ b/drivers/net/wireless/rsi/rsi_91x_pkt.c @@ -27,15 +27,15 @@ int rsi_send_data_pkt(struct rsi_common *common, struct sk_buff *skb) { struct rsi_hw *adapter = common->priv; - struct ieee80211_hdr *tmp_hdr = NULL; + struct ieee80211_hdr *tmp_hdr; struct ieee80211_tx_info *info; struct skb_info *tx_params; - struct ieee80211_bss_conf *bss = NULL; + struct ieee80211_bss_conf *bss; int status = -EINVAL; u8 ieee80211_size = MIN_802_11_HDR_LEN; - u8 extnd_size = 0; + u8 extnd_size; __le16 *frame_desc; - u16 seq_num = 0; + u16 seq_num; info = IEEE80211_SKB_CB(skb); bss = &info->control.vif->bss_conf; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 2/3] rsi: Delete unnecessary variable initialisations in rsi_send_data_pkt() @ 2016-01-02 14:44 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 14:44 UTC (permalink / raw) To: linux-wireless, netdev, Kalle Valo; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jan 2016 15:15:12 +0100 Omit explicit initialisation at the beginning for four local variables which are redefined before their first use. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/wireless/rsi/rsi_91x_pkt.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/rsi/rsi_91x_pkt.c b/drivers/net/wireless/rsi/rsi_91x_pkt.c index ee98f5b..ec65e1c 100644 --- a/drivers/net/wireless/rsi/rsi_91x_pkt.c +++ b/drivers/net/wireless/rsi/rsi_91x_pkt.c @@ -27,15 +27,15 @@ int rsi_send_data_pkt(struct rsi_common *common, struct sk_buff *skb) { struct rsi_hw *adapter = common->priv; - struct ieee80211_hdr *tmp_hdr = NULL; + struct ieee80211_hdr *tmp_hdr; struct ieee80211_tx_info *info; struct skb_info *tx_params; - struct ieee80211_bss_conf *bss = NULL; + struct ieee80211_bss_conf *bss; int status = -EINVAL; u8 ieee80211_size = MIN_802_11_HDR_LEN; - u8 extnd_size = 0; + u8 extnd_size; __le16 *frame_desc; - u16 seq_num = 0; + u16 seq_num; info = IEEE80211_SKB_CB(skb); bss = &info->control.vif->bss_conf; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 3/3] rsi: Replace variable initialisations by assignments in rsi_send_data_pkt() 2016-01-02 14:40 ` SF Markus Elfring @ 2016-01-02 14:45 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 14:45 UTC (permalink / raw) To: linux-wireless, netdev, Kalle Valo; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jan 2016 15:25:34 +0100 Replace explicit initialisation for two local variables at the beginning by assignments. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/wireless/rsi/rsi_91x_pkt.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/rsi/rsi_91x_pkt.c b/drivers/net/wireless/rsi/rsi_91x_pkt.c index ec65e1c..fe36e7d 100644 --- a/drivers/net/wireless/rsi/rsi_91x_pkt.c +++ b/drivers/net/wireless/rsi/rsi_91x_pkt.c @@ -26,12 +26,12 @@ */ int rsi_send_data_pkt(struct rsi_common *common, struct sk_buff *skb) { - struct rsi_hw *adapter = common->priv; + struct rsi_hw *adapter; struct ieee80211_hdr *tmp_hdr; struct ieee80211_tx_info *info; struct skb_info *tx_params; struct ieee80211_bss_conf *bss; - int status = -EINVAL; + int status; u8 ieee80211_size = MIN_802_11_HDR_LEN; u8 extnd_size; __le16 *frame_desc; @@ -41,8 +41,10 @@ int rsi_send_data_pkt(struct rsi_common *common, struct sk_buff *skb) bss = &info->control.vif->bss_conf; tx_params = (struct skb_info *)info->driver_data; - if (!bss->assoc) + if (!bss->assoc) { + status = -EINVAL; goto err; + } tmp_hdr = (struct ieee80211_hdr *)&skb->data[0]; seq_num = (le16_to_cpu(tmp_hdr->seq_ctrl) >> 4); @@ -97,7 +99,7 @@ int rsi_send_data_pkt(struct rsi_common *common, struct sk_buff *skb) frame_desc[7] = cpu_to_le16(((tx_params->tid & 0xf) << 4) | (skb->priority & 0xf) | (tx_params->sta_id << 8)); - + adapter = common->priv; status = adapter->host_intf_write_pkt(common->priv, skb->data, skb->len); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 3/3] rsi: Replace variable initialisations by assignments in rsi_send_data_pkt() @ 2016-01-02 14:45 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 14:45 UTC (permalink / raw) To: linux-wireless, netdev, Kalle Valo; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jan 2016 15:25:34 +0100 Replace explicit initialisation for two local variables at the beginning by assignments. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/wireless/rsi/rsi_91x_pkt.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/rsi/rsi_91x_pkt.c b/drivers/net/wireless/rsi/rsi_91x_pkt.c index ec65e1c..fe36e7d 100644 --- a/drivers/net/wireless/rsi/rsi_91x_pkt.c +++ b/drivers/net/wireless/rsi/rsi_91x_pkt.c @@ -26,12 +26,12 @@ */ int rsi_send_data_pkt(struct rsi_common *common, struct sk_buff *skb) { - struct rsi_hw *adapter = common->priv; + struct rsi_hw *adapter; struct ieee80211_hdr *tmp_hdr; struct ieee80211_tx_info *info; struct skb_info *tx_params; struct ieee80211_bss_conf *bss; - int status = -EINVAL; + int status; u8 ieee80211_size = MIN_802_11_HDR_LEN; u8 extnd_size; __le16 *frame_desc; @@ -41,8 +41,10 @@ int rsi_send_data_pkt(struct rsi_common *common, struct sk_buff *skb) bss = &info->control.vif->bss_conf; tx_params = (struct skb_info *)info->driver_data; - if (!bss->assoc) + if (!bss->assoc) { + status = -EINVAL; goto err; + } tmp_hdr = (struct ieee80211_hdr *)&skb->data[0]; seq_num = (le16_to_cpu(tmp_hdr->seq_ctrl) >> 4); @@ -97,7 +99,7 @@ int rsi_send_data_pkt(struct rsi_common *common, struct sk_buff *skb) frame_desc[7] = cpu_to_le16(((tx_params->tid & 0xf) << 4) | (skb->priority & 0xf) | (tx_params->sta_id << 8)); - + adapter = common->priv; status = adapter->host_intf_write_pkt(common->priv, skb->data, skb->len); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 3/3] rsi: Replace variable initialisations by assignments in rsi_send_data_pkt() 2016-01-02 14:45 ` SF Markus Elfring @ 2016-01-02 15:07 ` Francois Romieu -1 siblings, 0 replies; 3089+ messages in thread From: Francois Romieu @ 2016-01-02 15:07 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors, Julia Lawall SF Markus Elfring <elfring@users.sourceforge.net> : > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sat, 2 Jan 2016 15:25:34 +0100 > > Replace explicit initialisation for two local variables at the beginning > by assignments. It makes no sense for the 'adapter' variable. -- Ueimor ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 3/3] rsi: Replace variable initialisations by assignments in rsi_send_data_pkt() @ 2016-01-02 15:07 ` Francois Romieu 0 siblings, 0 replies; 3089+ messages in thread From: Francois Romieu @ 2016-01-02 15:07 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-wireless, netdev, Kalle Valo, LKML, kernel-janitors, Julia Lawall SF Markus Elfring <elfring@users.sourceforge.net> : > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sat, 2 Jan 2016 15:25:34 +0100 > > Replace explicit initialisation for two local variables at the beginning > by assignments. It makes no sense for the 'adapter' variable. -- Ueimor ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH v3 0/3] net-rsi: Fine-tuning for two function implementations @ 2016-01-15 13:04 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-15 13:04 UTC (permalink / raw) To: linux-wireless, netdev, Fariya Fatima, Jahnavi Meher, Kalle Valo Cc: LKML, kernel-janitors, Julia Lawall, John W. Linville From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 15 Jan 2016 13:54:43 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (3): Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() Delete unnecessary variable initialisations in rsi_send_data_pkt() Replace variable initialisations by assignments in rsi_send_data_pkt() drivers/net/wireless/rsi/rsi_91x_pkt.c | 26 ++++++++++++++------------ 1 file changed, 14 insertions(+), 12 deletions(-) --- v3: Rebase proposed changes on the source files for the software "Linux next-20160114". v2: Unfortunately, the first update step from this series contained an inappropriate suggestion. Thus fix that. -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH v3 0/3] net-rsi: Fine-tuning for two function implementations @ 2016-01-15 13:04 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-15 13:04 UTC (permalink / raw) To: linux-wireless, netdev, Fariya Fatima, Jahnavi Meher, Kalle Valo Cc: LKML, kernel-janitors, Julia Lawall, John W. Linville From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 15 Jan 2016 13:54:43 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (3): Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() Delete unnecessary variable initialisations in rsi_send_data_pkt() Replace variable initialisations by assignments in rsi_send_data_pkt() drivers/net/wireless/rsi/rsi_91x_pkt.c | 26 ++++++++++++++------------ 1 file changed, 14 insertions(+), 12 deletions(-) --- v3: Rebase proposed changes on the source files for the software "Linux next-20160114". v2: Unfortunately, the first update step from this series contained an inappropriate suggestion. Thus fix that. -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH v3 0/3] net-rsi: Fine-tuning for two function implementations @ 2016-01-15 13:04 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-15 13:04 UTC (permalink / raw) To: linux-wireless-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA, Fariya Fatima, Jahnavi Meher, Kalle Valo Cc: LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall, John W. Linville From: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> Date: Fri, 15 Jan 2016 13:54:43 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (3): Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() Delete unnecessary variable initialisations in rsi_send_data_pkt() Replace variable initialisations by assignments in rsi_send_data_pkt() drivers/net/wireless/rsi/rsi_91x_pkt.c | 26 ++++++++++++++------------ 1 file changed, 14 insertions(+), 12 deletions(-) --- v3: Rebase proposed changes on the source files for the software "Linux next-20160114". v2: Unfortunately, the first update step from this series contained an inappropriate suggestion. Thus fix that. -- 2.6.3 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH v3 1/3] rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() 2016-01-15 13:04 ` SF Markus Elfring @ 2016-01-15 13:09 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-15 13:09 UTC (permalink / raw) To: linux-wireless, netdev, Fariya Fatima, Jahnavi Meher, Kalle Valo Cc: LKML, kernel-janitors, Julia Lawall, John W. Linville From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 15 Jan 2016 13:30:39 +0100 Omit explicit initialisation at the beginning for four local variables which are redefined before their first use. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/wireless/rsi/rsi_91x_pkt.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/rsi/rsi_91x_pkt.c b/drivers/net/wireless/rsi/rsi_91x_pkt.c index 702593f..571eaba 100644 --- a/drivers/net/wireless/rsi/rsi_91x_pkt.c +++ b/drivers/net/wireless/rsi/rsi_91x_pkt.c @@ -123,15 +123,15 @@ int rsi_send_mgmt_pkt(struct rsi_common *common, struct sk_buff *skb) { struct rsi_hw *adapter = common->priv; - struct ieee80211_hdr *wh = NULL; + struct ieee80211_hdr *wh; struct ieee80211_tx_info *info; - struct ieee80211_bss_conf *bss = NULL; + struct ieee80211_bss_conf *bss; struct ieee80211_hw *hw = adapter->hw; struct ieee80211_conf *conf = &hw->conf; struct skb_info *tx_params; int status = -E2BIG; - __le16 *msg = NULL; - u8 extnd_size = 0; + __le16 *msg; + u8 extnd_size; u8 vap_id = 0; info = IEEE80211_SKB_CB(skb); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH v3 1/3] rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() @ 2016-01-15 13:09 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-15 13:09 UTC (permalink / raw) To: linux-wireless, netdev, Fariya Fatima, Jahnavi Meher, Kalle Valo Cc: LKML, kernel-janitors, Julia Lawall, John W. Linville From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 15 Jan 2016 13:30:39 +0100 Omit explicit initialisation at the beginning for four local variables which are redefined before their first use. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/wireless/rsi/rsi_91x_pkt.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/rsi/rsi_91x_pkt.c b/drivers/net/wireless/rsi/rsi_91x_pkt.c index 702593f..571eaba 100644 --- a/drivers/net/wireless/rsi/rsi_91x_pkt.c +++ b/drivers/net/wireless/rsi/rsi_91x_pkt.c @@ -123,15 +123,15 @@ int rsi_send_mgmt_pkt(struct rsi_common *common, struct sk_buff *skb) { struct rsi_hw *adapter = common->priv; - struct ieee80211_hdr *wh = NULL; + struct ieee80211_hdr *wh; struct ieee80211_tx_info *info; - struct ieee80211_bss_conf *bss = NULL; + struct ieee80211_bss_conf *bss; struct ieee80211_hw *hw = adapter->hw; struct ieee80211_conf *conf = &hw->conf; struct skb_info *tx_params; int status = -E2BIG; - __le16 *msg = NULL; - u8 extnd_size = 0; + __le16 *msg; + u8 extnd_size; u8 vap_id = 0; info = IEEE80211_SKB_CB(skb); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH v3 2/3] rsi: Delete unnecessary variable initialisations in rsi_send_data_pkt() 2016-01-15 13:04 ` SF Markus Elfring @ 2016-01-15 13:10 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-15 13:10 UTC (permalink / raw) To: linux-wireless, netdev, Fariya Fatima, Jahnavi Meher, Kalle Valo Cc: LKML, kernel-janitors, Julia Lawall, John W. Linville >From 017d1bb49f46266ffeb33178ddd3022d6b341d71 Mon Sep 17 00:00:00 2001 From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 15 Jan 2016 13:35:47 +0100 Subject: [PATCH 2/3] rsi: Delete unnecessary variable initialisations in rsi_send_data_pkt() Omit explicit initialisation at the beginning for four local variables which are redefined before their first use. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/wireless/rsi/rsi_91x_pkt.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/rsi/rsi_91x_pkt.c b/drivers/net/wireless/rsi/rsi_91x_pkt.c index 571eaba..4322df1 100644 --- a/drivers/net/wireless/rsi/rsi_91x_pkt.c +++ b/drivers/net/wireless/rsi/rsi_91x_pkt.c @@ -27,15 +27,15 @@ int rsi_send_data_pkt(struct rsi_common *common, struct sk_buff *skb) { struct rsi_hw *adapter = common->priv; - struct ieee80211_hdr *tmp_hdr = NULL; + struct ieee80211_hdr *tmp_hdr; struct ieee80211_tx_info *info; struct skb_info *tx_params; - struct ieee80211_bss_conf *bss = NULL; + struct ieee80211_bss_conf *bss; int status = -EINVAL; u8 ieee80211_size = MIN_802_11_HDR_LEN; - u8 extnd_size = 0; + u8 extnd_size; __le16 *frame_desc; - u16 seq_num = 0; + u16 seq_num; info = IEEE80211_SKB_CB(skb); bss = &info->control.vif->bss_conf; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH v3 2/3] rsi: Delete unnecessary variable initialisations in rsi_send_data_pkt() @ 2016-01-15 13:10 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-15 13:10 UTC (permalink / raw) To: linux-wireless, netdev, Fariya Fatima, Jahnavi Meher, Kalle Valo Cc: LKML, kernel-janitors, Julia Lawall, John W. Linville From 017d1bb49f46266ffeb33178ddd3022d6b341d71 Mon Sep 17 00:00:00 2001 From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 15 Jan 2016 13:35:47 +0100 Subject: [PATCH 2/3] rsi: Delete unnecessary variable initialisations in rsi_send_data_pkt() Omit explicit initialisation at the beginning for four local variables which are redefined before their first use. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/wireless/rsi/rsi_91x_pkt.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/rsi/rsi_91x_pkt.c b/drivers/net/wireless/rsi/rsi_91x_pkt.c index 571eaba..4322df1 100644 --- a/drivers/net/wireless/rsi/rsi_91x_pkt.c +++ b/drivers/net/wireless/rsi/rsi_91x_pkt.c @@ -27,15 +27,15 @@ int rsi_send_data_pkt(struct rsi_common *common, struct sk_buff *skb) { struct rsi_hw *adapter = common->priv; - struct ieee80211_hdr *tmp_hdr = NULL; + struct ieee80211_hdr *tmp_hdr; struct ieee80211_tx_info *info; struct skb_info *tx_params; - struct ieee80211_bss_conf *bss = NULL; + struct ieee80211_bss_conf *bss; int status = -EINVAL; u8 ieee80211_size = MIN_802_11_HDR_LEN; - u8 extnd_size = 0; + u8 extnd_size; __le16 *frame_desc; - u16 seq_num = 0; + u16 seq_num; info = IEEE80211_SKB_CB(skb); bss = &info->control.vif->bss_conf; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH v3 3/3] rsi: Replace variable initialisations by assignments in rsi_send_data_pkt() 2016-01-15 13:04 ` SF Markus Elfring @ 2016-01-15 13:12 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-15 13:12 UTC (permalink / raw) To: linux-wireless, netdev, Fariya Fatima, Jahnavi Meher, Kalle Valo Cc: LKML, kernel-janitors, Julia Lawall, John W. Linville From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 15 Jan 2016 13:40:22 +0100 Replace explicit initialisation for two local variables at the beginning by assignments. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/wireless/rsi/rsi_91x_pkt.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/rsi/rsi_91x_pkt.c b/drivers/net/wireless/rsi/rsi_91x_pkt.c index 4322df1..2c18c01 100644 --- a/drivers/net/wireless/rsi/rsi_91x_pkt.c +++ b/drivers/net/wireless/rsi/rsi_91x_pkt.c @@ -26,12 +26,12 @@ */ int rsi_send_data_pkt(struct rsi_common *common, struct sk_buff *skb) { - struct rsi_hw *adapter = common->priv; + struct rsi_hw *adapter; struct ieee80211_hdr *tmp_hdr; struct ieee80211_tx_info *info; struct skb_info *tx_params; struct ieee80211_bss_conf *bss; - int status = -EINVAL; + int status; u8 ieee80211_size = MIN_802_11_HDR_LEN; u8 extnd_size; __le16 *frame_desc; @@ -41,8 +41,10 @@ int rsi_send_data_pkt(struct rsi_common *common, struct sk_buff *skb) bss = &info->control.vif->bss_conf; tx_params = (struct skb_info *)info->driver_data; - if (!bss->assoc) + if (!bss->assoc) { + status = -EINVAL; goto err; + } tmp_hdr = (struct ieee80211_hdr *)&skb->data[0]; seq_num = (le16_to_cpu(tmp_hdr->seq_ctrl) >> 4); @@ -97,7 +99,7 @@ int rsi_send_data_pkt(struct rsi_common *common, struct sk_buff *skb) frame_desc[7] = cpu_to_le16(((tx_params->tid & 0xf) << 4) | (skb->priority & 0xf) | (tx_params->sta_id << 8)); - + adapter = common->priv; status = adapter->host_intf_write_pkt(common->priv, skb->data, skb->len); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH v3 3/3] rsi: Replace variable initialisations by assignments in rsi_send_data_pkt() @ 2016-01-15 13:12 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-15 13:12 UTC (permalink / raw) To: linux-wireless, netdev, Fariya Fatima, Jahnavi Meher, Kalle Valo Cc: LKML, kernel-janitors, Julia Lawall, John W. Linville From: Markus Elfring <elfring@users.sourceforge.net> Date: Fri, 15 Jan 2016 13:40:22 +0100 Replace explicit initialisation for two local variables at the beginning by assignments. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/wireless/rsi/rsi_91x_pkt.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/rsi/rsi_91x_pkt.c b/drivers/net/wireless/rsi/rsi_91x_pkt.c index 4322df1..2c18c01 100644 --- a/drivers/net/wireless/rsi/rsi_91x_pkt.c +++ b/drivers/net/wireless/rsi/rsi_91x_pkt.c @@ -26,12 +26,12 @@ */ int rsi_send_data_pkt(struct rsi_common *common, struct sk_buff *skb) { - struct rsi_hw *adapter = common->priv; + struct rsi_hw *adapter; struct ieee80211_hdr *tmp_hdr; struct ieee80211_tx_info *info; struct skb_info *tx_params; struct ieee80211_bss_conf *bss; - int status = -EINVAL; + int status; u8 ieee80211_size = MIN_802_11_HDR_LEN; u8 extnd_size; __le16 *frame_desc; @@ -41,8 +41,10 @@ int rsi_send_data_pkt(struct rsi_common *common, struct sk_buff *skb) bss = &info->control.vif->bss_conf; tx_params = (struct skb_info *)info->driver_data; - if (!bss->assoc) + if (!bss->assoc) { + status = -EINVAL; goto err; + } tmp_hdr = (struct ieee80211_hdr *)&skb->data[0]; seq_num = (le16_to_cpu(tmp_hdr->seq_ctrl) >> 4); @@ -97,7 +99,7 @@ int rsi_send_data_pkt(struct rsi_common *common, struct sk_buff *skb) frame_desc[7] = cpu_to_le16(((tx_params->tid & 0xf) << 4) | (skb->priority & 0xf) | (tx_params->sta_id << 8)); - + adapter = common->priv; status = adapter->host_intf_write_pkt(common->priv, skb->data, skb->len); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH v3 3/3] rsi: Replace variable initialisations by assignments in rsi_send_data_pkt() 2016-01-15 13:12 ` SF Markus Elfring @ 2016-01-19 12:40 ` Dan Carpenter -1 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2016-01-19 12:40 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-wireless, netdev, Fariya Fatima, Jahnavi Meher, Kalle Valo, LKML, kernel-janitors, Julia Lawall, John W. Linville Still makes no sense for adapter like Francois Romieu said. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH v3 3/3] rsi: Replace variable initialisations by assignments in rsi_send_data_pkt() @ 2016-01-19 12:40 ` Dan Carpenter 0 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2016-01-19 12:40 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-wireless, netdev, Fariya Fatima, Jahnavi Meher, Kalle Valo, LKML, kernel-janitors, Julia Lawall, John W. Linville Still makes no sense for adapter like Francois Romieu said. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/5] xen-netback: Fine-tuning for three function implementations 2015-12-11 12:08 ` SF Markus Elfring @ 2016-01-02 17:50 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 17:50 UTC (permalink / raw) To: xen-devel, netdev, Ian Campbell, Wei Liu Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jan 2016 18:46:45 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (5): Delete an unnecessary assignment in connect_rings() Delete an unnecessary goto statement in connect_rings() Replace a variable initialisation by an assignment in read_xenbus_vif_flags() Replace a variable initialisation by an assignment in xen_register_watchers() Delete an unnecessary variable initialisation in xen_register_watchers() drivers/net/xen-netback/xenbus.c | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/5] xen-netback: Fine-tuning for three function implementations @ 2016-01-02 17:50 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 17:50 UTC (permalink / raw) To: xen-devel, netdev, Ian Campbell, Wei Liu Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jan 2016 18:46:45 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (5): Delete an unnecessary assignment in connect_rings() Delete an unnecessary goto statement in connect_rings() Replace a variable initialisation by an assignment in read_xenbus_vif_flags() Replace a variable initialisation by an assignment in xen_register_watchers() Delete an unnecessary variable initialisation in xen_register_watchers() drivers/net/xen-netback/xenbus.c | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 1/5] xen-netback: Delete an unnecessary assignment in connect_rings() 2016-01-02 17:50 ` SF Markus Elfring (?) @ 2016-01-02 17:54 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 17:54 UTC (permalink / raw) To: xen-devel, netdev, Ian Campbell, Wei Liu Cc: Julia Lawall, kernel-janitors, LKML From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jan 2016 17:32:40 +0100 Remove the assignment for a local variable because its value is not changed compared to the one from a previous function call. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/xen-netback/xenbus.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c index 56ebd82..7f2895d 100644 --- a/drivers/net/xen-netback/xenbus.c +++ b/drivers/net/xen-netback/xenbus.c @@ -941,7 +941,6 @@ static int connect_rings(struct backend_info *be, struct xenvif_queue *queue) goto err; } - err = 0; err: /* Regular return falls through with err == 0 */ kfree(xspath); return err; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 1/5] xen-netback: Delete an unnecessary assignment in connect_rings() 2016-01-02 17:50 ` SF Markus Elfring @ 2016-01-02 17:54 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 17:54 UTC (permalink / raw) To: xen-devel, netdev, Ian Campbell, Wei Liu Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jan 2016 17:32:40 +0100 Remove the assignment for a local variable because its value is not changed compared to the one from a previous function call. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/xen-netback/xenbus.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c index 56ebd82..7f2895d 100644 --- a/drivers/net/xen-netback/xenbus.c +++ b/drivers/net/xen-netback/xenbus.c @@ -941,7 +941,6 @@ static int connect_rings(struct backend_info *be, struct xenvif_queue *queue) goto err; } - err = 0; err: /* Regular return falls through with err == 0 */ kfree(xspath); return err; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 1/5] xen-netback: Delete an unnecessary assignment in connect_rings() @ 2016-01-02 17:54 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 17:54 UTC (permalink / raw) To: xen-devel, netdev, Ian Campbell, Wei Liu Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jan 2016 17:32:40 +0100 Remove the assignment for a local variable because its value is not changed compared to the one from a previous function call. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/xen-netback/xenbus.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c index 56ebd82..7f2895d 100644 --- a/drivers/net/xen-netback/xenbus.c +++ b/drivers/net/xen-netback/xenbus.c @@ -941,7 +941,6 @@ static int connect_rings(struct backend_info *be, struct xenvif_queue *queue) goto err; } - err = 0; err: /* Regular return falls through with err = 0 */ kfree(xspath); return err; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 2/5] xen-netback: Delete an unnecessary goto statement in connect_rings() 2016-01-02 17:50 ` SF Markus Elfring ` (2 preceding siblings ...) (?) @ 2016-01-02 17:55 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 17:55 UTC (permalink / raw) To: xen-devel, netdev, Ian Campbell, Wei Liu Cc: Julia Lawall, kernel-janitors, LKML From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jan 2016 17:50:21 +0100 One goto statement referred to a source code position directly behind it. Thus omit such an unnecessary jump. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/xen-netback/xenbus.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c index 7f2895d..d4947e1 100644 --- a/drivers/net/xen-netback/xenbus.c +++ b/drivers/net/xen-netback/xenbus.c @@ -933,13 +933,11 @@ static int connect_rings(struct backend_info *be, struct xenvif_queue *queue) /* Map the shared frame, irq etc. */ err = xenvif_connect(queue, tx_ring_ref, rx_ring_ref, tx_evtchn, rx_evtchn); - if (err) { + if (err) xenbus_dev_fatal(dev, err, "mapping shared-frames %lu/%lu port tx %u rx %u", tx_ring_ref, rx_ring_ref, tx_evtchn, rx_evtchn); - goto err; - } err: /* Regular return falls through with err == 0 */ kfree(xspath); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 2/5] xen-netback: Delete an unnecessary goto statement in connect_rings() 2016-01-02 17:50 ` SF Markus Elfring @ 2016-01-02 17:55 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 17:55 UTC (permalink / raw) To: xen-devel, netdev, Ian Campbell, Wei Liu Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jan 2016 17:50:21 +0100 One goto statement referred to a source code position directly behind it. Thus omit such an unnecessary jump. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/xen-netback/xenbus.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c index 7f2895d..d4947e1 100644 --- a/drivers/net/xen-netback/xenbus.c +++ b/drivers/net/xen-netback/xenbus.c @@ -933,13 +933,11 @@ static int connect_rings(struct backend_info *be, struct xenvif_queue *queue) /* Map the shared frame, irq etc. */ err = xenvif_connect(queue, tx_ring_ref, rx_ring_ref, tx_evtchn, rx_evtchn); - if (err) { + if (err) xenbus_dev_fatal(dev, err, "mapping shared-frames %lu/%lu port tx %u rx %u", tx_ring_ref, rx_ring_ref, tx_evtchn, rx_evtchn); - goto err; - } err: /* Regular return falls through with err == 0 */ kfree(xspath); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 2/5] xen-netback: Delete an unnecessary goto statement in connect_rings() @ 2016-01-02 17:55 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 17:55 UTC (permalink / raw) To: xen-devel, netdev, Ian Campbell, Wei Liu Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jan 2016 17:50:21 +0100 One goto statement referred to a source code position directly behind it. Thus omit such an unnecessary jump. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/xen-netback/xenbus.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c index 7f2895d..d4947e1 100644 --- a/drivers/net/xen-netback/xenbus.c +++ b/drivers/net/xen-netback/xenbus.c @@ -933,13 +933,11 @@ static int connect_rings(struct backend_info *be, struct xenvif_queue *queue) /* Map the shared frame, irq etc. */ err = xenvif_connect(queue, tx_ring_ref, rx_ring_ref, tx_evtchn, rx_evtchn); - if (err) { + if (err) xenbus_dev_fatal(dev, err, "mapping shared-frames %lu/%lu port tx %u rx %u", tx_ring_ref, rx_ring_ref, tx_evtchn, rx_evtchn); - goto err; - } err: /* Regular return falls through with err = 0 */ kfree(xspath); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 3/5] xen-netback: Replace a variable initialisation by an assignment in read_xenbus_vif_flags() 2016-01-02 17:50 ` SF Markus Elfring ` (4 preceding siblings ...) (?) @ 2016-01-02 17:57 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 17:57 UTC (permalink / raw) To: xen-devel, netdev, Ian Campbell, Wei Liu Cc: Julia Lawall, kernel-janitors, LKML From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jan 2016 18:01:57 +0100 Replace an explicit initialisation for one local variable at the beginning by an assignment. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/xen-netback/xenbus.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c index d4947e1..aff963f 100644 --- a/drivers/net/xen-netback/xenbus.c +++ b/drivers/net/xen-netback/xenbus.c @@ -946,7 +946,7 @@ err: /* Regular return falls through with err == 0 */ static int read_xenbus_vif_flags(struct backend_info *be) { - struct xenvif *vif = be->vif; + struct xenvif *vif; struct xenbus_device *dev = be->dev; unsigned int rx_copy; int err, val; @@ -968,13 +968,14 @@ static int read_xenbus_vif_flags(struct backend_info *be) if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-rx-notify", "%d", &val) < 0) val = 0; + vif = be->vif; if (!val) { /* - Reduce drain timeout to poll more frequently for * Rx requests. * - Disable Rx stall detection. */ - be->vif->drain_timeout = msecs_to_jiffies(30); - be->vif->stall_timeout = 0; + vif->drain_timeout = msecs_to_jiffies(30); + vif->stall_timeout = 0; } if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-sg", -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 3/5] xen-netback: Replace a variable initialisation by an assignment in read_xenbus_vif_flags() 2016-01-02 17:50 ` SF Markus Elfring @ 2016-01-02 17:57 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 17:57 UTC (permalink / raw) To: xen-devel, netdev, Ian Campbell, Wei Liu Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jan 2016 18:01:57 +0100 Replace an explicit initialisation for one local variable at the beginning by an assignment. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/xen-netback/xenbus.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c index d4947e1..aff963f 100644 --- a/drivers/net/xen-netback/xenbus.c +++ b/drivers/net/xen-netback/xenbus.c @@ -946,7 +946,7 @@ err: /* Regular return falls through with err == 0 */ static int read_xenbus_vif_flags(struct backend_info *be) { - struct xenvif *vif = be->vif; + struct xenvif *vif; struct xenbus_device *dev = be->dev; unsigned int rx_copy; int err, val; @@ -968,13 +968,14 @@ static int read_xenbus_vif_flags(struct backend_info *be) if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-rx-notify", "%d", &val) < 0) val = 0; + vif = be->vif; if (!val) { /* - Reduce drain timeout to poll more frequently for * Rx requests. * - Disable Rx stall detection. */ - be->vif->drain_timeout = msecs_to_jiffies(30); - be->vif->stall_timeout = 0; + vif->drain_timeout = msecs_to_jiffies(30); + vif->stall_timeout = 0; } if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-sg", -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 3/5] xen-netback: Replace a variable initialisation by an assignment in read_xenbus_vif_flags @ 2016-01-02 17:57 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 17:57 UTC (permalink / raw) To: xen-devel, netdev, Ian Campbell, Wei Liu Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jan 2016 18:01:57 +0100 Replace an explicit initialisation for one local variable at the beginning by an assignment. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/xen-netback/xenbus.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c index d4947e1..aff963f 100644 --- a/drivers/net/xen-netback/xenbus.c +++ b/drivers/net/xen-netback/xenbus.c @@ -946,7 +946,7 @@ err: /* Regular return falls through with err = 0 */ static int read_xenbus_vif_flags(struct backend_info *be) { - struct xenvif *vif = be->vif; + struct xenvif *vif; struct xenbus_device *dev = be->dev; unsigned int rx_copy; int err, val; @@ -968,13 +968,14 @@ static int read_xenbus_vif_flags(struct backend_info *be) if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-rx-notify", "%d", &val) < 0) val = 0; + vif = be->vif; if (!val) { /* - Reduce drain timeout to poll more frequently for * Rx requests. * - Disable Rx stall detection. */ - be->vif->drain_timeout = msecs_to_jiffies(30); - be->vif->stall_timeout = 0; + vif->drain_timeout = msecs_to_jiffies(30); + vif->stall_timeout = 0; } if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-sg", -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 4/5] xen-netback: Replace a variable initialisation by an assignment in xen_register_watchers() 2016-01-02 17:50 ` SF Markus Elfring ` (6 preceding siblings ...) (?) @ 2016-01-02 17:58 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 17:58 UTC (permalink / raw) To: xen-devel, netdev, Ian Campbell, Wei Liu Cc: Julia Lawall, kernel-janitors, LKML From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jan 2016 18:23:16 +0100 Replace an explicit initialisation for one local variable at the beginning by an assignment. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/xen-netback/xenbus.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c index aff963f..e8dfc3d 100644 --- a/drivers/net/xen-netback/xenbus.c +++ b/drivers/net/xen-netback/xenbus.c @@ -687,11 +687,12 @@ static int xen_register_watchers(struct xenbus_device *dev, struct xenvif *vif) { int err = 0; char *node; - unsigned maxlen = strlen(dev->nodename) + sizeof("/rate"); + unsigned maxlen; if (vif->credit_watch.node) return -EADDRINUSE; + maxlen = strlen(dev->nodename) + sizeof("/rate"); node = kmalloc(maxlen, GFP_KERNEL); if (!node) return -ENOMEM; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 4/5] xen-netback: Replace a variable initialisation by an assignment in xen_register_watchers() 2016-01-02 17:50 ` SF Markus Elfring @ 2016-01-02 17:58 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 17:58 UTC (permalink / raw) To: xen-devel, netdev, Ian Campbell, Wei Liu Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jan 2016 18:23:16 +0100 Replace an explicit initialisation for one local variable at the beginning by an assignment. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/xen-netback/xenbus.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c index aff963f..e8dfc3d 100644 --- a/drivers/net/xen-netback/xenbus.c +++ b/drivers/net/xen-netback/xenbus.c @@ -687,11 +687,12 @@ static int xen_register_watchers(struct xenbus_device *dev, struct xenvif *vif) { int err = 0; char *node; - unsigned maxlen = strlen(dev->nodename) + sizeof("/rate"); + unsigned maxlen; if (vif->credit_watch.node) return -EADDRINUSE; + maxlen = strlen(dev->nodename) + sizeof("/rate"); node = kmalloc(maxlen, GFP_KERNEL); if (!node) return -ENOMEM; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 4/5] xen-netback: Replace a variable initialisation by an assignment in xen_register_watchers @ 2016-01-02 17:58 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 17:58 UTC (permalink / raw) To: xen-devel, netdev, Ian Campbell, Wei Liu Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jan 2016 18:23:16 +0100 Replace an explicit initialisation for one local variable at the beginning by an assignment. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/xen-netback/xenbus.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c index aff963f..e8dfc3d 100644 --- a/drivers/net/xen-netback/xenbus.c +++ b/drivers/net/xen-netback/xenbus.c @@ -687,11 +687,12 @@ static int xen_register_watchers(struct xenbus_device *dev, struct xenvif *vif) { int err = 0; char *node; - unsigned maxlen = strlen(dev->nodename) + sizeof("/rate"); + unsigned maxlen; if (vif->credit_watch.node) return -EADDRINUSE; + maxlen = strlen(dev->nodename) + sizeof("/rate"); node = kmalloc(maxlen, GFP_KERNEL); if (!node) return -ENOMEM; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 5/5] xen-netback: Delete an unnecessary variable initialisation in xen_register_watchers() 2016-01-02 17:50 ` SF Markus Elfring ` (8 preceding siblings ...) (?) @ 2016-01-02 18:00 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 18:00 UTC (permalink / raw) To: xen-devel, netdev, Ian Campbell, Wei Liu Cc: Julia Lawall, kernel-janitors, LKML From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jan 2016 18:28:26 +0100 Omit explicit initialisation at the beginning for one local variable that is redefined before its first use. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/xen-netback/xenbus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c index e8dfc3d..55f0735 100644 --- a/drivers/net/xen-netback/xenbus.c +++ b/drivers/net/xen-netback/xenbus.c @@ -685,7 +685,7 @@ static void xen_net_rate_changed(struct xenbus_watch *watch, static int xen_register_watchers(struct xenbus_device *dev, struct xenvif *vif) { - int err = 0; + int err; char *node; unsigned maxlen; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 5/5] xen-netback: Delete an unnecessary variable initialisation in xen_register_watchers() 2016-01-02 17:50 ` SF Markus Elfring @ 2016-01-02 18:00 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 18:00 UTC (permalink / raw) To: xen-devel, netdev, Ian Campbell, Wei Liu Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jan 2016 18:28:26 +0100 Omit explicit initialisation at the beginning for one local variable that is redefined before its first use. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/xen-netback/xenbus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c index e8dfc3d..55f0735 100644 --- a/drivers/net/xen-netback/xenbus.c +++ b/drivers/net/xen-netback/xenbus.c @@ -685,7 +685,7 @@ static void xen_net_rate_changed(struct xenbus_watch *watch, static int xen_register_watchers(struct xenbus_device *dev, struct xenvif *vif) { - int err = 0; + int err; char *node; unsigned maxlen; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 5/5] xen-netback: Delete an unnecessary variable initialisation in xen_register_watchers() @ 2016-01-02 18:00 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 18:00 UTC (permalink / raw) To: xen-devel, netdev, Ian Campbell, Wei Liu Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jan 2016 18:28:26 +0100 Omit explicit initialisation at the beginning for one local variable that is redefined before its first use. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/net/xen-netback/xenbus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c index e8dfc3d..55f0735 100644 --- a/drivers/net/xen-netback/xenbus.c +++ b/drivers/net/xen-netback/xenbus.c @@ -685,7 +685,7 @@ static void xen_net_rate_changed(struct xenbus_watch *watch, static int xen_register_watchers(struct xenbus_device *dev, struct xenvif *vif) { - int err = 0; + int err; char *node; unsigned maxlen; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/5] xen-netback: Fine-tuning for three function implementations 2016-01-02 17:50 ` SF Markus Elfring @ 2016-01-03 1:34 ` Joe Perches -1 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2016-01-03 1:34 UTC (permalink / raw) To: SF Markus Elfring, xen-devel, netdev, Ian Campbell, Wei Liu Cc: LKML, kernel-janitors, Julia Lawall On Sat, 2016-01-02 at 18:50 +0100, SF Markus Elfring wrote: > A few update suggestions were taken into account > from static source code analysis. While static analysis can be useful, I don't think these specific conversions are generally useful. Perhaps it would be more useful to convert the string duplication or snprintf logic to kstrdup/kasprintf This: if (num_queues == 1) { xspath = kzalloc(strlen(dev->otherend) + 1, GFP_KERNEL); if (!xspath) { xenbus_dev_fatal(dev, -ENOMEM, "reading ring references"); return -ENOMEM; } strcpy(xspath, dev->otherend); } else { xspathsize = strlen(dev->otherend) + xenstore_path_ext_size; xspath = kzalloc(xspathsize, GFP_KERNEL); if (!xspath) { xenbus_dev_fatal(dev, -ENOMEM, "reading ring references"); return -ENOMEM; } snprintf(xspath, xspathsize, "%s/queue-%u", dev->otherend, queue->id); } could be simplified to something like: if (num_queues == 1) xspath = kstrdup(dev->otherend, GFP_KERNEL); else xspath = kasprintf(GFP_KERNEL, "%s/queue-%u", dev->otherend, queue->id); if (!xspath) etc... ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/5] xen-netback: Fine-tuning for three function implementations @ 2016-01-03 1:34 ` Joe Perches 0 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2016-01-03 1:34 UTC (permalink / raw) To: SF Markus Elfring, xen-devel, netdev, Ian Campbell, Wei Liu Cc: LKML, kernel-janitors, Julia Lawall On Sat, 2016-01-02 at 18:50 +0100, SF Markus Elfring wrote: > A few update suggestions were taken into account > from static source code analysis. While static analysis can be useful, I don't think these specific conversions are generally useful. Perhaps it would be more useful to convert the string duplication or snprintf logic to kstrdup/kasprintf This: if (num_queues = 1) { xspath = kzalloc(strlen(dev->otherend) + 1, GFP_KERNEL); if (!xspath) { xenbus_dev_fatal(dev, -ENOMEM, "reading ring references"); return -ENOMEM; } strcpy(xspath, dev->otherend); } else { xspathsize = strlen(dev->otherend) + xenstore_path_ext_size; xspath = kzalloc(xspathsize, GFP_KERNEL); if (!xspath) { xenbus_dev_fatal(dev, -ENOMEM, "reading ring references"); return -ENOMEM; } snprintf(xspath, xspathsize, "%s/queue-%u", dev->otherend, queue->id); } could be simplified to something like: if (num_queues = 1) xspath = kstrdup(dev->otherend, GFP_KERNEL); else xspath = kasprintf(GFP_KERNEL, "%s/queue-%u", dev->otherend, queue->id); if (!xspath) etc... -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/5] xen-netback: Fine-tuning for three function implementations 2016-01-02 17:50 ` SF Markus Elfring ` (11 preceding siblings ...) (?) @ 2016-01-03 1:34 ` Joe Perches -1 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2016-01-03 1:34 UTC (permalink / raw) To: SF Markus Elfring, xen-devel, netdev, Ian Campbell, Wei Liu Cc: Julia Lawall, kernel-janitors, LKML On Sat, 2016-01-02 at 18:50 +0100, SF Markus Elfring wrote: > A few update suggestions were taken into account > from static source code analysis. While static analysis can be useful, I don't think these specific conversions are generally useful. Perhaps it would be more useful to convert the string duplication or snprintf logic to kstrdup/kasprintf This: if (num_queues == 1) { xspath = kzalloc(strlen(dev->otherend) + 1, GFP_KERNEL); if (!xspath) { xenbus_dev_fatal(dev, -ENOMEM, "reading ring references"); return -ENOMEM; } strcpy(xspath, dev->otherend); } else { xspathsize = strlen(dev->otherend) + xenstore_path_ext_size; xspath = kzalloc(xspathsize, GFP_KERNEL); if (!xspath) { xenbus_dev_fatal(dev, -ENOMEM, "reading ring references"); return -ENOMEM; } snprintf(xspath, xspathsize, "%s/queue-%u", dev->otherend, queue->id); } could be simplified to something like: if (num_queues == 1) xspath = kstrdup(dev->otherend, GFP_KERNEL); else xspath = kasprintf(GFP_KERNEL, "%s/queue-%u", dev->otherend, queue->id); if (!xspath) etc... ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/5] xen-netback: Fine-tuning for three function implementations 2016-01-02 17:50 ` SF Markus Elfring @ 2016-01-04 9:40 ` Dan Carpenter -1 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2016-01-04 9:40 UTC (permalink / raw) To: SF Markus Elfring Cc: xen-devel, netdev, Ian Campbell, Wei Liu, LKML, kernel-janitors, Julia Lawall The original code is fine. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/5] xen-netback: Fine-tuning for three function implementations @ 2016-01-04 9:40 ` Dan Carpenter 0 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2016-01-04 9:40 UTC (permalink / raw) To: SF Markus Elfring Cc: xen-devel, netdev, Ian Campbell, Wei Liu, LKML, kernel-janitors, Julia Lawall The original code is fine. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/5] xen-netback: Fine-tuning for three function implementations 2016-01-02 17:50 ` SF Markus Elfring ` (13 preceding siblings ...) (?) @ 2016-01-04 9:40 ` Dan Carpenter -1 siblings, 0 replies; 3089+ messages in thread From: Dan Carpenter @ 2016-01-04 9:40 UTC (permalink / raw) To: SF Markus Elfring Cc: Wei Liu, Ian Campbell, netdev, kernel-janitors, LKML, Julia Lawall, xen-devel The original code is fine. regards, dan carpenter ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/5] xen-netback: Fine-tuning for three function implementations 2016-01-02 17:50 ` SF Markus Elfring ` (14 preceding siblings ...) (?) @ 2016-01-04 11:08 ` Wei Liu -1 siblings, 0 replies; 3089+ messages in thread From: Wei Liu @ 2016-01-04 11:08 UTC (permalink / raw) To: SF Markus Elfring Cc: Wei Liu, Ian Campbell, netdev, kernel-janitors, LKML, Julia Lawall, xen-devel I think the original code is fine. Wei. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/5] xen-netback: Fine-tuning for three function implementations 2016-01-02 17:50 ` SF Markus Elfring @ 2016-01-04 11:08 ` Wei Liu -1 siblings, 0 replies; 3089+ messages in thread From: Wei Liu @ 2016-01-04 11:08 UTC (permalink / raw) To: SF Markus Elfring Cc: xen-devel, netdev, Ian Campbell, Wei Liu, LKML, kernel-janitors, Julia Lawall I think the original code is fine. Wei. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/5] xen-netback: Fine-tuning for three function implementations @ 2016-01-04 11:08 ` Wei Liu 0 siblings, 0 replies; 3089+ messages in thread From: Wei Liu @ 2016-01-04 11:08 UTC (permalink / raw) To: SF Markus Elfring Cc: xen-devel, netdev, Ian Campbell, Wei Liu, LKML, kernel-janitors, Julia Lawall I think the original code is fine. Wei. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/5] xen-netback: Fine-tuning for three function implementations 2015-12-11 12:08 ` SF Markus Elfring ` (45 preceding siblings ...) (?) @ 2016-01-02 17:50 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 17:50 UTC (permalink / raw) To: xen-devel, netdev, Ian Campbell, Wei Liu Cc: Julia Lawall, kernel-janitors, LKML From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jan 2016 18:46:45 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (5): Delete an unnecessary assignment in connect_rings() Delete an unnecessary goto statement in connect_rings() Replace a variable initialisation by an assignment in read_xenbus_vif_flags() Replace a variable initialisation by an assignment in xen_register_watchers() Delete an unnecessary variable initialisation in xen_register_watchers() drivers/net/xen-netback/xenbus.c | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/3] NFC-mei_phy: Fine-tuning for two function implementations 2015-12-11 12:08 ` SF Markus Elfring @ 2016-01-02 20:51 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 20:51 UTC (permalink / raw) To: linux-wireless, Aloisio Almeida Jr, Lauro Ramos Venancio, Samuel Ortiz Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jan 2016 21:47:30 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (3): Refactoring for mei_nfc_connect() Refactoring for mei_nfc_if_version() Delete an unnecessary variable initialisation in mei_nfc_if_version() drivers/nfc/mei_phy.c | 20 +++++++++----------- 1 file changed, 9 insertions(+), 11 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/3] NFC-mei_phy: Fine-tuning for two function implementations @ 2016-01-02 20:51 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 20:51 UTC (permalink / raw) To: linux-wireless, Aloisio Almeida Jr, Lauro Ramos Venancio, Samuel Ortiz Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jan 2016 21:47:30 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (3): Refactoring for mei_nfc_connect() Refactoring for mei_nfc_if_version() Delete an unnecessary variable initialisation in mei_nfc_if_version() drivers/nfc/mei_phy.c | 20 +++++++++----------- 1 file changed, 9 insertions(+), 11 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 1/3] NFC-mei_phy: Refactoring for mei_nfc_connect() 2016-01-02 20:51 ` SF Markus Elfring @ 2016-01-02 20:54 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 20:54 UTC (permalink / raw) To: linux-wireless, Aloisio Almeida Jr, Lauro Ramos Venancio, Samuel Ortiz Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jan 2016 21:21:24 +0100 This issue was detected by using the Coccinelle software. Adjust jump targets according to the current Linux coding style convention. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/nfc/mei_phy.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/drivers/nfc/mei_phy.c b/drivers/nfc/mei_phy.c index 83deda4..8e3a69f 100644 --- a/drivers/nfc/mei_phy.c +++ b/drivers/nfc/mei_phy.c @@ -173,8 +173,8 @@ static int mei_nfc_connect(struct nfc_mei_phy *phy) reply = kzalloc(connect_resp_length, GFP_KERNEL); if (!reply) { - kfree(cmd); - return -ENOMEM; + r = -ENOMEM; + goto free_cmd; } connect_resp = (struct mei_nfc_connect_resp *)reply->data; @@ -189,7 +189,7 @@ static int mei_nfc_connect(struct nfc_mei_phy *phy) r = mei_cldev_send(phy->cldev, (u8 *)cmd, connect_length); if (r < 0) { pr_err("Could not send connect cmd %d\n", r); - goto err; + goto free_reply; } bytes_recv = mei_cldev_recv(phy->cldev, (u8 *)reply, @@ -197,7 +197,7 @@ static int mei_nfc_connect(struct nfc_mei_phy *phy) if (bytes_recv < 0) { r = bytes_recv; pr_err("Could not read connect response %d\n", r); - goto err; + goto free_reply; } MEI_DUMP_NFC_HDR("connect reply", &reply->hdr); @@ -210,11 +210,10 @@ static int mei_nfc_connect(struct nfc_mei_phy *phy) connect_resp->me_hotfix, connect_resp->me_build); r = 0; - -err: +free_reply: kfree(reply); +free_cmd: kfree(cmd); - return r; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 1/3] NFC-mei_phy: Refactoring for mei_nfc_connect() @ 2016-01-02 20:54 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 20:54 UTC (permalink / raw) To: linux-wireless, Aloisio Almeida Jr, Lauro Ramos Venancio, Samuel Ortiz Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jan 2016 21:21:24 +0100 This issue was detected by using the Coccinelle software. Adjust jump targets according to the current Linux coding style convention. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/nfc/mei_phy.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/drivers/nfc/mei_phy.c b/drivers/nfc/mei_phy.c index 83deda4..8e3a69f 100644 --- a/drivers/nfc/mei_phy.c +++ b/drivers/nfc/mei_phy.c @@ -173,8 +173,8 @@ static int mei_nfc_connect(struct nfc_mei_phy *phy) reply = kzalloc(connect_resp_length, GFP_KERNEL); if (!reply) { - kfree(cmd); - return -ENOMEM; + r = -ENOMEM; + goto free_cmd; } connect_resp = (struct mei_nfc_connect_resp *)reply->data; @@ -189,7 +189,7 @@ static int mei_nfc_connect(struct nfc_mei_phy *phy) r = mei_cldev_send(phy->cldev, (u8 *)cmd, connect_length); if (r < 0) { pr_err("Could not send connect cmd %d\n", r); - goto err; + goto free_reply; } bytes_recv = mei_cldev_recv(phy->cldev, (u8 *)reply, @@ -197,7 +197,7 @@ static int mei_nfc_connect(struct nfc_mei_phy *phy) if (bytes_recv < 0) { r = bytes_recv; pr_err("Could not read connect response %d\n", r); - goto err; + goto free_reply; } MEI_DUMP_NFC_HDR("connect reply", &reply->hdr); @@ -210,11 +210,10 @@ static int mei_nfc_connect(struct nfc_mei_phy *phy) connect_resp->me_hotfix, connect_resp->me_build); r = 0; - -err: +free_reply: kfree(reply); +free_cmd: kfree(cmd); - return r; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/3] NFC-mei_phy: Refactoring for mei_nfc_connect() 2016-01-02 20:54 ` SF Markus Elfring @ 2016-01-02 23:41 ` Julian Calaby -1 siblings, 0 replies; 3089+ messages in thread From: Julian Calaby @ 2016-01-02 23:41 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-wireless, Aloisio Almeida Jr, Lauro Ramos Venancio, Samuel Ortiz, LKML, kernel-janitors, Julia Lawall Hi Markus, On Sun, Jan 3, 2016 at 7:54 AM, SF Markus Elfring <elfring@users.sourceforge.net> wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sat, 2 Jan 2016 21:21:24 +0100 > > This issue was detected by using the Coccinelle software. > > Adjust jump targets according to the current Linux coding style convention. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/nfc/mei_phy.c | 13 ++++++------- > 1 file changed, 6 insertions(+), 7 deletions(-) > > diff --git a/drivers/nfc/mei_phy.c b/drivers/nfc/mei_phy.c > index 83deda4..8e3a69f 100644 > --- a/drivers/nfc/mei_phy.c > +++ b/drivers/nfc/mei_phy.c > @@ -173,8 +173,8 @@ static int mei_nfc_connect(struct nfc_mei_phy *phy) > > reply = kzalloc(connect_resp_length, GFP_KERNEL); > if (!reply) { > - kfree(cmd); > - return -ENOMEM; > + r = -ENOMEM; > + goto free_cmd; > } > > connect_resp = (struct mei_nfc_connect_resp *)reply->data; > @@ -189,7 +189,7 @@ static int mei_nfc_connect(struct nfc_mei_phy *phy) > r = mei_cldev_send(phy->cldev, (u8 *)cmd, connect_length); > if (r < 0) { > pr_err("Could not send connect cmd %d\n", r); > - goto err; > + goto free_reply; > } > > bytes_recv = mei_cldev_recv(phy->cldev, (u8 *)reply, > @@ -197,7 +197,7 @@ static int mei_nfc_connect(struct nfc_mei_phy *phy) > if (bytes_recv < 0) { > r = bytes_recv; > pr_err("Could not read connect response %d\n", r); > - goto err; > + goto free_reply; > } > > MEI_DUMP_NFC_HDR("connect reply", &reply->hdr); > @@ -210,11 +210,10 @@ static int mei_nfc_connect(struct nfc_mei_phy *phy) > connect_resp->me_hotfix, connect_resp->me_build); > > r = 0; > - > -err: > +free_reply: > kfree(reply); > +free_cmd: > kfree(cmd); > - Why are you deleting the two blank lines here? Thanks, -- Julian Calaby Email: julian.calaby@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/3] NFC-mei_phy: Refactoring for mei_nfc_connect() @ 2016-01-02 23:41 ` Julian Calaby 0 siblings, 0 replies; 3089+ messages in thread From: Julian Calaby @ 2016-01-02 23:41 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-wireless, Aloisio Almeida Jr, Lauro Ramos Venancio, Samuel Ortiz, LKML, kernel-janitors, Julia Lawall Hi Markus, On Sun, Jan 3, 2016 at 7:54 AM, SF Markus Elfring <elfring@users.sourceforge.net> wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sat, 2 Jan 2016 21:21:24 +0100 > > This issue was detected by using the Coccinelle software. > > Adjust jump targets according to the current Linux coding style convention. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/nfc/mei_phy.c | 13 ++++++------- > 1 file changed, 6 insertions(+), 7 deletions(-) > > diff --git a/drivers/nfc/mei_phy.c b/drivers/nfc/mei_phy.c > index 83deda4..8e3a69f 100644 > --- a/drivers/nfc/mei_phy.c > +++ b/drivers/nfc/mei_phy.c > @@ -173,8 +173,8 @@ static int mei_nfc_connect(struct nfc_mei_phy *phy) > > reply = kzalloc(connect_resp_length, GFP_KERNEL); > if (!reply) { > - kfree(cmd); > - return -ENOMEM; > + r = -ENOMEM; > + goto free_cmd; > } > > connect_resp = (struct mei_nfc_connect_resp *)reply->data; > @@ -189,7 +189,7 @@ static int mei_nfc_connect(struct nfc_mei_phy *phy) > r = mei_cldev_send(phy->cldev, (u8 *)cmd, connect_length); > if (r < 0) { > pr_err("Could not send connect cmd %d\n", r); > - goto err; > + goto free_reply; > } > > bytes_recv = mei_cldev_recv(phy->cldev, (u8 *)reply, > @@ -197,7 +197,7 @@ static int mei_nfc_connect(struct nfc_mei_phy *phy) > if (bytes_recv < 0) { > r = bytes_recv; > pr_err("Could not read connect response %d\n", r); > - goto err; > + goto free_reply; > } > > MEI_DUMP_NFC_HDR("connect reply", &reply->hdr); > @@ -210,11 +210,10 @@ static int mei_nfc_connect(struct nfc_mei_phy *phy) > connect_resp->me_hotfix, connect_resp->me_build); > > r = 0; > - > -err: > +free_reply: > kfree(reply); > +free_cmd: > kfree(cmd); > - Why are you deleting the two blank lines here? Thanks, -- Julian Calaby Email: julian.calaby@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/3] NFC-mei_phy: Refactoring for mei_nfc_connect() 2016-01-02 23:41 ` Julian Calaby @ 2016-01-03 7:00 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 7:00 UTC (permalink / raw) To: Julian Calaby Cc: linux-wireless, Aloisio Almeida Jr, Lauro Ramos Venancio, Samuel Ortiz, LKML, kernel-janitors, Julia Lawall >> r = 0; >> - >> -err: >> +free_reply: >> kfree(reply); >> +free_cmd: >> kfree(cmd); >> - > > Why are you deleting the two blank lines here? Can they be unnecessary at this source code place according to the Linux coding style convention? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/3] NFC-mei_phy: Refactoring for mei_nfc_connect() @ 2016-01-03 7:00 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 7:00 UTC (permalink / raw) To: Julian Calaby Cc: linux-wireless, Aloisio Almeida Jr, Lauro Ramos Venancio, Samuel Ortiz, LKML, kernel-janitors, Julia Lawall >> r = 0; >> - >> -err: >> +free_reply: >> kfree(reply); >> +free_cmd: >> kfree(cmd); >> - > > Why are you deleting the two blank lines here? Can they be unnecessary at this source code place according to the Linux coding style convention? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/3] NFC-mei_phy: Refactoring for mei_nfc_connect() 2016-01-03 7:00 ` SF Markus Elfring @ 2016-01-03 7:29 ` Joe Perches -1 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2016-01-03 7:29 UTC (permalink / raw) To: SF Markus Elfring, Julian Calaby Cc: linux-wireless, Aloisio Almeida Jr, Lauro Ramos Venancio, Samuel Ortiz, LKML, kernel-janitors, Julia Lawall On Sun, 2016-01-03 at 08:00 +0100, SF Markus Elfring wrote: > > > r = 0; > > > - > > > -err: > > > +free_reply: > > > kfree(reply); > > > +free_cmd: > > > kfree(cmd); > > > - > > > > Why are you deleting the two blank lines here? > > Can they be unnecessary at this source code place > according to the Linux coding style convention? As far as I know, there's no linux specific accepted convention for blank lines preceding labels. My personal preference is for a blank line before a new block, but not before the second and subsequent labels in an error handling block. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/3] NFC-mei_phy: Refactoring for mei_nfc_connect() @ 2016-01-03 7:29 ` Joe Perches 0 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2016-01-03 7:29 UTC (permalink / raw) To: SF Markus Elfring, Julian Calaby Cc: linux-wireless, Aloisio Almeida Jr, Lauro Ramos Venancio, Samuel Ortiz, LKML, kernel-janitors, Julia Lawall On Sun, 2016-01-03 at 08:00 +0100, SF Markus Elfring wrote: > > > r = 0; > > > - > > > -err: > > > +free_reply: > > > kfree(reply); > > > +free_cmd: > > > kfree(cmd); > > > - > > > > Why are you deleting the two blank lines here? > > Can they be unnecessary at this source code place > according to the Linux coding style convention? As far as I know, there's no linux specific accepted convention for blank lines preceding labels. My personal preference is for a blank line before a new block, but not before the second and subsequent labels in an error handling block. -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 2/3] NFC-mei_phy: Refactoring for mei_nfc_if_version() 2016-01-02 20:51 ` SF Markus Elfring @ 2016-01-02 20:55 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 20:55 UTC (permalink / raw) To: linux-wireless, Aloisio Almeida Jr, Lauro Ramos Venancio, Samuel Ortiz Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jan 2016 21:33:04 +0100 Rename a jump label according to the current Linux coding style convention. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/nfc/mei_phy.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/nfc/mei_phy.c b/drivers/nfc/mei_phy.c index 8e3a69f..3c74028 100644 --- a/drivers/nfc/mei_phy.c +++ b/drivers/nfc/mei_phy.c @@ -136,7 +136,7 @@ static int mei_nfc_if_version(struct nfc_mei_phy *phy) if (bytes_recv < 0 || bytes_recv < sizeof(struct mei_nfc_reply)) { pr_err("Could not read IF version\n"); r = -EIO; - goto err; + goto free_reply; } version = (struct mei_nfc_if_version *)reply->data; @@ -144,8 +144,7 @@ static int mei_nfc_if_version(struct nfc_mei_phy *phy) phy->fw_ivn = version->fw_ivn; phy->vendor_id = version->vendor_id; phy->radio_type = version->radio_type; - -err: +free_reply: kfree(reply); return r; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 2/3] NFC-mei_phy: Refactoring for mei_nfc_if_version() @ 2016-01-02 20:55 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 20:55 UTC (permalink / raw) To: linux-wireless, Aloisio Almeida Jr, Lauro Ramos Venancio, Samuel Ortiz Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jan 2016 21:33:04 +0100 Rename a jump label according to the current Linux coding style convention. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/nfc/mei_phy.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/nfc/mei_phy.c b/drivers/nfc/mei_phy.c index 8e3a69f..3c74028 100644 --- a/drivers/nfc/mei_phy.c +++ b/drivers/nfc/mei_phy.c @@ -136,7 +136,7 @@ static int mei_nfc_if_version(struct nfc_mei_phy *phy) if (bytes_recv < 0 || bytes_recv < sizeof(struct mei_nfc_reply)) { pr_err("Could not read IF version\n"); r = -EIO; - goto err; + goto free_reply; } version = (struct mei_nfc_if_version *)reply->data; @@ -144,8 +144,7 @@ static int mei_nfc_if_version(struct nfc_mei_phy *phy) phy->fw_ivn = version->fw_ivn; phy->vendor_id = version->vendor_id; phy->radio_type = version->radio_type; - -err: +free_reply: kfree(reply); return r; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 3/3] NFC-mei_phy: Delete an unnecessary variable initialisation in mei_nfc_if_version() 2016-01-02 20:51 ` SF Markus Elfring @ 2016-01-02 20:56 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 20:56 UTC (permalink / raw) To: linux-wireless, Aloisio Almeida Jr, Lauro Ramos Venancio, Samuel Ortiz Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jan 2016 21:40:10 +0100 Omit explicit initialisation at the beginning for one local variable that is redefined before its first use. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/nfc/mei_phy.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/nfc/mei_phy.c b/drivers/nfc/mei_phy.c index 3c74028..99fd87d 100644 --- a/drivers/nfc/mei_phy.c +++ b/drivers/nfc/mei_phy.c @@ -105,7 +105,7 @@ static int mei_nfc_if_version(struct nfc_mei_phy *phy) { struct mei_nfc_cmd cmd; - struct mei_nfc_reply *reply = NULL; + struct mei_nfc_reply *reply; struct mei_nfc_if_version *version; size_t if_version_length; int bytes_recv, r; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 3/3] NFC-mei_phy: Delete an unnecessary variable initialisation in mei_nfc_if_version() @ 2016-01-02 20:56 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-02 20:56 UTC (permalink / raw) To: linux-wireless, Aloisio Almeida Jr, Lauro Ramos Venancio, Samuel Ortiz Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jan 2016 21:40:10 +0100 Omit explicit initialisation at the beginning for one local variable that is redefined before its first use. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/nfc/mei_phy.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/nfc/mei_phy.c b/drivers/nfc/mei_phy.c index 3c74028..99fd87d 100644 --- a/drivers/nfc/mei_phy.c +++ b/drivers/nfc/mei_phy.c @@ -105,7 +105,7 @@ static int mei_nfc_if_version(struct nfc_mei_phy *phy) { struct mei_nfc_cmd cmd; - struct mei_nfc_reply *reply = NULL; + struct mei_nfc_reply *reply; struct mei_nfc_if_version *version; size_t if_version_length; int bytes_recv, r; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 0/8] rtc-ab-b5ze-s3: Fine-tuning for some function implementations 2015-12-11 12:08 ` SF Markus Elfring (?) @ 2016-01-03 8:43 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 8:43 UTC (permalink / raw) To: rtc-linux, Alessandro Zummo, Alexandre Belloni Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 3 Jan 2016 09:37:34 +0100 Several update suggestions were taken into account from static source code analysis. Markus Elfring (8): Better exception handling in abb5zes3_probe() Delete an unnecessary variable in abb5zes3_rtc_set_alarm() Delete an unnecessary variable initialisation in _abb5zes3_rtc_set_timer() Replace a variable initialisation by an assignment in _abb5zes3_rtc_set_alarm() Replace a variable initialisation by an assignment in _abb5zes3_rtc_read_alarm() Delete an unnecessary variable in _abb5zes3_rtc_read_timer() Delete an unnecessary variable in _abb5zes3_rtc_interrupt() Delete an unnecessary variable in _abb5zes3_rtc_set_timer() drivers/rtc/rtc-ab-b5ze-s3.c | 59 ++++++++++++++++++++------------------------ 1 file changed, 27 insertions(+), 32 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/8] rtc-ab-b5ze-s3: Fine-tuning for some function implementations @ 2016-01-03 8:43 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 8:43 UTC (permalink / raw) To: rtc-linux, Alessandro Zummo, Alexandre Belloni Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 3 Jan 2016 09:37:34 +0100 Several update suggestions were taken into account from static source code analysis. Markus Elfring (8): Better exception handling in abb5zes3_probe() Delete an unnecessary variable in abb5zes3_rtc_set_alarm() Delete an unnecessary variable initialisation in _abb5zes3_rtc_set_timer() Replace a variable initialisation by an assignment in _abb5zes3_rtc_set_alarm() Replace a variable initialisation by an assignment in _abb5zes3_rtc_read_alarm() Delete an unnecessary variable in _abb5zes3_rtc_read_timer() Delete an unnecessary variable in _abb5zes3_rtc_interrupt() Delete an unnecessary variable in _abb5zes3_rtc_set_timer() drivers/rtc/rtc-ab-b5ze-s3.c | 59 ++++++++++++++++++++------------------------ 1 file changed, 27 insertions(+), 32 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [rtc-linux] [PATCH 0/8] rtc-ab-b5ze-s3: Fine-tuning for some function implementations @ 2016-01-03 8:43 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 8:43 UTC (permalink / raw) To: rtc-linux, Alessandro Zummo, Alexandre Belloni Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 3 Jan 2016 09:37:34 +0100 Several update suggestions were taken into account from static source code analysis. Markus Elfring (8): Better exception handling in abb5zes3_probe() Delete an unnecessary variable in abb5zes3_rtc_set_alarm() Delete an unnecessary variable initialisation in _abb5zes3_rtc_set_timer() Replace a variable initialisation by an assignment in _abb5zes3_rtc_set_alarm() Replace a variable initialisation by an assignment in _abb5zes3_rtc_read_alarm() Delete an unnecessary variable in _abb5zes3_rtc_read_timer() Delete an unnecessary variable in _abb5zes3_rtc_interrupt() Delete an unnecessary variable in _abb5zes3_rtc_set_timer() drivers/rtc/rtc-ab-b5ze-s3.c | 59 ++++++++++++++++++++------------------------ 1 file changed, 27 insertions(+), 32 deletions(-) -- 2.6.3 -- -- You received this message because you are subscribed to "rtc-linux". Membership options at http://groups.google.com/group/rtc-linux . Please read http://groups.google.com/group/rtc-linux/web/checklist before submitting a driver. --- You received this message because you are subscribed to the Google Groups "rtc-linux" group. To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 1/8] rtc-ab-b5ze-s3: Better exception handling in abb5zes3_probe() 2016-01-03 8:43 ` [rtc-linux] " SF Markus Elfring (?) @ 2016-01-03 8:50 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 8:50 UTC (permalink / raw) To: rtc-linux, Alessandro Zummo, Alexandre Belloni Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 3 Jan 2016 07:07:49 +0100 This issue was detected by using the Coccinelle software. * Return directly before the data structure element "irq" was assigned. * Drop the explicit initialisation for the variable "data" at the beginning then. * Adjust jump targets according to the Linux coding style convention. * Simplify a condition check at the end. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/rtc/rtc-ab-b5ze-s3.c | 32 ++++++++++++++------------------ 1 file changed, 14 insertions(+), 18 deletions(-) diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c index a319bf1..1291206 100644 --- a/drivers/rtc/rtc-ab-b5ze-s3.c +++ b/drivers/rtc/rtc-ab-b5ze-s3.c @@ -889,35 +889,31 @@ static const struct regmap_config abb5zes3_rtc_regmap_config = { static int abb5zes3_probe(struct i2c_client *client, const struct i2c_device_id *id) { - struct abb5zes3_rtc_data *data = NULL; + struct abb5zes3_rtc_data *data; struct device *dev = &client->dev; struct regmap *regmap; int ret; if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C | I2C_FUNC_SMBUS_BYTE_DATA | - I2C_FUNC_SMBUS_I2C_BLOCK)) { - ret = -ENODEV; - goto err; - } + I2C_FUNC_SMBUS_I2C_BLOCK)) + return -ENODEV; regmap = devm_regmap_init_i2c(client, &abb5zes3_rtc_regmap_config); if (IS_ERR(regmap)) { ret = PTR_ERR(regmap); dev_err(dev, "%s: regmap allocation failed: %d\n", __func__, ret); - goto err; + return ret; } ret = abb5zes3_i2c_validate_chip(regmap); if (ret) - goto err; + return ret; data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL); - if (!data) { - ret = -ENOMEM; - goto err; - } + if (!data) + return -ENOMEM; mutex_init(&data->lock); data->regmap = regmap; @@ -925,7 +921,7 @@ static int abb5zes3_probe(struct i2c_client *client, ret = abb5zes3_rtc_check_setup(dev); if (ret) - goto err; + return ret; if (client->irq > 0) { ret = devm_request_threaded_irq(dev, client->irq, NULL, @@ -940,7 +936,7 @@ static int abb5zes3_probe(struct i2c_client *client, } else { dev_err(dev, "%s: irq %d unavailable (%d)\n", __func__, client->irq, ret); - goto err; + return ret; } } @@ -950,7 +946,7 @@ static int abb5zes3_probe(struct i2c_client *client, if (ret) { dev_err(dev, "%s: unable to register RTC device (%d)\n", __func__, ret); - goto err; + goto check_irq; } /* Enable battery low detection interrupt if battery not already low */ @@ -959,12 +955,12 @@ static int abb5zes3_probe(struct i2c_client *client, if (ret) { dev_err(dev, "%s: enabling battery low interrupt " "generation failed (%d)\n", __func__, ret); - goto err; + goto check_irq; } } - -err: - if (ret && data && data->irq) + return 0; +check_irq: + if (data->irq) device_init_wakeup(dev, false); return ret; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 1/8] rtc-ab-b5ze-s3: Better exception handling in abb5zes3_probe() @ 2016-01-03 8:50 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 8:50 UTC (permalink / raw) To: rtc-linux, Alessandro Zummo, Alexandre Belloni Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 3 Jan 2016 07:07:49 +0100 This issue was detected by using the Coccinelle software. * Return directly before the data structure element "irq" was assigned. * Drop the explicit initialisation for the variable "data" at the beginning then. * Adjust jump targets according to the Linux coding style convention. * Simplify a condition check at the end. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/rtc/rtc-ab-b5ze-s3.c | 32 ++++++++++++++------------------ 1 file changed, 14 insertions(+), 18 deletions(-) diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c index a319bf1..1291206 100644 --- a/drivers/rtc/rtc-ab-b5ze-s3.c +++ b/drivers/rtc/rtc-ab-b5ze-s3.c @@ -889,35 +889,31 @@ static const struct regmap_config abb5zes3_rtc_regmap_config = { static int abb5zes3_probe(struct i2c_client *client, const struct i2c_device_id *id) { - struct abb5zes3_rtc_data *data = NULL; + struct abb5zes3_rtc_data *data; struct device *dev = &client->dev; struct regmap *regmap; int ret; if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C | I2C_FUNC_SMBUS_BYTE_DATA | - I2C_FUNC_SMBUS_I2C_BLOCK)) { - ret = -ENODEV; - goto err; - } + I2C_FUNC_SMBUS_I2C_BLOCK)) + return -ENODEV; regmap = devm_regmap_init_i2c(client, &abb5zes3_rtc_regmap_config); if (IS_ERR(regmap)) { ret = PTR_ERR(regmap); dev_err(dev, "%s: regmap allocation failed: %d\n", __func__, ret); - goto err; + return ret; } ret = abb5zes3_i2c_validate_chip(regmap); if (ret) - goto err; + return ret; data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL); - if (!data) { - ret = -ENOMEM; - goto err; - } + if (!data) + return -ENOMEM; mutex_init(&data->lock); data->regmap = regmap; @@ -925,7 +921,7 @@ static int abb5zes3_probe(struct i2c_client *client, ret = abb5zes3_rtc_check_setup(dev); if (ret) - goto err; + return ret; if (client->irq > 0) { ret = devm_request_threaded_irq(dev, client->irq, NULL, @@ -940,7 +936,7 @@ static int abb5zes3_probe(struct i2c_client *client, } else { dev_err(dev, "%s: irq %d unavailable (%d)\n", __func__, client->irq, ret); - goto err; + return ret; } } @@ -950,7 +946,7 @@ static int abb5zes3_probe(struct i2c_client *client, if (ret) { dev_err(dev, "%s: unable to register RTC device (%d)\n", __func__, ret); - goto err; + goto check_irq; } /* Enable battery low detection interrupt if battery not already low */ @@ -959,12 +955,12 @@ static int abb5zes3_probe(struct i2c_client *client, if (ret) { dev_err(dev, "%s: enabling battery low interrupt " "generation failed (%d)\n", __func__, ret); - goto err; + goto check_irq; } } - -err: - if (ret && data && data->irq) + return 0; +check_irq: + if (data->irq) device_init_wakeup(dev, false); return ret; } -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [rtc-linux] [PATCH 1/8] rtc-ab-b5ze-s3: Better exception handling in abb5zes3_probe() @ 2016-01-03 8:50 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 8:50 UTC (permalink / raw) To: rtc-linux, Alessandro Zummo, Alexandre Belloni Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 3 Jan 2016 07:07:49 +0100 This issue was detected by using the Coccinelle software. * Return directly before the data structure element "irq" was assigned. * Drop the explicit initialisation for the variable "data" at the beginning then. * Adjust jump targets according to the Linux coding style convention. * Simplify a condition check at the end. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/rtc/rtc-ab-b5ze-s3.c | 32 ++++++++++++++------------------ 1 file changed, 14 insertions(+), 18 deletions(-) diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c index a319bf1..1291206 100644 --- a/drivers/rtc/rtc-ab-b5ze-s3.c +++ b/drivers/rtc/rtc-ab-b5ze-s3.c @@ -889,35 +889,31 @@ static const struct regmap_config abb5zes3_rtc_regmap_config = { static int abb5zes3_probe(struct i2c_client *client, const struct i2c_device_id *id) { - struct abb5zes3_rtc_data *data = NULL; + struct abb5zes3_rtc_data *data; struct device *dev = &client->dev; struct regmap *regmap; int ret; if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C | I2C_FUNC_SMBUS_BYTE_DATA | - I2C_FUNC_SMBUS_I2C_BLOCK)) { - ret = -ENODEV; - goto err; - } + I2C_FUNC_SMBUS_I2C_BLOCK)) + return -ENODEV; regmap = devm_regmap_init_i2c(client, &abb5zes3_rtc_regmap_config); if (IS_ERR(regmap)) { ret = PTR_ERR(regmap); dev_err(dev, "%s: regmap allocation failed: %d\n", __func__, ret); - goto err; + return ret; } ret = abb5zes3_i2c_validate_chip(regmap); if (ret) - goto err; + return ret; data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL); - if (!data) { - ret = -ENOMEM; - goto err; - } + if (!data) + return -ENOMEM; mutex_init(&data->lock); data->regmap = regmap; @@ -925,7 +921,7 @@ static int abb5zes3_probe(struct i2c_client *client, ret = abb5zes3_rtc_check_setup(dev); if (ret) - goto err; + return ret; if (client->irq > 0) { ret = devm_request_threaded_irq(dev, client->irq, NULL, @@ -940,7 +936,7 @@ static int abb5zes3_probe(struct i2c_client *client, } else { dev_err(dev, "%s: irq %d unavailable (%d)\n", __func__, client->irq, ret); - goto err; + return ret; } } @@ -950,7 +946,7 @@ static int abb5zes3_probe(struct i2c_client *client, if (ret) { dev_err(dev, "%s: unable to register RTC device (%d)\n", __func__, ret); - goto err; + goto check_irq; } /* Enable battery low detection interrupt if battery not already low */ @@ -959,12 +955,12 @@ static int abb5zes3_probe(struct i2c_client *client, if (ret) { dev_err(dev, "%s: enabling battery low interrupt " "generation failed (%d)\n", __func__, ret); - goto err; + goto check_irq; } } - -err: - if (ret && data && data->irq) + return 0; +check_irq: + if (data->irq) device_init_wakeup(dev, false); return ret; } -- 2.6.3 -- -- You received this message because you are subscribed to "rtc-linux". Membership options at http://groups.google.com/group/rtc-linux . Please read http://groups.google.com/group/rtc-linux/web/checklist before submitting a driver. --- You received this message because you are subscribed to the Google Groups "rtc-linux" group. To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 2/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in abb5zes3_rtc_set_alarm() 2016-01-03 8:43 ` [rtc-linux] " SF Markus Elfring (?) @ 2016-01-03 8:51 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 8:51 UTC (permalink / raw) To: rtc-linux, Alessandro Zummo, Alexandre Belloni Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 3 Jan 2016 07:35:09 +0100 Pass the address of the data structure element "time" directly in a call of the function "rtc_tm_to_time" instead of an extra initialisation for one local variable at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/rtc/rtc-ab-b5ze-s3.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c index 1291206..ed9b873 100644 --- a/drivers/rtc/rtc-ab-b5ze-s3.c +++ b/drivers/rtc/rtc-ab-b5ze-s3.c @@ -596,7 +596,6 @@ err: static int abb5zes3_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alarm) { struct abb5zes3_rtc_data *data = dev_get_drvdata(dev); - struct rtc_time *alarm_tm = &alarm->time; unsigned long rtc_secs, alarm_secs; struct rtc_time rtc_tm; int ret; @@ -610,7 +609,7 @@ static int abb5zes3_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alarm) if (ret) goto err; - ret = rtc_tm_to_time(alarm_tm, &alarm_secs); + ret = rtc_tm_to_time(&alarm->time, &alarm_secs); if (ret) goto err; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 2/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in abb5zes3_rtc_set_alarm() @ 2016-01-03 8:51 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 8:51 UTC (permalink / raw) To: rtc-linux, Alessandro Zummo, Alexandre Belloni Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 3 Jan 2016 07:35:09 +0100 Pass the address of the data structure element "time" directly in a call of the function "rtc_tm_to_time" instead of an extra initialisation for one local variable at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/rtc/rtc-ab-b5ze-s3.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c index 1291206..ed9b873 100644 --- a/drivers/rtc/rtc-ab-b5ze-s3.c +++ b/drivers/rtc/rtc-ab-b5ze-s3.c @@ -596,7 +596,6 @@ err: static int abb5zes3_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alarm) { struct abb5zes3_rtc_data *data = dev_get_drvdata(dev); - struct rtc_time *alarm_tm = &alarm->time; unsigned long rtc_secs, alarm_secs; struct rtc_time rtc_tm; int ret; @@ -610,7 +609,7 @@ static int abb5zes3_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alarm) if (ret) goto err; - ret = rtc_tm_to_time(alarm_tm, &alarm_secs); + ret = rtc_tm_to_time(&alarm->time, &alarm_secs); if (ret) goto err; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [rtc-linux] [PATCH 2/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in abb5zes3_rtc_set_alarm() @ 2016-01-03 8:51 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 8:51 UTC (permalink / raw) To: rtc-linux, Alessandro Zummo, Alexandre Belloni Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 3 Jan 2016 07:35:09 +0100 Pass the address of the data structure element "time" directly in a call of the function "rtc_tm_to_time" instead of an extra initialisation for one local variable at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/rtc/rtc-ab-b5ze-s3.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c index 1291206..ed9b873 100644 --- a/drivers/rtc/rtc-ab-b5ze-s3.c +++ b/drivers/rtc/rtc-ab-b5ze-s3.c @@ -596,7 +596,6 @@ err: static int abb5zes3_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alarm) { struct abb5zes3_rtc_data *data = dev_get_drvdata(dev); - struct rtc_time *alarm_tm = &alarm->time; unsigned long rtc_secs, alarm_secs; struct rtc_time rtc_tm; int ret; @@ -610,7 +609,7 @@ static int abb5zes3_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alarm) if (ret) goto err; - ret = rtc_tm_to_time(alarm_tm, &alarm_secs); + ret = rtc_tm_to_time(&alarm->time, &alarm_secs); if (ret) goto err; -- 2.6.3 -- -- You received this message because you are subscribed to "rtc-linux". Membership options at http://groups.google.com/group/rtc-linux . Please read http://groups.google.com/group/rtc-linux/web/checklist before submitting a driver. --- You received this message because you are subscribed to the Google Groups "rtc-linux" group. To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 3/8] rtc-ab-b5ze-s3: Delete an unnecessary variable initialisation in _abb5zes3_rtc_set_timer() 2016-01-03 8:43 ` [rtc-linux] " SF Markus Elfring (?) @ 2016-01-03 8:52 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 8:52 UTC (permalink / raw) To: rtc-linux, Alessandro Zummo, Alexandre Belloni Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 3 Jan 2016 07:42:18 +0100 Omit explicit initialisation at the beginning for one local variable that is redefined before its first use. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/rtc/rtc-ab-b5ze-s3.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c index ed9b873..33a7cf1 100644 --- a/drivers/rtc/rtc-ab-b5ze-s3.c +++ b/drivers/rtc/rtc-ab-b5ze-s3.c @@ -560,7 +560,7 @@ static int _abb5zes3_rtc_set_timer(struct device *dev, struct rtc_wkalrm *alarm, struct abb5zes3_rtc_data *data = dev_get_drvdata(dev); u8 regs[ABB5ZES3_TIMA_SEC_LEN]; u8 mask = ABB5ZES3_REG_TIM_CLK_TAC0 | ABB5ZES3_REG_TIM_CLK_TAC1; - int ret = 0; + int ret; /* Program given number of seconds to Timer A registers */ sec_to_timer_a(secs, ®s[0], ®s[1]); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 3/8] rtc-ab-b5ze-s3: Delete an unnecessary variable initialisation in _abb5zes3_rtc_set_timer @ 2016-01-03 8:52 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 8:52 UTC (permalink / raw) To: rtc-linux, Alessandro Zummo, Alexandre Belloni Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 3 Jan 2016 07:42:18 +0100 Omit explicit initialisation at the beginning for one local variable that is redefined before its first use. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/rtc/rtc-ab-b5ze-s3.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c index ed9b873..33a7cf1 100644 --- a/drivers/rtc/rtc-ab-b5ze-s3.c +++ b/drivers/rtc/rtc-ab-b5ze-s3.c @@ -560,7 +560,7 @@ static int _abb5zes3_rtc_set_timer(struct device *dev, struct rtc_wkalrm *alarm, struct abb5zes3_rtc_data *data = dev_get_drvdata(dev); u8 regs[ABB5ZES3_TIMA_SEC_LEN]; u8 mask = ABB5ZES3_REG_TIM_CLK_TAC0 | ABB5ZES3_REG_TIM_CLK_TAC1; - int ret = 0; + int ret; /* Program given number of seconds to Timer A registers */ sec_to_timer_a(secs, ®s[0], ®s[1]); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [rtc-linux] [PATCH 3/8] rtc-ab-b5ze-s3: Delete an unnecessary variable initialisation in _abb5zes3_rtc_set_timer() @ 2016-01-03 8:52 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 8:52 UTC (permalink / raw) To: rtc-linux, Alessandro Zummo, Alexandre Belloni Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 3 Jan 2016 07:42:18 +0100 Omit explicit initialisation at the beginning for one local variable that is redefined before its first use. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/rtc/rtc-ab-b5ze-s3.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c index ed9b873..33a7cf1 100644 --- a/drivers/rtc/rtc-ab-b5ze-s3.c +++ b/drivers/rtc/rtc-ab-b5ze-s3.c @@ -560,7 +560,7 @@ static int _abb5zes3_rtc_set_timer(struct device *dev, struct rtc_wkalrm *alarm, struct abb5zes3_rtc_data *data = dev_get_drvdata(dev); u8 regs[ABB5ZES3_TIMA_SEC_LEN]; u8 mask = ABB5ZES3_REG_TIM_CLK_TAC0 | ABB5ZES3_REG_TIM_CLK_TAC1; - int ret = 0; + int ret; /* Program given number of seconds to Timer A registers */ sec_to_timer_a(secs, ®s[0], ®s[1]); -- 2.6.3 -- -- You received this message because you are subscribed to "rtc-linux". Membership options at http://groups.google.com/group/rtc-linux . Please read http://groups.google.com/group/rtc-linux/web/checklist before submitting a driver. --- You received this message because you are subscribed to the Google Groups "rtc-linux" group. To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 4/8] rtc-ab-b5ze-s3: Replace a variable initialisation by an assignment in _abb5zes3_rtc_set_alarm() 2016-01-03 8:43 ` [rtc-linux] " SF Markus Elfring (?) @ 2016-01-03 8:53 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 8:53 UTC (permalink / raw) To: rtc-linux, Alessandro Zummo, Alexandre Belloni Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 3 Jan 2016 07:51:49 +0100 Replace an explicit initialisation for one local variable at the beginning by an assignment. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/rtc/rtc-ab-b5ze-s3.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c index 33a7cf1..0986715 100644 --- a/drivers/rtc/rtc-ab-b5ze-s3.c +++ b/drivers/rtc/rtc-ab-b5ze-s3.c @@ -476,7 +476,7 @@ static int abb5zes3_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alarm) static int _abb5zes3_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alarm) { struct abb5zes3_rtc_data *data = dev_get_drvdata(dev); - struct rtc_time *alarm_tm = &alarm->time; + struct rtc_time *alarm_tm; unsigned long rtc_secs, alarm_secs; u8 regs[ABB5ZES3_ALRM_SEC_LEN]; struct rtc_time rtc_tm; @@ -490,6 +490,7 @@ static int _abb5zes3_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alarm) if (ret) goto err; + alarm_tm = &alarm->time; ret = rtc_tm_to_time(alarm_tm, &alarm_secs); if (ret) goto err; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 4/8] rtc-ab-b5ze-s3: Replace a variable initialisation by an assignment in _abb5zes3_rtc_set_ @ 2016-01-03 8:53 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 8:53 UTC (permalink / raw) To: rtc-linux, Alessandro Zummo, Alexandre Belloni Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 3 Jan 2016 07:51:49 +0100 Replace an explicit initialisation for one local variable at the beginning by an assignment. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/rtc/rtc-ab-b5ze-s3.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c index 33a7cf1..0986715 100644 --- a/drivers/rtc/rtc-ab-b5ze-s3.c +++ b/drivers/rtc/rtc-ab-b5ze-s3.c @@ -476,7 +476,7 @@ static int abb5zes3_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alarm) static int _abb5zes3_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alarm) { struct abb5zes3_rtc_data *data = dev_get_drvdata(dev); - struct rtc_time *alarm_tm = &alarm->time; + struct rtc_time *alarm_tm; unsigned long rtc_secs, alarm_secs; u8 regs[ABB5ZES3_ALRM_SEC_LEN]; struct rtc_time rtc_tm; @@ -490,6 +490,7 @@ static int _abb5zes3_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alarm) if (ret) goto err; + alarm_tm = &alarm->time; ret = rtc_tm_to_time(alarm_tm, &alarm_secs); if (ret) goto err; -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [rtc-linux] [PATCH 4/8] rtc-ab-b5ze-s3: Replace a variable initialisation by an assignment in _abb5zes3_rtc_set_alarm() @ 2016-01-03 8:53 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 8:53 UTC (permalink / raw) To: rtc-linux, Alessandro Zummo, Alexandre Belloni Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 3 Jan 2016 07:51:49 +0100 Replace an explicit initialisation for one local variable at the beginning by an assignment. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/rtc/rtc-ab-b5ze-s3.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c index 33a7cf1..0986715 100644 --- a/drivers/rtc/rtc-ab-b5ze-s3.c +++ b/drivers/rtc/rtc-ab-b5ze-s3.c @@ -476,7 +476,7 @@ static int abb5zes3_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alarm) static int _abb5zes3_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alarm) { struct abb5zes3_rtc_data *data = dev_get_drvdata(dev); - struct rtc_time *alarm_tm = &alarm->time; + struct rtc_time *alarm_tm; unsigned long rtc_secs, alarm_secs; u8 regs[ABB5ZES3_ALRM_SEC_LEN]; struct rtc_time rtc_tm; @@ -490,6 +490,7 @@ static int _abb5zes3_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alarm) if (ret) goto err; + alarm_tm = &alarm->time; ret = rtc_tm_to_time(alarm_tm, &alarm_secs); if (ret) goto err; -- 2.6.3 -- -- You received this message because you are subscribed to "rtc-linux". Membership options at http://groups.google.com/group/rtc-linux . Please read http://groups.google.com/group/rtc-linux/web/checklist before submitting a driver. --- You received this message because you are subscribed to the Google Groups "rtc-linux" group. To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 5/8] rtc-ab-b5ze-s3: Replace a variable initialisation by an assignment in _abb5zes3_rtc_read_alarm() 2016-01-03 8:43 ` [rtc-linux] " SF Markus Elfring (?) @ 2016-01-03 8:54 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 8:54 UTC (permalink / raw) To: rtc-linux, Alessandro Zummo, Alexandre Belloni Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 3 Jan 2016 08:00:29 +0100 Replace an explicit initialisation for one local variable at the beginning by an assignment. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/rtc/rtc-ab-b5ze-s3.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c index 0986715..02e3443 100644 --- a/drivers/rtc/rtc-ab-b5ze-s3.c +++ b/drivers/rtc/rtc-ab-b5ze-s3.c @@ -382,7 +382,7 @@ static int _abb5zes3_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alarm) { struct abb5zes3_rtc_data *data = dev_get_drvdata(dev); - struct rtc_time rtc_tm, *alarm_tm = &alarm->time; + struct rtc_time rtc_tm, *alarm_tm; unsigned long rtc_secs, alarm_secs; u8 regs[ABB5ZES3_ALRM_SEC_LEN]; unsigned int reg; @@ -396,6 +396,7 @@ static int _abb5zes3_rtc_read_alarm(struct device *dev, goto err; } + alarm_tm = &alarm->time; alarm_tm->tm_sec = 0; alarm_tm->tm_min = bcd2bin(regs[0] & 0x7f); alarm_tm->tm_hour = bcd2bin(regs[1] & 0x3f); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 5/8] rtc-ab-b5ze-s3: Replace a variable initialisation by an assignment in _abb5zes3_rtc_read @ 2016-01-03 8:54 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 8:54 UTC (permalink / raw) To: rtc-linux, Alessandro Zummo, Alexandre Belloni Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 3 Jan 2016 08:00:29 +0100 Replace an explicit initialisation for one local variable at the beginning by an assignment. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/rtc/rtc-ab-b5ze-s3.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c index 0986715..02e3443 100644 --- a/drivers/rtc/rtc-ab-b5ze-s3.c +++ b/drivers/rtc/rtc-ab-b5ze-s3.c @@ -382,7 +382,7 @@ static int _abb5zes3_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alarm) { struct abb5zes3_rtc_data *data = dev_get_drvdata(dev); - struct rtc_time rtc_tm, *alarm_tm = &alarm->time; + struct rtc_time rtc_tm, *alarm_tm; unsigned long rtc_secs, alarm_secs; u8 regs[ABB5ZES3_ALRM_SEC_LEN]; unsigned int reg; @@ -396,6 +396,7 @@ static int _abb5zes3_rtc_read_alarm(struct device *dev, goto err; } + alarm_tm = &alarm->time; alarm_tm->tm_sec = 0; alarm_tm->tm_min = bcd2bin(regs[0] & 0x7f); alarm_tm->tm_hour = bcd2bin(regs[1] & 0x3f); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [rtc-linux] [PATCH 5/8] rtc-ab-b5ze-s3: Replace a variable initialisation by an assignment in _abb5zes3_rtc_read_alarm() @ 2016-01-03 8:54 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 8:54 UTC (permalink / raw) To: rtc-linux, Alessandro Zummo, Alexandre Belloni Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 3 Jan 2016 08:00:29 +0100 Replace an explicit initialisation for one local variable at the beginning by an assignment. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/rtc/rtc-ab-b5ze-s3.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c index 0986715..02e3443 100644 --- a/drivers/rtc/rtc-ab-b5ze-s3.c +++ b/drivers/rtc/rtc-ab-b5ze-s3.c @@ -382,7 +382,7 @@ static int _abb5zes3_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alarm) { struct abb5zes3_rtc_data *data = dev_get_drvdata(dev); - struct rtc_time rtc_tm, *alarm_tm = &alarm->time; + struct rtc_time rtc_tm, *alarm_tm; unsigned long rtc_secs, alarm_secs; u8 regs[ABB5ZES3_ALRM_SEC_LEN]; unsigned int reg; @@ -396,6 +396,7 @@ static int _abb5zes3_rtc_read_alarm(struct device *dev, goto err; } + alarm_tm = &alarm->time; alarm_tm->tm_sec = 0; alarm_tm->tm_min = bcd2bin(regs[0] & 0x7f); alarm_tm->tm_hour = bcd2bin(regs[1] & 0x3f); -- 2.6.3 -- -- You received this message because you are subscribed to "rtc-linux". Membership options at http://groups.google.com/group/rtc-linux . Please read http://groups.google.com/group/rtc-linux/web/checklist before submitting a driver. --- You received this message because you are subscribed to the Google Groups "rtc-linux" group. To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 6/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_read_timer() 2016-01-03 8:43 ` [rtc-linux] " SF Markus Elfring (?) @ 2016-01-03 8:55 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 8:55 UTC (permalink / raw) To: rtc-linux, Alessandro Zummo, Alexandre Belloni Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 3 Jan 2016 08:46:50 +0100 Pass the address of the data structure element "time" directly in a call of the function "rtc_time_to_tm" instead of an extra initialisation for one local variable at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/rtc/rtc-ab-b5ze-s3.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c index 02e3443..e3a015a 100644 --- a/drivers/rtc/rtc-ab-b5ze-s3.c +++ b/drivers/rtc/rtc-ab-b5ze-s3.c @@ -326,7 +326,7 @@ static int _abb5zes3_rtc_read_timer(struct device *dev, struct rtc_wkalrm *alarm) { struct abb5zes3_rtc_data *data = dev_get_drvdata(dev); - struct rtc_time rtc_tm, *alarm_tm = &alarm->time; + struct rtc_time rtc_tm; u8 regs[ABB5ZES3_TIMA_SEC_LEN + 1]; unsigned long rtc_secs; unsigned int reg; @@ -362,7 +362,7 @@ static int _abb5zes3_rtc_read_timer(struct device *dev, goto err; /* ... and convert back. */ - rtc_time_to_tm(rtc_secs + timer_secs, alarm_tm); + rtc_time_to_tm(rtc_secs + timer_secs, &alarm->time); ret = regmap_read(data->regmap, ABB5ZES3_REG_CTRL2, ®); if (ret) { -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 6/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_read_timer() @ 2016-01-03 8:55 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 8:55 UTC (permalink / raw) To: rtc-linux, Alessandro Zummo, Alexandre Belloni Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 3 Jan 2016 08:46:50 +0100 Pass the address of the data structure element "time" directly in a call of the function "rtc_time_to_tm" instead of an extra initialisation for one local variable at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/rtc/rtc-ab-b5ze-s3.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c index 02e3443..e3a015a 100644 --- a/drivers/rtc/rtc-ab-b5ze-s3.c +++ b/drivers/rtc/rtc-ab-b5ze-s3.c @@ -326,7 +326,7 @@ static int _abb5zes3_rtc_read_timer(struct device *dev, struct rtc_wkalrm *alarm) { struct abb5zes3_rtc_data *data = dev_get_drvdata(dev); - struct rtc_time rtc_tm, *alarm_tm = &alarm->time; + struct rtc_time rtc_tm; u8 regs[ABB5ZES3_TIMA_SEC_LEN + 1]; unsigned long rtc_secs; unsigned int reg; @@ -362,7 +362,7 @@ static int _abb5zes3_rtc_read_timer(struct device *dev, goto err; /* ... and convert back. */ - rtc_time_to_tm(rtc_secs + timer_secs, alarm_tm); + rtc_time_to_tm(rtc_secs + timer_secs, &alarm->time); ret = regmap_read(data->regmap, ABB5ZES3_REG_CTRL2, ®); if (ret) { -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [rtc-linux] [PATCH 6/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_read_timer() @ 2016-01-03 8:55 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 8:55 UTC (permalink / raw) To: rtc-linux, Alessandro Zummo, Alexandre Belloni Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 3 Jan 2016 08:46:50 +0100 Pass the address of the data structure element "time" directly in a call of the function "rtc_time_to_tm" instead of an extra initialisation for one local variable at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/rtc/rtc-ab-b5ze-s3.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c index 02e3443..e3a015a 100644 --- a/drivers/rtc/rtc-ab-b5ze-s3.c +++ b/drivers/rtc/rtc-ab-b5ze-s3.c @@ -326,7 +326,7 @@ static int _abb5zes3_rtc_read_timer(struct device *dev, struct rtc_wkalrm *alarm) { struct abb5zes3_rtc_data *data = dev_get_drvdata(dev); - struct rtc_time rtc_tm, *alarm_tm = &alarm->time; + struct rtc_time rtc_tm; u8 regs[ABB5ZES3_TIMA_SEC_LEN + 1]; unsigned long rtc_secs; unsigned int reg; @@ -362,7 +362,7 @@ static int _abb5zes3_rtc_read_timer(struct device *dev, goto err; /* ... and convert back. */ - rtc_time_to_tm(rtc_secs + timer_secs, alarm_tm); + rtc_time_to_tm(rtc_secs + timer_secs, &alarm->time); ret = regmap_read(data->regmap, ABB5ZES3_REG_CTRL2, ®); if (ret) { -- 2.6.3 -- -- You received this message because you are subscribed to "rtc-linux". Membership options at http://groups.google.com/group/rtc-linux . Please read http://groups.google.com/group/rtc-linux/web/checklist before submitting a driver. --- You received this message because you are subscribed to the Google Groups "rtc-linux" group. To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 7/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_interrupt() 2016-01-03 8:43 ` [rtc-linux] " SF Markus Elfring (?) @ 2016-01-03 8:56 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 8:56 UTC (permalink / raw) To: rtc-linux, Alessandro Zummo, Alexandre Belloni Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 3 Jan 2016 09:00:30 +0100 Pass the address of the data structure element "time" directly in calls of the function "rtc_update_irq" instead of an extra initialisation for one local variable at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/rtc/rtc-ab-b5ze-s3.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c index e3a015a..88f1d0b 100644 --- a/drivers/rtc/rtc-ab-b5ze-s3.c +++ b/drivers/rtc/rtc-ab-b5ze-s3.c @@ -816,7 +816,6 @@ static irqreturn_t _abb5zes3_rtc_interrupt(int irq, void *data) struct i2c_client *client = data; struct device *dev = &client->dev; struct abb5zes3_rtc_data *rtc_data = dev_get_drvdata(dev); - struct rtc_device *rtc = rtc_data->rtc; u8 regs[ABB5ZES3_CTRL_SEC_LEN]; int ret, handled = IRQ_NONE; @@ -844,8 +843,7 @@ static irqreturn_t _abb5zes3_rtc_interrupt(int irq, void *data) /* Check alarm flag */ if (regs[ABB5ZES3_REG_CTRL2] & ABB5ZES3_REG_CTRL2_AF) { dev_dbg(dev, "RTC alarm!\n"); - - rtc_update_irq(rtc, 1, RTC_IRQF | RTC_AF); + rtc_update_irq(rtc_data->rtc, 1, RTC_IRQF | RTC_AF); /* Acknowledge and disable the alarm */ _abb5zes3_rtc_clear_alarm(dev); @@ -857,8 +855,7 @@ static irqreturn_t _abb5zes3_rtc_interrupt(int irq, void *data) /* Check watchdog Timer A flag */ if (regs[ABB5ZES3_REG_CTRL2] & ABB5ZES3_REG_CTRL2_WTAF) { dev_dbg(dev, "RTC timer!\n"); - - rtc_update_irq(rtc, 1, RTC_IRQF | RTC_AF); + rtc_update_irq(rtc_data->rtc, 1, RTC_IRQF | RTC_AF); /* * Acknowledge and disable the alarm. Note: WTAF -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 7/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_interrupt() @ 2016-01-03 8:56 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 8:56 UTC (permalink / raw) To: rtc-linux, Alessandro Zummo, Alexandre Belloni Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 3 Jan 2016 09:00:30 +0100 Pass the address of the data structure element "time" directly in calls of the function "rtc_update_irq" instead of an extra initialisation for one local variable at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/rtc/rtc-ab-b5ze-s3.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c index e3a015a..88f1d0b 100644 --- a/drivers/rtc/rtc-ab-b5ze-s3.c +++ b/drivers/rtc/rtc-ab-b5ze-s3.c @@ -816,7 +816,6 @@ static irqreturn_t _abb5zes3_rtc_interrupt(int irq, void *data) struct i2c_client *client = data; struct device *dev = &client->dev; struct abb5zes3_rtc_data *rtc_data = dev_get_drvdata(dev); - struct rtc_device *rtc = rtc_data->rtc; u8 regs[ABB5ZES3_CTRL_SEC_LEN]; int ret, handled = IRQ_NONE; @@ -844,8 +843,7 @@ static irqreturn_t _abb5zes3_rtc_interrupt(int irq, void *data) /* Check alarm flag */ if (regs[ABB5ZES3_REG_CTRL2] & ABB5ZES3_REG_CTRL2_AF) { dev_dbg(dev, "RTC alarm!\n"); - - rtc_update_irq(rtc, 1, RTC_IRQF | RTC_AF); + rtc_update_irq(rtc_data->rtc, 1, RTC_IRQF | RTC_AF); /* Acknowledge and disable the alarm */ _abb5zes3_rtc_clear_alarm(dev); @@ -857,8 +855,7 @@ static irqreturn_t _abb5zes3_rtc_interrupt(int irq, void *data) /* Check watchdog Timer A flag */ if (regs[ABB5ZES3_REG_CTRL2] & ABB5ZES3_REG_CTRL2_WTAF) { dev_dbg(dev, "RTC timer!\n"); - - rtc_update_irq(rtc, 1, RTC_IRQF | RTC_AF); + rtc_update_irq(rtc_data->rtc, 1, RTC_IRQF | RTC_AF); /* * Acknowledge and disable the alarm. Note: WTAF -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [rtc-linux] [PATCH 7/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_interrupt() @ 2016-01-03 8:56 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 8:56 UTC (permalink / raw) To: rtc-linux, Alessandro Zummo, Alexandre Belloni Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 3 Jan 2016 09:00:30 +0100 Pass the address of the data structure element "time" directly in calls of the function "rtc_update_irq" instead of an extra initialisation for one local variable at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/rtc/rtc-ab-b5ze-s3.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c index e3a015a..88f1d0b 100644 --- a/drivers/rtc/rtc-ab-b5ze-s3.c +++ b/drivers/rtc/rtc-ab-b5ze-s3.c @@ -816,7 +816,6 @@ static irqreturn_t _abb5zes3_rtc_interrupt(int irq, void *data) struct i2c_client *client = data; struct device *dev = &client->dev; struct abb5zes3_rtc_data *rtc_data = dev_get_drvdata(dev); - struct rtc_device *rtc = rtc_data->rtc; u8 regs[ABB5ZES3_CTRL_SEC_LEN]; int ret, handled = IRQ_NONE; @@ -844,8 +843,7 @@ static irqreturn_t _abb5zes3_rtc_interrupt(int irq, void *data) /* Check alarm flag */ if (regs[ABB5ZES3_REG_CTRL2] & ABB5ZES3_REG_CTRL2_AF) { dev_dbg(dev, "RTC alarm!\n"); - - rtc_update_irq(rtc, 1, RTC_IRQF | RTC_AF); + rtc_update_irq(rtc_data->rtc, 1, RTC_IRQF | RTC_AF); /* Acknowledge and disable the alarm */ _abb5zes3_rtc_clear_alarm(dev); @@ -857,8 +855,7 @@ static irqreturn_t _abb5zes3_rtc_interrupt(int irq, void *data) /* Check watchdog Timer A flag */ if (regs[ABB5ZES3_REG_CTRL2] & ABB5ZES3_REG_CTRL2_WTAF) { dev_dbg(dev, "RTC timer!\n"); - - rtc_update_irq(rtc, 1, RTC_IRQF | RTC_AF); + rtc_update_irq(rtc_data->rtc, 1, RTC_IRQF | RTC_AF); /* * Acknowledge and disable the alarm. Note: WTAF -- 2.6.3 -- -- You received this message because you are subscribed to "rtc-linux". Membership options at http://groups.google.com/group/rtc-linux . Please read http://groups.google.com/group/rtc-linux/web/checklist before submitting a driver. --- You received this message because you are subscribed to the Google Groups "rtc-linux" group. To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 7/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_interrupt() 2016-01-03 8:56 ` [rtc-linux] " SF Markus Elfring (?) @ 2016-01-03 12:48 ` Julia Lawall -1 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2016-01-03 12:48 UTC (permalink / raw) To: SF Markus Elfring Cc: rtc-linux, Alessandro Zummo, Alexandre Belloni, LKML, kernel-janitors, Julia Lawall On Sun, 3 Jan 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 3 Jan 2016 09:00:30 +0100 > > Pass the address of the data structure element "time" directly in calls > of the function "rtc_update_irq" instead of an extra initialisation > for one local variable at the beginning. Why is it better? julia > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/rtc/rtc-ab-b5ze-s3.c | 7 ++----- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c > index e3a015a..88f1d0b 100644 > --- a/drivers/rtc/rtc-ab-b5ze-s3.c > +++ b/drivers/rtc/rtc-ab-b5ze-s3.c > @@ -816,7 +816,6 @@ static irqreturn_t _abb5zes3_rtc_interrupt(int irq, void *data) > struct i2c_client *client = data; > struct device *dev = &client->dev; > struct abb5zes3_rtc_data *rtc_data = dev_get_drvdata(dev); > - struct rtc_device *rtc = rtc_data->rtc; > u8 regs[ABB5ZES3_CTRL_SEC_LEN]; > int ret, handled = IRQ_NONE; > > @@ -844,8 +843,7 @@ static irqreturn_t _abb5zes3_rtc_interrupt(int irq, void *data) > /* Check alarm flag */ > if (regs[ABB5ZES3_REG_CTRL2] & ABB5ZES3_REG_CTRL2_AF) { > dev_dbg(dev, "RTC alarm!\n"); > - > - rtc_update_irq(rtc, 1, RTC_IRQF | RTC_AF); > + rtc_update_irq(rtc_data->rtc, 1, RTC_IRQF | RTC_AF); > > /* Acknowledge and disable the alarm */ > _abb5zes3_rtc_clear_alarm(dev); > @@ -857,8 +855,7 @@ static irqreturn_t _abb5zes3_rtc_interrupt(int irq, void *data) > /* Check watchdog Timer A flag */ > if (regs[ABB5ZES3_REG_CTRL2] & ABB5ZES3_REG_CTRL2_WTAF) { > dev_dbg(dev, "RTC timer!\n"); > - > - rtc_update_irq(rtc, 1, RTC_IRQF | RTC_AF); > + rtc_update_irq(rtc_data->rtc, 1, RTC_IRQF | RTC_AF); > > /* > * Acknowledge and disable the alarm. Note: WTAF > -- > 2.6.3 > > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 7/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_interrupt() @ 2016-01-03 12:48 ` Julia Lawall 0 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2016-01-03 12:48 UTC (permalink / raw) To: SF Markus Elfring Cc: rtc-linux, Alessandro Zummo, Alexandre Belloni, LKML, kernel-janitors, Julia Lawall On Sun, 3 Jan 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 3 Jan 2016 09:00:30 +0100 > > Pass the address of the data structure element "time" directly in calls > of the function "rtc_update_irq" instead of an extra initialisation > for one local variable at the beginning. Why is it better? julia > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/rtc/rtc-ab-b5ze-s3.c | 7 ++----- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c > index e3a015a..88f1d0b 100644 > --- a/drivers/rtc/rtc-ab-b5ze-s3.c > +++ b/drivers/rtc/rtc-ab-b5ze-s3.c > @@ -816,7 +816,6 @@ static irqreturn_t _abb5zes3_rtc_interrupt(int irq, void *data) > struct i2c_client *client = data; > struct device *dev = &client->dev; > struct abb5zes3_rtc_data *rtc_data = dev_get_drvdata(dev); > - struct rtc_device *rtc = rtc_data->rtc; > u8 regs[ABB5ZES3_CTRL_SEC_LEN]; > int ret, handled = IRQ_NONE; > > @@ -844,8 +843,7 @@ static irqreturn_t _abb5zes3_rtc_interrupt(int irq, void *data) > /* Check alarm flag */ > if (regs[ABB5ZES3_REG_CTRL2] & ABB5ZES3_REG_CTRL2_AF) { > dev_dbg(dev, "RTC alarm!\n"); > - > - rtc_update_irq(rtc, 1, RTC_IRQF | RTC_AF); > + rtc_update_irq(rtc_data->rtc, 1, RTC_IRQF | RTC_AF); > > /* Acknowledge and disable the alarm */ > _abb5zes3_rtc_clear_alarm(dev); > @@ -857,8 +855,7 @@ static irqreturn_t _abb5zes3_rtc_interrupt(int irq, void *data) > /* Check watchdog Timer A flag */ > if (regs[ABB5ZES3_REG_CTRL2] & ABB5ZES3_REG_CTRL2_WTAF) { > dev_dbg(dev, "RTC timer!\n"); > - > - rtc_update_irq(rtc, 1, RTC_IRQF | RTC_AF); > + rtc_update_irq(rtc_data->rtc, 1, RTC_IRQF | RTC_AF); > > /* > * Acknowledge and disable the alarm. Note: WTAF > -- > 2.6.3 > > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [rtc-linux] Re: [PATCH 7/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_interrupt() @ 2016-01-03 12:48 ` Julia Lawall 0 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2016-01-03 12:48 UTC (permalink / raw) To: SF Markus Elfring Cc: rtc-linux, Alessandro Zummo, Alexandre Belloni, LKML, kernel-janitors, Julia Lawall On Sun, 3 Jan 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 3 Jan 2016 09:00:30 +0100 > > Pass the address of the data structure element "time" directly in calls > of the function "rtc_update_irq" instead of an extra initialisation > for one local variable at the beginning. Why is it better? julia > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/rtc/rtc-ab-b5ze-s3.c | 7 ++----- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c > index e3a015a..88f1d0b 100644 > --- a/drivers/rtc/rtc-ab-b5ze-s3.c > +++ b/drivers/rtc/rtc-ab-b5ze-s3.c > @@ -816,7 +816,6 @@ static irqreturn_t _abb5zes3_rtc_interrupt(int irq, void *data) > struct i2c_client *client = data; > struct device *dev = &client->dev; > struct abb5zes3_rtc_data *rtc_data = dev_get_drvdata(dev); > - struct rtc_device *rtc = rtc_data->rtc; > u8 regs[ABB5ZES3_CTRL_SEC_LEN]; > int ret, handled = IRQ_NONE; > > @@ -844,8 +843,7 @@ static irqreturn_t _abb5zes3_rtc_interrupt(int irq, void *data) > /* Check alarm flag */ > if (regs[ABB5ZES3_REG_CTRL2] & ABB5ZES3_REG_CTRL2_AF) { > dev_dbg(dev, "RTC alarm!\n"); > - > - rtc_update_irq(rtc, 1, RTC_IRQF | RTC_AF); > + rtc_update_irq(rtc_data->rtc, 1, RTC_IRQF | RTC_AF); > > /* Acknowledge and disable the alarm */ > _abb5zes3_rtc_clear_alarm(dev); > @@ -857,8 +855,7 @@ static irqreturn_t _abb5zes3_rtc_interrupt(int irq, void *data) > /* Check watchdog Timer A flag */ > if (regs[ABB5ZES3_REG_CTRL2] & ABB5ZES3_REG_CTRL2_WTAF) { > dev_dbg(dev, "RTC timer!\n"); > - > - rtc_update_irq(rtc, 1, RTC_IRQF | RTC_AF); > + rtc_update_irq(rtc_data->rtc, 1, RTC_IRQF | RTC_AF); > > /* > * Acknowledge and disable the alarm. Note: WTAF > -- > 2.6.3 > > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 7/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_interrupt() 2016-01-03 12:48 ` [rtc-linux] " Julia Lawall (?) @ 2016-01-03 16:54 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 16:54 UTC (permalink / raw) To: Julia Lawall Cc: rtc-linux, Alessandro Zummo, Alexandre Belloni, LKML, kernel-janitors >> Pass the address of the data structure element "time" directly in calls >> of the function "rtc_update_irq" instead of an extra initialisation >> for one local variable at the beginning. > > Why is it better? I suggest to refer to the data item "rtc_data->rtc" directly because the variable "rtc" was read only in two if branches. Does it make sense then to reduce the variable allocation? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 7/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_interrupt() @ 2016-01-03 16:54 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 16:54 UTC (permalink / raw) To: Julia Lawall Cc: rtc-linux, Alessandro Zummo, Alexandre Belloni, LKML, kernel-janitors >> Pass the address of the data structure element "time" directly in calls >> of the function "rtc_update_irq" instead of an extra initialisation >> for one local variable at the beginning. > > Why is it better? I suggest to refer to the data item "rtc_data->rtc" directly because the variable "rtc" was read only in two if branches. Does it make sense then to reduce the variable allocation? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [rtc-linux] Re: [PATCH 7/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_interrupt() @ 2016-01-03 16:54 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 16:54 UTC (permalink / raw) To: Julia Lawall Cc: rtc-linux, Alessandro Zummo, Alexandre Belloni, LKML, kernel-janitors >> Pass the address of the data structure element "time" directly in calls >> of the function "rtc_update_irq" instead of an extra initialisation >> for one local variable at the beginning. > > Why is it better? I suggest to refer to the data item "rtc_data->rtc" directly because the variable "rtc" was read only in two if branches. Does it make sense then to reduce the variable allocation? Regards, Markus -- -- You received this message because you are subscribed to "rtc-linux". Membership options at http://groups.google.com/group/rtc-linux . Please read http://groups.google.com/group/rtc-linux/web/checklist before submitting a driver. --- You received this message because you are subscribed to the Google Groups "rtc-linux" group. To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 7/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_interrupt() 2016-01-03 16:54 ` [rtc-linux] " SF Markus Elfring (?) @ 2016-01-03 16:59 ` Julia Lawall -1 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2016-01-03 16:59 UTC (permalink / raw) To: SF Markus Elfring Cc: rtc-linux, Alessandro Zummo, Alexandre Belloni, LKML, kernel-janitors On Sun, 3 Jan 2016, SF Markus Elfring wrote: > >> Pass the address of the data structure element "time" directly in calls > >> of the function "rtc_update_irq" instead of an extra initialisation > >> for one local variable at the beginning. > > > > Why is it better? > > I suggest to refer to the data item "rtc_data->rtc" directly because > the variable "rtc" was read only in two if branches. > Does it make sense then to reduce the variable allocation? No. That is the job of the compiler. For a local variable whose address is never taken, the compiler can easily detect its live region, and place the initialization in an optimal way. julia ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 7/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_interrupt() @ 2016-01-03 16:59 ` Julia Lawall 0 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2016-01-03 16:59 UTC (permalink / raw) To: SF Markus Elfring Cc: rtc-linux, Alessandro Zummo, Alexandre Belloni, LKML, kernel-janitors On Sun, 3 Jan 2016, SF Markus Elfring wrote: > >> Pass the address of the data structure element "time" directly in calls > >> of the function "rtc_update_irq" instead of an extra initialisation > >> for one local variable at the beginning. > > > > Why is it better? > > I suggest to refer to the data item "rtc_data->rtc" directly because > the variable "rtc" was read only in two if branches. > Does it make sense then to reduce the variable allocation? No. That is the job of the compiler. For a local variable whose address is never taken, the compiler can easily detect its live region, and place the initialization in an optimal way. julia ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [rtc-linux] Re: [PATCH 7/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_interrupt() @ 2016-01-03 16:59 ` Julia Lawall 0 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2016-01-03 16:59 UTC (permalink / raw) To: SF Markus Elfring Cc: rtc-linux, Alessandro Zummo, Alexandre Belloni, LKML, kernel-janitors On Sun, 3 Jan 2016, SF Markus Elfring wrote: > >> Pass the address of the data structure element "time" directly in calls > >> of the function "rtc_update_irq" instead of an extra initialisation > >> for one local variable at the beginning. > > > > Why is it better? > > I suggest to refer to the data item "rtc_data->rtc" directly because > the variable "rtc" was read only in two if branches. > Does it make sense then to reduce the variable allocation? No. That is the job of the compiler. For a local variable whose address is never taken, the compiler can easily detect its live region, and place the initialization in an optimal way. julia ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 7/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_interrupt() 2016-01-03 8:56 ` [rtc-linux] " SF Markus Elfring (?) @ 2016-01-03 12:48 ` Julia Lawall -1 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2016-01-03 12:48 UTC (permalink / raw) To: SF Markus Elfring Cc: rtc-linux, Alessandro Zummo, Alexandre Belloni, LKML, kernel-janitors, Julia Lawall On Sun, 3 Jan 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 3 Jan 2016 09:00:30 +0100 > > Pass the address of the data structure element "time" directly in calls > of the function "rtc_update_irq" instead of an extra initialisation > for one local variable at the beginning. Also, I don't see anything related to time in this patch. julia > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/rtc/rtc-ab-b5ze-s3.c | 7 ++----- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c > index e3a015a..88f1d0b 100644 > --- a/drivers/rtc/rtc-ab-b5ze-s3.c > +++ b/drivers/rtc/rtc-ab-b5ze-s3.c > @@ -816,7 +816,6 @@ static irqreturn_t _abb5zes3_rtc_interrupt(int irq, void *data) > struct i2c_client *client = data; > struct device *dev = &client->dev; > struct abb5zes3_rtc_data *rtc_data = dev_get_drvdata(dev); > - struct rtc_device *rtc = rtc_data->rtc; > u8 regs[ABB5ZES3_CTRL_SEC_LEN]; > int ret, handled = IRQ_NONE; > > @@ -844,8 +843,7 @@ static irqreturn_t _abb5zes3_rtc_interrupt(int irq, void *data) > /* Check alarm flag */ > if (regs[ABB5ZES3_REG_CTRL2] & ABB5ZES3_REG_CTRL2_AF) { > dev_dbg(dev, "RTC alarm!\n"); > - > - rtc_update_irq(rtc, 1, RTC_IRQF | RTC_AF); > + rtc_update_irq(rtc_data->rtc, 1, RTC_IRQF | RTC_AF); > > /* Acknowledge and disable the alarm */ > _abb5zes3_rtc_clear_alarm(dev); > @@ -857,8 +855,7 @@ static irqreturn_t _abb5zes3_rtc_interrupt(int irq, void *data) > /* Check watchdog Timer A flag */ > if (regs[ABB5ZES3_REG_CTRL2] & ABB5ZES3_REG_CTRL2_WTAF) { > dev_dbg(dev, "RTC timer!\n"); > - > - rtc_update_irq(rtc, 1, RTC_IRQF | RTC_AF); > + rtc_update_irq(rtc_data->rtc, 1, RTC_IRQF | RTC_AF); > > /* > * Acknowledge and disable the alarm. Note: WTAF > -- > 2.6.3 > > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 7/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_interrupt() @ 2016-01-03 12:48 ` Julia Lawall 0 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2016-01-03 12:48 UTC (permalink / raw) To: SF Markus Elfring Cc: rtc-linux, Alessandro Zummo, Alexandre Belloni, LKML, kernel-janitors, Julia Lawall On Sun, 3 Jan 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 3 Jan 2016 09:00:30 +0100 > > Pass the address of the data structure element "time" directly in calls > of the function "rtc_update_irq" instead of an extra initialisation > for one local variable at the beginning. Also, I don't see anything related to time in this patch. julia > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/rtc/rtc-ab-b5ze-s3.c | 7 ++----- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c > index e3a015a..88f1d0b 100644 > --- a/drivers/rtc/rtc-ab-b5ze-s3.c > +++ b/drivers/rtc/rtc-ab-b5ze-s3.c > @@ -816,7 +816,6 @@ static irqreturn_t _abb5zes3_rtc_interrupt(int irq, void *data) > struct i2c_client *client = data; > struct device *dev = &client->dev; > struct abb5zes3_rtc_data *rtc_data = dev_get_drvdata(dev); > - struct rtc_device *rtc = rtc_data->rtc; > u8 regs[ABB5ZES3_CTRL_SEC_LEN]; > int ret, handled = IRQ_NONE; > > @@ -844,8 +843,7 @@ static irqreturn_t _abb5zes3_rtc_interrupt(int irq, void *data) > /* Check alarm flag */ > if (regs[ABB5ZES3_REG_CTRL2] & ABB5ZES3_REG_CTRL2_AF) { > dev_dbg(dev, "RTC alarm!\n"); > - > - rtc_update_irq(rtc, 1, RTC_IRQF | RTC_AF); > + rtc_update_irq(rtc_data->rtc, 1, RTC_IRQF | RTC_AF); > > /* Acknowledge and disable the alarm */ > _abb5zes3_rtc_clear_alarm(dev); > @@ -857,8 +855,7 @@ static irqreturn_t _abb5zes3_rtc_interrupt(int irq, void *data) > /* Check watchdog Timer A flag */ > if (regs[ABB5ZES3_REG_CTRL2] & ABB5ZES3_REG_CTRL2_WTAF) { > dev_dbg(dev, "RTC timer!\n"); > - > - rtc_update_irq(rtc, 1, RTC_IRQF | RTC_AF); > + rtc_update_irq(rtc_data->rtc, 1, RTC_IRQF | RTC_AF); > > /* > * Acknowledge and disable the alarm. Note: WTAF > -- > 2.6.3 > > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [rtc-linux] Re: [PATCH 7/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_interrupt() @ 2016-01-03 12:48 ` Julia Lawall 0 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2016-01-03 12:48 UTC (permalink / raw) To: SF Markus Elfring Cc: rtc-linux, Alessandro Zummo, Alexandre Belloni, LKML, kernel-janitors, Julia Lawall On Sun, 3 Jan 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 3 Jan 2016 09:00:30 +0100 > > Pass the address of the data structure element "time" directly in calls > of the function "rtc_update_irq" instead of an extra initialisation > for one local variable at the beginning. Also, I don't see anything related to time in this patch. julia > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/rtc/rtc-ab-b5ze-s3.c | 7 ++----- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c > index e3a015a..88f1d0b 100644 > --- a/drivers/rtc/rtc-ab-b5ze-s3.c > +++ b/drivers/rtc/rtc-ab-b5ze-s3.c > @@ -816,7 +816,6 @@ static irqreturn_t _abb5zes3_rtc_interrupt(int irq, void *data) > struct i2c_client *client = data; > struct device *dev = &client->dev; > struct abb5zes3_rtc_data *rtc_data = dev_get_drvdata(dev); > - struct rtc_device *rtc = rtc_data->rtc; > u8 regs[ABB5ZES3_CTRL_SEC_LEN]; > int ret, handled = IRQ_NONE; > > @@ -844,8 +843,7 @@ static irqreturn_t _abb5zes3_rtc_interrupt(int irq, void *data) > /* Check alarm flag */ > if (regs[ABB5ZES3_REG_CTRL2] & ABB5ZES3_REG_CTRL2_AF) { > dev_dbg(dev, "RTC alarm!\n"); > - > - rtc_update_irq(rtc, 1, RTC_IRQF | RTC_AF); > + rtc_update_irq(rtc_data->rtc, 1, RTC_IRQF | RTC_AF); > > /* Acknowledge and disable the alarm */ > _abb5zes3_rtc_clear_alarm(dev); > @@ -857,8 +855,7 @@ static irqreturn_t _abb5zes3_rtc_interrupt(int irq, void *data) > /* Check watchdog Timer A flag */ > if (regs[ABB5ZES3_REG_CTRL2] & ABB5ZES3_REG_CTRL2_WTAF) { > dev_dbg(dev, "RTC timer!\n"); > - > - rtc_update_irq(rtc, 1, RTC_IRQF | RTC_AF); > + rtc_update_irq(rtc_data->rtc, 1, RTC_IRQF | RTC_AF); > > /* > * Acknowledge and disable the alarm. Note: WTAF > -- > 2.6.3 > > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 7/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_interrupt() 2016-01-03 12:48 ` [rtc-linux] " Julia Lawall (?) @ 2016-01-03 17:00 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 17:00 UTC (permalink / raw) To: Julia Lawall Cc: rtc-linux, Alessandro Zummo, Alexandre Belloni, LKML, kernel-janitors >> Pass the address of the data structure element "time" directly in calls >> of the function "rtc_update_irq" instead of an extra initialisation >> for one local variable at the beginning. > > Also, I don't see anything related to time in this patch. I should have referred to the data structure element "rtc" here. Should I resend this patch series with a corrected commit message now? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 7/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_interrupt() @ 2016-01-03 17:00 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 17:00 UTC (permalink / raw) To: Julia Lawall Cc: rtc-linux, Alessandro Zummo, Alexandre Belloni, LKML, kernel-janitors >> Pass the address of the data structure element "time" directly in calls >> of the function "rtc_update_irq" instead of an extra initialisation >> for one local variable at the beginning. > > Also, I don't see anything related to time in this patch. I should have referred to the data structure element "rtc" here. Should I resend this patch series with a corrected commit message now? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [rtc-linux] Re: [PATCH 7/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_interrupt() @ 2016-01-03 17:00 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 17:00 UTC (permalink / raw) To: Julia Lawall Cc: rtc-linux, Alessandro Zummo, Alexandre Belloni, LKML, kernel-janitors >> Pass the address of the data structure element "time" directly in calls >> of the function "rtc_update_irq" instead of an extra initialisation >> for one local variable at the beginning. > > Also, I don't see anything related to time in this patch. I should have referred to the data structure element "rtc" here. Should I resend this patch series with a corrected commit message now? Regards, Markus -- -- You received this message because you are subscribed to "rtc-linux". Membership options at http://groups.google.com/group/rtc-linux . Please read http://groups.google.com/group/rtc-linux/web/checklist before submitting a driver. --- You received this message because you are subscribed to the Google Groups "rtc-linux" group. To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 8/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_set_timer() 2016-01-03 8:43 ` [rtc-linux] " SF Markus Elfring (?) @ 2016-01-03 8:57 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 8:57 UTC (permalink / raw) To: rtc-linux, Alessandro Zummo, Alexandre Belloni Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 3 Jan 2016 09:19:32 +0100 Pass a value directly in a call of the function "regmap_update_bits" instead of an extra initialisation for one local variable at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/rtc/rtc-ab-b5ze-s3.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c index 88f1d0b..fed52d0 100644 --- a/drivers/rtc/rtc-ab-b5ze-s3.c +++ b/drivers/rtc/rtc-ab-b5ze-s3.c @@ -561,7 +561,6 @@ static int _abb5zes3_rtc_set_timer(struct device *dev, struct rtc_wkalrm *alarm, { struct abb5zes3_rtc_data *data = dev_get_drvdata(dev); u8 regs[ABB5ZES3_TIMA_SEC_LEN]; - u8 mask = ABB5ZES3_REG_TIM_CLK_TAC0 | ABB5ZES3_REG_TIM_CLK_TAC1; int ret; /* Program given number of seconds to Timer A registers */ @@ -575,7 +574,9 @@ static int _abb5zes3_rtc_set_timer(struct device *dev, struct rtc_wkalrm *alarm, /* Configure Timer A as a watchdog timer */ ret = regmap_update_bits(data->regmap, ABB5ZES3_REG_TIM_CLK, - mask, ABB5ZES3_REG_TIM_CLK_TAC1); + ABB5ZES3_REG_TIM_CLK_TAC0 + | ABB5ZES3_REG_TIM_CLK_TAC1, + ABB5ZES3_REG_TIM_CLK_TAC1); if (ret) dev_err(dev, "%s: failed to update timer\n", __func__); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 8/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_set_timer() @ 2016-01-03 8:57 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 8:57 UTC (permalink / raw) To: rtc-linux, Alessandro Zummo, Alexandre Belloni Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 3 Jan 2016 09:19:32 +0100 Pass a value directly in a call of the function "regmap_update_bits" instead of an extra initialisation for one local variable at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/rtc/rtc-ab-b5ze-s3.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c index 88f1d0b..fed52d0 100644 --- a/drivers/rtc/rtc-ab-b5ze-s3.c +++ b/drivers/rtc/rtc-ab-b5ze-s3.c @@ -561,7 +561,6 @@ static int _abb5zes3_rtc_set_timer(struct device *dev, struct rtc_wkalrm *alarm, { struct abb5zes3_rtc_data *data = dev_get_drvdata(dev); u8 regs[ABB5ZES3_TIMA_SEC_LEN]; - u8 mask = ABB5ZES3_REG_TIM_CLK_TAC0 | ABB5ZES3_REG_TIM_CLK_TAC1; int ret; /* Program given number of seconds to Timer A registers */ @@ -575,7 +574,9 @@ static int _abb5zes3_rtc_set_timer(struct device *dev, struct rtc_wkalrm *alarm, /* Configure Timer A as a watchdog timer */ ret = regmap_update_bits(data->regmap, ABB5ZES3_REG_TIM_CLK, - mask, ABB5ZES3_REG_TIM_CLK_TAC1); + ABB5ZES3_REG_TIM_CLK_TAC0 + | ABB5ZES3_REG_TIM_CLK_TAC1, + ABB5ZES3_REG_TIM_CLK_TAC1); if (ret) dev_err(dev, "%s: failed to update timer\n", __func__); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [rtc-linux] [PATCH 8/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_set_timer() @ 2016-01-03 8:57 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 8:57 UTC (permalink / raw) To: rtc-linux, Alessandro Zummo, Alexandre Belloni Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 3 Jan 2016 09:19:32 +0100 Pass a value directly in a call of the function "regmap_update_bits" instead of an extra initialisation for one local variable at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/rtc/rtc-ab-b5ze-s3.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c index 88f1d0b..fed52d0 100644 --- a/drivers/rtc/rtc-ab-b5ze-s3.c +++ b/drivers/rtc/rtc-ab-b5ze-s3.c @@ -561,7 +561,6 @@ static int _abb5zes3_rtc_set_timer(struct device *dev, struct rtc_wkalrm *alarm, { struct abb5zes3_rtc_data *data = dev_get_drvdata(dev); u8 regs[ABB5ZES3_TIMA_SEC_LEN]; - u8 mask = ABB5ZES3_REG_TIM_CLK_TAC0 | ABB5ZES3_REG_TIM_CLK_TAC1; int ret; /* Program given number of seconds to Timer A registers */ @@ -575,7 +574,9 @@ static int _abb5zes3_rtc_set_timer(struct device *dev, struct rtc_wkalrm *alarm, /* Configure Timer A as a watchdog timer */ ret = regmap_update_bits(data->regmap, ABB5ZES3_REG_TIM_CLK, - mask, ABB5ZES3_REG_TIM_CLK_TAC1); + ABB5ZES3_REG_TIM_CLK_TAC0 + | ABB5ZES3_REG_TIM_CLK_TAC1, + ABB5ZES3_REG_TIM_CLK_TAC1); if (ret) dev_err(dev, "%s: failed to update timer\n", __func__); -- 2.6.3 -- -- You received this message because you are subscribed to "rtc-linux". Membership options at http://groups.google.com/group/rtc-linux . Please read http://groups.google.com/group/rtc-linux/web/checklist before submitting a driver. --- You received this message because you are subscribed to the Google Groups "rtc-linux" group. To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 8/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_set_timer() 2016-01-03 8:57 ` [rtc-linux] " SF Markus Elfring (?) @ 2016-01-03 12:47 ` Julia Lawall -1 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2016-01-03 12:47 UTC (permalink / raw) To: SF Markus Elfring Cc: rtc-linux, Alessandro Zummo, Alexandre Belloni, LKML, kernel-janitors, Julia Lawall On Sun, 3 Jan 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 3 Jan 2016 09:19:32 +0100 > > Pass a value directly in a call of the function "regmap_update_bits" > instead of an extra initialisation for one local variable at the beginning. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/rtc/rtc-ab-b5ze-s3.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c > index 88f1d0b..fed52d0 100644 > --- a/drivers/rtc/rtc-ab-b5ze-s3.c > +++ b/drivers/rtc/rtc-ab-b5ze-s3.c > @@ -561,7 +561,6 @@ static int _abb5zes3_rtc_set_timer(struct device *dev, struct rtc_wkalrm *alarm, > { > struct abb5zes3_rtc_data *data = dev_get_drvdata(dev); > u8 regs[ABB5ZES3_TIMA_SEC_LEN]; > - u8 mask = ABB5ZES3_REG_TIM_CLK_TAC0 | ABB5ZES3_REG_TIM_CLK_TAC1; > int ret; > > /* Program given number of seconds to Timer A registers */ > @@ -575,7 +574,9 @@ static int _abb5zes3_rtc_set_timer(struct device *dev, struct rtc_wkalrm *alarm, > > /* Configure Timer A as a watchdog timer */ > ret = regmap_update_bits(data->regmap, ABB5ZES3_REG_TIM_CLK, > - mask, ABB5ZES3_REG_TIM_CLK_TAC1); > + ABB5ZES3_REG_TIM_CLK_TAC0 > + | ABB5ZES3_REG_TIM_CLK_TAC1, > + ABB5ZES3_REG_TIM_CLK_TAC1); This doesn't seem like an improvement. The concept (mask) has disappeared, the binary operation is strangely broken, and the function call has one more line of arguments, which all look sort of the same and thus are hard to understand. Don't underestimate the value of naming things. julia > if (ret) > dev_err(dev, "%s: failed to update timer\n", __func__); > > -- > 2.6.3 > > -- > To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 8/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_set_timer() @ 2016-01-03 12:47 ` Julia Lawall 0 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2016-01-03 12:47 UTC (permalink / raw) To: SF Markus Elfring Cc: rtc-linux, Alessandro Zummo, Alexandre Belloni, LKML, kernel-janitors, Julia Lawall On Sun, 3 Jan 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 3 Jan 2016 09:19:32 +0100 > > Pass a value directly in a call of the function "regmap_update_bits" > instead of an extra initialisation for one local variable at the beginning. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/rtc/rtc-ab-b5ze-s3.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c > index 88f1d0b..fed52d0 100644 > --- a/drivers/rtc/rtc-ab-b5ze-s3.c > +++ b/drivers/rtc/rtc-ab-b5ze-s3.c > @@ -561,7 +561,6 @@ static int _abb5zes3_rtc_set_timer(struct device *dev, struct rtc_wkalrm *alarm, > { > struct abb5zes3_rtc_data *data = dev_get_drvdata(dev); > u8 regs[ABB5ZES3_TIMA_SEC_LEN]; > - u8 mask = ABB5ZES3_REG_TIM_CLK_TAC0 | ABB5ZES3_REG_TIM_CLK_TAC1; > int ret; > > /* Program given number of seconds to Timer A registers */ > @@ -575,7 +574,9 @@ static int _abb5zes3_rtc_set_timer(struct device *dev, struct rtc_wkalrm *alarm, > > /* Configure Timer A as a watchdog timer */ > ret = regmap_update_bits(data->regmap, ABB5ZES3_REG_TIM_CLK, > - mask, ABB5ZES3_REG_TIM_CLK_TAC1); > + ABB5ZES3_REG_TIM_CLK_TAC0 > + | ABB5ZES3_REG_TIM_CLK_TAC1, > + ABB5ZES3_REG_TIM_CLK_TAC1); This doesn't seem like an improvement. The concept (mask) has disappeared, the binary operation is strangely broken, and the function call has one more line of arguments, which all look sort of the same and thus are hard to understand. Don't underestimate the value of naming things. julia > if (ret) > dev_err(dev, "%s: failed to update timer\n", __func__); > > -- > 2.6.3 > > -- > To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [rtc-linux] Re: [PATCH 8/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_set_timer() @ 2016-01-03 12:47 ` Julia Lawall 0 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2016-01-03 12:47 UTC (permalink / raw) To: SF Markus Elfring Cc: rtc-linux, Alessandro Zummo, Alexandre Belloni, LKML, kernel-janitors, Julia Lawall On Sun, 3 Jan 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 3 Jan 2016 09:19:32 +0100 > > Pass a value directly in a call of the function "regmap_update_bits" > instead of an extra initialisation for one local variable at the beginning. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/rtc/rtc-ab-b5ze-s3.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c > index 88f1d0b..fed52d0 100644 > --- a/drivers/rtc/rtc-ab-b5ze-s3.c > +++ b/drivers/rtc/rtc-ab-b5ze-s3.c > @@ -561,7 +561,6 @@ static int _abb5zes3_rtc_set_timer(struct device *dev, struct rtc_wkalrm *alarm, > { > struct abb5zes3_rtc_data *data = dev_get_drvdata(dev); > u8 regs[ABB5ZES3_TIMA_SEC_LEN]; > - u8 mask = ABB5ZES3_REG_TIM_CLK_TAC0 | ABB5ZES3_REG_TIM_CLK_TAC1; > int ret; > > /* Program given number of seconds to Timer A registers */ > @@ -575,7 +574,9 @@ static int _abb5zes3_rtc_set_timer(struct device *dev, struct rtc_wkalrm *alarm, > > /* Configure Timer A as a watchdog timer */ > ret = regmap_update_bits(data->regmap, ABB5ZES3_REG_TIM_CLK, > - mask, ABB5ZES3_REG_TIM_CLK_TAC1); > + ABB5ZES3_REG_TIM_CLK_TAC0 > + | ABB5ZES3_REG_TIM_CLK_TAC1, > + ABB5ZES3_REG_TIM_CLK_TAC1); This doesn't seem like an improvement. The concept (mask) has disappeared, the binary operation is strangely broken, and the function call has one more line of arguments, which all look sort of the same and thus are hard to understand. Don't underestimate the value of naming things. julia > if (ret) > dev_err(dev, "%s: failed to update timer\n", __func__); > > -- > 2.6.3 > > -- > To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 8/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_set_timer() 2016-01-03 12:47 ` [rtc-linux] " Julia Lawall (?) @ 2016-01-03 17:25 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 17:25 UTC (permalink / raw) To: Julia Lawall Cc: rtc-linux, Alessandro Zummo, Alexandre Belloni, LKML, kernel-janitors >> ret = regmap_update_bits(data->regmap, ABB5ZES3_REG_TIM_CLK, >> - mask, ABB5ZES3_REG_TIM_CLK_TAC1); >> + ABB5ZES3_REG_TIM_CLK_TAC0 >> + | ABB5ZES3_REG_TIM_CLK_TAC1, >> + ABB5ZES3_REG_TIM_CLK_TAC1); > > This doesn't seem like an improvement. Interesting … > The concept (mask) has disappeared, I suggest to drop another local variable. Can the operator "Bitwise OR" be sufficient to indicate the concept "mask"? > the binary operation is strangely broken, Do you prefer an other source code formatting within the usual line length range? > and the function call has one more line of arguments, How should several long preprocessor symbols be combined together with indentation so that they will fit into the limit of 80 characters? > which all look sort of the same and thus are hard to understand. Is this an usual consequence from an ordinary name pattern? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 8/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_set_timer() @ 2016-01-03 17:25 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 17:25 UTC (permalink / raw) To: Julia Lawall Cc: rtc-linux, Alessandro Zummo, Alexandre Belloni, LKML, kernel-janitors >> ret = regmap_update_bits(data->regmap, ABB5ZES3_REG_TIM_CLK, >> - mask, ABB5ZES3_REG_TIM_CLK_TAC1); >> + ABB5ZES3_REG_TIM_CLK_TAC0 >> + | ABB5ZES3_REG_TIM_CLK_TAC1, >> + ABB5ZES3_REG_TIM_CLK_TAC1); > > This doesn't seem like an improvement. Interesting … > The concept (mask) has disappeared, I suggest to drop another local variable. Can the operator "Bitwise OR" be sufficient to indicate the concept "mask"? > the binary operation is strangely broken, Do you prefer an other source code formatting within the usual line length range? > and the function call has one more line of arguments, How should several long preprocessor symbols be combined together with indentation so that they will fit into the limit of 80 characters? > which all look sort of the same and thus are hard to understand. Is this an usual consequence from an ordinary name pattern? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [rtc-linux] Re: [PATCH 8/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_set_timer() @ 2016-01-03 17:25 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 17:25 UTC (permalink / raw) To: Julia Lawall Cc: rtc-linux, Alessandro Zummo, Alexandre Belloni, LKML, kernel-janitors >> ret =3D regmap_update_bits(data->regmap, ABB5ZES3_REG_TIM_CLK, >> - mask, ABB5ZES3_REG_TIM_CLK_TAC1); >> + ABB5ZES3_REG_TIM_CLK_TAC0 >> + | ABB5ZES3_REG_TIM_CLK_TAC1, >> + ABB5ZES3_REG_TIM_CLK_TAC1); >=20 > This doesn't seem like an improvement. Interesting =E2=80=A6 > The concept (mask) has disappeared, I suggest to drop another local variable. Can the operator "Bitwise OR" be sufficient to indicate the concept "mask"? > the binary operation is strangely broken, Do you prefer an other source code formatting within the usual line length = range? > and the function call has one more line of arguments, How should several long preprocessor symbols be combined together with inde= ntation so that they will fit into the limit of 80 characters? > which all look sort of the same and thus are hard to understand. Is this an usual consequence from an ordinary name pattern? Regards, Markus --=20 --=20 You received this message because you are subscribed to "rtc-linux". Membership options at http://groups.google.com/group/rtc-linux . Please read http://groups.google.com/group/rtc-linux/web/checklist before submitting a driver. ---=20 You received this message because you are subscribed to the Google Groups "= rtc-linux" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to rtc-linux+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 8/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_set_timer() 2016-01-03 17:25 ` [rtc-linux] " SF Markus Elfring (?) @ 2016-01-03 17:29 ` Julia Lawall -1 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2016-01-03 17:29 UTC (permalink / raw) To: SF Markus Elfring Cc: Julia Lawall, rtc-linux, Alessandro Zummo, Alexandre Belloni, LKML, kernel-janitors [-- Attachment #1: Type: TEXT/PLAIN, Size: 1155 bytes --] On Sun, 3 Jan 2016, SF Markus Elfring wrote: > >> ret = regmap_update_bits(data->regmap, ABB5ZES3_REG_TIM_CLK, > >> - mask, ABB5ZES3_REG_TIM_CLK_TAC1); > >> + ABB5ZES3_REG_TIM_CLK_TAC0 > >> + | ABB5ZES3_REG_TIM_CLK_TAC1, > >> + ABB5ZES3_REG_TIM_CLK_TAC1); > > > > This doesn't seem like an improvement. > > Interesting … > > > > The concept (mask) has disappeared, > > I suggest to drop another local variable. > Can the operator "Bitwise OR" be sufficient to indicate the concept "mask"? > > > > the binary operation is strangely broken, > > Do you prefer an other source code formatting within the usual line length range? > > > > and the function call has one more line of arguments, > > How should several long preprocessor symbols be combined together with indentation > so that they will fit into the limit of 80 characters? > > > > which all look sort of the same and thus are hard to understand. > > Is this an usual consequence from an ordinary name pattern? The original code was better. No 80 character problem, easy to distinguish one argument from another, moderately meaningful variable name, etc. julia ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 8/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_set_timer() @ 2016-01-03 17:29 ` Julia Lawall 0 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2016-01-03 17:29 UTC (permalink / raw) To: SF Markus Elfring Cc: Julia Lawall, rtc-linux, Alessandro Zummo, Alexandre Belloni, LKML, kernel-janitors [-- Attachment #1: Type: TEXT/PLAIN, Size: 1193 bytes --] On Sun, 3 Jan 2016, SF Markus Elfring wrote: > >> ret = regmap_update_bits(data->regmap, ABB5ZES3_REG_TIM_CLK, > >> - mask, ABB5ZES3_REG_TIM_CLK_TAC1); > >> + ABB5ZES3_REG_TIM_CLK_TAC0 > >> + | ABB5ZES3_REG_TIM_CLK_TAC1, > >> + ABB5ZES3_REG_TIM_CLK_TAC1); > > > > This doesn't seem like an improvement. > > Interesting … > > > > The concept (mask) has disappeared, > > I suggest to drop another local variable. > Can the operator "Bitwise OR" be sufficient to indicate the concept "mask"? > > > > the binary operation is strangely broken, > > Do you prefer an other source code formatting within the usual line length range? > > > > and the function call has one more line of arguments, > > How should several long preprocessor symbols be combined together with indentation > so that they will fit into the limit of 80 characters? > > > > which all look sort of the same and thus are hard to understand. > > Is this an usual consequence from an ordinary name pattern? The original code was better. No 80 character problem, easy to distinguish one argument from another, moderately meaningful variable name, etc. julia ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [rtc-linux] Re: [PATCH 8/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_set_timer() @ 2016-01-03 17:29 ` Julia Lawall 0 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2016-01-03 17:29 UTC (permalink / raw) To: SF Markus Elfring Cc: Julia Lawall, rtc-linux, Alessandro Zummo, Alexandre Belloni, LKML, kernel-janitors [-- Attachment #1: Type: TEXT/PLAIN, Size: 1155 bytes --] On Sun, 3 Jan 2016, SF Markus Elfring wrote: > >> ret = regmap_update_bits(data->regmap, ABB5ZES3_REG_TIM_CLK, > >> - mask, ABB5ZES3_REG_TIM_CLK_TAC1); > >> + ABB5ZES3_REG_TIM_CLK_TAC0 > >> + | ABB5ZES3_REG_TIM_CLK_TAC1, > >> + ABB5ZES3_REG_TIM_CLK_TAC1); > > > > This doesn't seem like an improvement. > > Interesting … > > > > The concept (mask) has disappeared, > > I suggest to drop another local variable. > Can the operator "Bitwise OR" be sufficient to indicate the concept "mask"? > > > > the binary operation is strangely broken, > > Do you prefer an other source code formatting within the usual line length range? > > > > and the function call has one more line of arguments, > > How should several long preprocessor symbols be combined together with indentation > so that they will fit into the limit of 80 characters? > > > > which all look sort of the same and thus are hard to understand. > > Is this an usual consequence from an ordinary name pattern? The original code was better. No 80 character problem, easy to distinguish one argument from another, moderately meaningful variable name, etc. julia ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/2] 390/qeth: Fine-tuning for qeth_core_set_online() 2015-12-11 12:08 ` SF Markus Elfring @ 2016-01-03 10:00 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 10:00 UTC (permalink / raw) To: linux-s390, Heiko Carstens, Martin Schwidefsky, Ursula Braun Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 3 Jan 2016 10:56:45 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an unnecessary variable initialisation Refactoring drivers/s390/net/qeth_core_main.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/2] 390/qeth: Fine-tuning for qeth_core_set_online() @ 2016-01-03 10:00 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 10:00 UTC (permalink / raw) To: linux-s390, Heiko Carstens, Martin Schwidefsky, Ursula Braun Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 3 Jan 2016 10:56:45 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an unnecessary variable initialisation Refactoring drivers/s390/net/qeth_core_main.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) -- 2.6.3 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 1/2] 390/qeth: Delete an unnecessary variable initialisation in qeth_core_set_online() 2016-01-03 10:00 ` SF Markus Elfring @ 2016-01-03 10:02 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 10:02 UTC (permalink / raw) To: linux-s390, Heiko Carstens, Martin Schwidefsky, Ursula Braun Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 3 Jan 2016 10:48:05 +0100 Omit explicit initialisation at the beginning for one local variable that is redefined before its first use. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/s390/net/qeth_core_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/s390/net/qeth_core_main.c b/drivers/s390/net/qeth_core_main.c index 7871537..54fde2e 100644 --- a/drivers/s390/net/qeth_core_main.c +++ b/drivers/s390/net/qeth_core_main.c @@ -5637,7 +5637,7 @@ static void qeth_core_remove_device(struct ccwgroup_device *gdev) static int qeth_core_set_online(struct ccwgroup_device *gdev) { struct qeth_card *card = dev_get_drvdata(&gdev->dev); - int rc = 0; + int rc; int def_discipline; if (!card->discipline) { -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 1/2] 390/qeth: Delete an unnecessary variable initialisation in qeth_core_set_online() @ 2016-01-03 10:02 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 10:02 UTC (permalink / raw) To: linux-s390, Heiko Carstens, Martin Schwidefsky, Ursula Braun Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 3 Jan 2016 10:48:05 +0100 Omit explicit initialisation at the beginning for one local variable that is redefined before its first use. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/s390/net/qeth_core_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/s390/net/qeth_core_main.c b/drivers/s390/net/qeth_core_main.c index 7871537..54fde2e 100644 --- a/drivers/s390/net/qeth_core_main.c +++ b/drivers/s390/net/qeth_core_main.c @@ -5637,7 +5637,7 @@ static void qeth_core_remove_device(struct ccwgroup_device *gdev) static int qeth_core_set_online(struct ccwgroup_device *gdev) { struct qeth_card *card = dev_get_drvdata(&gdev->dev); - int rc = 0; + int rc; int def_discipline; if (!card->discipline) { -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/2] 390/qeth: Delete an unnecessary variable initialisation in qeth_core_set_online() 2016-01-03 10:02 ` SF Markus Elfring @ 2016-01-04 11:29 ` Heiko Carstens -1 siblings, 0 replies; 3089+ messages in thread From: Heiko Carstens @ 2016-01-04 11:29 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-s390, Martin Schwidefsky, Ursula Braun, LKML, kernel-janitors, Julia Lawall On Sun, Jan 03, 2016 at 11:02:00AM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 3 Jan 2016 10:48:05 +0100 > > Omit explicit initialisation at the beginning for one local variable > that is redefined before its first use. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/s390/net/qeth_core_main.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/s390/net/qeth_core_main.c b/drivers/s390/net/qeth_core_main.c > index 7871537..54fde2e 100644 > --- a/drivers/s390/net/qeth_core_main.c > +++ b/drivers/s390/net/qeth_core_main.c > @@ -5637,7 +5637,7 @@ static void qeth_core_remove_device(struct ccwgroup_device *gdev) > static int qeth_core_set_online(struct ccwgroup_device *gdev) > { > struct qeth_card *card = dev_get_drvdata(&gdev->dev); > - int rc = 0; > + int rc; > int def_discipline; You can generate hundreds of patches like this one. There are even plenty more opportunities within this same file. I don't think we need this. If at all then change all occurrences within a file at once, but that is Ursula's call. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/2] 390/qeth: Delete an unnecessary variable initialisation in qeth_core_set_online() @ 2016-01-04 11:29 ` Heiko Carstens 0 siblings, 0 replies; 3089+ messages in thread From: Heiko Carstens @ 2016-01-04 11:29 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-s390, Martin Schwidefsky, Ursula Braun, LKML, kernel-janitors, Julia Lawall On Sun, Jan 03, 2016 at 11:02:00AM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 3 Jan 2016 10:48:05 +0100 > > Omit explicit initialisation at the beginning for one local variable > that is redefined before its first use. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/s390/net/qeth_core_main.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/s390/net/qeth_core_main.c b/drivers/s390/net/qeth_core_main.c > index 7871537..54fde2e 100644 > --- a/drivers/s390/net/qeth_core_main.c > +++ b/drivers/s390/net/qeth_core_main.c > @@ -5637,7 +5637,7 @@ static void qeth_core_remove_device(struct ccwgroup_device *gdev) > static int qeth_core_set_online(struct ccwgroup_device *gdev) > { > struct qeth_card *card = dev_get_drvdata(&gdev->dev); > - int rc = 0; > + int rc; > int def_discipline; You can generate hundreds of patches like this one. There are even plenty more opportunities within this same file. I don't think we need this. If at all then change all occurrences within a file at once, but that is Ursula's call. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/2] 390/qeth: Delete an unnecessary variable initialisation in qeth_core_set_online() 2016-01-03 10:02 ` SF Markus Elfring @ 2016-01-07 14:33 ` Ursula Braun -1 siblings, 0 replies; 3089+ messages in thread From: Ursula Braun @ 2016-01-07 14:33 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-s390, Heiko Carstens, Martin Schwidefsky, LKML, kernel-janitors, Julia Lawall On Sun, 2016-01-03 at 11:02 +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 3 Jan 2016 10:48:05 +0100 > > Omit explicit initialisation at the beginning for one local variable > that is redefined before its first use. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/s390/net/qeth_core_main.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/s390/net/qeth_core_main.c b/drivers/s390/net/qeth_core_main.c > index 7871537..54fde2e 100644 > --- a/drivers/s390/net/qeth_core_main.c > +++ b/drivers/s390/net/qeth_core_main.c > @@ -5637,7 +5637,7 @@ static void qeth_core_remove_device(struct ccwgroup_device *gdev) > static int qeth_core_set_online(struct ccwgroup_device *gdev) > { > struct qeth_card *card = dev_get_drvdata(&gdev->dev); > - int rc = 0; > + int rc; > int def_discipline; > > if (!card->discipline) { As Heiko already answered, you could propose a lot of this kind of changes with just minor benefit. I do not want to push them in single patches. Either there is a cleanup patch for explicit initialisation of local variables in the whole qeth driver, or we take care about such minor changes, once we touch the code anyway due to other reasons. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 1/2] 390/qeth: Delete an unnecessary variable initialisation in qeth_core_set_online() @ 2016-01-07 14:33 ` Ursula Braun 0 siblings, 0 replies; 3089+ messages in thread From: Ursula Braun @ 2016-01-07 14:33 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-s390, Heiko Carstens, Martin Schwidefsky, LKML, kernel-janitors, Julia Lawall On Sun, 2016-01-03 at 11:02 +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 3 Jan 2016 10:48:05 +0100 > > Omit explicit initialisation at the beginning for one local variable > that is redefined before its first use. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/s390/net/qeth_core_main.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/s390/net/qeth_core_main.c b/drivers/s390/net/qeth_core_main.c > index 7871537..54fde2e 100644 > --- a/drivers/s390/net/qeth_core_main.c > +++ b/drivers/s390/net/qeth_core_main.c > @@ -5637,7 +5637,7 @@ static void qeth_core_remove_device(struct ccwgroup_device *gdev) > static int qeth_core_set_online(struct ccwgroup_device *gdev) > { > struct qeth_card *card = dev_get_drvdata(&gdev->dev); > - int rc = 0; > + int rc; > int def_discipline; > > if (!card->discipline) { As Heiko already answered, you could propose a lot of this kind of changes with just minor benefit. I do not want to push them in single patches. Either there is a cleanup patch for explicit initialisation of local variables in the whole qeth driver, or we take care about such minor changes, once we touch the code anyway due to other reasons. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: 390/qeth: Delete an unnecessary variable initialisation in qeth_core_set_online() 2016-01-07 14:33 ` Ursula Braun @ 2016-01-08 7:18 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-08 7:18 UTC (permalink / raw) To: Ursula Braun Cc: linux-s390, Heiko Carstens, Martin Schwidefsky, LKML, kernel-janitors, Julia Lawall > As Heiko already answered, you could propose a lot of this kind of changes > with just minor benefit. I do not want to push them in single patches. Thanks for your clarification. > Either there is a cleanup patch for explicit initialisation of > local variables in the whole qeth driver, Is there any more fine-tuning cooking in the background? > or we take care about such minor changes, once we touch the code anyway How often will this really happen? > due to other reasons. I am curious which ones will trigger further related software improvements. Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: 390/qeth: Delete an unnecessary variable initialisation in qeth_core_set_online() @ 2016-01-08 7:18 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-08 7:18 UTC (permalink / raw) To: Ursula Braun Cc: linux-s390, Heiko Carstens, Martin Schwidefsky, LKML, kernel-janitors, Julia Lawall > As Heiko already answered, you could propose a lot of this kind of changes > with just minor benefit. I do not want to push them in single patches. Thanks for your clarification. > Either there is a cleanup patch for explicit initialisation of > local variables in the whole qeth driver, Is there any more fine-tuning cooking in the background? > or we take care about such minor changes, once we touch the code anyway How often will this really happen? > due to other reasons. I am curious which ones will trigger further related software improvements. Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: 390/qeth: Delete an unnecessary variable initialisation in qeth_core_set_online() 2016-01-08 7:18 ` SF Markus Elfring @ 2016-01-08 8:25 ` Ursula Braun -1 siblings, 0 replies; 3089+ messages in thread From: Ursula Braun @ 2016-01-08 8:25 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-s390, Heiko Carstens, Martin Schwidefsky, LKML, kernel-janitors, Julia Lawall On Fri, 2016-01-08 at 08:18 +0100, SF Markus Elfring wrote: > > As Heiko already answered, you could propose a lot of this kind of changes > > with just minor benefit. I do not want to push them in single patches. > > Thanks for your clarification. > > > > Either there is a cleanup patch for explicit initialisation of > > local variables in the whole qeth driver, > > Is there any more fine-tuning cooking in the background? Not yet; qeth is an important driver for Linux on System z; there are lots of investigation ideas for improvements, which we will take care about according to their priorities. I regard your proposed fine-tuning code change as valid, but prioritize it as one with lowest benefit, since it does not really make a difference once compiled. > > > > or we take care about such minor changes, once we touch the code anyway > > How often will this really happen? There is no general rule. Check our git history to answer this question. > > > > due to other reasons. > > I am curious which ones will trigger further related software improvements. > > Regards, > Markus > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: 390/qeth: Delete an unnecessary variable initialisation in qeth_core_set_online() @ 2016-01-08 8:25 ` Ursula Braun 0 siblings, 0 replies; 3089+ messages in thread From: Ursula Braun @ 2016-01-08 8:25 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-s390, Heiko Carstens, Martin Schwidefsky, LKML, kernel-janitors, Julia Lawall On Fri, 2016-01-08 at 08:18 +0100, SF Markus Elfring wrote: > > As Heiko already answered, you could propose a lot of this kind of changes > > with just minor benefit. I do not want to push them in single patches. > > Thanks for your clarification. > > > > Either there is a cleanup patch for explicit initialisation of > > local variables in the whole qeth driver, > > Is there any more fine-tuning cooking in the background? Not yet; qeth is an important driver for Linux on System z; there are lots of investigation ideas for improvements, which we will take care about according to their priorities. I regard your proposed fine-tuning code change as valid, but prioritize it as one with lowest benefit, since it does not really make a difference once compiled. > > > > or we take care about such minor changes, once we touch the code anyway > > How often will this really happen? There is no general rule. Check our git history to answer this question. > > > > due to other reasons. > > I am curious which ones will trigger further related software improvements. > > Regards, > Markus > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: 390/qeth: Delete an unnecessary variable initialisation in qeth_core_set_online() 2016-01-08 8:25 ` Ursula Braun @ 2016-01-08 12:00 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-08 12:00 UTC (permalink / raw) To: Ursula Braun Cc: linux-s390, Heiko Carstens, Martin Schwidefsky, LKML, kernel-janitors, Julia Lawall >> Is there any more fine-tuning cooking in the background? > Not yet; I am a bit surprised by this information. > qeth is an important driver for Linux on System z; Good to know … > there are lots of investigation ideas for improvements, > which we will take care about according to their priorities. Software development as usual … > I regard your proposed fine-tuning code change as valid, Thanks for a bit of positive feedback. > but prioritize it as one with lowest benefit, This is fine in principle. > since it does not really make a difference once compiled. Would you like to help in the determination if deletion of unnecessary variable initialisations (besides in the implementation of the function "qeth_core_set_online") will result in measurable effects? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: 390/qeth: Delete an unnecessary variable initialisation in qeth_core_set_online() @ 2016-01-08 12:00 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-08 12:00 UTC (permalink / raw) To: Ursula Braun Cc: linux-s390, Heiko Carstens, Martin Schwidefsky, LKML, kernel-janitors, Julia Lawall >> Is there any more fine-tuning cooking in the background? > Not yet; I am a bit surprised by this information. > qeth is an important driver for Linux on System z; Good to know … > there are lots of investigation ideas for improvements, > which we will take care about according to their priorities. Software development as usual … > I regard your proposed fine-tuning code change as valid, Thanks for a bit of positive feedback. > but prioritize it as one with lowest benefit, This is fine in principle. > since it does not really make a difference once compiled. Would you like to help in the determination if deletion of unnecessary variable initialisations (besides in the implementation of the function "qeth_core_set_online") will result in measurable effects? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 2/2] 390/qeth: Refactoring for qeth_core_set_online() 2016-01-03 10:00 ` SF Markus Elfring @ 2016-01-03 10:02 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 10:02 UTC (permalink / raw) To: linux-s390, Heiko Carstens, Martin Schwidefsky, Ursula Braun Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 3 Jan 2016 10:50:11 +0100 Reduce the scope for the local variable "def_discipline" to one branch of an if statement. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/s390/net/qeth_core_main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/s390/net/qeth_core_main.c b/drivers/s390/net/qeth_core_main.c index 54fde2e..3261977 100644 --- a/drivers/s390/net/qeth_core_main.c +++ b/drivers/s390/net/qeth_core_main.c @@ -5638,9 +5638,10 @@ static int qeth_core_set_online(struct ccwgroup_device *gdev) { struct qeth_card *card = dev_get_drvdata(&gdev->dev); int rc; - int def_discipline; if (!card->discipline) { + int def_discipline; + if (card->info.type == QETH_CARD_TYPE_IQD) def_discipline = QETH_DISCIPLINE_LAYER3; else -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 2/2] 390/qeth: Refactoring for qeth_core_set_online() @ 2016-01-03 10:02 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 10:02 UTC (permalink / raw) To: linux-s390, Heiko Carstens, Martin Schwidefsky, Ursula Braun Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 3 Jan 2016 10:50:11 +0100 Reduce the scope for the local variable "def_discipline" to one branch of an if statement. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/s390/net/qeth_core_main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/s390/net/qeth_core_main.c b/drivers/s390/net/qeth_core_main.c index 54fde2e..3261977 100644 --- a/drivers/s390/net/qeth_core_main.c +++ b/drivers/s390/net/qeth_core_main.c @@ -5638,9 +5638,10 @@ static int qeth_core_set_online(struct ccwgroup_device *gdev) { struct qeth_card *card = dev_get_drvdata(&gdev->dev); int rc; - int def_discipline; if (!card->discipline) { + int def_discipline; + if (card->info.type = QETH_CARD_TYPE_IQD) def_discipline = QETH_DISCIPLINE_LAYER3; else -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] 390/qeth: Refactoring for qeth_core_set_online() 2016-01-03 10:02 ` SF Markus Elfring @ 2016-01-04 11:30 ` Heiko Carstens -1 siblings, 0 replies; 3089+ messages in thread From: Heiko Carstens @ 2016-01-04 11:30 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-s390, Martin Schwidefsky, Ursula Braun, LKML, kernel-janitors, Julia Lawall On Sun, Jan 03, 2016 at 11:02:56AM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 3 Jan 2016 10:50:11 +0100 > > Reduce the scope for the local variable "def_discipline" to one branch > of an if statement. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/s390/net/qeth_core_main.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/s390/net/qeth_core_main.c b/drivers/s390/net/qeth_core_main.c > index 54fde2e..3261977 100644 > --- a/drivers/s390/net/qeth_core_main.c > +++ b/drivers/s390/net/qeth_core_main.c > @@ -5638,9 +5638,10 @@ static int qeth_core_set_online(struct ccwgroup_device *gdev) > { > struct qeth_card *card = dev_get_drvdata(&gdev->dev); > int rc; > - int def_discipline; > > if (!card->discipline) { > + int def_discipline; > + > if (card->info.type == QETH_CARD_TYPE_IQD) > def_discipline = QETH_DISCIPLINE_LAYER3; Same here: I don't think we want to start with patches like this. This going to be a never ending story without much benefit. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] 390/qeth: Refactoring for qeth_core_set_online() @ 2016-01-04 11:30 ` Heiko Carstens 0 siblings, 0 replies; 3089+ messages in thread From: Heiko Carstens @ 2016-01-04 11:30 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-s390, Martin Schwidefsky, Ursula Braun, LKML, kernel-janitors, Julia Lawall On Sun, Jan 03, 2016 at 11:02:56AM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 3 Jan 2016 10:50:11 +0100 > > Reduce the scope for the local variable "def_discipline" to one branch > of an if statement. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/s390/net/qeth_core_main.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/s390/net/qeth_core_main.c b/drivers/s390/net/qeth_core_main.c > index 54fde2e..3261977 100644 > --- a/drivers/s390/net/qeth_core_main.c > +++ b/drivers/s390/net/qeth_core_main.c > @@ -5638,9 +5638,10 @@ static int qeth_core_set_online(struct ccwgroup_device *gdev) > { > struct qeth_card *card = dev_get_drvdata(&gdev->dev); > int rc; > - int def_discipline; > > if (!card->discipline) { > + int def_discipline; > + > if (card->info.type = QETH_CARD_TYPE_IQD) > def_discipline = QETH_DISCIPLINE_LAYER3; Same here: I don't think we want to start with patches like this. This going to be a never ending story without much benefit. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] 390/qeth: Refactoring for qeth_core_set_online() 2016-01-04 11:30 ` Heiko Carstens @ 2016-01-04 13:10 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-04 13:10 UTC (permalink / raw) To: Heiko Carstens Cc: linux-s390, Martin Schwidefsky, Ursula Braun, LKML, kernel-janitors, Julia Lawall >> +++ b/drivers/s390/net/qeth_core_main.c >> @@ -5638,9 +5638,10 @@ static int qeth_core_set_online(struct ccwgroup_device *gdev) >> { >> struct qeth_card *card = dev_get_drvdata(&gdev->dev); >> int rc; >> - int def_discipline; >> >> if (!card->discipline) { >> + int def_discipline; >> + >> if (card->info.type == QETH_CARD_TYPE_IQD) >> def_discipline = QETH_DISCIPLINE_LAYER3; > > Same here: I don't think we want to start with patches like this. Thanks for your feedback. > This going to be a never ending story without much benefit. Is the source code a bit clearer and safer if it will be expressed directly that the use of a specific variable is not intended for a complete function implementation but for the smaller scope of an if branch? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] 390/qeth: Refactoring for qeth_core_set_online() @ 2016-01-04 13:10 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-04 13:10 UTC (permalink / raw) To: Heiko Carstens Cc: linux-s390, Martin Schwidefsky, Ursula Braun, LKML, kernel-janitors, Julia Lawall >> +++ b/drivers/s390/net/qeth_core_main.c >> @@ -5638,9 +5638,10 @@ static int qeth_core_set_online(struct ccwgroup_device *gdev) >> { >> struct qeth_card *card = dev_get_drvdata(&gdev->dev); >> int rc; >> - int def_discipline; >> >> if (!card->discipline) { >> + int def_discipline; >> + >> if (card->info.type = QETH_CARD_TYPE_IQD) >> def_discipline = QETH_DISCIPLINE_LAYER3; > > Same here: I don't think we want to start with patches like this. Thanks for your feedback. > This going to be a never ending story without much benefit. Is the source code a bit clearer and safer if it will be expressed directly that the use of a specific variable is not intended for a complete function implementation but for the smaller scope of an if branch? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] 390/qeth: Refactoring for qeth_core_set_online() 2016-01-04 13:10 ` SF Markus Elfring @ 2016-01-04 14:04 ` Heiko Carstens -1 siblings, 0 replies; 3089+ messages in thread From: Heiko Carstens @ 2016-01-04 14:04 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-s390, Martin Schwidefsky, Ursula Braun, LKML, kernel-janitors, Julia Lawall On Mon, Jan 04, 2016 at 02:10:34PM +0100, SF Markus Elfring wrote: > >> +++ b/drivers/s390/net/qeth_core_main.c > >> @@ -5638,9 +5638,10 @@ static int qeth_core_set_online(struct ccwgroup_device *gdev) > >> { > >> struct qeth_card *card = dev_get_drvdata(&gdev->dev); > >> int rc; > >> - int def_discipline; > >> > >> if (!card->discipline) { > >> + int def_discipline; > >> + > >> if (card->info.type == QETH_CARD_TYPE_IQD) > >> def_discipline = QETH_DISCIPLINE_LAYER3; > > > > Same here: I don't think we want to start with patches like this. > > Thanks for your feedback. > > > > This going to be a never ending story without much benefit. > > Is the source code a bit clearer and safer if it will be expressed > directly that the use of a specific variable is not intended for > a complete function implementation but for the smaller scope > of an if branch? This depends on the function and what the author prefers. In this case the function body is very small so I don't see any benefit at all. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] 390/qeth: Refactoring for qeth_core_set_online() @ 2016-01-04 14:04 ` Heiko Carstens 0 siblings, 0 replies; 3089+ messages in thread From: Heiko Carstens @ 2016-01-04 14:04 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-s390, Martin Schwidefsky, Ursula Braun, LKML, kernel-janitors, Julia Lawall On Mon, Jan 04, 2016 at 02:10:34PM +0100, SF Markus Elfring wrote: > >> +++ b/drivers/s390/net/qeth_core_main.c > >> @@ -5638,9 +5638,10 @@ static int qeth_core_set_online(struct ccwgroup_device *gdev) > >> { > >> struct qeth_card *card = dev_get_drvdata(&gdev->dev); > >> int rc; > >> - int def_discipline; > >> > >> if (!card->discipline) { > >> + int def_discipline; > >> + > >> if (card->info.type = QETH_CARD_TYPE_IQD) > >> def_discipline = QETH_DISCIPLINE_LAYER3; > > > > Same here: I don't think we want to start with patches like this. > > Thanks for your feedback. > > > > This going to be a never ending story without much benefit. > > Is the source code a bit clearer and safer if it will be expressed > directly that the use of a specific variable is not intended for > a complete function implementation but for the smaller scope > of an if branch? This depends on the function and what the author prefers. In this case the function body is very small so I don't see any benefit at all. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: 390/qeth: Refactoring for qeth_core_set_online() 2016-01-04 14:04 ` Heiko Carstens @ 2016-01-04 14:10 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-04 14:10 UTC (permalink / raw) To: Heiko Carstens Cc: linux-s390, Martin Schwidefsky, Ursula Braun, LKML, kernel-janitors, Julia Lawall > In this case the function body is very small > so I don't see any benefit at all. Do you care for fine-tuning of variable placement occasionally? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: 390/qeth: Refactoring for qeth_core_set_online() @ 2016-01-04 14:10 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-04 14:10 UTC (permalink / raw) To: Heiko Carstens Cc: linux-s390, Martin Schwidefsky, Ursula Braun, LKML, kernel-janitors, Julia Lawall > In this case the function body is very small > so I don't see any benefit at all. Do you care for fine-tuning of variable placement occasionally? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: 390/qeth: Refactoring for qeth_core_set_online() 2016-01-04 14:10 ` SF Markus Elfring @ 2016-01-05 7:54 ` Heiko Carstens -1 siblings, 0 replies; 3089+ messages in thread From: Heiko Carstens @ 2016-01-05 7:54 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-s390, Martin Schwidefsky, Ursula Braun, LKML, kernel-janitors, Julia Lawall On Mon, Jan 04, 2016 at 03:10:41PM +0100, SF Markus Elfring wrote: > > In this case the function body is very small > > so I don't see any benefit at all. > > Do you care for fine-tuning of variable placement occasionally? No. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: 390/qeth: Refactoring for qeth_core_set_online() @ 2016-01-05 7:54 ` Heiko Carstens 0 siblings, 0 replies; 3089+ messages in thread From: Heiko Carstens @ 2016-01-05 7:54 UTC (permalink / raw) To: SF Markus Elfring Cc: linux-s390, Martin Schwidefsky, Ursula Braun, LKML, kernel-janitors, Julia Lawall On Mon, Jan 04, 2016 at 03:10:41PM +0100, SF Markus Elfring wrote: > > In this case the function body is very small > > so I don't see any benefit at all. > > Do you care for fine-tuning of variable placement occasionally? No. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH] staging-slicoss: Replace variable initialisations by assignments in slic_if_init() 2015-12-11 12:08 ` SF Markus Elfring @ 2016-01-03 16:32 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 16:32 UTC (permalink / raw) To: devel, Christopher Harrer, Greg Kroah-Hartman, Lior Dotan Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 3 Jan 2016 17:25:59 +0100 Replace explicit initialisation for two local variables at the beginning by assignments. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/slicoss/slicoss.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/staging/slicoss/slicoss.c b/drivers/staging/slicoss/slicoss.c index b23a2d1..8fdcac8 100644 --- a/drivers/staging/slicoss/slicoss.c +++ b/drivers/staging/slicoss/slicoss.c @@ -2301,9 +2301,9 @@ static int slic_adapter_allocresources(struct adapter *adapter, */ static int slic_if_init(struct adapter *adapter, unsigned long *flags) { - struct sliccard *card = adapter->card; + struct sliccard *card; struct net_device *dev = adapter->netdev; - __iomem struct slic_regs *slic_regs = adapter->slic_regs; + __iomem struct slic_regs *slic_regs; struct slic_shmem *pshmem; int rc; @@ -2348,6 +2348,7 @@ static int slic_if_init(struct adapter *adapter, unsigned long *flags) adapter->queues_initialized = 1; } + slic_regs = adapter->slic_regs; slic_reg32_write(&slic_regs->slic_icr, ICR_INT_OFF, FLUSH); mdelay(1); @@ -2374,6 +2375,7 @@ static int slic_if_init(struct adapter *adapter, unsigned long *flags) } adapter->state = ADAPT_UP; + card = adapter->card; if (!card->loadtimerset) { setup_timer(&card->loadtimer, &slic_timer_load_check, (ulong)card); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH] staging-slicoss: Replace variable initialisations by assignments in slic_if_init() @ 2016-01-03 16:32 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 16:32 UTC (permalink / raw) To: devel, Christopher Harrer, Greg Kroah-Hartman, Lior Dotan Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sun, 3 Jan 2016 17:25:59 +0100 Replace explicit initialisation for two local variables at the beginning by assignments. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/staging/slicoss/slicoss.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/staging/slicoss/slicoss.c b/drivers/staging/slicoss/slicoss.c index b23a2d1..8fdcac8 100644 --- a/drivers/staging/slicoss/slicoss.c +++ b/drivers/staging/slicoss/slicoss.c @@ -2301,9 +2301,9 @@ static int slic_adapter_allocresources(struct adapter *adapter, */ static int slic_if_init(struct adapter *adapter, unsigned long *flags) { - struct sliccard *card = adapter->card; + struct sliccard *card; struct net_device *dev = adapter->netdev; - __iomem struct slic_regs *slic_regs = adapter->slic_regs; + __iomem struct slic_regs *slic_regs; struct slic_shmem *pshmem; int rc; @@ -2348,6 +2348,7 @@ static int slic_if_init(struct adapter *adapter, unsigned long *flags) adapter->queues_initialized = 1; } + slic_regs = adapter->slic_regs; slic_reg32_write(&slic_regs->slic_icr, ICR_INT_OFF, FLUSH); mdelay(1); @@ -2374,6 +2375,7 @@ static int slic_if_init(struct adapter *adapter, unsigned long *flags) } adapter->state = ADAPT_UP; + card = adapter->card; if (!card->loadtimerset) { setup_timer(&card->loadtimer, &slic_timer_load_check, (ulong)card); -- 2.6.3 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH] staging-slicoss: Replace variable initialisations by assignments in slic_if_init() 2016-01-03 16:32 ` SF Markus Elfring @ 2016-01-03 16:41 ` Julia Lawall -1 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2016-01-03 16:41 UTC (permalink / raw) To: SF Markus Elfring Cc: devel, Christopher Harrer, Greg Kroah-Hartman, Lior Dotan, LKML, kernel-janitors, Julia Lawall On Sun, 3 Jan 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 3 Jan 2016 17:25:59 +0100 > > Replace explicit initialisation for two local variables at the beginning > by assignments. Why? julia > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/staging/slicoss/slicoss.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/slicoss/slicoss.c b/drivers/staging/slicoss/slicoss.c > index b23a2d1..8fdcac8 100644 > --- a/drivers/staging/slicoss/slicoss.c > +++ b/drivers/staging/slicoss/slicoss.c > @@ -2301,9 +2301,9 @@ static int slic_adapter_allocresources(struct adapter *adapter, > */ > static int slic_if_init(struct adapter *adapter, unsigned long *flags) > { > - struct sliccard *card = adapter->card; > + struct sliccard *card; > struct net_device *dev = adapter->netdev; > - __iomem struct slic_regs *slic_regs = adapter->slic_regs; > + __iomem struct slic_regs *slic_regs; > struct slic_shmem *pshmem; > int rc; > > @@ -2348,6 +2348,7 @@ static int slic_if_init(struct adapter *adapter, unsigned long *flags) > adapter->queues_initialized = 1; > } > > + slic_regs = adapter->slic_regs; > slic_reg32_write(&slic_regs->slic_icr, ICR_INT_OFF, FLUSH); > mdelay(1); > > @@ -2374,6 +2375,7 @@ static int slic_if_init(struct adapter *adapter, unsigned long *flags) > } > > adapter->state = ADAPT_UP; > + card = adapter->card; > if (!card->loadtimerset) { > setup_timer(&card->loadtimer, &slic_timer_load_check, > (ulong)card); > -- > 2.6.3 > > -- > To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] staging-slicoss: Replace variable initialisations by assignments in slic_if_init() @ 2016-01-03 16:41 ` Julia Lawall 0 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2016-01-03 16:41 UTC (permalink / raw) To: SF Markus Elfring Cc: devel, Christopher Harrer, Greg Kroah-Hartman, Lior Dotan, LKML, kernel-janitors, Julia Lawall On Sun, 3 Jan 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sun, 3 Jan 2016 17:25:59 +0100 > > Replace explicit initialisation for two local variables at the beginning > by assignments. Why? julia > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/staging/slicoss/slicoss.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/slicoss/slicoss.c b/drivers/staging/slicoss/slicoss.c > index b23a2d1..8fdcac8 100644 > --- a/drivers/staging/slicoss/slicoss.c > +++ b/drivers/staging/slicoss/slicoss.c > @@ -2301,9 +2301,9 @@ static int slic_adapter_allocresources(struct adapter *adapter, > */ > static int slic_if_init(struct adapter *adapter, unsigned long *flags) > { > - struct sliccard *card = adapter->card; > + struct sliccard *card; > struct net_device *dev = adapter->netdev; > - __iomem struct slic_regs *slic_regs = adapter->slic_regs; > + __iomem struct slic_regs *slic_regs; > struct slic_shmem *pshmem; > int rc; > > @@ -2348,6 +2348,7 @@ static int slic_if_init(struct adapter *adapter, unsigned long *flags) > adapter->queues_initialized = 1; > } > > + slic_regs = adapter->slic_regs; > slic_reg32_write(&slic_regs->slic_icr, ICR_INT_OFF, FLUSH); > mdelay(1); > > @@ -2374,6 +2375,7 @@ static int slic_if_init(struct adapter *adapter, unsigned long *flags) > } > > adapter->state = ADAPT_UP; > + card = adapter->card; > if (!card->loadtimerset) { > setup_timer(&card->loadtimer, &slic_timer_load_check, > (ulong)card); > -- > 2.6.3 > > -- > To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] staging-slicoss: Replace variable initialisations by assignments in slic_if_init() 2016-01-03 16:41 ` Julia Lawall @ 2016-01-03 17:48 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 17:48 UTC (permalink / raw) To: Julia Lawall Cc: devel, Christopher Harrer, Greg Kroah-Hartman, Lior Dotan, LKML, kernel-janitors >> Replace explicit initialisation for two local variables at the beginning >> by assignments. > > Why? I prefer that assignments for variables like "card" and "slic_regs" will only be performed immediately before the corresponding content will be read again (after a few condition checks were executed). Another description could be this view: I suggest to move the variable initialisation a bit. Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] staging-slicoss: Replace variable initialisations by assignments in slic_if_init() @ 2016-01-03 17:48 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 17:48 UTC (permalink / raw) To: Julia Lawall Cc: devel, Christopher Harrer, Greg Kroah-Hartman, Lior Dotan, LKML, kernel-janitors >> Replace explicit initialisation for two local variables at the beginning >> by assignments. > > Why? I prefer that assignments for variables like "card" and "slic_regs" will only be performed immediately before the corresponding content will be read again (after a few condition checks were executed). Another description could be this view: I suggest to move the variable initialisation a bit. Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] staging-slicoss: Replace variable initialisations by assignments in slic_if_init() 2016-01-03 17:48 ` SF Markus Elfring @ 2016-01-03 17:58 ` Greg Kroah-Hartman -1 siblings, 0 replies; 3089+ messages in thread From: Greg Kroah-Hartman @ 2016-01-03 17:58 UTC (permalink / raw) To: SF Markus Elfring Cc: Julia Lawall, devel, kernel-janitors, LKML, Lior Dotan, Christopher Harrer On Sun, Jan 03, 2016 at 06:48:17PM +0100, SF Markus Elfring wrote: > >> Replace explicit initialisation for two local variables at the beginning > >> by assignments. > > > > Why? > > I prefer that assignments for variables like "card" and "slic_regs" > will only be performed immediately before the corresponding content will be > read again (after a few condition checks were executed). > > Another description could be this view: > I suggest to move the variable initialisation a bit. And like David Miller and others just said, please don't bother us with pointless patches such as this, if you keep it up, I'll have to add you to my killfile as patches like this are a waste of everyone's valuable time. greg k-h ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] staging-slicoss: Replace variable initialisations by assignments in slic_if_init() @ 2016-01-03 17:58 ` Greg Kroah-Hartman 0 siblings, 0 replies; 3089+ messages in thread From: Greg Kroah-Hartman @ 2016-01-03 17:58 UTC (permalink / raw) To: SF Markus Elfring Cc: Julia Lawall, devel, kernel-janitors, LKML, Lior Dotan, Christopher Harrer On Sun, Jan 03, 2016 at 06:48:17PM +0100, SF Markus Elfring wrote: > >> Replace explicit initialisation for two local variables at the beginning > >> by assignments. > > > > Why? > > I prefer that assignments for variables like "card" and "slic_regs" > will only be performed immediately before the corresponding content will be > read again (after a few condition checks were executed). > > Another description could be this view: > I suggest to move the variable initialisation a bit. And like David Miller and others just said, please don't bother us with pointless patches such as this, if you keep it up, I'll have to add you to my killfile as patches like this are a waste of everyone's valuable time. greg k-h ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] staging-slicoss: Replace variable initialisations by assignments in slic_if_init() 2016-01-03 17:58 ` Greg Kroah-Hartman @ 2016-01-03 18:16 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 18:16 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Julia Lawall, devel, kernel-janitors, LKML, Lior Dotan, Christopher Harrer >> I prefer that assignments for variables like "card" and "slic_regs" >> will only be performed immediately before the corresponding content will be >> read again (after a few condition checks were executed). >> >> Another description could be this view: >> I suggest to move the variable initialisation a bit. > > And like David Miller and others just said, please don't bother us with > pointless patches such as this, if you keep it up, I'll have to add you > to my killfile as patches like this are a waste of everyone's valuable time. I am a bit surprised that you do not like such source code fine-tuning. Will related software improvements get another chance later (eventually together with other changes)? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] staging-slicoss: Replace variable initialisations by assignments in slic_if_init() @ 2016-01-03 18:16 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 18:16 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Julia Lawall, devel, kernel-janitors, LKML, Lior Dotan, Christopher Harrer >> I prefer that assignments for variables like "card" and "slic_regs" >> will only be performed immediately before the corresponding content will be >> read again (after a few condition checks were executed). >> >> Another description could be this view: >> I suggest to move the variable initialisation a bit. > > And like David Miller and others just said, please don't bother us with > pointless patches such as this, if you keep it up, I'll have to add you > to my killfile as patches like this are a waste of everyone's valuable time. I am a bit surprised that you do not like such source code fine-tuning. Will related software improvements get another chance later (eventually together with other changes)? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] staging-slicoss: Replace variable initialisations by assignments in slic_if_init() 2016-01-03 18:16 ` SF Markus Elfring @ 2016-01-03 18:26 ` Greg Kroah-Hartman -1 siblings, 0 replies; 3089+ messages in thread From: Greg Kroah-Hartman @ 2016-01-03 18:26 UTC (permalink / raw) To: SF Markus Elfring Cc: Julia Lawall, devel, kernel-janitors, LKML, Lior Dotan, Christopher Harrer On Sun, Jan 03, 2016 at 07:16:49PM +0100, SF Markus Elfring wrote: > >> I prefer that assignments for variables like "card" and "slic_regs" > >> will only be performed immediately before the corresponding content will be > >> read again (after a few condition checks were executed). > >> > >> Another description could be this view: > >> I suggest to move the variable initialisation a bit. > > > > And like David Miller and others just said, please don't bother us with > > pointless patches such as this, if you keep it up, I'll have to add you > > to my killfile as patches like this are a waste of everyone's valuable time. > > I am a bit surprised that you do not like such source code fine-tuning. It's moving stuff around for no real reason, why would I like it? Reading and reviewing and applying this type of stuff takes away from the time I have to spend reviewing and applying actual code fixes from other developers who are doing real and useful work. Remember maintainer's time is our most limited resource right now. You are abusing that by wasting their time for no valid reason. > Will related software improvements get another chance later (eventually together > with other changes)? Define "improvements". Did you fix an obvious bug? Did you speed up the code in a measurable way? Did you make the code easier to understand somehow? For this patch you did none of these things. Code in staging needs to be moved out of staging, and this patch does nothing toward achieving that goal and it wastes people's time reviewing it to see if it is correct or not. Please stop or again, you will end up in some killfiles, if you haven't already been placed there. thanks, greg k-h ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] staging-slicoss: Replace variable initialisations by assignments in slic_if_init() @ 2016-01-03 18:26 ` Greg Kroah-Hartman 0 siblings, 0 replies; 3089+ messages in thread From: Greg Kroah-Hartman @ 2016-01-03 18:26 UTC (permalink / raw) To: SF Markus Elfring Cc: Julia Lawall, devel, kernel-janitors, LKML, Lior Dotan, Christopher Harrer On Sun, Jan 03, 2016 at 07:16:49PM +0100, SF Markus Elfring wrote: > >> I prefer that assignments for variables like "card" and "slic_regs" > >> will only be performed immediately before the corresponding content will be > >> read again (after a few condition checks were executed). > >> > >> Another description could be this view: > >> I suggest to move the variable initialisation a bit. > > > > And like David Miller and others just said, please don't bother us with > > pointless patches such as this, if you keep it up, I'll have to add you > > to my killfile as patches like this are a waste of everyone's valuable time. > > I am a bit surprised that you do not like such source code fine-tuning. It's moving stuff around for no real reason, why would I like it? Reading and reviewing and applying this type of stuff takes away from the time I have to spend reviewing and applying actual code fixes from other developers who are doing real and useful work. Remember maintainer's time is our most limited resource right now. You are abusing that by wasting their time for no valid reason. > Will related software improvements get another chance later (eventually together > with other changes)? Define "improvements". Did you fix an obvious bug? Did you speed up the code in a measurable way? Did you make the code easier to understand somehow? For this patch you did none of these things. Code in staging needs to be moved out of staging, and this patch does nothing toward achieving that goal and it wastes people's time reviewing it to see if it is correct or not. Please stop or again, you will end up in some killfiles, if you haven't already been placed there. thanks, greg k-h ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] staging-slicoss: Replace variable initialisations by assignments in slic_if_init() 2016-01-03 18:26 ` Greg Kroah-Hartman @ 2016-01-03 18:50 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 18:50 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Julia Lawall, devel, kernel-janitors, LKML, Lior Dotan, Christopher Harrer >> I am a bit surprised that you do not like such source code fine-tuning. > > It's moving stuff around for no real reason, why would I like it? Can such fine-tuning result in positive effects for the run-time behaviour? > Reading and reviewing and applying this type of stuff takes away from > the time I have to spend reviewing and applying actual code fixes from > other developers who are doing real and useful work. I am aware that a lot of open issues are competing for your precious software development attention. > Remember maintainer's time is our most limited resource right now. That is mostly usual. > You are abusing that by wasting their time for no valid reason. I find a couple of my update suggestions still valid. I agree that the importance of proposed changes is varying. >> Will related software improvements get another chance later (eventually together >> with other changes)? > > Define "improvements". Did you fix an obvious bug? Maybe. - It depends on the error classes you are interested in at the moment. > Did you speed up the code in a measurable way? My suggestions can result in measurable differences. > Did you make the code easier to understand somehow? > For this patch you did none of these things. Thanks for your view on my approach. Will it become acceptable to reduce the scope for any more variable definitions in further function implementations? > Code in staging needs to be moved out of staging, and this patch does > nothing toward achieving that goal and it wastes people's time reviewing > it to see if it is correct or not. I am curious on the ways the discussed software can evolve further. Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] staging-slicoss: Replace variable initialisations by assignments in slic_if_init() @ 2016-01-03 18:50 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 18:50 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Julia Lawall, devel, kernel-janitors, LKML, Lior Dotan, Christopher Harrer >> I am a bit surprised that you do not like such source code fine-tuning. > > It's moving stuff around for no real reason, why would I like it? Can such fine-tuning result in positive effects for the run-time behaviour? > Reading and reviewing and applying this type of stuff takes away from > the time I have to spend reviewing and applying actual code fixes from > other developers who are doing real and useful work. I am aware that a lot of open issues are competing for your precious software development attention. > Remember maintainer's time is our most limited resource right now. That is mostly usual. > You are abusing that by wasting their time for no valid reason. I find a couple of my update suggestions still valid. I agree that the importance of proposed changes is varying. >> Will related software improvements get another chance later (eventually together >> with other changes)? > > Define "improvements". Did you fix an obvious bug? Maybe. - It depends on the error classes you are interested in at the moment. > Did you speed up the code in a measurable way? My suggestions can result in measurable differences. > Did you make the code easier to understand somehow? > For this patch you did none of these things. Thanks for your view on my approach. Will it become acceptable to reduce the scope for any more variable definitions in further function implementations? > Code in staging needs to be moved out of staging, and this patch does > nothing toward achieving that goal and it wastes people's time reviewing > it to see if it is correct or not. I am curious on the ways the discussed software can evolve further. Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] staging-slicoss: Replace variable initialisations by assignments in slic_if_init() 2016-01-03 18:50 ` SF Markus Elfring @ 2016-01-03 19:45 ` Greg Kroah-Hartman -1 siblings, 0 replies; 3089+ messages in thread From: Greg Kroah-Hartman @ 2016-01-03 19:45 UTC (permalink / raw) To: SF Markus Elfring Cc: Julia Lawall, devel, kernel-janitors, LKML, Lior Dotan, Christopher Harrer On Sun, Jan 03, 2016 at 07:50:18PM +0100, SF Markus Elfring wrote: > >> I am a bit surprised that you do not like such source code fine-tuning. > > > > It's moving stuff around for no real reason, why would I like it? > > Can such fine-tuning result in positive effects for the run-time behaviour? If you can not benchmark and show the proof, don't even start to claim such a thing. > > Did you speed up the code in a measurable way? > > My suggestions can result in measurable differences. Show the proof please. That's the only way I will ever accept anything else from you like this. > Will it become acceptable to reduce the scope for any more variable > definitions in further function implementations? No. > > Code in staging needs to be moved out of staging, and this patch does > > nothing toward achieving that goal and it wastes people's time reviewing > > it to see if it is correct or not. > > I am curious on the ways the discussed software can evolve further. That's nice, but that's not my concern. greg k-h ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH] staging-slicoss: Replace variable initialisations by assignments in slic_if_init() @ 2016-01-03 19:45 ` Greg Kroah-Hartman 0 siblings, 0 replies; 3089+ messages in thread From: Greg Kroah-Hartman @ 2016-01-03 19:45 UTC (permalink / raw) To: SF Markus Elfring Cc: Julia Lawall, devel, kernel-janitors, LKML, Lior Dotan, Christopher Harrer On Sun, Jan 03, 2016 at 07:50:18PM +0100, SF Markus Elfring wrote: > >> I am a bit surprised that you do not like such source code fine-tuning. > > > > It's moving stuff around for no real reason, why would I like it? > > Can such fine-tuning result in positive effects for the run-time behaviour? If you can not benchmark and show the proof, don't even start to claim such a thing. > > Did you speed up the code in a measurable way? > > My suggestions can result in measurable differences. Show the proof please. That's the only way I will ever accept anything else from you like this. > Will it become acceptable to reduce the scope for any more variable > definitions in further function implementations? No. > > Code in staging needs to be moved out of staging, and this patch does > > nothing toward achieving that goal and it wastes people's time reviewing > > it to see if it is correct or not. > > I am curious on the ways the discussed software can evolve further. That's nice, but that's not my concern. greg k-h ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: staging-slicoss: Replace variable initialisations by assignments in slic_if_init() 2016-01-03 19:45 ` Greg Kroah-Hartman @ 2016-01-03 20:10 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 20:10 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Julia Lawall, devel, kernel-janitors, LKML, Lior Dotan, Christopher Harrer >> Can such fine-tuning result in positive effects for the run-time behaviour? > > If you can not benchmark and show the proof, don't even start to claim > such a thing. Which measurement results would you accept for further discussion? >> My suggestions can result in measurable differences. > > Show the proof please. Which information presentations would finally qualify for "the proof" you request now? Which test systems will be representative for you? > That's the only way I will ever accept anything else from you like this. Are there any update suggestions remaining in the waiting queue which have a higher chance of acceptance because their value might be a bit more obvious? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: staging-slicoss: Replace variable initialisations by assignments in slic_if_init() @ 2016-01-03 20:10 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 20:10 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Julia Lawall, devel, kernel-janitors, LKML, Lior Dotan, Christopher Harrer >> Can such fine-tuning result in positive effects for the run-time behaviour? > > If you can not benchmark and show the proof, don't even start to claim > such a thing. Which measurement results would you accept for further discussion? >> My suggestions can result in measurable differences. > > Show the proof please. Which information presentations would finally qualify for "the proof" you request now? Which test systems will be representative for you? > That's the only way I will ever accept anything else from you like this. Are there any update suggestions remaining in the waiting queue which have a higher chance of acceptance because their value might be a bit more obvious? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: staging-slicoss: Replace variable initialisations by assignments in slic_if_init() 2016-01-03 20:10 ` SF Markus Elfring @ 2016-01-03 20:15 ` Greg Kroah-Hartman -1 siblings, 0 replies; 3089+ messages in thread From: Greg Kroah-Hartman @ 2016-01-03 20:15 UTC (permalink / raw) To: SF Markus Elfring Cc: Julia Lawall, devel, kernel-janitors, LKML, Lior Dotan, Christopher Harrer On Sun, Jan 03, 2016 at 09:10:45PM +0100, SF Markus Elfring wrote: > >> Can such fine-tuning result in positive effects for the run-time behaviour? > > > > If you can not benchmark and show the proof, don't even start to claim > > such a thing. > > Which measurement results would you accept for further discussion? If you don't know how to show your results, then this whole discussion is pointless. *plonk* ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: staging-slicoss: Replace variable initialisations by assignments in slic_if_init() @ 2016-01-03 20:15 ` Greg Kroah-Hartman 0 siblings, 0 replies; 3089+ messages in thread From: Greg Kroah-Hartman @ 2016-01-03 20:15 UTC (permalink / raw) To: SF Markus Elfring Cc: Julia Lawall, devel, kernel-janitors, LKML, Lior Dotan, Christopher Harrer On Sun, Jan 03, 2016 at 09:10:45PM +0100, SF Markus Elfring wrote: > >> Can such fine-tuning result in positive effects for the run-time behaviour? > > > > If you can not benchmark and show the proof, don't even start to claim > > such a thing. > > Which measurement results would you accept for further discussion? If you don't know how to show your results, then this whole discussion is pointless. *plonk* ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: staging-slicoss: Replace variable initialisations by assignments in slic_if_init() 2016-01-03 20:15 ` Greg Kroah-Hartman @ 2016-01-03 20:21 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 20:21 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Julia Lawall, devel, kernel-janitors, LKML, Lior Dotan, Christopher Harrer >> Which measurement results would you accept for further discussion? > > If you don't know how to show your results, then this whole discussion > is pointless. I could show test results. But it could happen that I would choose insufficient variations for execution environments. I am unsure about the requested detail and size around test parameters. Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: staging-slicoss: Replace variable initialisations by assignments in slic_if_init() @ 2016-01-03 20:21 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-01-03 20:21 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Julia Lawall, devel, kernel-janitors, LKML, Lior Dotan, Christopher Harrer >> Which measurement results would you accept for further discussion? > > If you don't know how to show your results, then this whole discussion > is pointless. I could show test results. But it could happen that I would choose insufficient variations for execution environments. I am unsure about the requested detail and size around test parameters. Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/2] Input-at32psif: Fine-tuning for OOM handling in psif_probe() 2015-12-11 12:08 ` SF Markus Elfring @ 2016-07-02 19:00 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-02 19:00 UTC (permalink / raw) To: Dmitry Torokhov, linux-input; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jul 2016 20:50:09 +0200 A few update suggestions were taken into account from static source code analysis. Markus Elfring (2): Return directly after a failed kzalloc() Remove two OOM messages drivers/input/serio/at32psif.c | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) -- 2.9.0 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 0/2] Input-at32psif: Fine-tuning for OOM handling in psif_probe() @ 2016-07-02 19:00 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-02 19:00 UTC (permalink / raw) To: Dmitry Torokhov, linux-input; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jul 2016 20:50:09 +0200 A few update suggestions were taken into account from static source code analysis. Markus Elfring (2): Return directly after a failed kzalloc() Remove two OOM messages drivers/input/serio/at32psif.c | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) -- 2.9.0 ^ permalink raw reply [flat|nested] 3089+ messages in thread
* [PATCH 1/2] Input-at32psif: Return directly after a failed kzalloc() in psif_probe() 2016-07-02 19:00 ` SF Markus Elfring @ 2016-07-02 19:05 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-02 19:05 UTC (permalink / raw) To: Dmitry Torokhov, linux-input; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jul 2016 18:34:43 +0200 Return directly after a memory allocation failed at the beginning. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/input/serio/at32psif.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/input/serio/at32psif.c b/drivers/input/serio/at32psif.c index 2e4ff5b..fcb769a 100644 --- a/drivers/input/serio/at32psif.c +++ b/drivers/input/serio/at32psif.c @@ -212,8 +212,7 @@ static int __init psif_probe(struct platform_device *pdev) psif = kzalloc(sizeof(struct psif), GFP_KERNEL); if (!psif) { dev_dbg(&pdev->dev, "out of memory\n"); - ret = -ENOMEM; - goto out; + return -ENOMEM; } psif->pdev = pdev; @@ -297,7 +296,6 @@ out_free_io: kfree(io); out_free_psif: kfree(psif); -out: return ret; } -- 2.9.0 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 1/2] Input-at32psif: Return directly after a failed kzalloc() in psif_probe() @ 2016-07-02 19:05 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-02 19:05 UTC (permalink / raw) To: Dmitry Torokhov, linux-input; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jul 2016 18:34:43 +0200 Return directly after a memory allocation failed at the beginning. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/input/serio/at32psif.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/input/serio/at32psif.c b/drivers/input/serio/at32psif.c index 2e4ff5b..fcb769a 100644 --- a/drivers/input/serio/at32psif.c +++ b/drivers/input/serio/at32psif.c @@ -212,8 +212,7 @@ static int __init psif_probe(struct platform_device *pdev) psif = kzalloc(sizeof(struct psif), GFP_KERNEL); if (!psif) { dev_dbg(&pdev->dev, "out of memory\n"); - ret = -ENOMEM; - goto out; + return -ENOMEM; } psif->pdev = pdev; @@ -297,7 +296,6 @@ out_free_io: kfree(io); out_free_psif: kfree(psif); -out: return ret; } -- 2.9.0 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 2/2] Input-at32psif: Remove OOM messages in psif_probe() 2016-07-02 19:00 ` SF Markus Elfring @ 2016-07-02 19:07 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-02 19:07 UTC (permalink / raw) To: Dmitry Torokhov, linux-input; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jul 2016 20:34:18 +0200 Delete two debug messages because Linux will usually provide an appropriate information for a memory allocation failure. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/input/serio/at32psif.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/input/serio/at32psif.c b/drivers/input/serio/at32psif.c index fcb769a..b30503d 100644 --- a/drivers/input/serio/at32psif.c +++ b/drivers/input/serio/at32psif.c @@ -210,15 +210,13 @@ static int __init psif_probe(struct platform_device *pdev) int ret; psif = kzalloc(sizeof(struct psif), GFP_KERNEL); - if (!psif) { - dev_dbg(&pdev->dev, "out of memory\n"); + if (!psif) return -ENOMEM; - } + psif->pdev = pdev; io = kzalloc(sizeof(struct serio), GFP_KERNEL); if (!io) { - dev_dbg(&pdev->dev, "out of memory\n"); ret = -ENOMEM; goto out_free_psif; } -- 2.9.0 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* [PATCH 2/2] Input-at32psif: Remove OOM messages in psif_probe() @ 2016-07-02 19:07 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-02 19:07 UTC (permalink / raw) To: Dmitry Torokhov, linux-input; +Cc: LKML, kernel-janitors, Julia Lawall From: Markus Elfring <elfring@users.sourceforge.net> Date: Sat, 2 Jul 2016 20:34:18 +0200 Delete two debug messages because Linux will usually provide an appropriate information for a memory allocation failure. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> --- drivers/input/serio/at32psif.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/input/serio/at32psif.c b/drivers/input/serio/at32psif.c index fcb769a..b30503d 100644 --- a/drivers/input/serio/at32psif.c +++ b/drivers/input/serio/at32psif.c @@ -210,15 +210,13 @@ static int __init psif_probe(struct platform_device *pdev) int ret; psif = kzalloc(sizeof(struct psif), GFP_KERNEL); - if (!psif) { - dev_dbg(&pdev->dev, "out of memory\n"); + if (!psif) return -ENOMEM; - } + psif->pdev = pdev; io = kzalloc(sizeof(struct serio), GFP_KERNEL); if (!io) { - dev_dbg(&pdev->dev, "out of memory\n"); ret = -ENOMEM; goto out_free_psif; } -- 2.9.0 ^ permalink raw reply related [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] Input-at32psif: Remove OOM messages in psif_probe() 2016-07-02 19:07 ` SF Markus Elfring @ 2016-07-02 19:29 ` Julia Lawall -1 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2016-07-02 19:29 UTC (permalink / raw) To: SF Markus Elfring; +Cc: Dmitry Torokhov, linux-input, LKML, kernel-janitors On Sat, 2 Jul 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sat, 2 Jul 2016 20:34:18 +0200 > > Delete two debug messages because Linux will usually provide > an appropriate information for a memory allocation failure. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/input/serio/at32psif.c | 6 ++---- > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/drivers/input/serio/at32psif.c b/drivers/input/serio/at32psif.c > index fcb769a..b30503d 100644 > --- a/drivers/input/serio/at32psif.c > +++ b/drivers/input/serio/at32psif.c > @@ -210,15 +210,13 @@ static int __init psif_probe(struct platform_device *pdev) > int ret; > > psif = kzalloc(sizeof(struct psif), GFP_KERNEL); > - if (!psif) { > - dev_dbg(&pdev->dev, "out of memory\n"); > + if (!psif) > return -ENOMEM; > - } > + Why add a blank line here? > psif->pdev = pdev; > > io = kzalloc(sizeof(struct serio), GFP_KERNEL); > if (!io) { > - dev_dbg(&pdev->dev, "out of memory\n"); > ret = -ENOMEM; > goto out_free_psif; > } > -- > 2.9.0 > > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 2/2] Input-at32psif: Remove OOM messages in psif_probe() @ 2016-07-02 19:29 ` Julia Lawall 0 siblings, 0 replies; 3089+ messages in thread From: Julia Lawall @ 2016-07-02 19:29 UTC (permalink / raw) To: SF Markus Elfring; +Cc: Dmitry Torokhov, linux-input, LKML, kernel-janitors On Sat, 2 Jul 2016, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sat, 2 Jul 2016 20:34:18 +0200 > > Delete two debug messages because Linux will usually provide > an appropriate information for a memory allocation failure. > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> > --- > drivers/input/serio/at32psif.c | 6 ++---- > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/drivers/input/serio/at32psif.c b/drivers/input/serio/at32psif.c > index fcb769a..b30503d 100644 > --- a/drivers/input/serio/at32psif.c > +++ b/drivers/input/serio/at32psif.c > @@ -210,15 +210,13 @@ static int __init psif_probe(struct platform_device *pdev) > int ret; > > psif = kzalloc(sizeof(struct psif), GFP_KERNEL); > - if (!psif) { > - dev_dbg(&pdev->dev, "out of memory\n"); > + if (!psif) > return -ENOMEM; > - } > + Why add a blank line here? > psif->pdev = pdev; > > io = kzalloc(sizeof(struct serio), GFP_KERNEL); > if (!io) { > - dev_dbg(&pdev->dev, "out of memory\n"); > ret = -ENOMEM; > goto out_free_psif; > } > -- > 2.9.0 > > ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/2] Input-at32psif: Fine-tuning for OOM handling in psif_probe() 2016-07-02 19:00 ` SF Markus Elfring (?) @ 2016-07-02 20:45 ` Joe Perches -1 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2016-07-02 20:45 UTC (permalink / raw) To: SF Markus Elfring, Dmitry Torokhov, linux-input Cc: LKML, kernel-janitors, Julia Lawall On Sat, 2016-07-02 at 21:00 +0200, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sat, 2 Jul 2016 20:50:09 +0200 > > A few update suggestions were taken into account > from static source code analysis. > > Markus Elfring (2): > Return directly after a failed kzalloc() > Remove two OOM messages > > drivers/input/serio/at32psif.c | 10 +++------- > 1 file changed, 3 insertions(+), 7 deletions(-) What possible rationale is there for including this "references" header? 566ABCD9.1060404@users.sourceforge.net This message id is for your message: "Source code review around jump label usage" sent December 11, 2015! Please stop adding unnecessary and useless email headers. ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/2] Input-at32psif: Fine-tuning for OOM handling in psif_probe() @ 2016-07-02 20:45 ` Joe Perches 0 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2016-07-02 20:45 UTC (permalink / raw) To: SF Markus Elfring, Dmitry Torokhov, linux-input Cc: LKML, kernel-janitors, Julia Lawall On Sat, 2016-07-02 at 21:00 +0200, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sat, 2 Jul 2016 20:50:09 +0200 > > A few update suggestions were taken into account > from static source code analysis. > > Markus Elfring (2): > Return directly after a failed kzalloc() > Remove two OOM messages > > drivers/input/serio/at32psif.c | 10 +++------- > 1 file changed, 3 insertions(+), 7 deletions(-) What possible rationale is there for including this "references" header? 566ABCD9.1060404@users.sourceforge.net This message id is for your message: "Source code review around jump label usage" sent December 11, 2015! Please stop adding unnecessary and useless email headers. -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/2] Input-at32psif: Fine-tuning for OOM handling in psif_probe() @ 2016-07-02 20:45 ` Joe Perches 0 siblings, 0 replies; 3089+ messages in thread From: Joe Perches @ 2016-07-02 20:45 UTC (permalink / raw) To: SF Markus Elfring, Dmitry Torokhov, linux-input Cc: LKML, kernel-janitors, Julia Lawall On Sat, 2016-07-02 at 21:00 +0200, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sat, 2 Jul 2016 20:50:09 +0200 > > A few update suggestions were taken into account > from static source code analysis. > > Markus Elfring (2): > Return directly after a failed kzalloc() > Remove two OOM messages > > drivers/input/serio/at32psif.c | 10 +++------- > 1 file changed, 3 insertions(+), 7 deletions(-) What possible rationale is there for including this "references" header? 566ABCD9.1060404@users.sourceforge.net This message id is for your message: "Source code review around jump label usage" sent December 11, 2015! Please stop adding unnecessary and useless email headers. -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/2] Input-at32psif: Fine-tuning for OOM handling in psif_probe() 2016-07-02 20:45 ` Joe Perches @ 2016-07-03 8:01 ` SF Markus Elfring -1 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-03 8:01 UTC (permalink / raw) To: Joe Perches, Dmitry Torokhov, linux-input Cc: LKML, kernel-janitors, Julia Lawall >> A few update suggestions were taken into account >> from static source code analysis. >> >> Markus Elfring (2): >> Return directly after a failed kzalloc() >> Remove two OOM messages >> >> drivers/input/serio/at32psif.c | 10 +++------- >> 1 file changed, 3 insertions(+), 7 deletions(-) > > What possible rationale is there for including this "references" header? > 566ABCD9.1060404@users.sourceforge.net Do any more software developers dare to reconsider source code also around a jump label like "out"? > This message id is for your message: > "Source code review around jump label usage" > sent December 11, 2015! Can such an association with a bit of background information be occasionally useful for clarification of corresponding implementation details? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/2] Input-at32psif: Fine-tuning for OOM handling in psif_probe() @ 2016-07-03 8:01 ` SF Markus Elfring 0 siblings, 0 replies; 3089+ messages in thread From: SF Markus Elfring @ 2016-07-03 8:01 UTC (permalink / raw) To: Joe Perches, Dmitry Torokhov, linux-input Cc: LKML, kernel-janitors, Julia Lawall >> A few update suggestions were taken into account >> from static source code analysis. >> >> Markus Elfring (2): >> Return directly after a failed kzalloc() >> Remove two OOM messages >> >> drivers/input/serio/at32psif.c | 10 +++------- >> 1 file changed, 3 insertions(+), 7 deletions(-) > > What possible rationale is there for including this "references" header? > 566ABCD9.1060404@users.sourceforge.net Do any more software developers dare to reconsider source code also around a jump label like "out"? > This message id is for your message: > "Source code review around jump label usage" > sent December 11, 2015! Can such an association with a bit of background information be occasionally useful for clarification of corresponding implementation details? Regards, Markus ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/2] Input-at32psif: Fine-tuning for OOM handling in psif_probe() 2016-07-02 19:00 ` SF Markus Elfring @ 2016-07-13 22:01 ` Dmitry Torokhov -1 siblings, 0 replies; 3089+ messages in thread From: Dmitry Torokhov @ 2016-07-13 22:01 UTC (permalink / raw) To: SF Markus Elfring; +Cc: linux-input, LKML, kernel-janitors, Julia Lawall On Sat, Jul 02, 2016 at 09:00:36PM +0200, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sat, 2 Jul 2016 20:50:09 +0200 > > A few update suggestions were taken into account > from static source code analysis. > > Markus Elfring (2): > Return directly after a failed kzalloc() > Remove two OOM messages I do not see a compelling reason for taking these... Thanks. -- Dmitry ^ permalink raw reply [flat|nested] 3089+ messages in thread
* Re: [PATCH 0/2] Input-at32psif: Fine-tuning for OOM handling in psif_probe() @ 2016-07-13 22:01 ` Dmitry Torokhov 0 siblings, 0 replies; 3089+ messages in thread From: Dmitry Torokhov @ 2016-07-13 22:01 UTC (permalink / raw) To: SF Markus Elfring; +Cc: linux-input, LKML, kernel-janitors, Julia Lawall On Sat, Jul 02, 2016 at 09:00:36PM +0200, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sat, 2 Jul 2016 20:50:09 +0200 > > A few update suggestions were taken into account > from static source code analysis. > > Markus Elfring (2): > Return directly after a failed kzalloc() > Remove two OOM messages I do not see a compelling reason for taking these... Thanks. -- Dmitry ^ permalink raw reply [flat|nested] 3089+ messages in thread
end of thread, other threads:[~2016-07-26 19:15 UTC | newest] Thread overview: 3089+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-12-11 12:08 Source code review around jump label usage SF Markus Elfring 2015-12-11 12:08 ` SF Markus Elfring 2015-12-11 12:14 ` Julia Lawall 2015-12-11 12:14 ` Julia Lawall 2015-12-11 12:48 ` Dan Carpenter 2015-12-11 12:48 ` Dan Carpenter 2015-12-11 18:00 ` Christophe JAILLET 2015-12-11 18:19 ` [PATCH 0/2] block: Fine-tuning for two function implementations SF Markus Elfring 2015-12-11 18:19 ` SF Markus Elfring 2015-12-11 18:24 ` [PATCH 1/2] zram: Less checks in zram_bvec_write() after error detection SF Markus Elfring 2015-12-11 18:24 ` SF Markus Elfring 2015-12-14 0:27 ` Sergey Senozhatsky 2015-12-14 0:27 ` Sergey Senozhatsky 2015-12-14 6:58 ` SF Markus Elfring 2015-12-14 6:58 ` SF Markus Elfring 2015-12-14 7:17 ` Julia Lawall 2015-12-14 7:17 ` Julia Lawall 2015-12-14 10:03 ` Sergey Senozhatsky 2015-12-14 10:03 ` Sergey Senozhatsky 2015-12-14 14:03 ` SF Markus Elfring 2015-12-14 14:03 ` SF Markus Elfring 2015-12-11 18:26 ` [PATCH 2/2] z2ram: Delete a jump label in z2_init() SF Markus Elfring 2015-12-11 18:26 ` SF Markus Elfring 2015-12-14 0:36 ` Sergey Senozhatsky 2015-12-14 0:36 ` Sergey Senozhatsky 2015-12-14 9:10 ` Geert Uytterhoeven 2015-12-14 9:10 ` Geert Uytterhoeven 2015-12-12 9:16 ` [PATCH] uinput: Rename a jump label in uinput_ioctl_handler() SF Markus Elfring 2015-12-12 9:16 ` SF Markus Elfring 2015-12-12 22:23 ` Dmitry Torokhov 2015-12-12 22:23 ` Dmitry Torokhov 2015-12-12 14:30 ` [PATCH 0/7] iSCSI-target: Fine-tuning for three function implementations SF Markus Elfring 2015-12-12 14:30 ` SF Markus Elfring 2015-12-12 14:34 ` [PATCH 1/7] iscsi-target: Use a variable initialisation in iscsi_set_default_param() directly SF Markus Elfring 2015-12-12 14:34 ` SF Markus Elfring 2015-12-12 19:49 ` Dan Carpenter 2015-12-12 19:49 ` Dan Carpenter 2015-12-12 21:22 ` SF Markus Elfring 2015-12-12 21:22 ` SF Markus Elfring 2015-12-14 8:41 ` Johannes Thumshirn 2015-12-14 8:41 ` Johannes Thumshirn 2015-12-14 11:38 ` SF Markus Elfring 2015-12-14 11:38 ` SF Markus Elfring 2015-12-12 14:37 ` [PATCH 2/7] iscsi-target: Less checks in iscsi_set_default_param() after error detection SF Markus Elfring 2015-12-12 14:37 ` SF Markus Elfring 2015-12-12 14:40 ` [PATCH 3/7] iscsi-target: Delete an unnecessary variable initialisation in iscsi_create_default_params() SF Markus Elfring 2015-12-12 14:40 ` [PATCH 3/7] iscsi-target: Delete an unnecessary variable initialisation in iscsi_create_default_para SF Markus Elfring 2015-12-12 14:41 ` [PATCH 4/7] iscsi-target: Make a variable initialisation a bit more obvious in iscsi_create_default_params() SF Markus Elfring 2015-12-12 14:41 ` [PATCH 4/7] iscsi-target: Make a variable initialisation a bit more obvious in iscsi_create_default_ SF Markus Elfring 2015-12-12 14:45 ` [PATCH 4/7] iscsi-target: Make a variable initialisation a bit more obvious in iscsi_create_default_params() Julia Lawall 2015-12-12 14:45 ` [PATCH 4/7] iscsi-target: Make a variable initialisation a bit more obvious in iscsi_create_defa Julia Lawall 2015-12-12 15:02 ` [PATCH 4/7] iscsi-target: Make a variable initialisation a bit more obvious in iscsi_create_default_params() SF Markus Elfring 2015-12-12 15:02 ` [PATCH 4/7] iscsi-target: Make a variable initialisation a bit more obvious in iscsi_create_defa SF Markus Elfring 2015-12-12 14:42 ` [PATCH 5/7] iscsi-target: Rename a jump label in iscsi_create_default_params() SF Markus Elfring 2015-12-12 14:42 ` SF Markus Elfring 2015-12-12 14:43 ` [PATCH 6/7] iscsi-target: Delete unnecessary variable initialisations in iscsi_check_valuelist_for_support() SF Markus Elfring 2015-12-12 14:43 ` [PATCH 6/7] iscsi-target: Delete unnecessary variable initialisations in iscsi_check_valuelist_for_s SF Markus Elfring 2015-12-12 14:45 ` [PATCH 7/7] iscsi-target: Make two variable initialisations a bit more obvious in iscsi_check_valuelist_for_support() SF Markus Elfring 2015-12-12 14:45 ` [PATCH 7/7] iscsi-target: Make two variable initialisations a bit more obvious in iscsi_check_valuel SF Markus Elfring 2015-12-12 17:17 ` [PATCH 7/7] iscsi-target: Make two variable initialisations a bit more obvious in iscsi_check_valuelist_for_support() walter harms 2015-12-12 17:17 ` [PATCH 7/7] iscsi-target: Make two variable initialisations a bit more obvious in iscsi_check_va walter harms 2015-12-13 13:48 ` [PATCH 0/7] staging-Lustre: Fine-tuning for some function implementations SF Markus Elfring 2015-12-13 13:48 ` [lustre-devel] " SF Markus Elfring 2015-12-13 13:48 ` SF Markus Elfring 2015-12-13 13:52 ` [PATCH 1/7] staging: lustre: Delete unnecessary goto statements in six functions SF Markus Elfring 2015-12-13 13:52 ` [lustre-devel] " SF Markus Elfring 2015-12-13 13:52 ` SF Markus Elfring 2015-12-15 14:27 ` Joe Perches 2015-12-15 14:27 ` [lustre-devel] " Joe Perches 2015-12-15 14:27 ` Joe Perches 2015-12-15 14:41 ` Dan Carpenter 2015-12-15 14:41 ` [lustre-devel] " Dan Carpenter 2015-12-15 14:41 ` Dan Carpenter 2015-12-15 15:02 ` Joe Perches 2015-12-15 15:02 ` [lustre-devel] " Joe Perches 2015-12-15 15:02 ` Joe Perches 2015-12-15 17:48 ` Dan Carpenter 2015-12-15 17:48 ` [lustre-devel] " Dan Carpenter 2015-12-15 17:48 ` Dan Carpenter 2015-12-15 18:10 ` Joe Perches 2015-12-15 18:10 ` [lustre-devel] " Joe Perches 2015-12-15 18:10 ` Joe Perches 2015-12-15 18:26 ` SF Markus Elfring 2015-12-15 18:26 ` [lustre-devel] " SF Markus Elfring 2015-12-15 18:26 ` SF Markus Elfring 2015-12-15 18:34 ` Joe Perches 2015-12-15 18:34 ` [lustre-devel] " Joe Perches 2015-12-15 18:34 ` Joe Perches 2015-12-15 18:49 ` SF Markus Elfring 2015-12-15 18:49 ` [lustre-devel] " SF Markus Elfring 2015-12-15 18:49 ` SF Markus Elfring 2015-12-15 18:55 ` Joe Perches 2015-12-15 18:55 ` [lustre-devel] " Joe Perches 2015-12-15 18:55 ` Joe Perches 2015-12-15 18:02 ` SF Markus Elfring 2015-12-15 18:02 ` [lustre-devel] " SF Markus Elfring 2015-12-15 18:02 ` SF Markus Elfring 2015-12-15 18:22 ` Joe Perches 2015-12-15 18:22 ` [lustre-devel] " Joe Perches 2015-12-15 18:22 ` Joe Perches 2015-12-13 13:54 ` [PATCH 2/7] staging: lustre: Rename a jump label for ptlrpc_req_finished() calls SF Markus Elfring 2015-12-13 13:54 ` [lustre-devel] " SF Markus Elfring 2015-12-13 13:54 ` SF Markus Elfring 2015-12-14 6:53 ` Dan Carpenter 2015-12-14 6:53 ` [lustre-devel] " Dan Carpenter 2015-12-14 6:53 ` Dan Carpenter 2015-12-14 9:08 ` SF Markus Elfring 2015-12-14 9:08 ` [lustre-devel] " SF Markus Elfring 2015-12-14 9:08 ` SF Markus Elfring 2015-12-14 9:31 ` Dan Carpenter 2015-12-14 9:31 ` [lustre-devel] " Dan Carpenter 2015-12-14 9:31 ` Dan Carpenter 2015-12-14 10:03 ` SF Markus Elfring 2015-12-14 10:03 ` [lustre-devel] " SF Markus Elfring 2015-12-14 10:03 ` SF Markus Elfring 2015-12-13 13:55 ` [PATCH 3/7] staging: lustre: Rename a jump label for a kfree(key) call SF Markus Elfring 2015-12-13 13:55 ` [lustre-devel] " SF Markus Elfring 2015-12-13 13:55 ` SF Markus Elfring 2015-12-13 13:56 ` [PATCH 4/7] staging: lustre: Delete an unnecessary variable initialisation in mgc_process_recover_log() SF Markus Elfring 2015-12-13 13:56 ` [lustre-devel] " SF Markus Elfring 2015-12-13 13:56 ` [PATCH 4/7] staging: lustre: Delete an unnecessary variable initialisation in mgc_process_recover_lo SF Markus Elfring 2015-12-13 13:57 ` [PATCH 5/7] staging: lustre: Less checks in mgc_process_recover_log() after error detection SF Markus Elfring 2015-12-13 13:57 ` [lustre-devel] " SF Markus Elfring 2015-12-13 13:57 ` SF Markus Elfring 2015-12-14 11:00 ` Dan Carpenter 2015-12-14 11:00 ` [lustre-devel] " Dan Carpenter 2015-12-14 11:00 ` Dan Carpenter 2015-12-14 12:04 ` SF Markus Elfring 2015-12-14 12:04 ` [lustre-devel] " SF Markus Elfring 2015-12-14 12:04 ` SF Markus Elfring 2015-12-14 12:38 ` Dan Carpenter 2015-12-14 12:38 ` [lustre-devel] " Dan Carpenter 2015-12-14 12:38 ` Dan Carpenter 2015-12-14 12:45 ` SF Markus Elfring 2015-12-14 12:45 ` [lustre-devel] " SF Markus Elfring 2015-12-14 12:45 ` SF Markus Elfring 2015-12-14 13:57 ` Dan Carpenter 2015-12-14 13:57 ` [lustre-devel] " Dan Carpenter 2015-12-14 13:57 ` Dan Carpenter 2015-12-14 17:43 ` SF Markus Elfring 2015-12-14 17:43 ` [lustre-devel] " SF Markus Elfring 2015-12-14 17:43 ` SF Markus Elfring 2015-12-15 11:42 ` Dan Carpenter 2015-12-15 11:42 ` [lustre-devel] " Dan Carpenter 2015-12-15 11:42 ` Dan Carpenter 2015-12-15 15:00 ` SF Markus Elfring 2015-12-15 15:00 ` [lustre-devel] " SF Markus Elfring 2015-12-15 15:00 ` SF Markus Elfring 2015-12-13 13:58 ` [PATCH 6/7] staging: lustre: A few checks less " SF Markus Elfring 2015-12-13 13:58 ` [lustre-devel] " SF Markus Elfring 2015-12-13 13:58 ` SF Markus Elfring 2015-12-13 14:00 ` [PATCH 7/7] staging: lustre: Rename a jump label for module_put() calls SF Markus Elfring 2015-12-13 14:00 ` [lustre-devel] " SF Markus Elfring 2015-12-13 14:00 ` SF Markus Elfring 2015-12-21 19:05 ` [PATCH v2 0/4] staging-Lustre: Fine-tuning for some function implementations SF Markus Elfring 2015-12-21 19:05 ` SF Markus Elfring 2015-12-21 19:09 ` [PATCH v2 1/4] staging: lustre: Delete unnecessary goto statements in six functions SF Markus Elfring 2015-12-21 19:09 ` SF Markus Elfring 2015-12-21 19:10 ` [PATCH v2 2/4] staging: lustre: Delete an unnecessary variable initialisation in mgc_process_recover_log() SF Markus Elfring 2015-12-21 19:10 ` [PATCH v2 2/4] staging: lustre: Delete an unnecessary variable initialisation in mgc_process_recover SF Markus Elfring 2015-12-21 19:12 ` [PATCH v2 3/4] staging: lustre: Less checks in mgc_process_recover_log() after error detection SF Markus Elfring 2015-12-21 19:12 ` SF Markus Elfring 2015-12-21 23:48 ` Greg Kroah-Hartman 2015-12-21 23:48 ` Greg Kroah-Hartman 2015-12-22 7:15 ` SF Markus Elfring 2015-12-22 7:15 ` SF Markus Elfring 2015-12-22 8:00 ` Dan Carpenter 2015-12-22 8:00 ` Dan Carpenter 2016-07-26 18:54 ` [PATCH 00/12] staging-Lustre: Fine-tuning for seven function implementations SF Markus Elfring 2016-07-26 18:54 ` [lustre-devel] " SF Markus Elfring 2016-07-26 18:54 ` SF Markus Elfring 2016-07-26 18:56 ` [PATCH 01/12] staging/lustre/ldlm: Delete unnecessary checks before the function call "kset_unregister" SF Markus Elfring 2016-07-26 18:56 ` [lustre-devel] " SF Markus Elfring 2016-07-26 18:56 ` [PATCH 01/12] staging/lustre/ldlm: Delete unnecessary checks before the function call "kset_unregist SF Markus Elfring 2016-07-26 19:00 ` [PATCH 02/12] staging: lustre: Delete unnecessary checks before the function call "kobject_put" SF Markus Elfring 2016-07-26 19:00 ` [lustre-devel] " SF Markus Elfring 2016-07-26 19:00 ` SF Markus Elfring 2016-07-26 19:02 ` [PATCH 03/12] staging: lustre: One function call less in class_register_type() after error detection SF Markus Elfring 2016-07-26 19:02 ` [lustre-devel] " SF Markus Elfring 2016-07-26 19:02 ` SF Markus Elfring 2016-07-26 19:08 ` Oleg Drokin 2016-07-26 19:08 ` [lustre-devel] " Oleg Drokin 2016-07-26 19:08 ` [PATCH 03/12] staging: lustre: One function call less in class_register_type() after error detec Oleg Drokin 2016-07-26 19:04 ` [PATCH 04/12] staging: lustre: Split a condition check in class_register_type() SF Markus Elfring 2016-07-26 19:04 ` [lustre-devel] " SF Markus Elfring 2016-07-26 19:04 ` SF Markus Elfring 2016-07-26 19:05 ` [PATCH 05/12] staging: lustre: Optimize error handling " SF Markus Elfring 2016-07-26 19:05 ` [lustre-devel] " SF Markus Elfring 2016-07-26 19:05 ` SF Markus Elfring 2016-07-26 19:11 ` Oleg Drokin 2016-07-26 19:11 ` [lustre-devel] " Oleg Drokin 2016-07-26 19:11 ` Oleg Drokin 2016-07-26 19:07 ` [PATCH 06/12] staging: lustre: Return directly after a failed kcalloc() in mgc_process_recover_log() SF Markus Elfring 2016-07-26 19:07 ` [lustre-devel] " SF Markus Elfring 2016-07-26 19:07 ` SF Markus Elfring 2016-07-26 19:08 ` [PATCH 07/12] staging: lustre: Less checks after a failed alloc_page() " SF Markus Elfring 2016-07-26 19:08 ` [lustre-devel] " SF Markus Elfring 2016-07-26 19:08 ` SF Markus Elfring 2016-07-26 19:09 ` [PATCH 08/12] staging: lustre: Less checks after a failed ptlrpc_request_alloc() " SF Markus Elfring 2016-07-26 19:09 ` [lustre-devel] " SF Markus Elfring 2016-07-26 19:09 ` [PATCH 08/12] staging: lustre: Less checks after a failed ptlrpc_request_alloc() in mgc_process_reco SF Markus Elfring 2016-07-26 19:10 ` [PATCH 09/12] staging: lustre: Delete a check for the variable "req" in mgc_process_recover_log() SF Markus Elfring 2016-07-26 19:10 ` [lustre-devel] " SF Markus Elfring 2016-07-26 19:10 ` SF Markus Elfring 2016-07-26 19:12 ` [PATCH 10/12] staging: lustre: Rename jump labels " SF Markus Elfring 2016-07-26 19:12 ` [lustre-devel] " SF Markus Elfring 2016-07-26 19:12 ` SF Markus Elfring 2016-07-26 19:13 ` [PATCH 11/12] staging: lustre: Move an assignment for the variable "eof" " SF Markus Elfring 2016-07-26 19:13 ` [lustre-devel] " SF Markus Elfring 2016-07-26 19:13 ` [PATCH 11/12] staging: lustre: Move an assignment for the variable "eof" in mgc_process_recover_log( SF Markus Elfring 2016-07-26 19:14 ` [PATCH 12/12] staging: lustre: Delete an unnecessary variable initialisation in mgc_process_recover_log() SF Markus Elfring 2015-12-21 19:13 ` [PATCH v2 4/4] staging: lustre: Fix a jump label position in osc_get_info() SF Markus Elfring 2015-12-21 19:13 ` SF Markus Elfring 2015-12-14 22:10 ` [POWERPC] bootwrapper: One check less in fsl_get_immr() after error detection SF Markus Elfring 2015-12-14 22:10 ` SF Markus Elfring 2015-12-14 22:20 ` Scott Wood 2015-12-14 22:20 ` Scott Wood 2015-12-23 9:43 ` [PATCH] block-LDM: One function call less in ldm_validate_tocblocks() " SF Markus Elfring 2015-12-23 9:43 ` SF Markus Elfring 2015-12-23 10:41 ` Julia Lawall 2015-12-23 10:41 ` Julia Lawall 2015-12-23 18:02 ` [PATCH 0/5] block-LDM: Improvements for exception handling SF Markus Elfring 2015-12-23 18:02 ` SF Markus Elfring 2015-12-23 18:06 ` [PATCH 1/5] block-LDM: One function call less in ldm_validate_tocblocks() after error detection SF Markus Elfring 2015-12-23 18:06 ` SF Markus Elfring 2015-12-23 18:09 ` [PATCH 2/5] block-LDM: Delete extra log messages for memory allocation failures SF Markus Elfring 2015-12-23 18:09 ` SF Markus Elfring 2015-12-23 18:10 ` [PATCH 3/5] block-LDM: One function call less in ldm_partition() after error detection SF Markus Elfring 2015-12-23 18:10 ` SF Markus Elfring 2015-12-23 18:12 ` [PATCH 4/5] block-LDM: Less function calls in ldm_validate_privheads() " SF Markus Elfring 2015-12-23 18:12 ` SF Markus Elfring 2015-12-23 18:13 ` [PATCH 5/5] block-LDM: Fine-tuning for the source code formatting SF Markus Elfring 2015-12-23 18:13 ` SF Markus Elfring 2015-12-24 12:31 ` [PATCH 0/3] Documentation-getdelays: Fine-tuning for two functions SF Markus Elfring 2015-12-24 12:31 ` SF Markus Elfring 2015-12-24 12:34 ` [PATCH 1/3] Documentation-getdelays: Fix a check for container file usage in main() SF Markus Elfring 2015-12-24 12:34 ` SF Markus Elfring 2015-12-24 14:22 ` Jonathan Corbet 2015-12-24 14:22 ` Jonathan Corbet 2015-12-24 17:54 ` SF Markus Elfring 2015-12-24 17:54 ` SF Markus Elfring 2015-12-24 12:36 ` [PATCH 2/3] Documentation-getdelays: Apply a recommendation from "checkpatch.pl" " SF Markus Elfring 2015-12-24 12:36 ` SF Markus Elfring 2015-12-24 14:22 ` Jonathan Corbet 2015-12-24 14:22 ` Jonathan Corbet 2015-12-24 12:38 ` [PATCH 3/3] Documentation-getdelays: Less function calls in usage() SF Markus Elfring 2015-12-24 12:38 ` SF Markus Elfring 2015-12-24 14:23 ` Jonathan Corbet 2015-12-24 14:23 ` Jonathan Corbet 2015-12-24 19:40 ` SF Markus Elfring 2015-12-24 19:40 ` SF Markus Elfring 2015-12-25 10:35 ` ACPI-fan: Another source code review around null pointer handling? SF Markus Elfring 2015-12-25 10:35 ` SF Markus Elfring 2015-12-25 16:00 ` sata_mv: Another source code review around exception handling? SF Markus Elfring 2015-12-25 16:00 ` SF Markus Elfring 2015-12-28 16:10 ` Tejun Heo 2015-12-28 16:10 ` Tejun Heo 2015-12-25 18:49 ` [PATCH] gpio-ucb1400: Delete an unnecessary variable initialisation in ucb1400_gpio_probe() SF Markus Elfring 2015-12-25 18:49 ` SF Markus Elfring 2015-12-26 6:34 ` [PATCH] i2c-core: One function call less in acpi_i2c_space_handler() after error detection SF Markus Elfring 2015-12-26 6:34 ` SF Markus Elfring 2015-12-26 6:47 ` kbuild test robot 2015-12-26 6:47 ` kbuild test robot 2015-12-26 7:08 ` [PATCH v2] " SF Markus Elfring 2015-12-26 7:08 ` SF Markus Elfring 2015-12-26 7:48 ` Wolfram Sang 2015-12-26 7:48 ` Wolfram Sang 2015-12-26 8:52 ` SF Markus Elfring 2015-12-26 8:52 ` SF Markus Elfring 2015-12-26 18:41 ` Wolfram Sang 2015-12-26 18:41 ` Wolfram Sang 2015-12-26 19:30 ` SF Markus Elfring 2015-12-26 19:30 ` SF Markus Elfring 2015-12-26 10:10 ` [PATCH 0/3] IDE-ACPI: Fine-tuning for a function SF Markus Elfring 2015-12-26 10:10 ` SF Markus Elfring 2015-12-26 10:15 ` [PATCH 1/3] IDE-ACPI: One function call less in ide_get_dev_handle() after error detection SF Markus Elfring 2015-12-26 10:15 ` SF Markus Elfring 2015-12-26 10:17 ` [PATCH 2/3] IDE-ACPI: Delete unnecessary null pointer checks in ide_get_dev_handle() SF Markus Elfring 2015-12-26 10:17 ` SF Markus Elfring 2015-12-26 10:20 ` [PATCH 3/3] IDE-ACPI: Move an assignment for one variable " SF Markus Elfring 2015-12-26 10:20 ` SF Markus Elfring 2015-12-26 18:12 ` [PATCH 0/3] IDE-ACPI: Fine-tuning for a function David Miller 2015-12-26 18:12 ` David Miller 2015-12-26 23:43 ` Joe Perches 2015-12-26 23:43 ` Joe Perches 2015-12-27 6:08 ` Julia Lawall 2015-12-27 6:08 ` Julia Lawall 2015-12-26 13:04 ` [PATCH] iio: qcom-spmi-vadc: One check less in vadc_measure_ref_points() after error detection SF Markus Elfring 2015-12-26 13:04 ` SF Markus Elfring 2016-01-02 18:28 ` Jonathan Cameron 2016-01-02 18:28 ` Jonathan Cameron 2015-12-26 18:39 ` [PATCH 0/6] InfiniBand-ocrdma: Fine-tuning for some function implementations SF Markus Elfring 2015-12-26 18:39 ` SF Markus Elfring 2015-12-26 18:43 ` [PATCH 1/6] InfiniBand-ocrdma: One variable and jump label less in ocrdma_alloc_ucontext_pd() SF Markus Elfring 2015-12-26 18:43 ` SF Markus Elfring 2015-12-26 19:41 ` kbuild test robot 2015-12-26 19:41 ` kbuild test robot 2015-12-26 21:28 ` [PATCH v2 1/6] InfiniBand-ocrdma: One " SF Markus Elfring 2015-12-26 21:28 ` SF Markus Elfring 2016-01-11 13:11 ` Selvin Xavier 2016-01-11 13:23 ` Selvin Xavier [not found] ` <567EDED5.4040201-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> 2015-12-26 18:45 ` [PATCH 2/6] InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions SF Markus Elfring 2015-12-26 18:45 ` SF Markus Elfring 2015-12-26 18:45 ` SF Markus Elfring 2015-12-26 18:47 ` [PATCH 3/6] InfiniBand-ocrdma: Returning only value constants in ocrdma_qp_state_change() SF Markus Elfring 2015-12-26 18:47 ` SF Markus Elfring 2015-12-26 18:47 ` SF Markus Elfring 2015-12-26 18:49 ` [PATCH 4/6] InfiniBand-ocrdma: Return a value from a function call in _ocrdma_modify_qp() directly SF Markus Elfring 2015-12-26 18:49 ` SF Markus Elfring 2015-12-26 18:49 ` SF Markus Elfring 2016-01-14 17:18 ` [PATCH v3 0/6] InfiniBand-ocrdma: Fine-tuning for some function implementations SF Markus Elfring 2016-01-14 17:18 ` SF Markus Elfring 2016-01-14 17:18 ` SF Markus Elfring [not found] ` <5697D865.5010507-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> 2016-01-14 17:38 ` [PATCH v3 1/6] InfiniBand-ocrdma: One jump label less in ocrdma_alloc_ucontext_pd() SF Markus Elfring 2016-01-14 17:38 ` SF Markus Elfring 2016-01-14 17:38 ` SF Markus Elfring 2016-01-14 17:50 ` [PATCH v3 5/6] InfiniBand-ocrdma: Returning only value constants in ocrdma_resize_cq() SF Markus Elfring 2016-01-14 17:50 ` SF Markus Elfring 2016-01-14 17:50 ` SF Markus Elfring 2016-01-14 17:43 ` [PATCH v3 2/6] InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions SF Markus Elfring 2016-01-14 17:43 ` SF Markus Elfring 2016-01-15 13:20 ` Leon Romanovsky 2016-01-15 13:20 ` Leon Romanovsky [not found] ` <20160115132014.GC30615-2ukJVAZIZ/Y@public.gmane.org> 2016-01-15 14:50 ` SF Markus Elfring 2016-01-15 14:50 ` SF Markus Elfring 2016-01-15 14:50 ` SF Markus Elfring [not found] ` <56990733.7000506-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> 2016-01-15 15:09 ` Leon Romanovsky 2016-01-15 15:09 ` Leon Romanovsky 2016-01-15 15:09 ` Leon Romanovsky [not found] ` <20160115150935.GA32346-2ukJVAZIZ/Y@public.gmane.org> 2016-01-15 15:26 ` SF Markus Elfring 2016-01-15 15:26 ` SF Markus Elfring 2016-01-15 15:26 ` SF Markus Elfring [not found] ` <56990FAC.6000506-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> 2016-01-15 15:59 ` Leon Romanovsky 2016-01-15 15:59 ` Leon Romanovsky 2016-01-15 15:59 ` Leon Romanovsky [not found] ` <20160115155938.GB32346-2ukJVAZIZ/Y@public.gmane.org> 2016-01-15 16:10 ` Dan Carpenter 2016-01-15 16:10 ` Dan Carpenter 2016-01-15 16:10 ` Dan Carpenter 2016-01-15 16:24 ` SF Markus Elfring 2016-01-15 16:24 ` SF Markus Elfring 2016-01-15 16:24 ` SF Markus Elfring [not found] ` <56991D52.8030808-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> 2016-01-15 17:00 ` Leon Romanovsky 2016-01-15 17:00 ` Leon Romanovsky 2016-01-15 17:00 ` Leon Romanovsky [not found] ` <20160115170048.GC32346-2ukJVAZIZ/Y@public.gmane.org> 2016-01-15 17:19 ` Bart Van Assche 2016-01-15 17:19 ` Bart Van Assche 2016-01-15 17:19 ` Bart Van Assche 2016-01-15 17:41 ` Leon Romanovsky 2016-01-15 17:41 ` Leon Romanovsky 2016-01-15 18:19 ` SF Markus Elfring 2016-01-15 18:19 ` SF Markus Elfring 2016-01-16 6:18 ` Leon Romanovsky 2016-01-16 6:18 ` Leon Romanovsky [not found] ` <20160116061843.GE32346-2ukJVAZIZ/Y@public.gmane.org> 2016-01-16 8:30 ` SF Markus Elfring 2016-01-16 8:30 ` [LTP] " SF Markus Elfring 2016-01-16 8:30 ` SF Markus Elfring 2016-01-16 8:30 ` SF Markus Elfring 2016-01-14 17:45 ` [PATCH v3 3/6] InfiniBand-ocrdma: Returning only value constants in ocrdma_qp_state_change() SF Markus Elfring 2016-01-14 17:45 ` SF Markus Elfring 2016-01-14 17:48 ` [PATCH v3 4/6] InfiniBand-ocrdma: Return a value from a function call in _ocrdma_modify_qp() directly SF Markus Elfring 2016-01-14 17:48 ` [PATCH v3 4/6] InfiniBand-ocrdma: Return a value from a function call in _ocrdma_modify_qp() directl SF Markus Elfring 2016-01-14 17:51 ` [PATCH v3 6/6] InfiniBand-ocrdma: Delete an unnecessary variable in ocrdma_dealloc_pd() SF Markus Elfring 2016-01-14 17:51 ` SF Markus Elfring 2015-12-26 18:50 ` [PATCH 5/6] InfiniBand-ocrdma: Returning only value constants in ocrdma_resize_cq() SF Markus Elfring 2015-12-26 18:50 ` SF Markus Elfring 2015-12-26 18:51 ` [PATCH 6/6] InfiniBand-ocrdma: Delete an unnecessary variable in ocrdma_dealloc_pd() SF Markus Elfring 2015-12-26 18:51 ` SF Markus Elfring 2015-12-27 12:36 ` [PATCH 0/2] InfiniBand-iSER: Refactoring for two function implementations SF Markus Elfring 2015-12-27 12:36 ` SF Markus Elfring 2015-12-27 12:40 ` [PATCH 1/2] InfiniBand-iSER: One jump label less in iser_reg_sig_mr() SF Markus Elfring 2015-12-27 12:40 ` SF Markus Elfring 2015-12-27 12:41 ` [PATCH 2/2] InfiniBand-iSER-target: One jump label less in isert_reg_sig_mr() SF Markus Elfring 2015-12-27 12:41 ` SF Markus Elfring [not found] ` <567FDB4E.2040000-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> 2015-12-27 12:43 ` [PATCH 0/2] InfiniBand-iSER: Refactoring for two function implementations Leon Romanovsky 2015-12-27 12:43 ` Leon Romanovsky 2015-12-27 12:43 ` Leon Romanovsky 2015-12-27 12:52 ` Leon Romanovsky 2015-12-27 12:52 ` Leon Romanovsky 2015-12-27 12:52 ` Leon Romanovsky 2016-01-06 18:47 ` Nicholas A. Bellinger 2016-01-06 18:47 ` Nicholas A. Bellinger 2016-01-06 18:47 ` Nicholas A. Bellinger 2015-12-27 15:26 ` Sagi Grimberg 2015-12-27 15:26 ` Sagi Grimberg 2015-12-27 17:33 ` [PATCH] [media] si2165: Refactoring for si2165_writereg_mask8() SF Markus Elfring 2015-12-27 17:33 ` SF Markus Elfring 2016-01-04 8:39 ` Matthias Schwarzott 2016-01-04 8:39 ` Matthias Schwarzott 2015-12-27 21:22 ` [PATCH] [media] bttv: Returning only value constants in two functions SF Markus Elfring 2015-12-27 21:22 ` SF Markus Elfring 2015-12-28 9:15 ` [PATCH] [media] tuners: One check less in m88rs6000t_get_rf_strength() after error detection SF Markus Elfring 2015-12-28 9:15 ` SF Markus Elfring 2015-12-28 9:20 ` Julia Lawall 2015-12-28 9:20 ` Julia Lawall 2015-12-28 10:30 ` SF Markus Elfring 2015-12-28 10:30 ` SF Markus Elfring 2015-12-28 10:36 ` Julia Lawall 2015-12-28 10:36 ` Julia Lawall 2015-12-28 14:36 ` [PATCH 0/2] [media] m88rs6000t: Fine-tuning for some function implementations SF Markus Elfring 2015-12-28 14:36 ` SF Markus Elfring 2015-12-28 14:38 ` [PATCH 1/2] [media] m88rs6000t: Better exception handling in five functions SF Markus Elfring 2015-12-28 14:38 ` SF Markus Elfring 2015-12-28 14:42 ` Julia Lawall 2015-12-28 14:42 ` Julia Lawall 2015-12-28 15:03 ` SF Markus Elfring 2015-12-28 15:03 ` SF Markus Elfring 2015-12-28 15:12 ` Julia Lawall 2015-12-28 15:12 ` Julia Lawall 2016-01-25 17:01 ` [PATCH 1/2] " Mauro Carvalho Chehab 2016-01-25 17:01 ` Mauro Carvalho Chehab 2016-01-25 18:15 ` SF Markus Elfring 2016-01-25 18:15 ` SF Markus Elfring 2015-12-28 14:42 ` [PATCH 2/2] [media] tuners: Refactoring for m88rs6000t_sleep() SF Markus Elfring 2015-12-28 14:42 ` SF Markus Elfring 2015-12-28 16:24 ` [PATCH 0/2] [media] r820t: Fine-tuning for generic_set_freq() SF Markus Elfring 2015-12-28 16:24 ` SF Markus Elfring 2015-12-28 16:30 ` [PATCH 1/2] [media] r820t: Delete an unnecessary variable initialisation in generic_set_freq() SF Markus Elfring 2015-12-28 16:30 ` SF Markus Elfring 2015-12-28 16:32 ` [PATCH 2/2] [media] r820t: Better exception handling " SF Markus Elfring 2015-12-28 16:32 ` SF Markus Elfring 2016-01-25 17:04 ` Mauro Carvalho Chehab 2016-01-25 17:04 ` Mauro Carvalho Chehab 2015-12-28 19:20 ` [PATCH] [media] xc5000: Faster result reporting in xc_load_fw_and_init_tuner() SF Markus Elfring 2015-12-28 19:20 ` SF Markus Elfring 2016-01-25 17:06 ` Mauro Carvalho Chehab 2016-01-25 17:06 ` Mauro Carvalho Chehab 2016-01-25 18:23 ` SF Markus Elfring 2016-01-25 18:23 ` SF Markus Elfring 2016-01-25 18:38 ` Devin Heitmueller 2016-01-25 18:38 ` Devin Heitmueller 2015-12-28 21:15 ` [PATCH] [media] airspy: Better exception handling in two functions SF Markus Elfring 2015-12-28 21:15 ` SF Markus Elfring 2015-12-28 21:56 ` [PATCH] [media] au0828: Refactoring for start_urb_transfer() SF Markus Elfring 2015-12-28 21:56 ` SF Markus Elfring 2015-12-29 10:18 ` [PATCH] [media] hdpvr: Refactoring for hdpvr_read() SF Markus Elfring 2015-12-29 10:18 ` SF Markus Elfring 2015-12-29 11:37 ` [PATCH] [media] msi2500: Delete an unnecessary check in msi2500_set_usb_adc() SF Markus Elfring 2015-12-29 11:37 ` SF Markus Elfring 2015-12-29 13:04 ` [PATCH] mfd-dm355evm_msp: One function call less in add_child() after error detection SF Markus Elfring 2015-12-29 13:04 ` SF Markus Elfring 2016-01-11 8:31 ` Lee Jones 2016-01-11 8:31 ` Lee Jones 2016-01-12 8:34 ` SF Markus Elfring 2016-01-12 8:34 ` SF Markus Elfring 2016-01-12 9:06 ` Lee Jones 2016-01-12 9:06 ` Lee Jones 2016-01-12 11:48 ` SF Markus Elfring 2016-01-12 11:48 ` SF Markus Elfring 2016-01-12 11:59 ` Lee Jones 2016-01-12 11:59 ` Lee Jones 2016-01-12 11:59 ` [PATCH] " Lee Jones 2016-01-12 11:59 ` Lee Jones 2016-01-12 12:20 ` SF Markus Elfring 2016-01-12 12:20 ` SF Markus Elfring 2015-12-29 14:15 ` [PATCH 0/2] mfd: smsc-ece1099: Fine-tuning for smsc_i2c_probe() SF Markus Elfring 2015-12-29 14:15 ` SF Markus Elfring 2015-12-29 14:17 ` [PATCH 1/2] mfd: smsc-ece1099: Delete an unnecessary variable initialisation in smsc_i2c_probe() SF Markus Elfring 2015-12-29 14:17 ` SF Markus Elfring 2016-01-11 8:15 ` Lee Jones 2016-01-11 8:15 ` Lee Jones 2015-12-29 14:18 ` [PATCH 2/2] mfd: smsc-ece1099: Refactoring for smsc_i2c_probe() SF Markus Elfring 2015-12-29 14:18 ` SF Markus Elfring 2016-01-11 8:10 ` Lee Jones 2016-01-11 8:10 ` Lee Jones 2016-01-11 8:12 ` Lee Jones 2016-01-11 8:12 ` Lee Jones [not found] ` <5694BE21.3010504@users.sourceforge.net> 2016-01-12 9:05 ` Lee Jones 2016-01-12 9:05 ` Lee Jones 2016-01-12 11:28 ` SF Markus Elfring 2016-01-12 11:28 ` SF Markus Elfring 2016-01-11 8:08 ` [PATCH 0/2] mfd: smsc-ece1099: Fine-tuning " Lee Jones 2016-01-11 8:08 ` Lee Jones 2016-01-12 9:00 ` SF Markus Elfring 2016-01-12 9:00 ` SF Markus Elfring 2016-01-12 9:12 ` Lee Jones 2016-01-12 11:03 ` SF Markus Elfring 2016-01-12 11:03 ` SF Markus Elfring 2016-01-12 11:14 ` Lee Jones 2016-01-12 11:42 ` SF Markus Elfring 2016-01-12 11:42 ` SF Markus Elfring 2016-01-12 12:03 ` Lee Jones 2016-01-12 12:03 ` Lee Jones 2015-12-29 18:34 ` [PATCH] mfd: twl-core: One function call less in add_numbered_child() after error detection SF Markus Elfring 2015-12-29 18:34 ` SF Markus Elfring 2016-01-11 8:29 ` Lee Jones 2016-01-11 8:29 ` Lee Jones 2016-01-11 8:29 ` Lee Jones 2016-05-15 18:11 ` [PATCH 0/2] mfd: twl-core: Fine-tuning for add_numbered_child() SF Markus Elfring 2016-05-15 18:11 ` SF Markus Elfring 2016-05-16 6:26 ` [PATCH 1/2] mfd: twl-core: Return directly after a failed platform_device_alloc() in add_numbered_child() SF Markus Elfring 2016-05-16 6:26 ` [PATCH 1/2] mfd: twl-core: Return directly after a failed platform_device_alloc() in add_numbered_ch SF Markus Elfring 2016-05-16 6:51 ` [PATCH 1/2] mfd: twl-core: Return directly after a failed platform_device_alloc() in add_numbered_child() Julia Lawall 2016-05-16 6:51 ` [PATCH 1/2] mfd: twl-core: Return directly after a failed platform_device_alloc() in add_numbere Julia Lawall 2016-05-16 7:54 ` mfd: twl-core: Return directly after a failed platform_device_alloc() in add_numbered_child() SF Markus Elfring 2016-05-16 7:54 ` SF Markus Elfring 2016-05-16 8:07 ` Julia Lawall 2016-05-16 8:07 ` Julia Lawall 2016-05-17 6:00 ` Lee Jones 2016-05-17 6:00 ` Lee Jones 2016-05-17 14:15 ` SF Markus Elfring 2016-05-17 14:15 ` SF Markus Elfring 2016-05-16 6:28 ` [PATCH 2/2] mfd: twl-core: Refactoring for add_numbered_child() SF Markus Elfring 2016-05-16 6:28 ` SF Markus Elfring 2016-06-08 11:14 ` Lee Jones 2016-06-08 11:14 ` Lee Jones 2016-06-26 13:34 ` [PATCH 0/6] mfd: Fine-tuning for three function implementations SF Markus Elfring 2016-06-26 13:34 ` SF Markus Elfring 2016-06-26 13:45 ` [PATCH 1/6] mfd: twl-core: Return directly after a failed platform_device_alloc() in add_numbered_child() SF Markus Elfring 2016-06-26 13:45 ` [PATCH 1/6] mfd: twl-core: Return directly after a failed platform_device_alloc() in add_numbered_ch SF Markus Elfring 2016-06-28 15:02 ` [PATCH 1/6] mfd: twl-core: Return directly after a failed platform_device_alloc() in add_numbered_child() Lee Jones 2016-06-28 15:02 ` [PATCH 1/6] mfd: twl-core: Return directly after a failed platform_device_alloc() in add_numbere Lee Jones 2016-06-26 13:47 ` [PATCH 2/6] mfd: twl-core: Refactoring for add_numbered_child() SF Markus Elfring 2016-06-26 13:47 ` SF Markus Elfring 2016-06-28 15:03 ` Lee Jones 2016-06-28 15:03 ` Lee Jones 2016-06-28 15:03 ` Lee Jones 2016-06-26 13:48 ` [PATCH 3/6] mfd: dm355evm_msp: Return directly after a failed platform_device_alloc() in add_child() SF Markus Elfring 2016-06-26 13:48 ` SF Markus Elfring 2016-06-28 15:03 ` Lee Jones 2016-06-28 15:03 ` [PATCH 3/6] mfd: dm355evm_msp: Return directly after a failed platform_device_alloc() in add_chi Lee Jones 2016-06-26 13:50 ` [PATCH 4/6] mfd: dm355evm_msp: Refactoring for add_child() SF Markus Elfring 2016-06-26 13:50 ` SF Markus Elfring 2016-06-28 15:07 ` Lee Jones 2016-06-28 15:07 ` Lee Jones 2016-06-28 15:07 ` Lee Jones 2016-06-28 15:40 ` SF Markus Elfring 2016-06-28 15:40 ` SF Markus Elfring 2016-06-28 16:31 ` Lee Jones 2016-06-28 16:31 ` Lee Jones 2016-06-30 20:15 ` [PATCH] " SF Markus Elfring 2016-06-30 20:15 ` SF Markus Elfring 2016-06-30 20:34 ` Joe Perches 2016-06-30 20:34 ` Joe Perches 2016-06-30 20:59 ` Lee Jones 2016-06-30 21:00 ` Lee Jones 2016-07-01 14:40 ` SF Markus Elfring 2016-07-01 14:40 ` SF Markus Elfring 2016-07-01 16:23 ` Joe Perches 2016-07-01 16:23 ` Joe Perches 2016-07-01 9:17 ` [PATCH] " Lee Jones 2016-07-01 9:17 ` Lee Jones 2016-07-01 14:54 ` SF Markus Elfring 2016-07-01 14:54 ` SF Markus Elfring 2016-06-26 13:51 ` [PATCH 5/6] mfd: smsc-ece1099: Delete an unnecessary variable initialisation in smsc_i2c_probe() SF Markus Elfring 2016-06-26 13:51 ` SF Markus Elfring 2016-06-28 15:07 ` Lee Jones 2016-06-28 15:07 ` Lee Jones 2016-06-28 15:07 ` Lee Jones 2016-06-26 13:54 ` [PATCH 6/6] mfd: smsc-ece1099: Return directly after a function failure " SF Markus Elfring 2016-06-26 13:54 ` SF Markus Elfring 2016-06-28 15:08 ` Lee Jones 2016-06-28 15:08 ` Lee Jones 2016-06-28 15:01 ` [PATCH 0/6] mfd: Fine-tuning for three function implementations Lee Jones 2016-06-28 15:01 ` Lee Jones 2016-06-28 15:01 ` Lee Jones 2015-12-29 19:50 ` [PATCH] mmc-core: One check less in mmc_select_hs200() after error detection SF Markus Elfring 2015-12-29 19:50 ` SF Markus Elfring 2016-01-12 15:07 ` Ulf Hansson 2016-01-12 15:07 ` Ulf Hansson 2015-12-29 20:57 ` [PATCH 0/2] mmc-host: Fine-tuning for one function SF Markus Elfring 2015-12-29 20:57 ` SF Markus Elfring 2015-12-29 21:00 ` [PATCH 1/2] mmc-sdricoh_cs: Delete unnecessary variable initialisations in sdricoh_init_mmc() SF Markus Elfring 2015-12-29 21:00 ` SF Markus Elfring 2016-02-21 9:11 ` Sascha Sommer 2016-02-21 9:11 ` Sascha Sommer 2015-12-29 21:02 ` [PATCH 2/2] mmc-sdricoh_cs: Less checks in sdricoh_init_mmc() after, error detection SF Markus Elfring 2015-12-29 21:02 ` SF Markus Elfring 2016-02-21 9:15 ` Sascha Sommer 2016-02-21 9:15 ` Sascha Sommer 2016-01-27 14:15 ` [PATCH 0/2] mmc-host: Fine-tuning for one function Ulf Hansson 2016-01-27 14:15 ` Ulf Hansson 2015-12-31 20:21 ` [PATCH 0/3] mtd-rfd_ftl: Fine-tuning for two function implementations SF Markus Elfring 2015-12-31 20:21 ` SF Markus Elfring 2015-12-31 20:25 ` [PATCH 1/3] mtd-rfd_ftl: Replace a variable initialisation by assignments in move_block_contents() SF Markus Elfring 2015-12-31 20:25 ` SF Markus Elfring 2015-12-31 20:26 ` [PATCH 2/3] mtd-rfd_ftl: Refactoring for move_block_contents() SF Markus Elfring 2015-12-31 20:26 ` SF Markus Elfring 2015-12-31 20:27 ` [PATCH 3/3] mtd-rfd_ftl: Refactoring for erase_block() SF Markus Elfring 2015-12-31 20:27 ` SF Markus Elfring 2016-01-05 0:13 ` [PATCH 0/3] mtd-rfd_ftl: Fine-tuning for two function implementations Brian Norris 2016-01-05 0:13 ` Brian Norris 2015-12-31 21:47 ` [PATCH] net-thunder: One check less in nicvf_register_interrupts() after error detection SF Markus Elfring 2015-12-31 21:47 ` SF Markus Elfring 2015-12-31 21:47 ` SF Markus Elfring 2015-12-31 21:47 ` SF Markus Elfring 2016-01-07 11:07 ` Robert Richter 2016-01-07 11:07 ` Robert Richter 2016-01-07 11:07 ` Robert Richter 2016-01-07 19:30 ` SF Markus Elfring 2016-01-07 19:30 ` SF Markus Elfring 2016-01-07 19:30 ` SF Markus Elfring 2016-01-07 19:44 ` Joe Perches 2016-01-07 19:44 ` Joe Perches 2016-01-07 19:44 ` Joe Perches 2016-01-07 19:56 ` SF Markus Elfring 2016-01-07 19:56 ` SF Markus Elfring 2016-01-07 19:56 ` SF Markus Elfring 2016-01-07 19:59 ` Joe Perches 2016-01-07 19:59 ` Joe Perches 2016-01-07 19:59 ` Joe Perches 2016-01-07 20:07 ` SF Markus Elfring 2016-01-07 20:07 ` SF Markus Elfring 2016-01-07 20:07 ` SF Markus Elfring 2016-01-07 20:28 ` Joe Perches 2016-01-07 20:28 ` Joe Perches 2016-01-07 20:28 ` Joe Perches 2016-01-07 20:38 ` SF Markus Elfring 2016-01-07 20:38 ` SF Markus Elfring 2016-01-07 20:38 ` SF Markus Elfring 2016-01-07 20:42 ` Joe Perches 2016-01-07 20:42 ` Joe Perches 2016-01-07 20:42 ` Joe Perches 2015-12-31 23:22 ` [PATCH] be2net: Delete an unnecessary check in two functions SF Markus Elfring 2015-12-31 23:22 ` SF Markus Elfring 2016-01-06 6:25 ` Sathya Perla 2016-01-06 6:37 ` Sathya Perla 2016-01-01 12:18 ` [PATCH 0/3] net-gianfar: Fine-tuning for gfar_ethflow_to_filer_table() SF Markus Elfring 2016-01-01 12:18 ` SF Markus Elfring 2016-01-01 12:22 ` [PATCH 1/3] net-gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detection SF Markus Elfring 2016-01-01 12:22 ` SF Markus Elfring 2016-01-01 12:35 ` Julia Lawall 2016-01-01 12:35 ` [PATCH 1/3] net-gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detect Julia Lawall 2016-01-01 12:50 ` [PATCH 1/3] net-gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detection SF Markus Elfring 2016-01-01 12:50 ` [PATCH 1/3] net-gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detect SF Markus Elfring 2016-01-01 13:05 ` [PATCH 1/3] net-gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detection Julia Lawall 2016-01-01 13:05 ` [PATCH 1/3] net-gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detect Julia Lawall 2016-01-01 14:45 ` [PATCH 1/3] net-gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detection Francois Romieu 2016-01-01 14:45 ` [PATCH 1/3] net-gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detect Francois Romieu 2016-01-01 13:04 ` [PATCH v2 1/3] net-gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detection SF Markus Elfring 2016-01-01 13:04 ` [PATCH v2 1/3] net-gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detecti SF Markus Elfring 2016-01-02 3:16 ` [PATCH v2 1/3] net-gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detection David Miller 2016-01-02 3:16 ` [PATCH v2 1/3] net-gianfar: Less function calls in gfar_ethflow_to_filer_table() after error det David Miller 2016-01-01 12:23 ` [PATCH 2/3] net-gianfar: Delete unnecessary variable initialisations in gfar_ethflow_to_filer_table() SF Markus Elfring 2016-01-01 12:23 ` [PATCH 2/3] net-gianfar: Delete unnecessary variable initialisations in gfar_ethflow_to_filer_table( SF Markus Elfring 2016-01-01 12:24 ` [PATCH 3/3] net-gianfar: Extend an initialisation clause of a for loop in gfar_ethflow_to_filer_table() SF Markus Elfring 2016-01-01 12:24 ` [PATCH 3/3] net-gianfar: Extend an initialisation clause of a for loop in gfar_ethflow_to_filer_tabl SF Markus Elfring 2016-01-15 10:09 ` [PATCH v3 0/3] gianfar: Fine-tuning for gfar_ethflow_to_filer_table() SF Markus Elfring 2016-01-15 10:09 ` SF Markus Elfring 2016-01-15 10:11 ` [PATCH v3 1/3] gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detection SF Markus Elfring 2016-01-15 10:11 ` SF Markus Elfring 2016-01-15 10:37 ` Joe Perches 2016-01-15 10:37 ` [PATCH v3 1/3] gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detecti Joe Perches 2016-01-15 11:47 ` gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detection SF Markus Elfring 2016-01-15 11:47 ` SF Markus Elfring 2016-01-15 12:03 ` Joe Perches 2016-01-15 12:03 ` Joe Perches 2016-01-15 12:03 ` Joe Perches 2016-01-15 17:32 ` SF Markus Elfring 2016-01-15 17:32 ` SF Markus Elfring 2016-01-18 13:11 ` Claudiu Manoil 2016-01-15 10:12 ` [PATCH v3 2/3] gianfar: Delete unnecessary variable initialisations in gfar_ethflow_to_filer_table() SF Markus Elfring 2016-01-15 10:12 ` SF Markus Elfring 2016-01-15 10:29 ` Dan Carpenter 2016-01-15 10:29 ` [PATCH v3 2/3] gianfar: Delete unnecessary variable initialisations in gfar_ethflow_to_filer_tab Dan Carpenter 2016-01-15 11:34 ` [PATCH v3 2/3] gianfar: Delete unnecessary variable initialisations in gfar_ethflow_to_filer_table() SF Markus Elfring 2016-01-15 11:34 ` [PATCH v3 2/3] gianfar: Delete unnecessary variable initialisations in gfar_ethflow_to_filer_tab SF Markus Elfring 2016-01-15 12:15 ` [PATCH v3 2/3] gianfar: Delete unnecessary variable initialisations in gfar_ethflow_to_filer_table() Dan Carpenter 2016-01-15 12:15 ` [PATCH v3 2/3] gianfar: Delete unnecessary variable initialisations in gfar_ethflow_to_filer_tab Dan Carpenter 2016-01-15 16:42 ` [PATCH v3 2/3] gianfar: Delete unnecessary variable initialisations in gfar_ethflow_to_filer_table() David Miller 2016-01-15 16:42 ` [PATCH v3 2/3] gianfar: Delete unnecessary variable initialisations in gfar_ethflow_to_filer_tab David Miller 2016-01-15 17:15 ` gianfar: Delete unnecessary variable initialisations in gfar_ethflow_to_filer_table() SF Markus Elfring 2016-01-15 17:15 ` SF Markus Elfring 2016-01-15 10:14 ` [PATCH v3 3/3] gianfar: Extend an initialisation clause of a for loop " SF Markus Elfring 2016-01-15 10:14 ` [PATCH v3 3/3] gianfar: Extend an initialisation clause of a for loop in gfar_ethflow_to_filer_table SF Markus Elfring 2016-01-01 14:32 ` [PATCH] net-i40e: Replace variable initialisations by assignments in i40e_vc_get_vf_resources_msg() SF Markus Elfring 2016-01-01 14:32 ` [Intel-wired-lan] " SF Markus Elfring 2016-01-01 14:32 ` SF Markus Elfring 2016-01-01 14:51 ` net-i40e: Reconsider further usage of variable "i" " SF Markus Elfring 2016-01-01 14:51 ` [Intel-wired-lan] " SF Markus Elfring 2016-01-01 14:51 ` SF Markus Elfring 2016-01-08 20:51 ` Nelson, Shannon 2016-01-08 20:51 ` [Intel-wired-lan] " Nelson, Shannon 2016-01-08 20:51 ` Nelson, Shannon 2016-01-07 22:43 ` [PATCH] net-i40e: Replace variable initialisations by assignments " Nelson, Shannon 2016-01-07 22:43 ` [Intel-wired-lan] " Nelson, Shannon 2016-01-07 22:43 ` [PATCH] net-i40e: Replace variable initialisations by assignments in i40e_vc_get_vf_resources_ms Nelson, Shannon 2016-01-08 10:42 ` [PATCH] net-i40e: Replace variable initialisations by assignments in i40e_vc_get_vf_resources_msg() Jeff Kirsher 2016-01-08 10:42 ` [Intel-wired-lan] " Jeff Kirsher 2016-01-08 10:42 ` [PATCH] net-i40e: Replace variable initialisations by assignments in i40e_vc_get_vf_resources_ms Jeff Kirsher 2016-01-01 15:57 ` [PATCH] net-huawei_cdc_ncm: Delete an unnecessary variable initialisation in huawei_cdc_ncm_bind() SF Markus Elfring 2016-01-01 15:57 ` SF Markus Elfring 2016-01-01 16:50 ` [PATCH 0/2] net-qmi_wwan: Fine-tuning for two function implementations SF Markus Elfring 2016-01-01 16:50 ` SF Markus Elfring 2016-01-01 16:50 ` SF Markus Elfring 2016-01-01 16:54 ` [PATCH 1/2] net-qmi_wwan: Refactoring for qmi_wwan_bind() SF Markus Elfring 2016-01-01 16:54 ` SF Markus Elfring 2016-01-01 16:54 ` SF Markus Elfring 2016-01-02 21:38 ` Bjørn Mork 2016-01-02 21:38 ` Bjørn Mork 2016-01-02 21:38 ` Bjørn Mork 2016-01-01 16:56 ` [PATCH 2/2] net-qmi_wwan: Delete an unnecessary variable initialisation in qmi_wwan_register_subdriver() SF Markus Elfring 2016-01-01 16:56 ` [PATCH 2/2] net-qmi_wwan: Delete an unnecessary variable initialisation in qmi_wwan_register_subdriv SF Markus Elfring 2016-01-02 21:30 ` [PATCH 2/2] net-qmi_wwan: Delete an unnecessary variable initialisation in qmi_wwan_register_subdriver() Bjørn Mork 2016-01-02 21:30 ` [PATCH 2/2] net-qmi_wwan: Delete an unnecessary variable initialisation in qmi_wwan_register_sub Bjørn Mork 2016-01-02 21:30 ` [PATCH 2/2] net-qmi_wwan: Delete an unnecessary variable initialisation in qmi_wwan_register_subdriver() Bjørn Mork 2016-01-03 1:45 ` David Miller 2016-01-03 1:45 ` [PATCH 2/2] net-qmi_wwan: Delete an unnecessary variable initialisation in qmi_wwan_register_sub David Miller 2016-01-03 1:45 ` [PATCH 2/2] net-qmi_wwan: Delete an unnecessary variable initialisation in qmi_wwan_register_subdriver() David Miller 2016-01-01 18:21 ` [PATCH 0/2] net-ath9k_htc: Fine-tuning for two function implementations SF Markus Elfring 2016-01-01 18:21 ` [ath9k-devel] " SF Markus Elfring 2016-01-01 18:21 ` SF Markus Elfring 2016-01-01 18:21 ` SF Markus Elfring 2016-01-01 18:21 ` SF Markus Elfring 2016-01-01 18:23 ` [PATCH 1/2] net-ath9k_htc: Delete an unnecessary variable initialisation in ath9k_hif_usb_rx_stream() SF Markus Elfring 2016-01-01 18:23 ` [ath9k-devel] " SF Markus Elfring 2016-01-01 18:23 ` [PATCH 1/2] net-ath9k_htc: Delete an unnecessary variable initialisation in ath9k_hif_usb_rx_stream( SF Markus Elfring 2016-01-01 18:23 ` [PATCH 1/2] net-ath9k_htc: Delete an unnecessary variable initialisation in ath9k_hif_usb_rx_stream() SF Markus Elfring 2016-01-01 19:14 ` Oleksij Rempel 2016-01-01 19:14 ` [ath9k-devel] " Oleksij Rempel 2016-01-01 19:14 ` [PATCH 1/2] net-ath9k_htc: Delete an unnecessary variable initialisation in ath9k_hif_usb_rx_str Oleksij Rempel 2016-01-01 19:14 ` [PATCH 1/2] net-ath9k_htc: Delete an unnecessary variable initialisation in ath9k_hif_usb_rx_stream() Oleksij Rempel 2016-01-01 19:14 ` Oleksij Rempel 2016-01-01 18:25 ` [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() SF Markus Elfring 2016-01-01 18:25 ` [ath9k-devel] " SF Markus Elfring 2016-01-01 18:25 ` [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_chann SF Markus Elfring 2016-01-01 18:25 ` [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() SF Markus Elfring 2016-01-01 19:14 ` Oleksij Rempel 2016-01-01 19:14 ` [ath9k-devel] " Oleksij Rempel 2016-01-01 19:14 ` [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_c Oleksij Rempel 2016-01-01 19:14 ` [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() Oleksij Rempel 2016-04-08 1:40 ` Julian Calaby 2016-04-08 1:40 ` [ath9k-devel] " Julian Calaby 2016-04-08 1:40 ` [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_c Julian Calaby 2016-04-08 1:40 ` [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() Julian Calaby 2016-04-15 12:09 ` Kalle Valo 2016-04-15 12:09 ` [ath9k-devel] " Kalle Valo 2016-04-15 12:09 ` [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_c Kalle Valo 2016-04-15 12:09 ` [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() Kalle Valo 2016-04-15 14:34 ` Julian Calaby 2016-04-15 14:34 ` [ath9k-devel] " Julian Calaby 2016-04-15 14:34 ` [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_c Julian Calaby 2016-04-15 14:34 ` [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() Julian Calaby 2016-04-19 16:13 ` Kalle Valo 2016-04-19 16:13 ` [ath9k-devel] " Kalle Valo 2016-04-19 16:13 ` [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_c Kalle Valo 2016-04-19 16:13 ` [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel() Kalle Valo 2016-01-01 19:26 ` [PATCH] net-brcmfmac: Delete an unnecessary variable initialisation in brcmf_sdio_download_firmware() SF Markus Elfring 2016-01-01 19:26 ` [PATCH] net-brcmfmac: Delete an unnecessary variable initialisation in brcmf_sdio_download_firmware( SF Markus Elfring 2016-01-02 8:50 ` [PATCH] net-brcmfmac: Delete an unnecessary variable initialisation in brcmf_sdio_download_firmware() Arend van Spriel 2016-01-02 8:50 ` [PATCH] net-brcmfmac: Delete an unnecessary variable initialisation in brcmf_sdio_download_firmw Arend van Spriel 2016-01-02 8:50 ` [PATCH] net-brcmfmac: Delete an unnecessary variable initialisation in brcmf_sdio_download_firmware() Arend van Spriel 2016-01-14 6:58 ` Kalle Valo 2016-01-14 6:58 ` [PATCH] net-brcmfmac: Delete an unnecessary variable initialisation in brcmf_sdio_download_firmw Kalle Valo 2016-01-01 20:27 ` [PATCH 0/3] net-iwlegacy: Fine-tuning for il_eeprom_init() SF Markus Elfring 2016-01-01 20:27 ` SF Markus Elfring 2016-01-01 20:30 ` [PATCH 1/3] net-iwlegacy: Refactoring " SF Markus Elfring 2016-01-01 20:30 ` SF Markus Elfring 2016-01-04 9:33 ` Stanislaw Gruszka 2016-01-04 9:33 ` Stanislaw Gruszka 2016-01-04 9:33 ` Stanislaw Gruszka 2016-01-01 20:31 ` [PATCH 2/3] net-iwlegacy: One check less in il_eeprom_init() after error detection SF Markus Elfring 2016-01-01 20:31 ` SF Markus Elfring 2016-01-01 23:13 ` Sergei Shtylyov 2016-01-01 23:13 ` Sergei Shtylyov 2016-01-01 20:32 ` [PATCH 3/3] net-iwlegacy: Another refactoring for il_eeprom_init() SF Markus Elfring 2016-01-01 20:32 ` SF Markus Elfring 2016-01-02 18:18 ` Souptick Joarder 2016-01-02 18:30 ` Souptick Joarder 2016-01-01 21:33 ` [PATCH] net-libertas: Better exception handling in if_spi_host_to_card_worker() SF Markus Elfring 2016-01-01 21:33 ` SF Markus Elfring 2016-01-01 21:41 ` Julia Lawall 2016-01-01 21:41 ` Julia Lawall 2016-01-01 23:14 ` Sergei Shtylyov 2016-01-01 23:14 ` Sergei Shtylyov 2016-01-02 8:09 ` SF Markus Elfring 2016-01-02 8:09 ` SF Markus Elfring 2016-01-02 8:21 ` Julia Lawall 2016-01-02 8:21 ` Julia Lawall 2016-01-02 8:21 ` Julia Lawall 2016-01-02 9:08 ` SF Markus Elfring 2016-01-02 9:08 ` SF Markus Elfring 2016-01-02 10:13 ` Arend van Spriel 2016-01-02 10:13 ` Arend van Spriel 2016-01-02 11:21 ` SF Markus Elfring 2016-01-02 11:21 ` SF Markus Elfring 2016-01-03 9:36 ` Arend van Spriel 2016-01-03 9:36 ` Arend van Spriel 2016-01-03 12:13 ` SF Markus Elfring 2016-01-03 12:13 ` SF Markus Elfring 2016-01-03 12:13 ` SF Markus Elfring 2016-01-03 15:18 ` Rafał Miłecki 2016-01-03 15:18 ` Rafał Miłecki 2016-01-03 15:18 ` Rafał Miłecki 2016-01-04 10:05 ` Arend van Spriel 2016-01-04 10:05 ` Arend van Spriel 2016-01-04 10:05 ` Arend van Spriel 2016-01-04 11:18 ` Rafał Miłecki 2016-01-04 11:18 ` Rafał Miłecki 2016-01-04 11:18 ` Rafał Miłecki 2016-01-21 15:07 ` [PATCH] " Kalle Valo 2016-01-21 15:07 ` Kalle Valo 2016-01-02 14:40 ` [PATCH 0/3] net-rsi: Fine-tuning for two function implementations SF Markus Elfring 2016-01-02 14:40 ` SF Markus Elfring 2016-01-02 14:43 ` [PATCH 1/3] rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() SF Markus Elfring 2016-01-02 14:43 ` SF Markus Elfring 2016-01-02 15:12 ` net-rsi: Reconsider usage of variable "vap_id" " SF Markus Elfring 2016-01-02 15:12 ` SF Markus Elfring 2016-01-02 16:32 ` [PATCH 1/3] rsi: Delete unnecessary variable initialisations " kbuild test robot 2016-01-02 16:32 ` kbuild test robot 2016-01-02 18:27 ` [PATCH v2 " SF Markus Elfring 2016-01-02 18:27 ` SF Markus Elfring 2016-01-04 9:28 ` [PATCH " Dan Carpenter 2016-01-04 9:28 ` Dan Carpenter 2016-01-04 9:38 ` Dan Carpenter 2016-01-04 9:38 ` Dan Carpenter 2016-01-04 10:44 ` SF Markus Elfring 2016-01-04 10:44 ` SF Markus Elfring 2016-01-04 11:48 ` Dan Carpenter 2016-01-04 11:48 ` Dan Carpenter 2016-01-04 12:33 ` SF Markus Elfring 2016-01-04 12:33 ` SF Markus Elfring 2016-01-04 23:54 ` Julian Calaby 2016-01-04 23:54 ` Julian Calaby 2016-01-04 23:54 ` Julian Calaby 2016-01-05 8:29 ` SF Markus Elfring 2016-01-05 8:29 ` SF Markus Elfring 2016-01-05 9:47 ` Julian Calaby 2016-01-05 9:47 ` Julian Calaby 2016-01-05 16:23 ` SF Markus Elfring 2016-01-05 16:23 ` SF Markus Elfring 2016-01-04 13:17 ` [PATCH 1/3] " Bjørn Mork 2016-01-04 13:17 ` Bjørn Mork 2016-01-04 13:17 ` Bjørn Mork 2016-01-04 14:25 ` Dan Carpenter 2016-01-04 14:25 ` Dan Carpenter 2016-01-04 14:25 ` Dan Carpenter 2016-01-04 17:14 ` David Miller 2016-01-04 17:14 ` David Miller 2016-01-02 14:44 ` [PATCH 2/3] rsi: Delete unnecessary variable initialisations in rsi_send_data_pkt() SF Markus Elfring 2016-01-02 14:44 ` SF Markus Elfring 2016-01-02 14:45 ` [PATCH 3/3] rsi: Replace variable initialisations by assignments " SF Markus Elfring 2016-01-02 14:45 ` SF Markus Elfring 2016-01-02 15:07 ` Francois Romieu 2016-01-02 15:07 ` Francois Romieu 2016-01-15 13:04 ` [PATCH v3 0/3] net-rsi: Fine-tuning for two function implementations SF Markus Elfring 2016-01-15 13:04 ` SF Markus Elfring 2016-01-15 13:04 ` SF Markus Elfring 2016-01-15 13:09 ` [PATCH v3 1/3] rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt() SF Markus Elfring 2016-01-15 13:09 ` SF Markus Elfring 2016-01-15 13:10 ` [PATCH v3 2/3] rsi: Delete unnecessary variable initialisations in rsi_send_data_pkt() SF Markus Elfring 2016-01-15 13:10 ` SF Markus Elfring 2016-01-15 13:12 ` [PATCH v3 3/3] rsi: Replace variable initialisations by assignments " SF Markus Elfring 2016-01-15 13:12 ` SF Markus Elfring 2016-01-19 12:40 ` Dan Carpenter 2016-01-19 12:40 ` Dan Carpenter 2016-01-02 17:50 ` [PATCH 0/5] xen-netback: Fine-tuning for three function implementations SF Markus Elfring 2016-01-02 17:50 ` SF Markus Elfring 2016-01-02 17:54 ` [PATCH 1/5] xen-netback: Delete an unnecessary assignment in connect_rings() SF Markus Elfring 2016-01-02 17:54 ` SF Markus Elfring 2016-01-02 17:54 ` SF Markus Elfring 2016-01-02 17:55 ` [PATCH 2/5] xen-netback: Delete an unnecessary goto statement " SF Markus Elfring 2016-01-02 17:55 ` SF Markus Elfring 2016-01-02 17:55 ` SF Markus Elfring 2016-01-02 17:57 ` [PATCH 3/5] xen-netback: Replace a variable initialisation by an assignment in read_xenbus_vif_flags() SF Markus Elfring 2016-01-02 17:57 ` SF Markus Elfring 2016-01-02 17:57 ` [PATCH 3/5] xen-netback: Replace a variable initialisation by an assignment in read_xenbus_vif_flags SF Markus Elfring 2016-01-02 17:58 ` [PATCH 4/5] xen-netback: Replace a variable initialisation by an assignment in xen_register_watchers() SF Markus Elfring 2016-01-02 17:58 ` SF Markus Elfring 2016-01-02 17:58 ` [PATCH 4/5] xen-netback: Replace a variable initialisation by an assignment in xen_register_watchers SF Markus Elfring 2016-01-02 18:00 ` [PATCH 5/5] xen-netback: Delete an unnecessary variable initialisation in xen_register_watchers() SF Markus Elfring 2016-01-02 18:00 ` SF Markus Elfring 2016-01-02 18:00 ` SF Markus Elfring 2016-01-03 1:34 ` [PATCH 0/5] xen-netback: Fine-tuning for three function implementations Joe Perches 2016-01-03 1:34 ` Joe Perches 2016-01-03 1:34 ` Joe Perches 2016-01-04 9:40 ` Dan Carpenter 2016-01-04 9:40 ` Dan Carpenter 2016-01-04 9:40 ` Dan Carpenter 2016-01-04 11:08 ` Wei Liu 2016-01-04 11:08 ` Wei Liu 2016-01-04 11:08 ` Wei Liu 2016-01-02 17:50 ` SF Markus Elfring 2016-01-02 20:51 ` [PATCH 0/3] NFC-mei_phy: Fine-tuning for two " SF Markus Elfring 2016-01-02 20:51 ` SF Markus Elfring 2016-01-02 20:54 ` [PATCH 1/3] NFC-mei_phy: Refactoring for mei_nfc_connect() SF Markus Elfring 2016-01-02 20:54 ` SF Markus Elfring 2016-01-02 23:41 ` Julian Calaby 2016-01-02 23:41 ` Julian Calaby 2016-01-03 7:00 ` SF Markus Elfring 2016-01-03 7:00 ` SF Markus Elfring 2016-01-03 7:29 ` Joe Perches 2016-01-03 7:29 ` Joe Perches 2016-01-02 20:55 ` [PATCH 2/3] NFC-mei_phy: Refactoring for mei_nfc_if_version() SF Markus Elfring 2016-01-02 20:55 ` SF Markus Elfring 2016-01-02 20:56 ` [PATCH 3/3] NFC-mei_phy: Delete an unnecessary variable initialisation in mei_nfc_if_version() SF Markus Elfring 2016-01-02 20:56 ` SF Markus Elfring 2016-01-03 8:43 ` [PATCH 0/8] rtc-ab-b5ze-s3: Fine-tuning for some function implementations SF Markus Elfring 2016-01-03 8:43 ` SF Markus Elfring 2016-01-03 8:43 ` [rtc-linux] " SF Markus Elfring 2016-01-03 8:50 ` [PATCH 1/8] rtc-ab-b5ze-s3: Better exception handling in abb5zes3_probe() SF Markus Elfring 2016-01-03 8:50 ` SF Markus Elfring 2016-01-03 8:50 ` [rtc-linux] " SF Markus Elfring 2016-01-03 8:51 ` [PATCH 2/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in abb5zes3_rtc_set_alarm() SF Markus Elfring 2016-01-03 8:51 ` SF Markus Elfring 2016-01-03 8:51 ` [rtc-linux] " SF Markus Elfring 2016-01-03 8:52 ` [PATCH 3/8] rtc-ab-b5ze-s3: Delete an unnecessary variable initialisation in _abb5zes3_rtc_set_timer() SF Markus Elfring 2016-01-03 8:52 ` [PATCH 3/8] rtc-ab-b5ze-s3: Delete an unnecessary variable initialisation in _abb5zes3_rtc_set_timer SF Markus Elfring 2016-01-03 8:52 ` [rtc-linux] [PATCH 3/8] rtc-ab-b5ze-s3: Delete an unnecessary variable initialisation in _abb5zes3_rtc_set_timer() SF Markus Elfring 2016-01-03 8:53 ` [PATCH 4/8] rtc-ab-b5ze-s3: Replace a variable initialisation by an assignment in _abb5zes3_rtc_set_alarm() SF Markus Elfring 2016-01-03 8:53 ` [PATCH 4/8] rtc-ab-b5ze-s3: Replace a variable initialisation by an assignment in _abb5zes3_rtc_set_ SF Markus Elfring 2016-01-03 8:53 ` [rtc-linux] [PATCH 4/8] rtc-ab-b5ze-s3: Replace a variable initialisation by an assignment in _abb5zes3_rtc_set_alarm() SF Markus Elfring 2016-01-03 8:54 ` [PATCH 5/8] rtc-ab-b5ze-s3: Replace a variable initialisation by an assignment in _abb5zes3_rtc_read_alarm() SF Markus Elfring 2016-01-03 8:54 ` [PATCH 5/8] rtc-ab-b5ze-s3: Replace a variable initialisation by an assignment in _abb5zes3_rtc_read SF Markus Elfring 2016-01-03 8:54 ` [rtc-linux] [PATCH 5/8] rtc-ab-b5ze-s3: Replace a variable initialisation by an assignment in _abb5zes3_rtc_read_alarm() SF Markus Elfring 2016-01-03 8:55 ` [PATCH 6/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_read_timer() SF Markus Elfring 2016-01-03 8:55 ` SF Markus Elfring 2016-01-03 8:55 ` [rtc-linux] " SF Markus Elfring 2016-01-03 8:56 ` [PATCH 7/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_interrupt() SF Markus Elfring 2016-01-03 8:56 ` SF Markus Elfring 2016-01-03 8:56 ` [rtc-linux] " SF Markus Elfring 2016-01-03 12:48 ` Julia Lawall 2016-01-03 12:48 ` Julia Lawall 2016-01-03 12:48 ` [rtc-linux] " Julia Lawall 2016-01-03 16:54 ` SF Markus Elfring 2016-01-03 16:54 ` SF Markus Elfring 2016-01-03 16:54 ` [rtc-linux] " SF Markus Elfring 2016-01-03 16:59 ` Julia Lawall 2016-01-03 16:59 ` Julia Lawall 2016-01-03 16:59 ` [rtc-linux] " Julia Lawall 2016-01-03 12:48 ` Julia Lawall 2016-01-03 12:48 ` Julia Lawall 2016-01-03 12:48 ` [rtc-linux] " Julia Lawall 2016-01-03 17:00 ` SF Markus Elfring 2016-01-03 17:00 ` SF Markus Elfring 2016-01-03 17:00 ` [rtc-linux] " SF Markus Elfring 2016-01-03 8:57 ` [PATCH 8/8] rtc-ab-b5ze-s3: Delete an unnecessary variable in _abb5zes3_rtc_set_timer() SF Markus Elfring 2016-01-03 8:57 ` SF Markus Elfring 2016-01-03 8:57 ` [rtc-linux] " SF Markus Elfring 2016-01-03 12:47 ` Julia Lawall 2016-01-03 12:47 ` Julia Lawall 2016-01-03 12:47 ` [rtc-linux] " Julia Lawall 2016-01-03 17:25 ` SF Markus Elfring 2016-01-03 17:25 ` SF Markus Elfring 2016-01-03 17:25 ` [rtc-linux] " SF Markus Elfring 2016-01-03 17:29 ` Julia Lawall 2016-01-03 17:29 ` Julia Lawall 2016-01-03 17:29 ` [rtc-linux] " Julia Lawall 2016-01-03 10:00 ` [PATCH 0/2] 390/qeth: Fine-tuning for qeth_core_set_online() SF Markus Elfring 2016-01-03 10:00 ` SF Markus Elfring 2016-01-03 10:02 ` [PATCH 1/2] 390/qeth: Delete an unnecessary variable initialisation in qeth_core_set_online() SF Markus Elfring 2016-01-03 10:02 ` SF Markus Elfring 2016-01-04 11:29 ` Heiko Carstens 2016-01-04 11:29 ` Heiko Carstens 2016-01-07 14:33 ` Ursula Braun 2016-01-07 14:33 ` Ursula Braun 2016-01-08 7:18 ` SF Markus Elfring 2016-01-08 7:18 ` SF Markus Elfring 2016-01-08 8:25 ` Ursula Braun 2016-01-08 8:25 ` Ursula Braun 2016-01-08 12:00 ` SF Markus Elfring 2016-01-08 12:00 ` SF Markus Elfring 2016-01-03 10:02 ` [PATCH 2/2] 390/qeth: Refactoring for qeth_core_set_online() SF Markus Elfring 2016-01-03 10:02 ` SF Markus Elfring 2016-01-04 11:30 ` Heiko Carstens 2016-01-04 11:30 ` Heiko Carstens 2016-01-04 13:10 ` SF Markus Elfring 2016-01-04 13:10 ` SF Markus Elfring 2016-01-04 14:04 ` Heiko Carstens 2016-01-04 14:04 ` Heiko Carstens 2016-01-04 14:10 ` SF Markus Elfring 2016-01-04 14:10 ` SF Markus Elfring 2016-01-05 7:54 ` Heiko Carstens 2016-01-05 7:54 ` Heiko Carstens 2016-01-03 16:32 ` [PATCH] staging-slicoss: Replace variable initialisations by assignments in slic_if_init() SF Markus Elfring 2016-01-03 16:32 ` SF Markus Elfring 2016-01-03 16:41 ` Julia Lawall 2016-01-03 16:41 ` Julia Lawall 2016-01-03 17:48 ` SF Markus Elfring 2016-01-03 17:48 ` SF Markus Elfring 2016-01-03 17:58 ` Greg Kroah-Hartman 2016-01-03 17:58 ` Greg Kroah-Hartman 2016-01-03 18:16 ` SF Markus Elfring 2016-01-03 18:16 ` SF Markus Elfring 2016-01-03 18:26 ` Greg Kroah-Hartman 2016-01-03 18:26 ` Greg Kroah-Hartman 2016-01-03 18:50 ` SF Markus Elfring 2016-01-03 18:50 ` SF Markus Elfring 2016-01-03 19:45 ` Greg Kroah-Hartman 2016-01-03 19:45 ` Greg Kroah-Hartman 2016-01-03 20:10 ` SF Markus Elfring 2016-01-03 20:10 ` SF Markus Elfring 2016-01-03 20:15 ` Greg Kroah-Hartman 2016-01-03 20:15 ` Greg Kroah-Hartman 2016-01-03 20:21 ` SF Markus Elfring 2016-01-03 20:21 ` SF Markus Elfring 2016-07-02 19:00 ` [PATCH 0/2] Input-at32psif: Fine-tuning for OOM handling in psif_probe() SF Markus Elfring 2016-07-02 19:00 ` SF Markus Elfring 2016-07-02 19:05 ` [PATCH 1/2] Input-at32psif: Return directly after a failed kzalloc() " SF Markus Elfring 2016-07-02 19:05 ` SF Markus Elfring 2016-07-02 19:07 ` [PATCH 2/2] Input-at32psif: Remove OOM messages " SF Markus Elfring 2016-07-02 19:07 ` SF Markus Elfring 2016-07-02 19:29 ` Julia Lawall 2016-07-02 19:29 ` Julia Lawall 2016-07-02 20:45 ` [PATCH 0/2] Input-at32psif: Fine-tuning for OOM handling " Joe Perches 2016-07-02 20:45 ` Joe Perches 2016-07-02 20:45 ` Joe Perches 2016-07-03 8:01 ` SF Markus Elfring 2016-07-03 8:01 ` SF Markus Elfring 2016-07-13 22:01 ` Dmitry Torokhov 2016-07-13 22:01 ` Dmitry Torokhov
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.