[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160229204136.GA23568@eudyptula.hq.kempniu.pl>
Date: Mon, 29 Feb 2016 21:41:36 +0100
From: Michał Kępień <kernel@...pniu.pl>
To: Pali Rohár <pali.rohar@...il.com>
Cc: Darren Hart <dvhart@...radead.org>,
Matthew Garrett <mjg59@...f.ucam.org>,
Darek Stojaczyk <darek.stojaczyk@...il.com>,
platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 1/5] dell-laptop: move dell_smi_error() to dell-smbios
> On Monday 29 February 2016 21:22:54 Michał Kępień wrote:
> > > On Wednesday 24 February 2016 08:20:11 Michał Kępień wrote:
> > > > The dell_smi_error() method could be used by modules other than
> > > > dell-laptop for convenient translation of SMBIOS request errors
> > > > into errno values. Thus, move it to dell-smbios.
> > > >
> > > > Signed-off-by: Michał Kępień <kernel@...pniu.pl>
> > > > ---
> > > >
> > > > drivers/platform/x86/dell-laptop.c | 14 --------------
> > > > drivers/platform/x86/dell-smbios.c | 16 ++++++++++++++++
> > > > drivers/platform/x86/dell-smbios.h | 2 ++
> > > > 3 files changed, 18 insertions(+), 14 deletions(-)
> > > >
> > > > diff --git a/drivers/platform/x86/dell-laptop.c
> > > > b/drivers/platform/x86/dell-laptop.c index 76064c8..cbafb95
> > > > 100644
> > > > --- a/drivers/platform/x86/dell-laptop.c
> > > > +++ b/drivers/platform/x86/dell-laptop.c
> > > > @@ -273,20 +273,6 @@ static const struct dmi_system_id
> > > > dell_quirks[] __initconst = {
> > > >
> > > > { }
> > > >
> > > > };
> > > >
> > > > -static inline int dell_smi_error(int value)
> > > > -{
> > > > - switch (value) {
> > > > - case 0: /* Completed successfully */
> > > > - return 0;
> > > > - case -1: /* Completed with error */
> > > > - return -EIO;
> > > > - case -2: /* Function not supported */
> > > > - return -ENXIO;
> > > > - default: /* Unknown error */
> > > > - return -EINVAL;
> > > > - }
> > > > -}
> > > > -
> > > >
> > > > /*
> > > >
> > > > * Derived from information in smbios-wireless-ctl:
> > > > *
> > > >
> > > > diff --git a/drivers/platform/x86/dell-smbios.c
> > > > b/drivers/platform/x86/dell-smbios.c index 2a4992a..942572f
> > > > 100644
> > > > --- a/drivers/platform/x86/dell-smbios.c
> > > > +++ b/drivers/platform/x86/dell-smbios.c
> > > > @@ -16,6 +16,7 @@
> > > >
> > > > #include <linux/kernel.h>
> > > > #include <linux/module.h>
> > > > #include <linux/dmi.h>
> > > >
> > > > +#include <linux/err.h>
> > > >
> > > > #include <linux/gfp.h>
> > > > #include <linux/mutex.h>
> > > > #include <linux/slab.h>
> > > >
> > > > @@ -39,6 +40,21 @@ static int da_command_code;
> > > >
> > > > static int da_num_tokens;
> > > > static struct calling_interface_token *da_tokens;
> > > >
> > > > +int dell_smi_error(int value)
> > > > +{
> > > > + switch (value) {
> > > > + case 0: /* Completed successfully */
> > > > + return 0;
> > > > + case -1: /* Completed with error */
> > > > + return -EIO;
> > > > + case -2: /* Function not supported */
> > > > + return -ENXIO;
> > > > + default: /* Unknown error */
> > > > + return -EINVAL;
> > > > + }
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(dell_smi_error);
> > > > +
> > > >
> > > > struct calling_interface_buffer *dell_smbios_get_buffer(void)
> > > > {
> > > >
> > > > mutex_lock(&buffer_mutex);
> > > >
> > > > diff --git a/drivers/platform/x86/dell-smbios.h
> > > > b/drivers/platform/x86/dell-smbios.h index 4f69b16..52febe6
> > > > 100644
> > > > --- a/drivers/platform/x86/dell-smbios.h
> > > > +++ b/drivers/platform/x86/dell-smbios.h
> > > > @@ -35,6 +35,8 @@ struct calling_interface_token {
> > > >
> > > > };
> > > >
> > > > };
> > > >
> > > > +int dell_smi_error(int value);
> > > > +
> > > >
> > > > struct calling_interface_buffer *dell_smbios_get_buffer(void);
> > > > void dell_smbios_clear_buffer(void);
> > > > void dell_smbios_release_buffer(void);
> > >
> > > And... here what about inline vs EXPORT_SYMBOL function? Just
> > > asking...
> >
> > Well, what about it? :) The commit message is pretty explicit in
> > describing what happens here, i.e. a previously static function is
> > moved to another module so that it can be reused. Thus, keeping the
> > inline keyword makes no sense. What exactly is your concern?
>
> Just asking if this function should be or not be inline (of course in
> header file, not in module .c).
If you mark a function as inline in the header file, you have to provide
its definition, otherwise you'll get a compilation error. Given that
this is in no way performance-critical code, I see no point in
clobbering the header file with the body of this function.
--
Best regards,
Michał Kępień
Powered by blists - more mailing lists