lkml.org 
[lkml]   [2017]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 02/38] Annotate hardware config module parameters in arch/x86/mm/
Date
Thomas Gleixner <tglx@linutronix.de> wrote:

> > -module_param(mmio_address, ulong, 0);
> > +module_param_hw(mmio_address, ulong, iomem, 0);
> > MODULE_PARM_DESC(mmio_address, " Start address of the mapping of 16 kB "
> > "(or 8 MB if read_far is non-zero).");
>
> The copied boilerplate above is really nonsensical here. The default
> address is 0, so the init function will emit:
>
> pr_err("you have to use the module argument mmio_address.\n");
> pr_err("DO NOT LOAD THIS MODULE UNLESS YOU REALLY KNOW WHAT YOU ARE DOING!\n");
>
> Pretty useless when you can't supply a valid address.
>
> if (kernel_locked_down()) {
> pr_info("This is not allowed because ...");
> return -EPERM;
> }
>
> would make too much sense for the user, right?

In some drivers, this would be wrong - ipmi, for example - and we've already
been through this. The hwparam series of patches annotates *all*
ioport/iomem/irq/dma specifiers unconditionally. The hwparam series is the
way it is is because this has no overhead if it's not used - and also has the
potentially useful side effect of making such parameters greppable.

It may well make sense to add your above suggestion also - but in the other
patch series.

David

\
 
 \ /
  Last update: 2017-04-18 14:39    [W:0.362 / U:2.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site