All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mattias Jacobsson <2pi@mok.nu>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: "Masahiro Yamada" <yamada.masahiro@socionext.com>,
	michal.lkml@markovi.net, "Darren Hart" <dvhart@infradead.org>,
	"Andy Shevchenko" <andy@infradead.org>,
	"Pali Rohár" <pali.rohar@gmail.com>,
	"Platform Driver" <platform-driver-x86@vger.kernel.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	2pi@mok.nu
Subject: Re: [PATCH v3 2/3] platform/x86: wmi: add WMI support to MODULE_DEVICE_TABLE()
Date: Sun, 3 Feb 2019 20:04:23 +0100	[thread overview]
Message-ID: <20190203190423.lmsix5la6ioyawwi@mok.nu> (raw)
In-Reply-To: <CAHp75VcLizx+jtMrbc3Ev-HcJVEjH2naFC0sj=7fX5nZSCGc8Q@mail.gmail.com>

On 2019-01-30, Andy Shevchenko wrote:
> On Wed, Jan 30, 2019 at 5:15 PM Mattias Jacobsson <2pi@mok.nu> wrote:
> >
> > The kernel provides the macro MODULE_DEVICE_TABLE() where driver authors
> > can specify their device type and their array of device_ids and thereby
> > trigger the generation of the appropriate MODULE_ALIAS() output. This is
> > opposed to having to specify one MODULE_ALIAS() for each device. The WMI
> > device type is currently not supported.
> >
> > While using MODULE_DEVICE_TABLE() does increase the complexity as well
> > as spreading out the implementation across the kernel, it does come with
> > some benefits too;
> > * It makes different drivers look more similar; if you can specify the
> >   array of device_ids any device type specific input to MODULE_ALIAS()
> >   will automatically be generated for you.
> > * It helps each driver avoid keeping multiple versions of the same
> >   information in sync. That is, both the array of device_ids and the
> >   potential multitude of MODULE_ALIAS()'s.
> >
> > Add WMI support to MODULE_DEVICE_TABLE() by adding info about struct
> > wmi_device_id in devicetable-offsets.c and add a WMI entry point in
> > file2alias.c.
> >
> > The type argument for MODULE_DEVICE_TABLE(type, name) is wmi.
> >
> > Suggested-by: Pali Rohár <pali.rohar@gmail.com>
> > Signed-off-by: Mattias Jacobsson <2pi@mok.nu>
> > ---
> >
> > What do you think about this usage of snprintf()? Now we check if there
> > is an error or if the printed string tried to exceeded the buffer.
> > Ideally 500 should be a macro or a parameter, but there isn't one
> > available. The number 500 comes from a few lines below in the function
> > do_table().
> 
> This looks better, though minor comments.
> 
> Indeed, 500 would be nicer to be defined as a constant (via preprocessor macro).
> 
> > +/* Looks like: wmi:guid */
> > +static int do_wmi_entry(const char *filename, void *symval, char *alias)
> > +{
> > +       DEF_FIELD_ADDR(symval, wmi_device_id, guid_string);
> > +       if (strlen(*guid_string) != UUID_STRING_LEN) {
> > +               warn("Invalid WMI device id 'wmi:%s' in '%s'\n",
> > +                               *guid_string, filename);
> > +               return 0;
> > +       }
> > +
> 
> > +       int len = snprintf(alias, 500, WMI_MODULE_PREFIX "%s", *guid_string);
> 
> Please, split declaration and assignment...

Done.

> 
> > +
> 
> ...and drop this line.

Done.

> 
> > +       if (len < 0 || len >= 500) {
> 
> Would it even possible to get a negative number here?
> Same for any other number than slightly bigger than 36.

snprintf returns a negative number on error. BTW AFAIU the code from
file2alias.c gets dynamically linked against a libc.

> 
> You have above a check and here is the matter of either sudden
> replacement of the string during the operation or how snprintf is
> broken itself.
> Do you have a case in mind which can bring to the above conditions?
> 
> > +               warn("Could not generate all MODULE_ALIAS's in '%s'\n",
> > +                               filename);
> > +               return 0;
> > +       }
> 
> On top of that you have an ordinary case here and in similar ones we
> don't care about buffer size at all (perhaps BUILD_BUG_ON() what is
> needed here).

I used warn() as it is what is being used in similar conditions
elsewhere in the file.

> 
> So, what about simple
> 
> {
>  DEF_FIELD_ADDR(...);
>  size_t len;
> 
>  len = strlen(*guid_string);
>  if (len != ...) {
>   ...
>  }
> sprintf(...);
> return 1;
> }
> 
> ?

Then we are missing the check that we are within the bounds of alias as
well as the negative code from s*printf(). snprintf() does this nicely
for us.

> 
> > +       return 1;
> > +}
> > +
> >  /* Does namelen bytes of name exactly match the symbol? */
> >  static bool sym_is(const char *name, unsigned namelen, const char *symbol)
> >  {
> > @@ -1357,6 +1378,7 @@ static const struct devtable devtable[] = {
> >         {"fslmc", SIZE_fsl_mc_device_id, do_fsl_mc_entry},
> >         {"tbsvc", SIZE_tb_service_id, do_tbsvc_entry},
> >         {"typec", SIZE_typec_device_id, do_typec_entry},
> > +       {"wmi", SIZE_wmi_device_id, do_wmi_entry},
> >  };
> >
> >  /* Create MODULE_ALIAS() statements.
> > --
> > 2.20.1
> >
> 
> 
> -- 
> With Best Regards,
> Andy Shevchenko

Thanks,
Mattias

  reply	other threads:[~2019-02-03 19:05 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-30 15:14 [PATCH v3 0/3] platform/x86: wmi: add WMI support to MODULE_DEVICE_TABLE() Mattias Jacobsson
2019-01-30 15:14 ` Mattias Jacobsson
2019-01-30 15:14 ` [PATCH v3 1/3] platform/x86: wmi: move struct wmi_device_id to mod_devicetable.h Mattias Jacobsson
2019-01-30 15:14   ` Mattias Jacobsson
2019-01-30 15:14 ` [PATCH v3 2/3] platform/x86: wmi: add WMI support to MODULE_DEVICE_TABLE() Mattias Jacobsson
2019-01-30 15:14   ` Mattias Jacobsson
2019-01-30 16:01   ` Andy Shevchenko
2019-02-03 19:04     ` Mattias Jacobsson [this message]
2019-02-05 15:45       ` Andy Shevchenko
2019-02-07 12:39         ` Mattias Jacobsson
2019-01-30 15:14 ` [PATCH v3 3/3] platform/x86: wmi: use MODULE_DEVICE_TABLE() instead of MODULE_ALIAS() Mattias Jacobsson
2019-01-30 15:14   ` Mattias Jacobsson
2019-01-30 15:48   ` Andy Shevchenko
2019-01-31 15:24     ` Mattias Jacobsson
2019-01-31 15:38       ` Mario.Limonciello
2019-01-31 15:38         ` Mario.Limonciello

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190203190423.lmsix5la6ioyawwi@mok.nu \
    --to=2pi@mok.nu \
    --cc=andy.shevchenko@gmail.com \
    --cc=andy@infradead.org \
    --cc=dvhart@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michal.lkml@markovi.net \
    --cc=pali.rohar@gmail.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=yamada.masahiro@socionext.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.