It was being done in two different places now that hard-coded devices
use platform devices, and it's about to be three with hotmod switching
to platform devices. So put the code in one place.
This required some rework on some interfaces to make the type space
clean.
Signed-off-by: Corey Minyard <cminyard@mvista.com>
When excuting a command like:
modprobe ipmi_si ports=0xffc0e3 type=bt
The system would get an oops.
The trouble here is that ipmi_si_hardcode_find_bmc() is called before
ipmi_si_platform_init(), but initialization of the hard-coded device
creates an IPMI platform device, which won't be initialized yet.
The real trouble is that hard-coded devices aren't created with
any device, and the fixup is done later. So do it right, create the
hard-coded devices as normal platform devices.
This required adding some new resource types to the IPMI platform
code for passing information required by the hard-coded device
and adding some code to remove the hard-coded platform devices
on module removal.
To enforce the "hard-coded devices passed by the user take priority
over firmware devices" rule, some special code was added to check
and see if a hard-coded device already exists.
Reported-by: Yang Yingliang <yangyingliang@huawei.com>
Cc: stable@vger.kernel.org # v4.15+
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Tested-by: Yang Yingliang <yangyingliang@huawei.com>
The IPMI DMI code was adding platform overrides, which is not
really an ideal solution. Switch to using the id_table in
the drivers to identify the devices.
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Add and use #define pr_fmt/dev_fmt, and remove #define PFX
This also prefixes some messages that were not previously prefixed.
Miscellanea:
o Convert printk(KERN_<level> to pr_<level>(
o Use %s, __func__ where appropriate
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
The IPMI spec states:
The purpose of the SPMI Table is to provide a mechanism that can
be used by the OSPM (an ACPI term for “OS Operating System-directed
configuration and Power Management” essentially meaning an ACPI-aware
OS or OS loader) very early in the boot process, e.g., before the
ability to execute ACPI control methods in the OS is available.
When we are probing IPMI in Linux, ACPI control methods are available,
so we shouldn't be probing using SPMI. It could cause some confusion
during the probing process.
Signed-off-by: Corey Minyard <cminyard@mvista.com>
And get rid of the license text that is no longer necessary.
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Alistair Popple <alistair@popple.id.au>
Cc: Jeremy Kerr <jk@ozlabs.org>
Cc: Joel Stanley <joel@jms.id.au>
Cc: Rocky Craig <rocky.craig@hp.com>
Fix typo in parameter description.
Fixes: 95e300c052 ("ipmi: Make the DMI probe into a generic platform probe")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Rework the DMI probe function to be a generic platform probe, and
then rework the DMI code (and a few other things) to use the more
generic information. This is so other things can declare platform
IPMI devices.
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Corey Minyard