Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-25 Thread Miguel Ojeda
On Wed, Nov 25, 2020 at 5:24 PM Jakub Kicinski wrote: > > 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

Re: [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-24 Thread Miguel Ojeda
On Mon, Nov 23, 2020 at 9:38 PM James Bottomley wrote: > > So you think a one line patch should take one minute to produce ... I > really don't think that's grounded in reality. No, I have not said that. Please don't put words in my mouth (again). I have said *authoring* lines of *this* kind

Re: [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-23 Thread Miguel Ojeda
On Mon, Nov 23, 2020 at 4:58 PM James Bottomley wrote: > > Well, I used git. It says that as of today in Linus' tree we have 889 > patches related to fall throughs and the first series went in in > october 2017 ... ignoring a couple of outliers back to February. I can see ~10k insertions over

Re: [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-23 Thread Miguel Ojeda
On Sun, Nov 22, 2020 at 11:36 PM James Bottomley wrote: > > Well, it seems to be three years of someone's time plus the maintainer > review time and series disruption of nearly a thousand patches. Let's > be conservative and assume the producer worked about 30% on the series > and it takes about

Re: [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-22 Thread Miguel Ojeda
On Sun, Nov 22, 2020 at 7:22 PM James Bottomley wrote: > > Well, it's a problem in an error leg, sure, but it's not a really > compelling reason for a 141 patch series, is it? All that fixing this > error will do is get the driver to print "oh dear there's a problem" > under four more conditions

Re: [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-20 Thread Miguel Ojeda
Hi Gustavo, On Fri, Nov 20, 2020 at 7:21 PM Gustavo A. R. Silva wrote: > > Hi all, > > This series aims to fix almost all remaining fall-through warnings in > order to enable -Wimplicit-fallthrough for Clang. Thanks for this. Since this warning is reliable in both/all compilers and we are

Re: [PATCH 3/5] Drivers: hv: kvp: Fix the recent regression caused by incorrect clean-up

2018-10-20 Thread Miguel Ojeda
Hi Dan, On Sat, Oct 20, 2018 at 9:22 PM Dan Carpenter wrote: > > On Sat, Oct 20, 2018 at 04:42:07PM +0200, Miguel Ojeda wrote: > > Using an attribute is indeed better whenever possible. In C++17 it is > > an standard attribute and there have been proposals to include some

Re: [PATCH 3/5] Drivers: hv: kvp: Fix the recent regression caused by incorrect clean-up

2018-10-20 Thread Miguel Ojeda
+On Wed, Oct 17, 2018 at 8:25 AM Dan Carpenter wrote: > > It's not common at all. It should be wrapped in a macro and put into > compiler.h. > > But I hope it does become adopted. It's better than randomly grepping > for non-standard comments. Using an attribute is indeed better whenever

Re: [PATCH v5 1/4] gpiolib: Pass bitmaps, not integer arrays, to get/set array

2018-08-30 Thread Miguel Ojeda
spective GPIO > chip callbacks if applicable is implemented. > > Cc: Jonathan Corbet > Cc: Miguel Ojeda Sandonis > Cc: Peter Korsgaard > Cc: Peter Rosin > Cc: Andrew Lunn > Cc: Florian Fainelli > Cc: "David S. Miller" > Cc: Dominik Brodowski > Cc: Kishon

Re: [RFC RFT PATCH v4 1/4] gpiolib: Pass bitmaps, not integer arrays, to get/set array

2018-08-29 Thread Miguel Ojeda
Hi Janusz, On Tue, Aug 21, 2018 at 1:43 AM, Janusz Krzysztofik wrote: > Most users of get/set array functions iterate consecutive bits of data, > usually a single integer, while or processing array of results obtained > from or building an array of values to be passed to those functions. > Save