Thomas Gleixner <[email protected]> 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
