Create a device attribute for everything we show in proc, getting
ready for removing the proc stuff.
Signed-off-by: Corey Minyard <cminyard@mvista.com>

It's only used in one place now, so it's overkill.
Signed-off-by: Corey Minyard <cminyard@mvista.com>

Signed-off-by: Corey Minyard <cminyard@mvista.com>

Signed-off-by: Corey Minyard <cminyard@mvista.com>

Signed-off-by: Corey Minyard <cminyard@mvista.com>

Signed-off-by: Corey Minyard <cminyard@mvista.com>

Stephen Rothwell <sfr@canb.auug.org.au> fixed an issue with the
include files

Signed-off-by: Corey Minyard <cminyard@mvista.com>

Stephen Rothwell <sfr@canb.auug.org.au> fixed an issue with the
include files

Signed-off-by: Corey Minyard <cminyard@mvista.com>

Signed-off-by: Corey Minyard <cminyard@mvista.com>

Instead of allocating the smi_info structure, filling in the I/O
info, and passing it to ipmi_si_add_smi(), just pass the I/O
info in the io structure and let ipmi_si_add_smi() allocate
the smi_info structure.

This required redoing the way the remove functions for some
device interfaces worked, a new function named
ipmi_si_remove_by_dev() allows the device to be passed in and
detected instead of using driver data, which couldn't be
filled out easily othersize.

After this the platform handling should be decoupled from the
smi_info structure and that handling can be pulled out to its
own files.
Signed-off-by: Corey Minyard <cminyard@mvista.com>

Where it belongs, and getting ready for pulling the platform
handling into its own file.
Signed-off-by: Corey Minyard <cminyard@mvista.com>

So the platform code can do it without having to access the
smi info, getting ready for pulling the platform handling
section to their own files.
Signed-off-by: Corey Minyard <cminyard@mvista.com>

That's where it belongs, and we are getting ready for moving the
platform handling out of the main ipmi_si_intf.c file.
Signed-off-by: Corey Minyard <cminyard@mvista.com>

Getting ready for moving the platform-specific stuff into their
own files.
Signed-off-by: Corey Minyard <cminyard@mvista.com>

Signed-off-by: Corey Minyard <cminyard@mvista.com>

If the BMC changes versions or a change is otherwise detected,
rescan the channels on the BMC.
Signed-off-by: Corey Minyard <cminyard@mvista.com>

Put it in it's own struct, getting ready for channel information
being dynamically changed.
Signed-off-by: Corey Minyard <cminyard@mvista.com>

If the BMC fails to register, just set up to retry periodically.
Signed-off-by: Corey Minyard <cminyard@mvista.com>

A BMC's guid or device id info may change dynamically, this could
result in a different configuration that needs to be done.  Adjust
the BMCs dynamically.
Signed-off-by: Corey Minyard <cminyard@mvista.com>

This is getting ready for the ability to redo the BMC if it's
information changes, we need a fallback mechanism.
Signed-off-by: Corey Minyard <cminyard@mvista.com>

This will catch if the GUID changes.
Signed-off-by: Corey Minyard <cminyard@mvista.com>

This is in preparation for making ipmi_get_device_id() dynamically
return the guid and device id.
Signed-off-by: Corey Minyard <cminyard@mvista.com>

It's no longer used, dynamic device id handling is in place now.
Signed-off-by: Corey Minyard <cminyard@mvista.com>

Currently, it's up to the IPMI SMIs to provide the product & version
details of BMCs behind registered IPMI SMI interfaces. This device ID is
provided on SMI regsitration, and kept around for all future queries.

However, this version information isn't always static. For example, a
BMC may be upgraded at runtime, making the old version information
stale.

This change allows querying the BMC device ID & version information
dynamically. If no static device_id argument is provided to
ipmi_register_smi, then the IPMI core code will perform a Get Device ID
IPMI command to query the version information when needed. We keep a
short-term cache of this information so we don't need to re-query
for every attribute access.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>

I basically rewrote this, I fixed some locking issues and simplified
things.  Same functional change, though.
Signed-off-by: Corey Minyard <cminyard@mvista.com>

There are a lot of bad things that a set of BMCs could do that
would really confuse the IPMI driver; it's possible for BMCs with
different GUIDs to have the same product/devid (though that's
not technically legal), which would result in platform device
namespace collisions.  Fixing it would involve either using
the GUID in the BMC name, which resulted in huge names, or
just using an ida for numbering the BMCs.  The latter approach
was chosen to avoid the huge names.
Signed-off-by: Corey Minyard <cminyard@mvista.com>

Currently, ipmi_demagle_device_id requires a full response buffer in its
data argument. This means we can't use it to parse a response in a
struct ipmi_recv_msg, which has the netfn and cmd as separate bytes.

This change alters the definition and users of ipmi_demangle_device_id
to use a split netfn, cmd and data buffer, so it can be used with
non-sequential responses.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>

Fixed the ipmi_ssif.c and ipmi_si_intf.c changes to use data from the
response, not the data from the message, when passing info to the
ipmi_demangle_device_id() function.
Signed-off-by: Corey Minyard <cminyard@mvista.com>

In an upcoming change, we'll want to grab a reference to the ipmi_smi_t
from a struct bmc_device. This change adds a pointer to allow this.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>

Reworked to support multiple interfaces on a BMC.
Signed-off-by: Corey Minyard <cminyard@mvista.com>

This makes getting the device id consistent, and make it possible
to add a function to fetch it dynamically later.
Signed-off-by: Corey Minyard <cminyard@mvista.com>

It was just wrong.  Make it print according to the guid spec.
Signed-off-by: Corey Minyard <cminyard@mvista.com>

There was a certain error case where the BMC wouldn't be deregistered
like it should be.  Rework the BMC registration to make calling
ipmi_bmc_unregister() ok even if it's not registered and to clean up
the error handling for ipmi_bmc_register().
Signed-off-by: Corey Minyard <cminyard@mvista.com>

The recent changes to add SMBIOS (DMI) IPMI interfaces as platform
devices caused DMI to be selected before ACPI, causing ACPI type
of operations to not work.
Signed-off-by: Corey Minyard <cminyard@mvista.com>

BMC device refcounts were not being decremented after fetching from
driver_find_device().  Also, document the use of ipmidriver_mutex
and tighten it's span some by incrementing the BMC's usecount in
the BMC find routines and not later.  This will be important for
future changes where a long mutex hold area will complicate things.
Signed-off-by: Corey Minyard <cminyard@mvista.com>

Just an added safety check.
Signed-off-by: Corey Minyard <cminyard@mvista.com>

No functional change, this is for a later change that uses the
bmc device type.
Signed-off-by: Corey Minyard <cminyard@mvista.com>

It was off by one.
Signed-off-by: Corey Minyard <cminyard@mvista.com>

Make this const as it is only passed to a const argument of the function
ipmi_create_user.
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>

They were set by config items, but people complained that they were
never turned on.  So have them always available and enabled by a
module parameter.
Signed-off-by: Corey Minyard <cminyard@mvista.com>

The function ipmi_get_info_from_resources is local to the source and
does not need to be in global scope, so make it static.  Add in
newline to function declaration to make it checkpatch warning clean.

Cleans up sparse warnings:
symbol 'ipmi_get_info_from_resources' was not declared. Should it
be static?
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>

When I set the timeout to a specific value such as 500ms, the timeout
event will not happen in time due to the overflow in function
check_msg_timeout:
...
	ent->timeout -= timeout_period;
	if (ent->timeout > 0)
		return;
...

The type of timeout_period is long, but ent->timeout is unsigned long.
This patch makes the type consistent.
Reported-by: Weilong Chen <chenweilong@huawei.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Tested-by: Weilong Chen <chenweilong@huawei.com>
Cc: <stable@vger.kernel.org> # 3.16.x

When ipmi is probed via ACPI, the boot log shows

[   17.945139] ipmi_si IPI0001:00: probing via device tree
[   17.950369] ipmi_si IPI0001:00: ipmi_si: probing via ACPI
[   17.955795] ipmi_si IPI0001:00: [io  0x00e4-0x3fff] regsize 1 spacing 1 irq 0
[   17.962932] ipmi_si: Adding ACPI-specified bt state machine

which "ipmi_si IPI0001:00: probing via device tree" is misleading
with a ACPI HID "IPI0001" but probing via DT.

Eliminate this misleading print info by checking of_node is valid
or not before calling of_ipmi_probe().
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Corey Minyard <cminyard@mvista.com>