similar to: [PATCH 00/18] use ARRAY_SIZE macro

Using the ARRAY_SIZE macro improves the readability of the code. Also, it is not always useful to use a variable to store this constant calculated at compile time nor to re-invent the ARRAY_SIZE macro. Found with Coccinelle with the following semantic patch: @r depends on (org || report)@ type T; T[] E; position p; @@ ( (sizeof(E)@p /sizeof(*E)) | (sizeof(E)@p /sizeof(E[...])) | (sizeof(E)@p

From: Ville Syrjälä <ville.syrjala at linux.intel.com> drm_property_add_enum() can calculate the index itself just fine, so no point in having the caller pass it in. Cc: Patrik Jakobsson <patrik.r.jakobsson at gmail.com> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: nouveau at lists.freedesktop.org Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com> ---

Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy at intel.com> Best Regards, Lisovskiy Stanislav Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo ________________________________________ From: Intel-gfx [intel-gfx-bounces at lists.freedesktop.org] on behalf of Lisovskiy, Stanislav [stanislav.lisovskiy at intel.com] Sent: Monday, April 23, 2018 4:59 PM

On Sun, Oct 01, 2017 at 03:30:38PM -0400, Jérémy Lefaure wrote: > Hi everyone, > Using ARRAY_SIZE improves the code readability. I used coccinelle (I > made a change to the array_size.cocci file [1]) to find several places > where ARRAY_SIZE could be used instead of other macros or sizeof > division. > > I tried to divide the changes into a patch per subsystem (excepted for

On Sun, Oct 01, 2017 at 08:52:20PM -0400, Jérémy Lefaure wrote: > On Mon, 2 Oct 2017 09:01:31 +1100 > "Tobin C. Harding" <me at tobin.cc> wrote: > > > > In order to reduce the size of the To: and Cc: lines, each patch of the > > > series is sent only to the maintainers and lists concerned by the patch. > > > This cover letter is sent to every

On Mon, 2 Oct 2017 15:22:24 -0400 bfields at fieldses.org (J. Bruce Fields) wrote: > Mainly I'd just like to know which you're asking for. Do you want me to > apply this, or to ACK it so someone else can? If it's sent as a series > I tend to assume the latter. > > But in this case I'm assuming it's the former, so I'll pick up the nfsd > one.... Could

Acked-by: Stanislav Lisovskiy <stanislav.lisovskiy at intel.com> Best Regards, Lisovskiy Stanislav Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo> ________________________________________ From: Ville Syrjala [ville.syrjala at linux.intel.com] Sent: Friday, March 16, 2018 9:04 PM To: dri-devel at lists.freedesktop.org Cc: intel-gfx at

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Warning level 3 was used: -Wimplicit-fallthrough=3 Notice that, in some cases, the code comment is modified in accordance with what GCC is expecting to find. This patch is part of the ongoing efforts to enable -Wimplicit-fallthrough. Signed-off-by: Gustavo A. R. Silva <gustavo at

Using the ARRAY_SIZE macro improves the readability of the code. Also, it is useless to re-invent it. Found with Coccinelle with the following semantic patch: @r depends on (org || report)@ type T; T[] E; position p; @@ ( (sizeof(E)@p /sizeof(*E)) | (sizeof(E)@p /sizeof(E[...])) | (sizeof(E)@p /sizeof(T)) ) Reviewed-by: Thierry Reding <treding at nvidia.com> Signed-off-by: Jérémy

On Wed, Oct 10, 2018 at 01:54:33PM -0500, Segher Boessenkool wrote: > It would be great to hear from kernel people if it works adequately for > what you guys want it for :-) Sure, ping me when you have the final version and I'll try to build gcc with it and do some size comparisons. Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the

On Wed, Oct 10, 2018 at 01:54:33PM -0500, Segher Boessenkool wrote: > It would be great to hear from kernel people if it works adequately for > what you guys want it for :-) Sure, ping me when you have the final version and I'll try to build gcc with it and do some size comparisons. Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the

Is there a rake task for removing node parameters from the dashboard? The online dashboard manual is silent on the parameters related to rake tasks altogether. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.

On Mon, Oct 02, 2017 at 07:35:54AM +0200, Greg KH wrote: > On Sun, Oct 01, 2017 at 08:52:20PM -0400, Jérémy Lefaure wrote: > > On Mon, 2 Oct 2017 09:01:31 +1100 > > "Tobin C. Harding" <me at tobin.cc> wrote: > > > > > > In order to reduce the size of the To: and Cc: lines, each patch of the > > > > series is sent only to the maintainers

On Mon, Oct 02, 2017 at 09:33:12PM -0400, Jérémy Lefaure wrote: > On Mon, 2 Oct 2017 15:22:24 -0400 > bfields at fieldses.org (J. Bruce Fields) wrote: > > > Mainly I'd just like to know which you're asking for. Do you want me to > > apply this, or to ACK it so someone else can? If it's sent as a series > > I tend to assume the latter. > > > >

On Thu, 2018-06-07 at 10:26 -0700, Nick Desaulniers wrote: > I get the feeling that the use of __inline__ or __inline (vs inline) > in the kernel may be wrong and their use should be eradicated in the > follow up patch set, but it would be cool if others have additional > insight. __inline is easy and useful to remove as it's used in just a few files. But __inline__ is used in a

Hi Peter, On Wed, Oct 31, 2018 at 9:58 PM Peter Zijlstra <peterz at infradead.org> wrote: > > On Sat, Oct 13, 2018 at 09:33:35PM +0200, Borislav Petkov wrote: > > Ok, > > > > with Segher's help I've been playing with his patch ontop of bleeding > > edge gcc 9 and here are my observations. Please double-check me for > > booboos so that they can be

Hello, after the reply of Jerome Alet, I forward our questions to you. I hope it is now the right place to put it. Could you please send your answers, questions, comments to interopcast-general@nongnu.org so everyone in the group can get a copy of it. Thank you. ----- Original Message ----- From: "Jerome Alet" <alet@librelogiciel.com> To: <interopcast-general@nongnu.org>

Hi all, this series improves the use_mm / unuse_mm interface by better documenting the assumptions, and my taking the set_fs manipulations spread over the callers into the core API.

Hi all, this series improves the use_mm / unuse_mm interface by better documenting the assumptions, and my taking the set_fs manipulations spread over the callers into the core API.

Hi all, this series improves the use_mm / unuse_mm interface by better documenting the assumptions, and my taking the set_fs manipulations spread over the callers into the core API. Changes since v1: - drop a few patches - fix a comment typo - cover the newly merged use_mm/unuse_mm caller in vfio