Re: [PATCH v7 13/24] wfx: add hif_tx*.c/hif_tx*.h
On Tue, 05 Oct 2021 09:12:27 +0300 Kalle Valo wrote:
> >> I didn't know it was mandatory to prefix all the functions with the
> >> same prefix.
>
> I don't know either if this is mandatory or not, for example I do not
> have any recollection what Linus and other maintainers think of this. I
> just personally think it's good practise to use driver prefix ("wfx_")
> in all non-static functions.
I'd even say all functions. The prefixes are usually 3 chars, it's no
hassle to add and makes reading the code and looking at stack traces
much more intuitive for people who are not intimately familiar with
the code.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC] wimax: move out to staging
On Wed, 28 Oct 2020 06:56:28 +0100 Greg Kroah-Hartman wrote:
> On Tue, Oct 27, 2020 at 10:20:13PM +0100, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > There are no known users of this driver as of October 2020, and it will
> > be removed unless someone turns out to still need it in future releases.
> >
> > According to https://en.wikipedia.org/wiki/List_of_WiMAX_networks, there
> > have been many public wimax networks, but it appears that these entries
> > are all stale, after everyone has migrated to LTE or discontinued their
> > service altogether.
> >
> > NetworkManager appears to have dropped userspace support in 2015
> > https://bugzilla.gnome.org/show_bug.cgi?id=747846, the
> > www.linuxwimax.org
> > site had already shut down earlier.
> >
> > WiMax is apparently still being deployed on airport campus networks
> > ("AeroMACS"), but in a frequency band that was not supported by the old
> > Intel 2400m (used in Sandy Bridge laptops and earlier), which is the
> > only driver using the kernel's wimax stack.
> >
> > Move all files into drivers/staging/wimax, including the uapi header
> > files and documentation, to make it easier to remove it when it gets
> > to that. Only minimal changes are made to the source files, in order
> > to make it possible to port patches across the move.
> >
> > Also remove the MAINTAINERS entry that refers to a broken mailing
> > list and website.
> >
> > Suggested-by: Inaky Perez-Gonzalez
> > Signed-off-by: Arnd Bergmann
>
> Is this ok for me to take through the staging tree? If so, I need an
> ack from the networking maintainers.
>
> If not, feel free to send it through the networking tree and add:
>
> Acked-by: Greg Kroah-Hartman
Thinking about it now - we want this applied to -next, correct?
In that case it may be better if we take it. The code is pretty dead
but syzbot and the trivial fix crowd don't know it, so I may slip,
apply something and we'll have a conflict.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC] wimax: move out to staging
On Thu, 29 Oct 2020 17:26:09 +0100 Arnd Bergmann wrote: > n Thu, Oct 29, 2020 at 4:56 PM Jakub Kicinski wrote: > > On Wed, 28 Oct 2020 06:56:28 +0100 Greg Kroah-Hartman wrote: > > > On Tue, Oct 27, 2020 at 10:20:13PM +0100, Arnd Bergmann wrote: > > > > > > Is this ok for me to take through the staging tree? If so, I need an > > > ack from the networking maintainers. > > > > > > If not, feel free to send it through the networking tree and add: > > > > > > Acked-by: Greg Kroah-Hartman > > > > Thinking about it now - we want this applied to -next, correct? > > In that case it may be better if we take it. The code is pretty dead > > but syzbot and the trivial fix crowd don't know it, so I may slip, > > apply something and we'll have a conflict. > > I think git will deal with a merge between branches containing > the move vs fix, so it should work either way. > > A downside of having the move in net-next would be that > you'd get trivial fixes send to Greg, but him being unable to > apply them to his tree because the code is elsewhere. > > If you think it helps, I could prepare a pull request with this one > patch (and probably the bugfix I sent first that triggered it), and > then you can both merge the branch into net-next as well > as staging-next. If you wouldn't mind branch sounds like the best solution. Acked-by: Jakub Kicinski ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [GIT PULL, staging, net-next] wimax: move to staging
On Fri, 30 Oct 2020 13:22:31 +0100 gregkh wrote: > On Thu, Oct 29, 2020 at 10:06:14PM +0100, Arnd Bergmann wrote: > > The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec: > > > > Linux 5.10-rc1 (2020-10-25 15:14:11 -0700) > > > > are available in the Git repository at: > > > > git://git.kernel.org:/pub/scm/linux/kernel/git/arnd/playground.git > > tags/wimax-staging > > Line wrapping makes this hard :( > > Anyway, pulled into the staging-next branch now, so it's fine if this > also gets pulled into the networking branch/tree as well, and then all > should be fine. ..and pulled into net-next, thanks! ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 000/141] Fix fall-through warnings for Clang
On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote: > This series aims to fix almost all remaining fall-through warnings in > order to enable -Wimplicit-fallthrough for Clang. > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly > add multiple break/goto/return/fallthrough statements instead of just > letting the code fall through to the next case. > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this > change[1] is meant to be reverted at some point. So, this patch helps > to move in that direction. > > Something important to mention is that there is currently a discrepancy > between GCC and Clang when dealing with switch fall-through to empty case > statements or to cases that only contain a break/continue/return > statement[2][3][4]. Are we sure we want to make this change? Was it discussed before? Are there any bugs Clangs puritanical definition of fallthrough helped find? IMVHO compiler warnings are supposed to warn about issues that could be bugs. Falling through to default: break; can hardly be a bug?! ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 000/141] Fix fall-through warnings for Clang
On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote: > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote: > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote: > > > This series aims to fix almost all remaining fall-through warnings in > > > order to enable -Wimplicit-fallthrough for Clang. > > > > > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly > > > add multiple break/goto/return/fallthrough statements instead of just > > > letting the code fall through to the next case. > > > > > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this > > > change[1] is meant to be reverted at some point. So, this patch helps > > > to move in that direction. > > > > > > Something important to mention is that there is currently a discrepancy > > > between GCC and Clang when dealing with switch fall-through to empty case > > > statements or to cases that only contain a break/continue/return > > > statement[2][3][4]. > > > > Are we sure we want to make this change? Was it discussed before? > > > > Are there any bugs Clangs puritanical definition of fallthrough helped > > find? > > > > IMVHO compiler warnings are supposed to warn about issues that could > > be bugs. Falling through to default: break; can hardly be a bug?! > > It's certainly a place where the intent is not always clear. I think > this makes all the cases unambiguous, and doesn't impact the machine > code, since the compiler will happily optimize away any behavioral > redundancy. If none of the 140 patches here fix a real bug, and there is no change to machine code then it sounds to me like a W=2 kind of a warning. I think clang is just being annoying here, but if I'm the only one who feels this way chances are I'm wrong :) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 000/141] Fix fall-through warnings for Clang
On Mon, 23 Nov 2020 17:32:51 -0800 Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it sounds to me like a W=2 kind of a warning.
> >
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=kr...@mail.gmail.com/
> >
>
> So looks like the bulk of these are:
> switch (x) {
> case 0:
> ++x;
> default:
> break;
> }
>
> I have a patch that fixes those up for clang:
> https://reviews.llvm.org/D91895
😍
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
On Wed, 25 Nov 2020 04:24:27 -0800 Nick Desaulniers wrote: > I even agree that most of the churn comes from > > case 0: > ++x; > default: > break; And just to spell it out, case ENUM_VALUE1: bla(); break; case ENUM_VALUE2: bla(); default: break; is a fairly idiomatic way of indicating that not all values of the enum are expected to be handled by the switch statement. I really hope the Clang folks are reasonable and merge your patch. > If trivial patches are adding too much to your workload, consider > training a co-maintainer or asking for help from one of your reviewers > whom you trust. I don't doubt it's hard to find maintainers, but > existing maintainers should go out of their way to entrust > co-maintainers especially when they find their workload becomes too > high. And reviewing/picking up trivial patches is probably a great > way to get started. If we allow too much knowledge of any one > subsystem to collect with one maintainer, what happens when that > maintainer leaves the community (which, given a finite lifespan, is an > inevitability)? The burn out point is about enjoying your work and feeling that it matters. It really doesn't make much difference if you're doing something you don't like for 12 hours every day or only in shifts with another maintainer. You'll dislike it either way. Applying a real patch set and then getting a few follow ups the next day for trivial coding things like fallthrough missing or static missing, just because I didn't have the full range of compilers to check with before applying makes me feel pretty shitty, like I'm not doing a good job. YMMV. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC net-next 11/13] nfp: Handle SWITCHDEV_PORT_ATTR_GET event
On Fri, 1 Feb 2019 14:06:55 -0800, Florian Fainelli wrote: > Following patches will change the way we communicate getting or setting > a port's attribute and use a blocking notifier to perform those tasks. > > Prepare nfp to support receiving notifier events targeting > SWITCHDEV_PORT_ATTR_GET and simply translate that into the existing > switchdev_ops::switchdev_port_attr_get operation. > > We register a single blocking switchdev notifier for the entire driver > instance and we differentiate a "net" from a "repr" by comparing the > network device's netdev_ops with the ones that this driver manages. > > Signed-off-by: Florian Fainelli Thanks Florian, the code looks good, only nit I have is - could you move nfp_switchdev_blocking_event() to nfp_port.c and nfp_port.h? We shouldn't touch nfp_net_common.c here. In general calling a notifier to get the parent_id (which is the only thing all these SR-IOV NIC drivers implement) seems a tad heavy. It's an immutable, read-only attribute of a port, perhaps we can break it out? Could we make it an NDO, perhaps? That's just my knee jerk reaction, given that NIC drivers don't implement any of the bridging side of switchdev I may not have a full appreciation of the abstraction you are building here :) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 07/12] nfp: Implement ndo_get_port_parent_id()
On Mon, 4 Feb 2019 15:36:28 -0800, Florian Fainelli wrote: > NFP only supports SWITCHDEV_ATTR_ID_PORT_PARENT_ID, which makes it a > great candidate to be converted to use the ndo_get_port_parent_id() NDO > instead of implementing switchdev_port_attr_get(). > > Signed-off-by: Florian Fainelli Acked-by: Jakub Kicinski Very nice!! Hopefully nobody hates this approach :) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 09/12] netdevsim: Implement ndo_get_port_parent_id()
On Mon, 4 Feb 2019 15:36:30 -0800, Florian Fainelli wrote: > netdevsim only supports SWITCHDEV_ATTR_ID_PORT_PARENT_ID, which makes it a > great candidate to be converted to use the ndo_get_port_parent_id() NDO > instead of implementing switchdev_port_attr_get(). > > Signed-off-by: Florian Fainelli Acked-by: Jakub Kicinski ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net 8/9] hv_netvsc: propagate rx filters to VF
On Thu, 1 Mar 2018 10:27:55 -0800, Stephen Hemminger wrote: > The netvsc device should propagate filters to the SR-IOV VF > device (if present). The flags also need to be propagated to the > VF device as well. This only really matters on local Hyper-V > since Azure does not support multiple addresses. > > The rx filter management in netvsc device does not need to be done > in a work queue since it is called with RTNL held. > > Signed-off-by: Stephen Hemminger Do you also propagate them when VF gets unplugged and plugged back in? ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH PATCH net v2 0/9] hv_netvsc: minor fixes
On Fri, 2 Mar 2018 13:49:00 -0800, Stephen Hemminger wrote: >- change propogate rx mode patch to handle startup of vf Thanks! :) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v10 0/1] wfx: get out from the staging area
On Mon, 04 Apr 2022 13:49:18 +0300 Kalle Valo wrote: > Dave&Jakub, once you guys open net-next will it be based on -rc1? Not normally. We usually let net feed net-next so it'd get -rc1 this Thursday. But we should be able to fast-forward, let me confirm with Dave. > That would make it easier for me to create an immutable branch between > staging-next and wireless-next. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v10 0/1] wfx: get out from the staging area
On Mon, 4 Apr 2022 23:22:47 -0700 Jakub Kicinski wrote: > On Mon, 04 Apr 2022 13:49:18 +0300 Kalle Valo wrote: > > Dave&Jakub, once you guys open net-next will it be based on -rc1? > > Not normally. We usually let net feed net-next so it'd get -rc1 this > Thursday. But we should be able to fast-forward, let me confirm with > Dave. Wait, why is -rc1 magic? If you based the branch on whatever the merge-base of net-next and staging-next is, would that be an aberration? ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v10 0/1] wfx: get out from the staging area
On Tue, 05 Apr 2022 10:16:58 +0300 Kalle Valo wrote: > Sure, that would technically work. But I just think it's cleaner to use > -rc1 (or later) as the baseline for an immutable branch. If the baseline > is an arbitrary commit somewhere within merge windows commits, it's more > work for everyone to verify the branch is suitable. > > Also in general I would also prefer to base -next trees to -rc1 or newer > to make the bisect cleaner. The less we need to test kernels from the > merge window (ie. commits after the final release and before -rc1) the > better. > > But this is just a small wish from me, I fully understand that it might > be too much changes to your process. Wanted to point out this anyway. Forwarded! ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
