Added #define pr_fmt KBUILD_MODNAME ": " fmt
Converted printks to pr_<level>
Coalesced any long formats
Removed prefixes from formats

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>

smsc47m1_restore is called from sm_smsc47m1_exit, which is an __exit
function, so it can't be __init.

Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>

If the address is set but the device isn't enabled, attempt to enable
it. If it won't work for any reason (resource conflict, no function
enabled) the initial state is restored. The initial state is also
restored on module unloading.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Tested-by: Sean Fidler <fidlersean@gmail.com>

If an error occurs during probing, there's no point in keeping the
module in memory. Better fail the module loading early to make the
problem more visible.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Tested-by: Sean Fidler <fidlersean@gmail.com>

The I/O area of the SMSC LPC47M1xx chips which we use, gives access to
a lot of registers, some of which are related to fan speed monitoring
and control, but many are not. At the moment, the smsc47m1 driver
requests the whole I/O port range. This could easily result in
resource conflicts with either ACPI or other drivers.

Request only the I/O ports we really use, to prevent such conflicts.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Tested-by: Sean Fidler <fidlersean@gmail.com>

Drivers should be including <linux/io.h> instead of <asm/io.h>.

Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Alistair John Strachan <alistair@devzero.co.uk>
Cc: Nicolas Boichat <nicolas@boichat.ch>
Cc: Juerg Haefliger <juergh@gmail.com>
Cc: Frank Seidel <frank@f-seidel.de>
Acked-by: Jim Cromie <jim.cromie@gmail.com>
Cc: "Mark M. Hoffman" <mhoffman@lightlink.com>
Cc: Roger Lucas <vt8231@hiddenengine.co.uk>
Signed-off-by: Jean Delvare <khali@linux-fr.org>

The SMSC LPC47M233 and LPC47M292 chips have the same device ID but
are not compatible.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Juerg Haefliger <juergh@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>

Check for ACPI resource conflicts in hwmon drivers. I've included
all Super-I/O and PCI drivers.

I've voluntarily left out:
* Vendor-specific drivers: if they conflicted on any system, this would
  pretty much mean that they conflict on all systems, and we would know
  by now.
* Legacy ISA drivers (lm78 and w83781d): they only support chips found
  on old designs were ACPI either wasn't supported or didn't deal with
  thermal management.
* Drivers accessing the I/O resources indirectly (e.g. through SMBus):
  the checks are already done where they belong, i.e. in the bus drivers.

Signed-off-by: Jean Delvare <jdelvare@suse.de>
Acked-by: David Hubbard <david.c.hubbard@gmail.com>

The new libsensors needs these individual alarm files.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Juerg Haefliger <juergh at gmail.com>
Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com>

While it is possible to force SMBus-based hardware monitoring chip
drivers to drive a not officially supported device, we do not have this
possibility for Super-I/O-based drivers. That's unfortunate because
sometimes newer chips are fully compatible and just forcing the driver
to load would work. Instead of that we have to tell the users to
recompile the kernel driver, which isn't an easy task for everyone.

So, I propose that we add a module parameter to all Super-I/O based
hardware monitoring drivers, letting advanced users force the driver
to load on their machine. The user has to provide the device ID of a
supposedly compatible device. This requires looking at the source code or
a datasheet, so I am confident that users can't randomly force a driver
without knowing what they are doing. Thus this should be relatively safe.

As you can see from the code, the implementation is pretty simple and
unintrusive.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Hans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com>