Re: [RFC] treewide: cleanup unreachable breaks
Hi Tom,
Quick self intro: I have take over drivers/platform/x86
maintainership from Andy.
On 10/17/20 6:09 PM, t...@redhat.com wrote:
> From: Tom Rix
>
> This is a upcoming change to clean up a new warning treewide.
> I am wondering if the change could be one mega patch (see below) or
> normal patch per file about 100 patches or somewhere half way by collecting
> early acks.
>
> clang has a number of useful, new warnings see
> https://clang.llvm.org/docs/DiagnosticsReference.html
>
> This change cleans up -Wunreachable-code-break
> https://clang.llvm.org/docs/DiagnosticsReference.html#wunreachable-code-break
> for 266 of 485 warnings in this week's linux-next, allyesconfig on x86_64.
>
> The method of fixing was to look for warnings where the preceding statement
> was a simple statement and by inspection made the subsequent break unneeded.
> In order of frequency these look like
>
> return and break
>
> switch (c->x86_vendor) {
> case X86_VENDOR_INTEL:
> intel_p5_mcheck_init(c);
> return 1;
> - break;
>
> goto and break
>
> default:
> operation = 0; /* make gcc happy */
> goto fail_response;
> - break;
>
> break and break
> case COLOR_SPACE_SRGB:
> /* by pass */
> REG_SET(OUTPUT_CSC_CONTROL, 0,
> OUTPUT_CSC_GRPH_MODE, 0);
> break;
> - break;
>
> The exception to the simple statement, is a switch case with a block
> and the end of block is a return
>
> struct obj_buffer *buff = r->ptr;
> return scnprintf(str, PRIV_STR_SIZE,
> "size=%u\naddr=0x%X\n", buff->size,
> buff->addr);
> }
> - break;
>
> Not considered obvious and excluded, breaks after
> multi level switches
> complicated if-else if-else blocks
> panic() or similar calls
>
> And there is an odd addition of a 'fallthrough' in drivers/tty/nozomi.c
As Greg already mentioned please split this out into per subsystem patches.
I would be happy to take all the changes to drivers/platform/x86
code upstream as a single patch for all the files there.
Regards,
Hans
> ---
>
> diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
> index 1c08cb9eb9f6..16ce86aed8e2 100644
> --- a/arch/x86/kernel/cpu/mce/core.c
> +++ b/arch/x86/kernel/cpu/mce/core.c
> @@ -1809,15 +1809,13 @@ static int __mcheck_cpu_ancient_init(struct
> cpuinfo_x86 *c)
>
> switch (c->x86_vendor) {
> case X86_VENDOR_INTEL:
> intel_p5_mcheck_init(c);
> return 1;
> - break;
> case X86_VENDOR_CENTAUR:
> winchip_mcheck_init(c);
> return 1;
> - break;
> default:
> return 0;
> }
>
> return 0;
> diff --git a/arch/x86/kernel/cpu/microcode/amd.c
> b/arch/x86/kernel/cpu/microcode/amd.c
> index 3f6b137ef4e6..3d4a48336084 100644
> --- a/arch/x86/kernel/cpu/microcode/amd.c
> +++ b/arch/x86/kernel/cpu/microcode/amd.c
> @@ -213,11 +213,10 @@ static unsigned int __verify_patch_size(u8 family, u32
> sh_psize, size_t buf_size
> max_size = F14H_MPB_MAX_SIZE;
> break;
> default:
> WARN(1, "%s: WTF family: 0x%x\n", __func__, family);
> return 0;
> - break;
> }
>
> if (sh_psize > min_t(u32, buf_size, max_size))
> return 0;
>
> diff --git a/drivers/acpi/utils.c b/drivers/acpi/utils.c
> index 838b719ec7ce..d5411a166685 100644
> --- a/drivers/acpi/utils.c
> +++ b/drivers/acpi/utils.c
> @@ -102,11 +102,10 @@ acpi_extract_package(union acpi_object *package,
> printk(KERN_WARNING PREFIX "Invalid package
> element"
> " [%d]: got number, expecting"
> " [%c]\n",
> i, format_string[i]);
> return AE_BAD_DATA;
> - break;
> }
> break;
>
> case ACPI_TYPE_STRING:
> case ACPI_TYPE_BUFFER:
> @@ -127,11 +126,10 @@ acpi_extract_package(union acpi_object *package,
> printk(KERN_WARNING PREFIX "Invalid package
> element"
> " [%d] got string/buffer,"
> " expecting [%c]\n",
> i, format_string[i]);
> return AE_BAD_DATA;
> - break;
> }
> break;
> case ACPI_TYPE_LOCAL_REFERENCE:
> switch (format_string[i]) {
>
Re: [PATCH v2 1/7] staging: qlge: replace ql_* with qlge_* to avoid namespace clashes with other qlogic drivers
On 2020-10-17 07:16 +0800, Coiby Xu wrote: > On Thu, Oct 15, 2020 at 10:01:36AM +0900, Benjamin Poirier wrote: > > On 2020-10-14 18:43 +0800, Coiby Xu wrote: > > > To avoid namespace clashes with other qlogic drivers and also for the > > > sake of naming consistency, use the "qlge_" prefix as suggested in > > > drivers/staging/qlge/TODO. > > > > > > Suggested-by: Benjamin Poirier > > > Signed-off-by: Coiby Xu > > > --- > > > drivers/staging/qlge/TODO |4 - > > > drivers/staging/qlge/qlge.h | 190 ++-- > > > drivers/staging/qlge/qlge_dbg.c | 1073 --- > > > drivers/staging/qlge/qlge_ethtool.c | 231 ++--- > > > drivers/staging/qlge/qlge_main.c| 1257 +-- > > > drivers/staging/qlge/qlge_mpi.c | 352 > > > 6 files changed, 1551 insertions(+), 1556 deletions(-) > > > > > > diff --git a/drivers/staging/qlge/TODO b/drivers/staging/qlge/TODO > > > index f93f7428f5d5..5ac55664c3e2 100644 > > > --- a/drivers/staging/qlge/TODO > > > +++ b/drivers/staging/qlge/TODO > > > @@ -28,10 +28,6 @@ > > > * the driver has a habit of using runtime checks where compile time > > > checks are > > >possible (ex. ql_free_rx_buffers(), ql_alloc_rx_buffers()) > > > * reorder struct members to avoid holes if it doesn't impact performance > > > -* in terms of namespace, the driver uses either qlge_, ql_ (used by > > > - other qlogic drivers, with clashes, ex: ql_sem_spinlock) or nothing > > > (with > > > - clashes, ex: struct ob_mac_iocb_req). Rename everything to use the > > > "qlge_" > > > - prefix. > > > > You only renamed ql -> qlge. The prefix needs to be added where there is > > currently none like the second example of that text. > > On second thoughts, these structs like ob_mac_iocb_req are defined in > local headers and there is no mixed usage. So even when we want to > build this diver and other qlogic drivers into the kernel instead of > as separate modules, it won't lead to real problems, is it right? Using cscope or ctags and searching for ob_mac_iocb_req will yield ambiguous results. It might also make things more difficult if using a debugger. Looking at other drivers (ex. ice, mlx5), they use a prefix for their private types, just like for their static functions, even though it's not absolutely necessary. I think it's helpful when reading the code because it quickly shows that it is something that was defined in the driver, not in some subsystem. I didn't think about it earlier but it would have been better to leave out this renaming to a subsequent patchset, since this change is unrelated to the debugging features. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC] treewide: cleanup unreachable breaks
On 10/17/20 10:43 PM, Greg KH wrote: > On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote: >> From: Tom Rix >> >> This is a upcoming change to clean up a new warning treewide. >> I am wondering if the change could be one mega patch (see below) or >> normal patch per file about 100 patches or somewhere half way by collecting >> early acks. > Please break it up into one-patch-per-subsystem, like normal, and get it > merged that way. OK. Thanks, Tom > > Sending us a patch, without even a diffstat to review, isn't going to > get you very far... > > thanks, > > greg k-h > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [Ocfs2-devel] [RFC] treewide: cleanup unreachable breaks
On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
> clang has a number of useful, new warnings see
> https://urldefense.com/v3/__https://clang.llvm.org/docs/DiagnosticsReference.html__;!!GqivPVa7Brio!Krxz78O3RKcB9JBMVo_F98FupVhj_jxX60ddN6tKGEbv_cnooXc1nnBmchm-e_O9ieGnyQ$
>
Please get your IT department to remove that stupidity. If you can't,
please send email from a non-Red Hat email address.
I don't understand why this is a useful warning to fix. What actual
problem is caused by the code below?
> return and break
>
> switch (c->x86_vendor) {
> case X86_VENDOR_INTEL:
> intel_p5_mcheck_init(c);
> return 1;
> - break;
Sure, it's unnecessary, but it's not masking a bug. It's not unclear.
Why do we want to enable this warning?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [Ocfs2-devel] [RFC] treewide: cleanup unreachable breaks
On Sun, 2020-10-18 at 19:59 +0100, Matthew Wilcox wrote: > On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote: > > clang has a number of useful, new warnings see > > https://urldefense.com/v3/__https://clang.llvm.org/docs/DiagnosticsReference.html__;!!GqivPVa7Brio!Krxz78O3RKcB9JBMVo_F98FupVhj_jxX60ddN6tKGEbv_cnooXc1nnBmchm-e_O9ieGnyQ$ > > > > Please get your IT department to remove that stupidity. If you can't, > please send email from a non-Red Hat email address. I didn't get it this way, neither did lore. It's on your end. https://lore.kernel.org/lkml/20201017160928.12698-1-t...@redhat.com/ > I don't understand why this is a useful warning to fix. Precision in coding style intent and code minimization would be the biggest factors IMO. > What actual problem is caused by the code below? Obviously none. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [Ocfs2-devel] [RFC] treewide: cleanup unreachable breaks
On Sun, 2020-10-18 at 19:59 +0100, Matthew Wilcox wrote: > On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote: > > clang has a number of useful, new warnings see > > https://urldefense.com/v3/__https://clang.llvm.org/docs/DiagnosticsReference.html__;!!GqivPVa7Brio!Krxz78O3RKcB9JBMVo_F98FupVhj_jxX60ddN6tKGEbv_cnooXc1nnBmchm-e_O9ieGnyQ$ > > > > Please get your IT department to remove that stupidity. If you > can't, please send email from a non-Red Hat email address. Actually, the problem is at Oracle's end somewhere in the ocfs2 list ... if you could fix it, that would be great. The usual real mailing lists didn't get this transformation https://lore.kernel.org/bpf/20201017160928.12698-1-t...@redhat.com/ but the ocfs2 list archive did: https://oss.oracle.com/pipermail/ocfs2-devel/2020-October/015330.html I bet Oracle IT has put some spam filter on the list that mangles URLs this way. James ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [Ocfs2-devel] [RFC] treewide: cleanup unreachable breaks
On Sun, Oct 18, 2020 at 12:13:35PM -0700, James Bottomley wrote: > On Sun, 2020-10-18 at 19:59 +0100, Matthew Wilcox wrote: > > On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote: > > > clang has a number of useful, new warnings see > > > https://urldefense.com/v3/__https://clang.llvm.org/docs/DiagnosticsReference.html__;!!GqivPVa7Brio!Krxz78O3RKcB9JBMVo_F98FupVhj_jxX60ddN6tKGEbv_cnooXc1nnBmchm-e_O9ieGnyQ$ > > > > > > > Please get your IT department to remove that stupidity. If you > > can't, please send email from a non-Red Hat email address. > > Actually, the problem is at Oracle's end somewhere in the ocfs2 list > ... if you could fix it, that would be great. The usual real mailing > lists didn't get this transformation > > https://lore.kernel.org/bpf/20201017160928.12698-1-t...@redhat.com/ > > but the ocfs2 list archive did: > > https://oss.oracle.com/pipermail/ocfs2-devel/2020-October/015330.html > > I bet Oracle IT has put some spam filter on the list that mangles URLs > this way. *sigh*. I'm sure there's a way. I've raised it with someone who should be able to fix it. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [Ocfs2-devel] [RFC] treewide: cleanup unreachable breaks
On Sun, 2020-10-18 at 20:16 +0100, Matthew Wilcox wrote: > On Sun, Oct 18, 2020 at 12:13:35PM -0700, James Bottomley wrote: > > On Sun, 2020-10-18 at 19:59 +0100, Matthew Wilcox wrote: > > > On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote: > > > > clang has a number of useful, new warnings see > > > > https://urldefense.com/v3/__https://clang.llvm.org/docs/DiagnosticsReference.html__;!!GqivPVa7Brio!Krxz78O3RKcB9JBMVo_F98FupVhj_jxX60ddN6tKGEbv_cnooXc1nnBmchm-e_O9ieGnyQ$ > > > > > > > > > > Please get your IT department to remove that stupidity. If you > > > can't, please send email from a non-Red Hat email address. > > > > Actually, the problem is at Oracle's end somewhere in the ocfs2 > > list ... if you could fix it, that would be great. The usual real > > mailing lists didn't get this transformation > > > > https://lore.kernel.org/bpf/20201017160928.12698-1-t...@redhat.com/ > > > > but the ocfs2 list archive did: > > > > https://oss.oracle.com/pipermail/ocfs2-devel/2020-October/015330.html > > > > I bet Oracle IT has put some spam filter on the list that mangles > > URLs this way. > > *sigh*. I'm sure there's a way. I've raised it with someone who > should be able to fix it. As someone who works for IBM I can only say I feel your pain ... James ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH AUTOSEL 5.9 029/111] media: atomisp: fix memleak in ia_css_stream_create
From: Dinghao Liu
[ Upstream commit c1bca5b5ced0cbd779d56f60cdbc9f5e6f6449fe ]
When aspect_ratio_crop_init() fails, curr_stream needs
to be freed just like what we've done in the following
error paths. However, current code is returning directly
and ends up leaking memory.
Signed-off-by: Dinghao Liu
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Sasha Levin
---
drivers/staging/media/atomisp/pci/sh_css.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/atomisp/pci/sh_css.c
b/drivers/staging/media/atomisp/pci/sh_css.c
index a68cbb4995f0f..33a0f8ff82aa8 100644
--- a/drivers/staging/media/atomisp/pci/sh_css.c
+++ b/drivers/staging/media/atomisp/pci/sh_css.c
@@ -9521,7 +9521,7 @@ ia_css_stream_create(const struct ia_css_stream_config
*stream_config,
if (err)
{
IA_CSS_LEAVE_ERR(err);
- return err;
+ goto ERR;
}
#endif
for (i = 0; i < num_pipes; i++)
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH AUTOSEL 5.9 039/111] staging: wfx: fix handling of MMIC error
From: Jérôme Pouiller [ Upstream commit 8d350c14ee5eb62ecd40b0991248bfbce511954d ] As expected, when the device detect a MMIC error, it returns a specific status. However, it also strip IV from the frame (don't ask me why). So, with the current code, mac80211 detects a corrupted frame and it drops it before it handle the MMIC error. The expected behavior would be to detect MMIC error then to renegotiate the EAP session. So, this patch correctly informs mac80211 that IV is not available. So, mac80211 correctly takes into account the MMIC error. Signed-off-by: Jérôme Pouiller Link: https://lore.kernel.org/r/20201007101943.749898-2-jerome.pouil...@silabs.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin --- drivers/staging/wfx/data_rx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/wfx/data_rx.c b/drivers/staging/wfx/data_rx.c index 6fb0788807426..81c37ec0f2834 100644 --- a/drivers/staging/wfx/data_rx.c +++ b/drivers/staging/wfx/data_rx.c @@ -41,7 +41,7 @@ void wfx_rx_cb(struct wfx_vif *wvif, memset(hdr, 0, sizeof(*hdr)); if (arg->status == HIF_STATUS_RX_FAIL_MIC) - hdr->flag |= RX_FLAG_MMIC_ERROR; + hdr->flag |= RX_FLAG_MMIC_ERROR | RX_FLAG_IV_STRIPPED; else if (arg->status) goto drop; -- 2.25.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH AUTOSEL 5.8 037/101] staging: wfx: fix handling of MMIC error
From: Jérôme Pouiller [ Upstream commit 8d350c14ee5eb62ecd40b0991248bfbce511954d ] As expected, when the device detect a MMIC error, it returns a specific status. However, it also strip IV from the frame (don't ask me why). So, with the current code, mac80211 detects a corrupted frame and it drops it before it handle the MMIC error. The expected behavior would be to detect MMIC error then to renegotiate the EAP session. So, this patch correctly informs mac80211 that IV is not available. So, mac80211 correctly takes into account the MMIC error. Signed-off-by: Jérôme Pouiller Link: https://lore.kernel.org/r/20201007101943.749898-2-jerome.pouil...@silabs.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin --- drivers/staging/wfx/data_rx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/wfx/data_rx.c b/drivers/staging/wfx/data_rx.c index 0e959ebc38b56..a9fb5165b33d9 100644 --- a/drivers/staging/wfx/data_rx.c +++ b/drivers/staging/wfx/data_rx.c @@ -80,7 +80,7 @@ void wfx_rx_cb(struct wfx_vif *wvif, goto drop; if (arg->status == HIF_STATUS_RX_FAIL_MIC) - hdr->flag |= RX_FLAG_MMIC_ERROR; + hdr->flag |= RX_FLAG_MMIC_ERROR | RX_FLAG_IV_STRIPPED; else if (arg->status) goto drop; -- 2.25.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH AUTOSEL 5.8 028/101] media: atomisp: fix memleak in ia_css_stream_create
From: Dinghao Liu
[ Upstream commit c1bca5b5ced0cbd779d56f60cdbc9f5e6f6449fe ]
When aspect_ratio_crop_init() fails, curr_stream needs
to be freed just like what we've done in the following
error paths. However, current code is returning directly
and ends up leaking memory.
Signed-off-by: Dinghao Liu
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Sasha Levin
---
drivers/staging/media/atomisp/pci/sh_css.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/atomisp/pci/sh_css.c
b/drivers/staging/media/atomisp/pci/sh_css.c
index 54434c2dbaf90..8473e14370747 100644
--- a/drivers/staging/media/atomisp/pci/sh_css.c
+++ b/drivers/staging/media/atomisp/pci/sh_css.c
@@ -9521,7 +9521,7 @@ ia_css_stream_create(const struct ia_css_stream_config
*stream_config,
if (err)
{
IA_CSS_LEAVE_ERR(err);
- return err;
+ goto ERR;
}
#endif
for (i = 0; i < num_pipes; i++)
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/2] staging: comedi: Simplify conditional evaluation
Boolean comparison of the condition inside unittest function is unnecessary and can be simplified by directly using the condition outcome for evaluation. Issue reported by : scripts/coccinelle/misc/boolinit.cocci Signed-off-by: Deepak R Varma --- drivers/staging/comedi/drivers/tests/ni_routes_test.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/staging/comedi/drivers/tests/ni_routes_test.c b/drivers/staging/comedi/drivers/tests/ni_routes_test.c index eaefaf596a37..7db83cf5e4aa 100644 --- a/drivers/staging/comedi/drivers/tests/ni_routes_test.c +++ b/drivers/staging/comedi/drivers/tests/ni_routes_test.c @@ -499,13 +499,13 @@ void test_route_register_is_valid(void) const struct ni_route_tables *T = &private.routing_tables; init_pci_fake(); - unittest(route_register_is_valid(4, O(4), T) == false, + unittest(!route_register_is_valid(4, O(4), T), "check for bad source 4-->4\n"); - unittest(route_register_is_valid(0, O(1), T) == true, + unittest(!route_register_is_valid(0, O(1), T), "find first source\n"); - unittest(route_register_is_valid(4, O(6), T) == true, + unittest(!route_register_is_valid(4, O(6), T), "find middle source\n"); - unittest(route_register_is_valid(9, O(8), T) == true, + unittest(!route_register_is_valid(9, O(8), T), "find last source"); } -- 2.25.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/2] staging: comedi: combine split lines for improved readability
Instructions split on multiple lines can be combined on a single line for improved readability of the code. Signed-off-by: Deepak R Varma --- .../staging/comedi/drivers/tests/ni_routes_test.c| 12 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/drivers/staging/comedi/drivers/tests/ni_routes_test.c b/drivers/staging/comedi/drivers/tests/ni_routes_test.c index 7db83cf5e4aa..a3b1be623861 100644 --- a/drivers/staging/comedi/drivers/tests/ni_routes_test.c +++ b/drivers/staging/comedi/drivers/tests/ni_routes_test.c @@ -499,14 +499,10 @@ void test_route_register_is_valid(void) const struct ni_route_tables *T = &private.routing_tables; init_pci_fake(); - unittest(!route_register_is_valid(4, O(4), T), -"check for bad source 4-->4\n"); - unittest(!route_register_is_valid(0, O(1), T), -"find first source\n"); - unittest(!route_register_is_valid(4, O(6), T), -"find middle source\n"); - unittest(!route_register_is_valid(9, O(8), T), -"find last source"); + unittest(!route_register_is_valid(4, O(4), T), "check for bad source 4-->4\n"); + unittest(!route_register_is_valid(0, O(1), T), "find first source\n"); + unittest(!route_register_is_valid(4, O(6), T), "find middle source\n"); + unittest(!route_register_is_valid(9, O(8), T), "find last source"); } void test_ni_check_trigger_arg(void) -- 2.25.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: r8188eu: inline rtw_init_netdev_name()
The rtw_init_netdev_name() is a small function
that is used once and does not encapsulate any logic.
Signed-off-by: Ivan Safonov
---
drivers/staging/rtl8188eu/include/osdep_intf.h | 1 -
drivers/staging/rtl8188eu/os_dep/os_intfs.c| 9 -
drivers/staging/rtl8188eu/os_dep/usb_intf.c| 6 +-
3 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/rtl8188eu/include/osdep_intf.h
b/drivers/staging/rtl8188eu/include/osdep_intf.h
index 07c32768f649..5ee4ed995025 100644
--- a/drivers/staging/rtl8188eu/include/osdep_intf.h
+++ b/drivers/staging/rtl8188eu/include/osdep_intf.h
@@ -23,7 +23,6 @@ void rtw_cancel_all_timer(struct adapter *padapter);
int rtw_ioctl(struct net_device *dev, struct ifreq *rq, int cmd);
-int rtw_init_netdev_name(struct net_device *pnetdev, const char *ifname);
struct net_device *rtw_init_netdev(struct adapter *padapter);
u16 rtw_recv_select_queue(struct sk_buff *skb);
diff --git a/drivers/staging/rtl8188eu/os_dep/os_intfs.c
b/drivers/staging/rtl8188eu/os_dep/os_intfs.c
index e291df87f620..c80d30f31869 100644
--- a/drivers/staging/rtl8188eu/os_dep/os_intfs.c
+++ b/drivers/staging/rtl8188eu/os_dep/os_intfs.c
@@ -292,15 +292,6 @@ static const struct net_device_ops rtw_netdev_ops = {
.ndo_do_ioctl = rtw_ioctl,
};
-int rtw_init_netdev_name(struct net_device *pnetdev, const char *ifname)
-{
- if (dev_alloc_name(pnetdev, ifname) < 0)
- RT_TRACE(_module_os_intfs_c_, _drv_err_, ("dev_alloc_name,
fail!\n"));
-
- netif_carrier_off(pnetdev);
- return 0;
-}
-
static const struct device_type wlan_type = {
.name = "wlan",
};
diff --git a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
index 99bfc828672c..43ebd11b53fe 100644
--- a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
+++ b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
@@ -390,7 +390,11 @@ static struct adapter *rtw_usb_if1_init(struct dvobj_priv
*dvobj,
pr_debug("can't get autopm:\n");
/* alloc dev name after read efuse. */
- rtw_init_netdev_name(pnetdev, padapter->registrypriv.ifname);
+ if (dev_alloc_name(pnetdev, padapter->registrypriv.ifname) < 0)
+ RT_TRACE(_module_os_intfs_c_, _drv_err_, ("dev_alloc_name,
fail!\n"));
+
+ netif_carrier_off(pnetdev);
+
rtw_macaddr_cfg(padapter->eeprompriv.mac_addr);
memcpy(pnetdev->dev_addr, padapter->eeprompriv.mac_addr, ETH_ALEN);
pr_debug("MAC Address from pnetdev->dev_addr = %pM\n",
--
2.26.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[staging:staging-testing] BUILD SUCCESS a259a22338ed6906256a51a440d31ea086a0b90b
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git staging-testing branch HEAD: a259a22338ed6906256a51a440d31ea086a0b90b staging: qlge: remove extra blank lines elapsed time: 724m configs tested: 93 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig armzeus_defconfig powerpcmvme5100_defconfig mipsomega2p_defconfig powerpc sequoia_defconfig microblaze mmu_defconfig arcvdk_hs38_defconfig powerpc mpc8313_rdb_defconfig powerpc asp8347_defconfig mipsnlm_xlr_defconfig powerpc skiroot_defconfig powerpc rainier_defconfig powerpc canyonlands_defconfig m68k multi_defconfig mips cu1830-neo_defconfig powerpc mpc8272_ads_defconfig powerpc tqm5200_defconfig powerpc ep8248e_defconfig pariscgeneric-32bit_defconfig mips mpc30x_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a006-20201018 i386 randconfig-a005-20201018 i386 randconfig-a001-20201018 i386 randconfig-a003-20201018 i386 randconfig-a004-20201018 i386 randconfig-a002-20201018 x86_64 randconfig-a016-20201018 x86_64 randconfig-a015-20201018 x86_64 randconfig-a012-20201018 x86_64 randconfig-a013-20201018 x86_64 randconfig-a011-20201018 x86_64 randconfig-a014-20201018 i386 randconfig-a015-20201018 i386 randconfig-a013-20201018 i386 randconfig-a016-20201018 i386 randconfig-a012-20201018 i386 randconfig-a011-20201018 i386 randconfig-a014-20201018 riscvnommu_k210_defconfig riscvallyesconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec clang tested configs: x86_64 randconfig-a004-20201018 x86_64 randconfig-a002-20201018 x86_64 randconfig-a006-20201018 x86_64 randconfig-a003-20201018 x86_64 randconfig-a005-20201018 x86_64 randconfig-a001-20201018 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] arch: um: convert tasklets to use new tasklet_setup() API
On Mon, Aug 17, 2020 at 11:17 AM Allen Pais wrote: > > From: Allen Pais > > In preparation for unconditionally passing the > struct tasklet_struct pointer to all tasklet > callbacks, switch to using the new tasklet_setup() > and from_tasklet() to pass the tasklet pointer explicitly. > > Signed-off-by: Romain Perier > Signed-off-by: Allen Pais > --- > arch/um/drivers/vector_kern.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Anton, can you please review this patch? -- Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/7] staging: qlge: replace ql_* with qlge_* to avoid namespace clashes with other qlogic drivers
On Sun, Oct 18, 2020 at 08:02:53PM +0900, Benjamin Poirier wrote: On 2020-10-17 07:16 +0800, Coiby Xu wrote: On Thu, Oct 15, 2020 at 10:01:36AM +0900, Benjamin Poirier wrote: > On 2020-10-14 18:43 +0800, Coiby Xu wrote: > > To avoid namespace clashes with other qlogic drivers and also for the > > sake of naming consistency, use the "qlge_" prefix as suggested in > > drivers/staging/qlge/TODO. > > > > Suggested-by: Benjamin Poirier > > Signed-off-by: Coiby Xu > > --- > > drivers/staging/qlge/TODO |4 - > > drivers/staging/qlge/qlge.h | 190 ++-- > > drivers/staging/qlge/qlge_dbg.c | 1073 --- > > drivers/staging/qlge/qlge_ethtool.c | 231 ++--- > > drivers/staging/qlge/qlge_main.c| 1257 +-- > > drivers/staging/qlge/qlge_mpi.c | 352 > > 6 files changed, 1551 insertions(+), 1556 deletions(-) > > > > diff --git a/drivers/staging/qlge/TODO b/drivers/staging/qlge/TODO > > index f93f7428f5d5..5ac55664c3e2 100644 > > --- a/drivers/staging/qlge/TODO > > +++ b/drivers/staging/qlge/TODO > > @@ -28,10 +28,6 @@ > > * the driver has a habit of using runtime checks where compile time checks are > >possible (ex. ql_free_rx_buffers(), ql_alloc_rx_buffers()) > > * reorder struct members to avoid holes if it doesn't impact performance > > -* in terms of namespace, the driver uses either qlge_, ql_ (used by > > - other qlogic drivers, with clashes, ex: ql_sem_spinlock) or nothing (with > > - clashes, ex: struct ob_mac_iocb_req). Rename everything to use the "qlge_" > > - prefix. > > You only renamed ql -> qlge. The prefix needs to be added where there is > currently none like the second example of that text. On second thoughts, these structs like ob_mac_iocb_req are defined in local headers and there is no mixed usage. So even when we want to build this diver and other qlogic drivers into the kernel instead of as separate modules, it won't lead to real problems, is it right? Using cscope or ctags and searching for ob_mac_iocb_req will yield ambiguous results. It might also make things more difficult if using a debugger. Even if I have been using gtags, I didn't realize it. Thank you for explaining it to me. Looking at other drivers (ex. ice, mlx5), they use a prefix for their private types, just like for their static functions, even though it's not absolutely necessary. I think it's helpful when reading the code because it quickly shows that it is something that was defined in the driver, not in some subsystem. Good point! I didn't think about it earlier but it would have been better to leave out this renaming to a subsequent patchset, since this change is unrelated to the debugging features. It seems it's more reasonable to do renaming first. So in a sense, the renaming is a preparatory step for the debugging features. -- Best regards, Coiby ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
