On 04/17 :25, Greg KH wrote: > On Tue, Apr 16, 2019 at 05:13:18PM -0500, Madhumitha Prabakaran wrote: > > Fix a blank line after structure declarations. Also, convert > > macros into inline functions in order to maintain Linux kernel > > coding style based on which the inline function is > > preferable over the macro. > > > > Blank line fixes are suggested by checkpatch.pl > > > > Signed-off-by: Madhumitha Prabakaran <madhumithabiw@xxxxxxxxx> > > > > Changes in v2: > > - To maintain consistency in driver greybus, all the instances of macro > > with container_of are fixed in a single patch. > > --- > > drivers/staging/greybus/bundle.h | 6 +++++- > > drivers/staging/greybus/control.h | 6 +++++- > > drivers/staging/greybus/gbphy.h | 12 ++++++++++-- > > drivers/staging/greybus/greybus.h | 6 +++++- > > drivers/staging/greybus/hd.h | 6 +++++- > > drivers/staging/greybus/interface.h | 6 +++++- > > drivers/staging/greybus/module.h | 6 +++++- > > drivers/staging/greybus/svc.h | 6 +++++- > > 8 files changed, 45 insertions(+), 9 deletions(-) > > > > diff --git a/drivers/staging/greybus/bundle.h b/drivers/staging/greybus/bundle.h > > index 8734d2055657..84956eedb1c4 100644 > > --- a/drivers/staging/greybus/bundle.h > > +++ b/drivers/staging/greybus/bundle.h > > @@ -31,7 +31,11 @@ struct gb_bundle { > > > > struct list_head links; /* interface->bundles */ > > }; > > -#define to_gb_bundle(d) container_of(d, struct gb_bundle, dev) > > + > > +static inline struct gb_bundle *to_gb_bundle(struct device *d) > > +{ > > + return container_of(d, struct gb_bundle, dev); > > +} > > Why are we changing this to an inline function? The #define is fine, > and how we "normally" do this type of container_of conversion. > > I understand the objection of the "no blank line", but this was the > "original" style that we used to create these #defines from the very > beginning of the driver model work a decade ago. Changing that > muscle-memory is going to be hard for some of us. Look at > drivers/base/base.h for other examples of this. Thanks for explaining it. > > thanks, > > greg k-h _______________________________________________ greybus-dev mailing list greybus-dev@xxxxxxxxxxxxxxxx https://lists.linaro.org/mailman/listinfo/greybus-dev