On Mon, Apr 15, 2019 at 05:03:33PM +0200, Johan Hovold wrote:
> But then all eight or so instances should be replaced in one go, to
> maintain consistency.
Yeah, that's fair enough, I suppose.
regards,
dan carepenter
___
devel mailing list
On Mon, Apr 15, 2019 at 05:40:16PM +0300, Dan Carpenter wrote:
> What I'm saying is that if we just apply it then we avoid the long
> discussion forever. The macro is OK, sure, but it's not like anyone is
> going to come back later and argue that macros are better or preferred.
That may be a
What I'm saying is that if we just apply it then we avoid the long
discussion forever. The macro is OK, sure, but it's not like anyone is
going to come back later and argue that macros are better or preferred.
regards,
dan carpenter
___
devel mailing
On Mon, Apr 15, 2019 at 04:33:57PM +0300, Dan Carpenter wrote:
> On Mon, Apr 15, 2019 at 03:10:02PM +0200, Johan Hovold wrote:
> > On Fri, Apr 05, 2019 at 03:14:37PM -0500, Madhumitha Prabakaran wrote:
> > > Fix a blank line after function/struct/union/enum
> > > declarations. Also, convert
On Mon, Apr 15, 2019 at 03:10:02PM +0200, Johan Hovold wrote:
> On Fri, Apr 05, 2019 at 03:14:37PM -0500, Madhumitha Prabakaran wrote:
> > Fix a blank line after function/struct/union/enum
> > declarations. Also, convert to_gb_control() macro into an inline
> > function in order to maintain Linux
On Fri, Apr 05, 2019 at 03:14:37PM -0500, Madhumitha Prabakaran wrote:
> Fix a blank line after function/struct/union/enum
> declarations. Also, convert to_gb_control() macro into an inline
> function in order to maintain Linux kernel coding style based
> on which the inline function is
Fix a blank line after function/struct/union/enum
declarations. Also, convert to_gb_control() macro into an inline
function in order to maintain Linux kernel coding style based
on which the inline function is preferable over the macro.
Signed-off-by: Madhumitha Prabakaran
---
