Signed-off-by: NCorey 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: NCorey Minyard <cminyard@mvista.com>

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

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

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

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

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

If the BMC fails to register, just set up to retry periodically.
Signed-off-by: NCorey 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: NCorey 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: NCorey Minyard <cminyard@mvista.com>

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

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

It's no longer used, dynamic device id handling is in place now.
Signed-off-by: NCorey 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: NJeremy Kerr <jk@ozlabs.org>

I basically rewrote this, I fixed some locking issues and simplified
things.  Same functional change, though.
Signed-off-by: NCorey 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: NCorey 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: NJeremy 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: NCorey 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: NJeremy Kerr <jk@ozlabs.org>

Reworked to support multiple interfaces on a BMC.
Signed-off-by: NCorey 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: NCorey Minyard <cminyard@mvista.com>

It was just wrong.  Make it print according to the guid spec.
Signed-off-by: NCorey 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: NCorey 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: NCorey 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: NCorey Minyard <cminyard@mvista.com>

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

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

It was off by one.
Signed-off-by: NCorey 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: NBhumika Goyal <bhumirks@gmail.com>
Signed-off-by: NCorey 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: NCorey 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: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NCorey 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: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Tested-by: NWeilong 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: NHanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

Now that there are potentially long delays between when a remoteport or
targetport delete calls is made and when the callback occurs (dev_loss_tmo
timeout), no longer block in the delete routines and move the final nport
puts to the callbacks.

Moved the fcloop_nport_get/put/free routines to avoid forward declarations.

Ensure port_info structs used in registrations are nulled in case fields
are not set (ex: devloss_tmo values).
Signed-off-by: NJames Smart <james.smart@broadcom.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NJens Axboe <axboe@kernel.dk>

When searching for queue id's ensure they are within the expected range.
Signed-off-by: NJames Smart <james.smart@broadcom.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NJens Axboe <axboe@kernel.dk>

Avoid calling the put routine, as it may traverse to free routines while
holding the target lock.
Signed-off-by: NJames Smart <james.smart@broadcom.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NJens Axboe <axboe@kernel.dk>

By calling nvme_stop_ctrl on a already failed controller will wait for the
scan work to complete (only by identify timeout expiration which is 60
seconds). This is unnecessary when we already know that the controller has
failed.
Reported-by: NYi Zhang <yizhan@redhat.com>
Signed-off-by: NSagi Grimberg <sagi@grimberg.me>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NJens Axboe <axboe@kernel.dk>

If we failed to transition to state LIVE after a successful reconnect,
then controller deletion already started. In this case there is no
point moving forward with reconnect.
Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: NSagi Grimberg <sagi@grimberg.me>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NJens Axboe <axboe@kernel.dk>

async_event_work might race as it is executed from two different
workqueues at the moment.
Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: NSagi Grimberg <sagi@grimberg.me>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NJens Axboe <axboe@kernel.dk>

Fix bug in sqhd patch.

It wasn't the sq that was at risk. In the case where the admin queue
connect command fails, the sq->size field is not set. Therefore, this
becomes a divide by zero error.

Add a quick check to bypass under this failure condition.
Signed-off-by: NJames Smart <james.smart@broadcom.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NJens Axboe <axboe@kernel.dk>

To support sqhd, for initiators that are following the spec and
paying attention to sqhd vs their sqtail values:

- add sqhd to struct nvmet_sq
- initialize sqhd to 0 in nvmet_sq_setup
- rather than propagate the 0's-based qsize value from the connect message
  which requires a +1 in every sqhd update, and as nothing else references
  it, convert to 1's-based value in nvmt_sq/cq_setup() calls.
- validate connect message sqsize being non-zero per spec.
- updated assign sqhd for every completion that goes back.

Also remove handling the NULL sq case in __nvmet_req_complete, as it can't
happen with the current code.
Signed-off-by: NJames Smart <james.smart@broadcom.com>
Reviewed-by: NSagi Grimberg <sagi@grimberg.me>
Reviewed-by: NMax Gurtovoy <maxg@mellanox.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NJens Axboe <axboe@kernel.dk>