2019-05-27 09:55:06 +03:00
// SPDX-License-Identifier: GPL-2.0-or-later
2010-12-08 05:10:18 +03:00
/*
* acpi_ipmi . c - ACPI IPMI opregion
*
2013-09-13 09:13:54 +04:00
* Copyright ( C ) 2010 , 2013 Intel Corporation
* Author : Zhao Yakui < yakui . zhao @ intel . com >
* Lv Zheng < lv . zheng @ intel . com >
2010-12-08 05:10:18 +03:00
*/
# include <linux/module.h>
2013-09-13 09:14:41 +04:00
# include <linux/acpi.h>
2010-12-08 05:10:18 +03:00
# include <linux/ipmi.h>
2013-09-13 09:13:23 +04:00
# include <linux/spinlock.h>
2010-12-08 05:10:18 +03:00
MODULE_AUTHOR ( " Zhao Yakui " ) ;
MODULE_DESCRIPTION ( " ACPI IPMI Opregion driver " ) ;
MODULE_LICENSE ( " GPL " ) ;
# define ACPI_IPMI_OK 0
# define ACPI_IPMI_TIMEOUT 0x10
# define ACPI_IPMI_UNKNOWN 0x07
/* the IPMI timeout is 5s */
2013-09-13 09:13:47 +04:00
# define IPMI_TIMEOUT (5000)
2013-09-13 09:13:30 +04:00
# define ACPI_IPMI_MAX_MSG_LENGTH 64
2010-12-08 05:10:18 +03:00
struct acpi_ipmi_device {
/* the device list attached to driver_data.ipmi_devices */
struct list_head head ;
2013-09-13 09:15:00 +04:00
2010-12-08 05:10:18 +03:00
/* the IPMI request message list */
struct list_head tx_msg_list ;
2013-09-13 09:15:00 +04:00
spinlock_t tx_msg_lock ;
2010-12-08 05:10:18 +03:00
acpi_handle handle ;
2013-09-13 09:14:21 +04:00
struct device * dev ;
2018-04-11 21:05:33 +03:00
struct ipmi_user * user_interface ;
2010-12-08 05:10:18 +03:00
int ipmi_ifnum ; /* IPMI interface number */
long curr_msgid ;
2013-09-13 09:13:54 +04:00
bool dead ;
struct kref kref ;
2010-12-08 05:10:18 +03:00
} ;
struct ipmi_driver_data {
2013-09-13 09:15:00 +04:00
struct list_head ipmi_devices ;
struct ipmi_smi_watcher bmc_events ;
2017-01-05 19:52:54 +03:00
const struct ipmi_user_hndl ipmi_hndlrs ;
2013-09-13 09:15:00 +04:00
struct mutex ipmi_lock ;
ACPI / IPMI: Use global IPMI operation region handler
It is found on a real machine, in its ACPI namespace, the IPMI
OperationRegions (in the ACPI000D - ACPI power meter) are not defined under
the IPMI system interface device (the IPI0001 with KCS type returned from
_IFT control method):
Device (PMI0)
{
Name (_HID, "ACPI000D") // _HID: Hardware ID
OperationRegion (SYSI, IPMI, 0x0600, 0x0100)
Field (SYSI, BufferAcc, Lock, Preserve)
{
AccessAs (BufferAcc, 0x01),
Offset (0x58),
SCMD, 8,
GCMD, 8
}
OperationRegion (POWR, IPMI, 0x3000, 0x0100)
Field (POWR, BufferAcc, Lock, Preserve)
{
AccessAs (BufferAcc, 0x01),
Offset (0xB3),
GPMM, 8
}
}
Device (PCI0)
{
Device (ISA)
{
Device (NIPM)
{
Name (_HID, EisaId ("IPI0001")) // _HID: Hardware ID
Method (_IFT, 0, NotSerialized) // _IFT: IPMI Interface Type
{
Return (0x01)
}
}
}
}
Current ACPI_IPMI code registers IPMI operation region handler on a
per-device basis, so for the above namespace the IPMI operation region
handler is registered only under the scope of \_SB.PCI0.ISA.NIPM. Thus
when an IPMI operation region field of \PMI0 is accessed, there are errors
reported on such platform:
ACPI Error: No handlers for Region [IPMI]
ACPI Error: Region IPMI(7) has no handler
The solution is to install an IPMI operation region handler from root node
so that every object that defines IPMI OperationRegion can get an address
space handler registered.
When an IPMI operation region field is accessed, the Network Function
(0x06 for SYSI and 0x30 for POWR) and the Command (SCMD, GCMD, GPMM) are
passed to the operation region handler, there is no system interface
specified by the BIOS. The patch tries to select one system interface by
monitoring the system interface notification. IPMI messages passed from
the ACPI codes are sent to this selected global IPMI system interface.
The ACPI_IPMI will always select the first registered IPMI interface
with an ACPI handle (i.e., defined in the ACPI namespace). It's hard to
determine the selection when there are multiple IPMI system interfaces
defined in the ACPI namespace. According to the IPMI specification:
A BMC device may make available multiple system interfaces, but only one
management controller is allowed to be 'active' BMC that provides BMC
functionality for the system (in case of a 'partitioned' system, there
can be only one active BMC per partition). Only the system interface(s)
for the active BMC allowed to respond to the 'Get Device Id' command.
According to the ipmi_si desigin:
The ipmi_si registeration notifications can only happen after a
successful "Get Device ID" command.
Thus it should be OK for non-partitioned systems to do such selection.
However, we do not have much knowledge on 'partitioned' systems.
References: https://bugzilla.kernel.org/show_bug.cgi?id=46741
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Reviewed-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-09-13 09:14:02 +04:00
/*
* NOTE : IPMI System Interface Selection
* There is no system interface specified by the IPMI operation
* region access . We try to select one system interface with ACPI
* handle set . IPMI messages passed from the ACPI codes are sent
* to this selected global IPMI system interface .
*/
struct acpi_ipmi_device * selected_smi ;
2010-12-08 05:10:18 +03:00
} ;
struct acpi_ipmi_msg {
struct list_head head ;
2013-09-13 09:15:00 +04:00
2010-12-08 05:10:18 +03:00
/*
* General speaking the addr type should be SI_ADDR_TYPE . And
* the addr channel should be BMC .
* In fact it can also be IPMB type . But we will have to
* parse it from the Netfn command buffer . It is so complex
* that it is skipped .
*/
struct ipmi_addr addr ;
long tx_msgid ;
2013-09-13 09:15:00 +04:00
2010-12-08 05:10:18 +03:00
/* it is used to track whether the IPMI message is finished */
struct completion tx_complete ;
2013-09-13 09:15:00 +04:00
2010-12-08 05:10:18 +03:00
struct kernel_ipmi_msg tx_message ;
2013-09-13 09:15:00 +04:00
int msg_done ;
2013-09-13 09:13:30 +04:00
/* tx/rx data . And copy it from/to ACPI object buffer */
2013-09-13 09:15:00 +04:00
u8 data [ ACPI_IPMI_MAX_MSG_LENGTH ] ;
u8 rx_len ;
2010-12-08 05:10:18 +03:00
struct acpi_ipmi_device * device ;
2013-09-13 09:15:00 +04:00
struct kref kref ;
2010-12-08 05:10:18 +03:00
} ;
/* IPMI request/response buffer per ACPI 4.0, sec 5.5.2.4.3.2 */
struct acpi_ipmi_buffer {
u8 status ;
u8 length ;
2013-09-13 09:13:30 +04:00
u8 data [ ACPI_IPMI_MAX_MSG_LENGTH ] ;
2010-12-08 05:10:18 +03:00
} ;
static void ipmi_register_bmc ( int iface , struct device * dev ) ;
static void ipmi_bmc_gone ( int iface ) ;
static void ipmi_msg_handler ( struct ipmi_recv_msg * msg , void * user_msg_data ) ;
static struct ipmi_driver_data driver_data = {
. ipmi_devices = LIST_HEAD_INIT ( driver_data . ipmi_devices ) ,
. bmc_events = {
. owner = THIS_MODULE ,
. new_smi = ipmi_register_bmc ,
. smi_gone = ipmi_bmc_gone ,
} ,
. ipmi_hndlrs = {
. ipmi_recv_hndl = ipmi_msg_handler ,
} ,
2013-09-13 09:14:31 +04:00
. ipmi_lock = __MUTEX_INITIALIZER ( driver_data . ipmi_lock )
2010-12-08 05:10:18 +03:00
} ;
2013-09-13 09:13:54 +04:00
static struct acpi_ipmi_device *
2013-09-13 09:14:21 +04:00
ipmi_dev_alloc ( int iface , struct device * dev , acpi_handle handle )
2013-09-13 09:13:54 +04:00
{
struct acpi_ipmi_device * ipmi_device ;
int err ;
2018-04-11 21:05:33 +03:00
struct ipmi_user * user ;
2013-09-13 09:13:54 +04:00
ipmi_device = kzalloc ( sizeof ( * ipmi_device ) , GFP_KERNEL ) ;
if ( ! ipmi_device )
return NULL ;
kref_init ( & ipmi_device - > kref ) ;
INIT_LIST_HEAD ( & ipmi_device - > head ) ;
INIT_LIST_HEAD ( & ipmi_device - > tx_msg_list ) ;
spin_lock_init ( & ipmi_device - > tx_msg_lock ) ;
ipmi_device - > handle = handle ;
2013-09-13 09:14:21 +04:00
ipmi_device - > dev = get_device ( dev ) ;
2013-09-13 09:13:54 +04:00
ipmi_device - > ipmi_ifnum = iface ;
err = ipmi_create_user ( iface , & driver_data . ipmi_hndlrs ,
ipmi_device , & user ) ;
if ( err ) {
2013-09-13 09:14:21 +04:00
put_device ( dev ) ;
2013-09-13 09:13:54 +04:00
kfree ( ipmi_device ) ;
return NULL ;
}
ipmi_device - > user_interface = user ;
return ipmi_device ;
}
static void ipmi_dev_release ( struct acpi_ipmi_device * ipmi_device )
{
ipmi_destroy_user ( ipmi_device - > user_interface ) ;
2013-09-13 09:14:21 +04:00
put_device ( ipmi_device - > dev ) ;
2013-09-13 09:13:54 +04:00
kfree ( ipmi_device ) ;
}
static void ipmi_dev_release_kref ( struct kref * kref )
{
struct acpi_ipmi_device * ipmi =
container_of ( kref , struct acpi_ipmi_device , kref ) ;
ipmi_dev_release ( ipmi ) ;
}
static void __ipmi_dev_kill ( struct acpi_ipmi_device * ipmi_device )
{
list_del ( & ipmi_device - > head ) ;
ACPI / IPMI: Use global IPMI operation region handler
It is found on a real machine, in its ACPI namespace, the IPMI
OperationRegions (in the ACPI000D - ACPI power meter) are not defined under
the IPMI system interface device (the IPI0001 with KCS type returned from
_IFT control method):
Device (PMI0)
{
Name (_HID, "ACPI000D") // _HID: Hardware ID
OperationRegion (SYSI, IPMI, 0x0600, 0x0100)
Field (SYSI, BufferAcc, Lock, Preserve)
{
AccessAs (BufferAcc, 0x01),
Offset (0x58),
SCMD, 8,
GCMD, 8
}
OperationRegion (POWR, IPMI, 0x3000, 0x0100)
Field (POWR, BufferAcc, Lock, Preserve)
{
AccessAs (BufferAcc, 0x01),
Offset (0xB3),
GPMM, 8
}
}
Device (PCI0)
{
Device (ISA)
{
Device (NIPM)
{
Name (_HID, EisaId ("IPI0001")) // _HID: Hardware ID
Method (_IFT, 0, NotSerialized) // _IFT: IPMI Interface Type
{
Return (0x01)
}
}
}
}
Current ACPI_IPMI code registers IPMI operation region handler on a
per-device basis, so for the above namespace the IPMI operation region
handler is registered only under the scope of \_SB.PCI0.ISA.NIPM. Thus
when an IPMI operation region field of \PMI0 is accessed, there are errors
reported on such platform:
ACPI Error: No handlers for Region [IPMI]
ACPI Error: Region IPMI(7) has no handler
The solution is to install an IPMI operation region handler from root node
so that every object that defines IPMI OperationRegion can get an address
space handler registered.
When an IPMI operation region field is accessed, the Network Function
(0x06 for SYSI and 0x30 for POWR) and the Command (SCMD, GCMD, GPMM) are
passed to the operation region handler, there is no system interface
specified by the BIOS. The patch tries to select one system interface by
monitoring the system interface notification. IPMI messages passed from
the ACPI codes are sent to this selected global IPMI system interface.
The ACPI_IPMI will always select the first registered IPMI interface
with an ACPI handle (i.e., defined in the ACPI namespace). It's hard to
determine the selection when there are multiple IPMI system interfaces
defined in the ACPI namespace. According to the IPMI specification:
A BMC device may make available multiple system interfaces, but only one
management controller is allowed to be 'active' BMC that provides BMC
functionality for the system (in case of a 'partitioned' system, there
can be only one active BMC per partition). Only the system interface(s)
for the active BMC allowed to respond to the 'Get Device Id' command.
According to the ipmi_si desigin:
The ipmi_si registeration notifications can only happen after a
successful "Get Device ID" command.
Thus it should be OK for non-partitioned systems to do such selection.
However, we do not have much knowledge on 'partitioned' systems.
References: https://bugzilla.kernel.org/show_bug.cgi?id=46741
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Reviewed-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-09-13 09:14:02 +04:00
if ( driver_data . selected_smi = = ipmi_device )
driver_data . selected_smi = NULL ;
2013-09-13 09:15:00 +04:00
2013-09-13 09:13:54 +04:00
/*
* Always setting dead flag after deleting from the list or
* list_for_each_entry ( ) codes must get changed .
*/
ipmi_device - > dead = true ;
}
ACPI / IPMI: Use global IPMI operation region handler
It is found on a real machine, in its ACPI namespace, the IPMI
OperationRegions (in the ACPI000D - ACPI power meter) are not defined under
the IPMI system interface device (the IPI0001 with KCS type returned from
_IFT control method):
Device (PMI0)
{
Name (_HID, "ACPI000D") // _HID: Hardware ID
OperationRegion (SYSI, IPMI, 0x0600, 0x0100)
Field (SYSI, BufferAcc, Lock, Preserve)
{
AccessAs (BufferAcc, 0x01),
Offset (0x58),
SCMD, 8,
GCMD, 8
}
OperationRegion (POWR, IPMI, 0x3000, 0x0100)
Field (POWR, BufferAcc, Lock, Preserve)
{
AccessAs (BufferAcc, 0x01),
Offset (0xB3),
GPMM, 8
}
}
Device (PCI0)
{
Device (ISA)
{
Device (NIPM)
{
Name (_HID, EisaId ("IPI0001")) // _HID: Hardware ID
Method (_IFT, 0, NotSerialized) // _IFT: IPMI Interface Type
{
Return (0x01)
}
}
}
}
Current ACPI_IPMI code registers IPMI operation region handler on a
per-device basis, so for the above namespace the IPMI operation region
handler is registered only under the scope of \_SB.PCI0.ISA.NIPM. Thus
when an IPMI operation region field of \PMI0 is accessed, there are errors
reported on such platform:
ACPI Error: No handlers for Region [IPMI]
ACPI Error: Region IPMI(7) has no handler
The solution is to install an IPMI operation region handler from root node
so that every object that defines IPMI OperationRegion can get an address
space handler registered.
When an IPMI operation region field is accessed, the Network Function
(0x06 for SYSI and 0x30 for POWR) and the Command (SCMD, GCMD, GPMM) are
passed to the operation region handler, there is no system interface
specified by the BIOS. The patch tries to select one system interface by
monitoring the system interface notification. IPMI messages passed from
the ACPI codes are sent to this selected global IPMI system interface.
The ACPI_IPMI will always select the first registered IPMI interface
with an ACPI handle (i.e., defined in the ACPI namespace). It's hard to
determine the selection when there are multiple IPMI system interfaces
defined in the ACPI namespace. According to the IPMI specification:
A BMC device may make available multiple system interfaces, but only one
management controller is allowed to be 'active' BMC that provides BMC
functionality for the system (in case of a 'partitioned' system, there
can be only one active BMC per partition). Only the system interface(s)
for the active BMC allowed to respond to the 'Get Device Id' command.
According to the ipmi_si desigin:
The ipmi_si registeration notifications can only happen after a
successful "Get Device ID" command.
Thus it should be OK for non-partitioned systems to do such selection.
However, we do not have much knowledge on 'partitioned' systems.
References: https://bugzilla.kernel.org/show_bug.cgi?id=46741
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Reviewed-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-09-13 09:14:02 +04:00
static struct acpi_ipmi_device * acpi_ipmi_dev_get ( void )
2013-09-13 09:13:54 +04:00
{
ACPI / IPMI: Use global IPMI operation region handler
It is found on a real machine, in its ACPI namespace, the IPMI
OperationRegions (in the ACPI000D - ACPI power meter) are not defined under
the IPMI system interface device (the IPI0001 with KCS type returned from
_IFT control method):
Device (PMI0)
{
Name (_HID, "ACPI000D") // _HID: Hardware ID
OperationRegion (SYSI, IPMI, 0x0600, 0x0100)
Field (SYSI, BufferAcc, Lock, Preserve)
{
AccessAs (BufferAcc, 0x01),
Offset (0x58),
SCMD, 8,
GCMD, 8
}
OperationRegion (POWR, IPMI, 0x3000, 0x0100)
Field (POWR, BufferAcc, Lock, Preserve)
{
AccessAs (BufferAcc, 0x01),
Offset (0xB3),
GPMM, 8
}
}
Device (PCI0)
{
Device (ISA)
{
Device (NIPM)
{
Name (_HID, EisaId ("IPI0001")) // _HID: Hardware ID
Method (_IFT, 0, NotSerialized) // _IFT: IPMI Interface Type
{
Return (0x01)
}
}
}
}
Current ACPI_IPMI code registers IPMI operation region handler on a
per-device basis, so for the above namespace the IPMI operation region
handler is registered only under the scope of \_SB.PCI0.ISA.NIPM. Thus
when an IPMI operation region field of \PMI0 is accessed, there are errors
reported on such platform:
ACPI Error: No handlers for Region [IPMI]
ACPI Error: Region IPMI(7) has no handler
The solution is to install an IPMI operation region handler from root node
so that every object that defines IPMI OperationRegion can get an address
space handler registered.
When an IPMI operation region field is accessed, the Network Function
(0x06 for SYSI and 0x30 for POWR) and the Command (SCMD, GCMD, GPMM) are
passed to the operation region handler, there is no system interface
specified by the BIOS. The patch tries to select one system interface by
monitoring the system interface notification. IPMI messages passed from
the ACPI codes are sent to this selected global IPMI system interface.
The ACPI_IPMI will always select the first registered IPMI interface
with an ACPI handle (i.e., defined in the ACPI namespace). It's hard to
determine the selection when there are multiple IPMI system interfaces
defined in the ACPI namespace. According to the IPMI specification:
A BMC device may make available multiple system interfaces, but only one
management controller is allowed to be 'active' BMC that provides BMC
functionality for the system (in case of a 'partitioned' system, there
can be only one active BMC per partition). Only the system interface(s)
for the active BMC allowed to respond to the 'Get Device Id' command.
According to the ipmi_si desigin:
The ipmi_si registeration notifications can only happen after a
successful "Get Device ID" command.
Thus it should be OK for non-partitioned systems to do such selection.
However, we do not have much knowledge on 'partitioned' systems.
References: https://bugzilla.kernel.org/show_bug.cgi?id=46741
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Reviewed-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-09-13 09:14:02 +04:00
struct acpi_ipmi_device * ipmi_device = NULL ;
2013-09-13 09:13:54 +04:00
mutex_lock ( & driver_data . ipmi_lock ) ;
ACPI / IPMI: Use global IPMI operation region handler
It is found on a real machine, in its ACPI namespace, the IPMI
OperationRegions (in the ACPI000D - ACPI power meter) are not defined under
the IPMI system interface device (the IPI0001 with KCS type returned from
_IFT control method):
Device (PMI0)
{
Name (_HID, "ACPI000D") // _HID: Hardware ID
OperationRegion (SYSI, IPMI, 0x0600, 0x0100)
Field (SYSI, BufferAcc, Lock, Preserve)
{
AccessAs (BufferAcc, 0x01),
Offset (0x58),
SCMD, 8,
GCMD, 8
}
OperationRegion (POWR, IPMI, 0x3000, 0x0100)
Field (POWR, BufferAcc, Lock, Preserve)
{
AccessAs (BufferAcc, 0x01),
Offset (0xB3),
GPMM, 8
}
}
Device (PCI0)
{
Device (ISA)
{
Device (NIPM)
{
Name (_HID, EisaId ("IPI0001")) // _HID: Hardware ID
Method (_IFT, 0, NotSerialized) // _IFT: IPMI Interface Type
{
Return (0x01)
}
}
}
}
Current ACPI_IPMI code registers IPMI operation region handler on a
per-device basis, so for the above namespace the IPMI operation region
handler is registered only under the scope of \_SB.PCI0.ISA.NIPM. Thus
when an IPMI operation region field of \PMI0 is accessed, there are errors
reported on such platform:
ACPI Error: No handlers for Region [IPMI]
ACPI Error: Region IPMI(7) has no handler
The solution is to install an IPMI operation region handler from root node
so that every object that defines IPMI OperationRegion can get an address
space handler registered.
When an IPMI operation region field is accessed, the Network Function
(0x06 for SYSI and 0x30 for POWR) and the Command (SCMD, GCMD, GPMM) are
passed to the operation region handler, there is no system interface
specified by the BIOS. The patch tries to select one system interface by
monitoring the system interface notification. IPMI messages passed from
the ACPI codes are sent to this selected global IPMI system interface.
The ACPI_IPMI will always select the first registered IPMI interface
with an ACPI handle (i.e., defined in the ACPI namespace). It's hard to
determine the selection when there are multiple IPMI system interfaces
defined in the ACPI namespace. According to the IPMI specification:
A BMC device may make available multiple system interfaces, but only one
management controller is allowed to be 'active' BMC that provides BMC
functionality for the system (in case of a 'partitioned' system, there
can be only one active BMC per partition). Only the system interface(s)
for the active BMC allowed to respond to the 'Get Device Id' command.
According to the ipmi_si desigin:
The ipmi_si registeration notifications can only happen after a
successful "Get Device ID" command.
Thus it should be OK for non-partitioned systems to do such selection.
However, we do not have much knowledge on 'partitioned' systems.
References: https://bugzilla.kernel.org/show_bug.cgi?id=46741
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Reviewed-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-09-13 09:14:02 +04:00
if ( driver_data . selected_smi ) {
ipmi_device = driver_data . selected_smi ;
kref_get ( & ipmi_device - > kref ) ;
2013-09-13 09:13:54 +04:00
}
mutex_unlock ( & driver_data . ipmi_lock ) ;
return ipmi_device ;
}
static void acpi_ipmi_dev_put ( struct acpi_ipmi_device * ipmi_device )
{
kref_put ( & ipmi_device - > kref , ipmi_dev_release_kref ) ;
}
2013-09-13 09:14:11 +04:00
static struct acpi_ipmi_msg * ipmi_msg_alloc ( void )
2010-12-08 05:10:18 +03:00
{
2013-09-13 09:14:11 +04:00
struct acpi_ipmi_device * ipmi ;
2010-12-08 05:10:18 +03:00
struct acpi_ipmi_msg * ipmi_msg ;
2013-09-13 09:14:11 +04:00
ipmi = acpi_ipmi_dev_get ( ) ;
if ( ! ipmi )
return NULL ;
2013-09-13 09:15:00 +04:00
2010-12-08 05:10:18 +03:00
ipmi_msg = kzalloc ( sizeof ( struct acpi_ipmi_msg ) , GFP_KERNEL ) ;
2013-09-13 09:14:11 +04:00
if ( ! ipmi_msg ) {
acpi_ipmi_dev_put ( ipmi ) ;
2010-12-08 05:10:18 +03:00
return NULL ;
}
2013-09-13 09:15:00 +04:00
2013-09-13 09:14:11 +04:00
kref_init ( & ipmi_msg - > kref ) ;
2010-12-08 05:10:18 +03:00
init_completion ( & ipmi_msg - > tx_complete ) ;
INIT_LIST_HEAD ( & ipmi_msg - > head ) ;
ipmi_msg - > device = ipmi ;
2013-09-13 09:13:47 +04:00
ipmi_msg - > msg_done = ACPI_IPMI_UNKNOWN ;
2013-09-13 09:15:00 +04:00
2010-12-08 05:10:18 +03:00
return ipmi_msg ;
}
2013-09-13 09:14:11 +04:00
static void ipmi_msg_release ( struct acpi_ipmi_msg * tx_msg )
{
acpi_ipmi_dev_put ( tx_msg - > device ) ;
kfree ( tx_msg ) ;
}
static void ipmi_msg_release_kref ( struct kref * kref )
{
struct acpi_ipmi_msg * tx_msg =
container_of ( kref , struct acpi_ipmi_msg , kref ) ;
ipmi_msg_release ( tx_msg ) ;
}
static struct acpi_ipmi_msg * acpi_ipmi_msg_get ( struct acpi_ipmi_msg * tx_msg )
{
kref_get ( & tx_msg - > kref ) ;
return tx_msg ;
}
static void acpi_ipmi_msg_put ( struct acpi_ipmi_msg * tx_msg )
{
kref_put ( & tx_msg - > kref , ipmi_msg_release_kref ) ;
}
2013-09-13 09:15:00 +04:00
# define IPMI_OP_RGN_NETFN(offset) ((offset >> 8) & 0xff)
# define IPMI_OP_RGN_CMD(offset) (offset & 0xff)
2013-09-13 09:13:30 +04:00
static int acpi_format_ipmi_request ( struct acpi_ipmi_msg * tx_msg ,
2013-09-13 09:15:00 +04:00
acpi_physical_address address ,
acpi_integer * value )
2010-12-08 05:10:18 +03:00
{
struct kernel_ipmi_msg * msg ;
struct acpi_ipmi_buffer * buffer ;
struct acpi_ipmi_device * device ;
2013-09-13 09:13:23 +04:00
unsigned long flags ;
2010-12-08 05:10:18 +03:00
msg = & tx_msg - > tx_message ;
2013-09-13 09:15:00 +04:00
2010-12-08 05:10:18 +03:00
/*
* IPMI network function and command are encoded in the address
* within the IPMI OpRegion ; see ACPI 4.0 , sec 5.5 .2 .4 .3 .
*/
msg - > netfn = IPMI_OP_RGN_NETFN ( address ) ;
msg - > cmd = IPMI_OP_RGN_CMD ( address ) ;
2013-09-13 09:13:30 +04:00
msg - > data = tx_msg - > data ;
2013-09-13 09:15:00 +04:00
2010-12-08 05:10:18 +03:00
/*
* value is the parameter passed by the IPMI opregion space handler .
* It points to the IPMI request message buffer
*/
buffer = ( struct acpi_ipmi_buffer * ) value ;
2013-09-13 09:15:00 +04:00
2010-12-08 05:10:18 +03:00
/* copy the tx message data */
2013-09-13 09:13:30 +04:00
if ( buffer - > length > ACPI_IPMI_MAX_MSG_LENGTH ) {
2013-09-13 09:14:21 +04:00
dev_WARN_ONCE ( tx_msg - > device - > dev , true ,
2013-09-13 09:13:30 +04:00
" Unexpected request (msg len %d). \n " ,
buffer - > length ) ;
return - EINVAL ;
}
2010-12-08 05:10:18 +03:00
msg - > data_len = buffer - > length ;
2013-09-13 09:13:30 +04:00
memcpy ( tx_msg - > data , buffer - > data , msg - > data_len ) ;
2013-09-13 09:15:00 +04:00
2010-12-08 05:10:18 +03:00
/*
* now the default type is SYSTEM_INTERFACE and channel type is BMC .
* If the netfn is APP_REQUEST and the cmd is SEND_MESSAGE ,
* the addr type should be changed to IPMB . Then we will have to parse
* the IPMI request message buffer to get the IPMB address .
* If so , please fix me .
*/
tx_msg - > addr . addr_type = IPMI_SYSTEM_INTERFACE_ADDR_TYPE ;
tx_msg - > addr . channel = IPMI_BMC_CHANNEL ;
tx_msg - > addr . data [ 0 ] = 0 ;
/* Get the msgid */
device = tx_msg - > device ;
2013-09-13 09:15:00 +04:00
2013-09-13 09:13:23 +04:00
spin_lock_irqsave ( & device - > tx_msg_lock , flags ) ;
2010-12-08 05:10:18 +03:00
device - > curr_msgid + + ;
tx_msg - > tx_msgid = device - > curr_msgid ;
2013-09-13 09:13:23 +04:00
spin_unlock_irqrestore ( & device - > tx_msg_lock , flags ) ;
2013-09-13 09:15:00 +04:00
2013-09-13 09:13:30 +04:00
return 0 ;
2010-12-08 05:10:18 +03:00
}
static void acpi_format_ipmi_response ( struct acpi_ipmi_msg * msg ,
2013-09-13 09:15:00 +04:00
acpi_integer * value )
2010-12-08 05:10:18 +03:00
{
struct acpi_ipmi_buffer * buffer ;
/*
* value is also used as output parameter . It represents the response
* IPMI message returned by IPMI command .
*/
buffer = ( struct acpi_ipmi_buffer * ) value ;
2013-09-13 09:15:00 +04:00
2010-12-08 05:10:18 +03:00
/*
2013-09-13 09:13:47 +04:00
* If the flag of msg_done is not set , it means that the IPMI command is
* not executed correctly .
2010-12-08 05:10:18 +03:00
*/
2013-09-13 09:13:47 +04:00
buffer - > status = msg - > msg_done ;
if ( msg - > msg_done ! = ACPI_IPMI_OK )
2010-12-08 05:10:18 +03:00
return ;
2013-09-13 09:15:00 +04:00
2010-12-08 05:10:18 +03:00
/*
* If the IPMI response message is obtained correctly , the status code
* will be ACPI_IPMI_OK
*/
buffer - > length = msg - > rx_len ;
2013-09-13 09:13:30 +04:00
memcpy ( buffer - > data , msg - > data , msg - > rx_len ) ;
2010-12-08 05:10:18 +03:00
}
static void ipmi_flush_tx_msg ( struct acpi_ipmi_device * ipmi )
{
2013-09-13 09:14:11 +04:00
struct acpi_ipmi_msg * tx_msg ;
2013-09-13 09:13:39 +04:00
unsigned long flags ;
2010-12-08 05:10:18 +03:00
2013-09-13 09:13:54 +04:00
/*
* NOTE : On - going ipmi_recv_msg
* ipmi_msg_handler ( ) may still be invoked by ipmi_si after
* flushing . But it is safe to do a fast flushing on module_exit ( )
* without waiting for all ipmi_recv_msg ( s ) to complete from
* ipmi_msg_handler ( ) as it is ensured by ipmi_si that all
* ipmi_recv_msg ( s ) are freed after invoking ipmi_destroy_user ( ) .
*/
2013-09-13 09:13:39 +04:00
spin_lock_irqsave ( & ipmi - > tx_msg_lock , flags ) ;
2013-09-13 09:14:11 +04:00
while ( ! list_empty ( & ipmi - > tx_msg_list ) ) {
tx_msg = list_first_entry ( & ipmi - > tx_msg_list ,
struct acpi_ipmi_msg ,
head ) ;
list_del ( & tx_msg - > head ) ;
spin_unlock_irqrestore ( & ipmi - > tx_msg_lock , flags ) ;
2010-12-08 05:10:18 +03:00
/* wake up the sleep thread on the Tx msg */
complete ( & tx_msg - > tx_complete ) ;
2013-09-13 09:14:11 +04:00
acpi_ipmi_msg_put ( tx_msg ) ;
spin_lock_irqsave ( & ipmi - > tx_msg_lock , flags ) ;
}
spin_unlock_irqrestore ( & ipmi - > tx_msg_lock , flags ) ;
}
static void ipmi_cancel_tx_msg ( struct acpi_ipmi_device * ipmi ,
struct acpi_ipmi_msg * msg )
{
2022-03-24 10:04:41 +03:00
struct acpi_ipmi_msg * tx_msg = NULL , * iter , * temp ;
2013-09-13 09:14:11 +04:00
unsigned long flags ;
spin_lock_irqsave ( & ipmi - > tx_msg_lock , flags ) ;
2022-03-24 10:04:41 +03:00
list_for_each_entry_safe ( iter , temp , & ipmi - > tx_msg_list , head ) {
if ( msg = = iter ) {
tx_msg = iter ;
list_del ( & iter - > head ) ;
2013-09-13 09:14:11 +04:00
break ;
}
2010-12-08 05:10:18 +03:00
}
2013-09-13 09:13:39 +04:00
spin_unlock_irqrestore ( & ipmi - > tx_msg_lock , flags ) ;
2013-09-13 09:14:11 +04:00
2022-03-24 10:04:41 +03:00
if ( tx_msg )
2013-09-13 09:14:11 +04:00
acpi_ipmi_msg_put ( tx_msg ) ;
2010-12-08 05:10:18 +03:00
}
static void ipmi_msg_handler ( struct ipmi_recv_msg * msg , void * user_msg_data )
{
struct acpi_ipmi_device * ipmi_device = user_msg_data ;
2022-03-24 10:04:41 +03:00
struct acpi_ipmi_msg * tx_msg = NULL , * iter , * temp ;
2013-09-13 09:14:21 +04:00
struct device * dev = ipmi_device - > dev ;
2013-09-13 09:13:23 +04:00
unsigned long flags ;
2010-12-08 05:10:18 +03:00
if ( msg - > user ! = ipmi_device - > user_interface ) {
2013-09-13 09:15:00 +04:00
dev_warn ( dev ,
" Unexpected response is returned. returned user %p, expected user %p \n " ,
msg - > user , ipmi_device - > user_interface ) ;
2013-09-13 09:13:30 +04:00
goto out_msg ;
2010-12-08 05:10:18 +03:00
}
2013-09-13 09:15:00 +04:00
2013-09-13 09:13:23 +04:00
spin_lock_irqsave ( & ipmi_device - > tx_msg_lock , flags ) ;
2022-03-24 10:04:41 +03:00
list_for_each_entry_safe ( iter , temp , & ipmi_device - > tx_msg_list , head ) {
if ( msg - > msgid = = iter - > tx_msgid ) {
tx_msg = iter ;
list_del ( & iter - > head ) ;
2010-12-08 05:10:18 +03:00
break ;
}
}
2013-09-13 09:14:11 +04:00
spin_unlock_irqrestore ( & ipmi_device - > tx_msg_lock , flags ) ;
2010-12-08 05:10:18 +03:00
2022-03-24 10:04:41 +03:00
if ( ! tx_msg ) {
2013-09-13 09:15:00 +04:00
dev_warn ( dev ,
" Unexpected response (msg id %ld) is returned. \n " ,
msg - > msgid ) ;
2013-09-13 09:14:11 +04:00
goto out_msg ;
2010-12-08 05:10:18 +03:00
}
2013-09-13 09:13:30 +04:00
/* copy the response data to Rx_data buffer */
if ( msg - > msg . data_len > ACPI_IPMI_MAX_MSG_LENGTH ) {
2013-09-13 09:14:21 +04:00
dev_WARN_ONCE ( dev , true ,
2013-09-13 09:13:30 +04:00
" Unexpected response (msg len %d). \n " ,
msg - > msg . data_len ) ;
2013-09-13 09:13:47 +04:00
goto out_comp ;
2010-12-08 05:10:18 +03:00
}
2013-09-13 09:15:00 +04:00
2013-09-13 09:13:47 +04:00
/* response msg is an error msg */
msg - > recv_type = IPMI_RESPONSE_RECV_TYPE ;
if ( msg - > recv_type = = IPMI_RESPONSE_RECV_TYPE & &
msg - > msg . data_len = = 1 ) {
if ( msg - > msg . data [ 0 ] = = IPMI_TIMEOUT_COMPLETION_CODE ) {
2017-03-23 18:32:29 +03:00
dev_dbg_once ( dev , " Unexpected response (timeout). \n " ) ;
2013-09-13 09:13:47 +04:00
tx_msg - > msg_done = ACPI_IPMI_TIMEOUT ;
}
goto out_comp ;
}
2013-09-13 09:15:00 +04:00
2013-09-13 09:13:47 +04:00
tx_msg - > rx_len = msg - > msg . data_len ;
memcpy ( tx_msg - > data , msg - > msg . data , tx_msg - > rx_len ) ;
tx_msg - > msg_done = ACPI_IPMI_OK ;
2013-09-13 09:15:00 +04:00
2013-09-13 09:13:47 +04:00
out_comp :
2010-12-08 05:10:18 +03:00
complete ( & tx_msg - > tx_complete ) ;
2013-09-13 09:14:11 +04:00
acpi_ipmi_msg_put ( tx_msg ) ;
2013-09-13 09:13:30 +04:00
out_msg :
2010-12-08 05:10:18 +03:00
ipmi_free_recv_msg ( msg ) ;
2013-09-13 09:15:00 +04:00
}
2010-12-08 05:10:18 +03:00
static void ipmi_register_bmc ( int iface , struct device * dev )
{
struct acpi_ipmi_device * ipmi_device , * temp ;
int err ;
struct ipmi_smi_info smi_data ;
acpi_handle handle ;
err = ipmi_get_smi_info ( iface , & smi_data ) ;
if ( err )
return ;
2013-09-13 09:13:54 +04:00
if ( smi_data . addr_src ! = SI_ACPI )
goto err_ref ;
2010-12-08 05:10:18 +03:00
handle = smi_data . addr_info . acpi_info . acpi_handle ;
2013-09-13 09:13:54 +04:00
if ( ! handle )
goto err_ref ;
2013-09-13 09:14:21 +04:00
ipmi_device = ipmi_dev_alloc ( iface , smi_data . dev , handle ) ;
2013-09-13 09:13:54 +04:00
if ( ! ipmi_device ) {
2013-09-13 09:14:21 +04:00
dev_warn ( smi_data . dev , " Can't create IPMI user interface \n " ) ;
2013-09-13 09:13:54 +04:00
goto err_ref ;
}
2010-12-08 05:10:18 +03:00
mutex_lock ( & driver_data . ipmi_lock ) ;
list_for_each_entry ( temp , & driver_data . ipmi_devices , head ) {
/*
* if the corresponding ACPI handle is already added
* to the device list , don ' t add it again .
*/
if ( temp - > handle = = handle )
2013-09-13 09:13:54 +04:00
goto err_lock ;
2010-12-08 05:10:18 +03:00
}
ACPI / IPMI: Use global IPMI operation region handler
It is found on a real machine, in its ACPI namespace, the IPMI
OperationRegions (in the ACPI000D - ACPI power meter) are not defined under
the IPMI system interface device (the IPI0001 with KCS type returned from
_IFT control method):
Device (PMI0)
{
Name (_HID, "ACPI000D") // _HID: Hardware ID
OperationRegion (SYSI, IPMI, 0x0600, 0x0100)
Field (SYSI, BufferAcc, Lock, Preserve)
{
AccessAs (BufferAcc, 0x01),
Offset (0x58),
SCMD, 8,
GCMD, 8
}
OperationRegion (POWR, IPMI, 0x3000, 0x0100)
Field (POWR, BufferAcc, Lock, Preserve)
{
AccessAs (BufferAcc, 0x01),
Offset (0xB3),
GPMM, 8
}
}
Device (PCI0)
{
Device (ISA)
{
Device (NIPM)
{
Name (_HID, EisaId ("IPI0001")) // _HID: Hardware ID
Method (_IFT, 0, NotSerialized) // _IFT: IPMI Interface Type
{
Return (0x01)
}
}
}
}
Current ACPI_IPMI code registers IPMI operation region handler on a
per-device basis, so for the above namespace the IPMI operation region
handler is registered only under the scope of \_SB.PCI0.ISA.NIPM. Thus
when an IPMI operation region field of \PMI0 is accessed, there are errors
reported on such platform:
ACPI Error: No handlers for Region [IPMI]
ACPI Error: Region IPMI(7) has no handler
The solution is to install an IPMI operation region handler from root node
so that every object that defines IPMI OperationRegion can get an address
space handler registered.
When an IPMI operation region field is accessed, the Network Function
(0x06 for SYSI and 0x30 for POWR) and the Command (SCMD, GCMD, GPMM) are
passed to the operation region handler, there is no system interface
specified by the BIOS. The patch tries to select one system interface by
monitoring the system interface notification. IPMI messages passed from
the ACPI codes are sent to this selected global IPMI system interface.
The ACPI_IPMI will always select the first registered IPMI interface
with an ACPI handle (i.e., defined in the ACPI namespace). It's hard to
determine the selection when there are multiple IPMI system interfaces
defined in the ACPI namespace. According to the IPMI specification:
A BMC device may make available multiple system interfaces, but only one
management controller is allowed to be 'active' BMC that provides BMC
functionality for the system (in case of a 'partitioned' system, there
can be only one active BMC per partition). Only the system interface(s)
for the active BMC allowed to respond to the 'Get Device Id' command.
According to the ipmi_si desigin:
The ipmi_si registeration notifications can only happen after a
successful "Get Device ID" command.
Thus it should be OK for non-partitioned systems to do such selection.
However, we do not have much knowledge on 'partitioned' systems.
References: https://bugzilla.kernel.org/show_bug.cgi?id=46741
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Reviewed-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-09-13 09:14:02 +04:00
if ( ! driver_data . selected_smi )
driver_data . selected_smi = ipmi_device ;
2013-09-13 09:13:54 +04:00
list_add_tail ( & ipmi_device - > head , & driver_data . ipmi_devices ) ;
2010-12-08 05:10:18 +03:00
mutex_unlock ( & driver_data . ipmi_lock ) ;
2013-09-13 09:15:00 +04:00
2013-09-13 09:13:54 +04:00
put_device ( smi_data . dev ) ;
2010-12-08 05:10:18 +03:00
return ;
2013-09-13 09:13:54 +04:00
err_lock :
2010-12-08 05:10:18 +03:00
mutex_unlock ( & driver_data . ipmi_lock ) ;
2013-09-13 09:13:54 +04:00
ipmi_dev_release ( ipmi_device ) ;
err_ref :
2010-12-08 05:10:18 +03:00
put_device ( smi_data . dev ) ;
}
static void ipmi_bmc_gone ( int iface )
{
2022-03-24 10:04:41 +03:00
struct acpi_ipmi_device * ipmi_device = NULL , * iter , * temp ;
2010-12-08 05:10:18 +03:00
mutex_lock ( & driver_data . ipmi_lock ) ;
2022-03-24 10:04:41 +03:00
list_for_each_entry_safe ( iter , temp ,
2013-09-13 09:15:00 +04:00
& driver_data . ipmi_devices , head ) {
2022-03-24 10:04:41 +03:00
if ( iter - > ipmi_ifnum ! = iface ) {
ipmi_device = iter ;
__ipmi_dev_kill ( iter ) ;
2013-09-13 09:13:54 +04:00
break ;
}
2010-12-08 05:10:18 +03:00
}
ACPI / IPMI: Use global IPMI operation region handler
It is found on a real machine, in its ACPI namespace, the IPMI
OperationRegions (in the ACPI000D - ACPI power meter) are not defined under
the IPMI system interface device (the IPI0001 with KCS type returned from
_IFT control method):
Device (PMI0)
{
Name (_HID, "ACPI000D") // _HID: Hardware ID
OperationRegion (SYSI, IPMI, 0x0600, 0x0100)
Field (SYSI, BufferAcc, Lock, Preserve)
{
AccessAs (BufferAcc, 0x01),
Offset (0x58),
SCMD, 8,
GCMD, 8
}
OperationRegion (POWR, IPMI, 0x3000, 0x0100)
Field (POWR, BufferAcc, Lock, Preserve)
{
AccessAs (BufferAcc, 0x01),
Offset (0xB3),
GPMM, 8
}
}
Device (PCI0)
{
Device (ISA)
{
Device (NIPM)
{
Name (_HID, EisaId ("IPI0001")) // _HID: Hardware ID
Method (_IFT, 0, NotSerialized) // _IFT: IPMI Interface Type
{
Return (0x01)
}
}
}
}
Current ACPI_IPMI code registers IPMI operation region handler on a
per-device basis, so for the above namespace the IPMI operation region
handler is registered only under the scope of \_SB.PCI0.ISA.NIPM. Thus
when an IPMI operation region field of \PMI0 is accessed, there are errors
reported on such platform:
ACPI Error: No handlers for Region [IPMI]
ACPI Error: Region IPMI(7) has no handler
The solution is to install an IPMI operation region handler from root node
so that every object that defines IPMI OperationRegion can get an address
space handler registered.
When an IPMI operation region field is accessed, the Network Function
(0x06 for SYSI and 0x30 for POWR) and the Command (SCMD, GCMD, GPMM) are
passed to the operation region handler, there is no system interface
specified by the BIOS. The patch tries to select one system interface by
monitoring the system interface notification. IPMI messages passed from
the ACPI codes are sent to this selected global IPMI system interface.
The ACPI_IPMI will always select the first registered IPMI interface
with an ACPI handle (i.e., defined in the ACPI namespace). It's hard to
determine the selection when there are multiple IPMI system interfaces
defined in the ACPI namespace. According to the IPMI specification:
A BMC device may make available multiple system interfaces, but only one
management controller is allowed to be 'active' BMC that provides BMC
functionality for the system (in case of a 'partitioned' system, there
can be only one active BMC per partition). Only the system interface(s)
for the active BMC allowed to respond to the 'Get Device Id' command.
According to the ipmi_si desigin:
The ipmi_si registeration notifications can only happen after a
successful "Get Device ID" command.
Thus it should be OK for non-partitioned systems to do such selection.
However, we do not have much knowledge on 'partitioned' systems.
References: https://bugzilla.kernel.org/show_bug.cgi?id=46741
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Reviewed-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-09-13 09:14:02 +04:00
if ( ! driver_data . selected_smi )
driver_data . selected_smi = list_first_entry_or_null (
& driver_data . ipmi_devices ,
struct acpi_ipmi_device , head ) ;
2010-12-08 05:10:18 +03:00
mutex_unlock ( & driver_data . ipmi_lock ) ;
2013-09-13 09:15:00 +04:00
2022-03-24 10:04:41 +03:00
if ( ipmi_device ) {
2013-09-13 09:13:54 +04:00
ipmi_flush_tx_msg ( ipmi_device ) ;
acpi_ipmi_dev_put ( ipmi_device ) ;
}
2010-12-08 05:10:18 +03:00
}
2013-09-13 09:15:00 +04:00
2010-12-08 05:10:18 +03:00
/*
* This is the IPMI opregion space handler .
* @ function : indicates the read / write . In fact as the IPMI message is driven
* by command , only write is meaningful .
* @ address : This contains the netfn / command of IPMI request message .
* @ bits : not used .
* @ value : it is an in / out parameter . It points to the IPMI message buffer .
* Before the IPMI message is sent , it represents the actual request
* IPMI message . After the IPMI message is finished , it represents
* the response IPMI message returned by IPMI command .
* @ handler_context : IPMI device context .
*/
static acpi_status
acpi_ipmi_space_handler ( u32 function , acpi_physical_address address ,
2013-09-13 09:15:00 +04:00
u32 bits , acpi_integer * value ,
void * handler_context , void * region_context )
2010-12-08 05:10:18 +03:00
{
struct acpi_ipmi_msg * tx_msg ;
2013-09-13 09:13:54 +04:00
struct acpi_ipmi_device * ipmi_device ;
2013-09-13 09:13:47 +04:00
int err ;
2010-12-08 05:10:18 +03:00
acpi_status status ;
2013-09-13 09:13:23 +04:00
unsigned long flags ;
2013-09-13 09:15:00 +04:00
2010-12-08 05:10:18 +03:00
/*
* IPMI opregion message .
* IPMI message is firstly written to the BMC and system software
* can get the respsonse . So it is unmeaningful for the read access
* of IPMI opregion .
*/
if ( ( function & ACPI_IO_MASK ) = = ACPI_READ )
return AE_TYPE ;
2013-09-13 09:14:11 +04:00
tx_msg = ipmi_msg_alloc ( ) ;
if ( ! tx_msg )
2010-12-08 05:10:18 +03:00
return AE_NOT_EXIST ;
2013-09-13 09:14:11 +04:00
ipmi_device = tx_msg - > device ;
2010-12-08 05:10:18 +03:00
2013-09-13 09:13:30 +04:00
if ( acpi_format_ipmi_request ( tx_msg , address , value ) ! = 0 ) {
2013-09-13 09:14:11 +04:00
ipmi_msg_release ( tx_msg ) ;
return AE_TYPE ;
2013-09-13 09:13:30 +04:00
}
2013-09-13 09:15:00 +04:00
2013-09-13 09:14:11 +04:00
acpi_ipmi_msg_get ( tx_msg ) ;
2013-09-13 09:13:54 +04:00
mutex_lock ( & driver_data . ipmi_lock ) ;
/* Do not add a tx_msg that can not be flushed. */
if ( ipmi_device - > dead ) {
mutex_unlock ( & driver_data . ipmi_lock ) ;
2013-09-13 09:14:11 +04:00
ipmi_msg_release ( tx_msg ) ;
return AE_NOT_EXIST ;
2013-09-13 09:13:54 +04:00
}
2013-09-13 09:13:23 +04:00
spin_lock_irqsave ( & ipmi_device - > tx_msg_lock , flags ) ;
2010-12-08 05:10:18 +03:00
list_add_tail ( & tx_msg - > head , & ipmi_device - > tx_msg_list ) ;
2013-09-13 09:13:23 +04:00
spin_unlock_irqrestore ( & ipmi_device - > tx_msg_lock , flags ) ;
2013-09-13 09:13:54 +04:00
mutex_unlock ( & driver_data . ipmi_lock ) ;
2013-09-13 09:15:00 +04:00
2010-12-08 05:10:18 +03:00
err = ipmi_request_settime ( ipmi_device - > user_interface ,
2013-09-13 09:15:00 +04:00
& tx_msg - > addr ,
tx_msg - > tx_msgid ,
& tx_msg - > tx_message ,
NULL , 0 , 0 , IPMI_TIMEOUT ) ;
2010-12-08 05:10:18 +03:00
if ( err ) {
status = AE_ERROR ;
2013-09-13 09:14:11 +04:00
goto out_msg ;
2010-12-08 05:10:18 +03:00
}
2013-09-13 09:13:47 +04:00
wait_for_completion ( & tx_msg - > tx_complete ) ;
2013-09-13 09:15:00 +04:00
2013-09-13 09:13:47 +04:00
acpi_format_ipmi_response ( tx_msg , value ) ;
2010-12-08 05:10:18 +03:00
status = AE_OK ;
2013-09-13 09:13:30 +04:00
out_msg :
2013-09-13 09:14:11 +04:00
ipmi_cancel_tx_msg ( ipmi_device , tx_msg ) ;
acpi_ipmi_msg_put ( tx_msg ) ;
2010-12-08 05:10:18 +03:00
return status ;
}
static int __init acpi_ipmi_init ( void )
{
2013-09-13 09:14:31 +04:00
int result ;
ACPI / IPMI: Use global IPMI operation region handler
It is found on a real machine, in its ACPI namespace, the IPMI
OperationRegions (in the ACPI000D - ACPI power meter) are not defined under
the IPMI system interface device (the IPI0001 with KCS type returned from
_IFT control method):
Device (PMI0)
{
Name (_HID, "ACPI000D") // _HID: Hardware ID
OperationRegion (SYSI, IPMI, 0x0600, 0x0100)
Field (SYSI, BufferAcc, Lock, Preserve)
{
AccessAs (BufferAcc, 0x01),
Offset (0x58),
SCMD, 8,
GCMD, 8
}
OperationRegion (POWR, IPMI, 0x3000, 0x0100)
Field (POWR, BufferAcc, Lock, Preserve)
{
AccessAs (BufferAcc, 0x01),
Offset (0xB3),
GPMM, 8
}
}
Device (PCI0)
{
Device (ISA)
{
Device (NIPM)
{
Name (_HID, EisaId ("IPI0001")) // _HID: Hardware ID
Method (_IFT, 0, NotSerialized) // _IFT: IPMI Interface Type
{
Return (0x01)
}
}
}
}
Current ACPI_IPMI code registers IPMI operation region handler on a
per-device basis, so for the above namespace the IPMI operation region
handler is registered only under the scope of \_SB.PCI0.ISA.NIPM. Thus
when an IPMI operation region field of \PMI0 is accessed, there are errors
reported on such platform:
ACPI Error: No handlers for Region [IPMI]
ACPI Error: Region IPMI(7) has no handler
The solution is to install an IPMI operation region handler from root node
so that every object that defines IPMI OperationRegion can get an address
space handler registered.
When an IPMI operation region field is accessed, the Network Function
(0x06 for SYSI and 0x30 for POWR) and the Command (SCMD, GCMD, GPMM) are
passed to the operation region handler, there is no system interface
specified by the BIOS. The patch tries to select one system interface by
monitoring the system interface notification. IPMI messages passed from
the ACPI codes are sent to this selected global IPMI system interface.
The ACPI_IPMI will always select the first registered IPMI interface
with an ACPI handle (i.e., defined in the ACPI namespace). It's hard to
determine the selection when there are multiple IPMI system interfaces
defined in the ACPI namespace. According to the IPMI specification:
A BMC device may make available multiple system interfaces, but only one
management controller is allowed to be 'active' BMC that provides BMC
functionality for the system (in case of a 'partitioned' system, there
can be only one active BMC per partition). Only the system interface(s)
for the active BMC allowed to respond to the 'Get Device Id' command.
According to the ipmi_si desigin:
The ipmi_si registeration notifications can only happen after a
successful "Get Device ID" command.
Thus it should be OK for non-partitioned systems to do such selection.
However, we do not have much knowledge on 'partitioned' systems.
References: https://bugzilla.kernel.org/show_bug.cgi?id=46741
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Reviewed-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-09-13 09:14:02 +04:00
acpi_status status ;
2010-12-08 05:10:18 +03:00
if ( acpi_disabled )
2013-09-13 09:14:31 +04:00
return 0 ;
2010-12-08 05:10:18 +03:00
ACPI / IPMI: Use global IPMI operation region handler
It is found on a real machine, in its ACPI namespace, the IPMI
OperationRegions (in the ACPI000D - ACPI power meter) are not defined under
the IPMI system interface device (the IPI0001 with KCS type returned from
_IFT control method):
Device (PMI0)
{
Name (_HID, "ACPI000D") // _HID: Hardware ID
OperationRegion (SYSI, IPMI, 0x0600, 0x0100)
Field (SYSI, BufferAcc, Lock, Preserve)
{
AccessAs (BufferAcc, 0x01),
Offset (0x58),
SCMD, 8,
GCMD, 8
}
OperationRegion (POWR, IPMI, 0x3000, 0x0100)
Field (POWR, BufferAcc, Lock, Preserve)
{
AccessAs (BufferAcc, 0x01),
Offset (0xB3),
GPMM, 8
}
}
Device (PCI0)
{
Device (ISA)
{
Device (NIPM)
{
Name (_HID, EisaId ("IPI0001")) // _HID: Hardware ID
Method (_IFT, 0, NotSerialized) // _IFT: IPMI Interface Type
{
Return (0x01)
}
}
}
}
Current ACPI_IPMI code registers IPMI operation region handler on a
per-device basis, so for the above namespace the IPMI operation region
handler is registered only under the scope of \_SB.PCI0.ISA.NIPM. Thus
when an IPMI operation region field of \PMI0 is accessed, there are errors
reported on such platform:
ACPI Error: No handlers for Region [IPMI]
ACPI Error: Region IPMI(7) has no handler
The solution is to install an IPMI operation region handler from root node
so that every object that defines IPMI OperationRegion can get an address
space handler registered.
When an IPMI operation region field is accessed, the Network Function
(0x06 for SYSI and 0x30 for POWR) and the Command (SCMD, GCMD, GPMM) are
passed to the operation region handler, there is no system interface
specified by the BIOS. The patch tries to select one system interface by
monitoring the system interface notification. IPMI messages passed from
the ACPI codes are sent to this selected global IPMI system interface.
The ACPI_IPMI will always select the first registered IPMI interface
with an ACPI handle (i.e., defined in the ACPI namespace). It's hard to
determine the selection when there are multiple IPMI system interfaces
defined in the ACPI namespace. According to the IPMI specification:
A BMC device may make available multiple system interfaces, but only one
management controller is allowed to be 'active' BMC that provides BMC
functionality for the system (in case of a 'partitioned' system, there
can be only one active BMC per partition). Only the system interface(s)
for the active BMC allowed to respond to the 'Get Device Id' command.
According to the ipmi_si desigin:
The ipmi_si registeration notifications can only happen after a
successful "Get Device ID" command.
Thus it should be OK for non-partitioned systems to do such selection.
However, we do not have much knowledge on 'partitioned' systems.
References: https://bugzilla.kernel.org/show_bug.cgi?id=46741
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Reviewed-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-09-13 09:14:02 +04:00
status = acpi_install_address_space_handler ( ACPI_ROOT_OBJECT ,
2013-09-13 09:15:00 +04:00
ACPI_ADR_SPACE_IPMI ,
& acpi_ipmi_space_handler ,
NULL , NULL ) ;
ACPI / IPMI: Use global IPMI operation region handler
It is found on a real machine, in its ACPI namespace, the IPMI
OperationRegions (in the ACPI000D - ACPI power meter) are not defined under
the IPMI system interface device (the IPI0001 with KCS type returned from
_IFT control method):
Device (PMI0)
{
Name (_HID, "ACPI000D") // _HID: Hardware ID
OperationRegion (SYSI, IPMI, 0x0600, 0x0100)
Field (SYSI, BufferAcc, Lock, Preserve)
{
AccessAs (BufferAcc, 0x01),
Offset (0x58),
SCMD, 8,
GCMD, 8
}
OperationRegion (POWR, IPMI, 0x3000, 0x0100)
Field (POWR, BufferAcc, Lock, Preserve)
{
AccessAs (BufferAcc, 0x01),
Offset (0xB3),
GPMM, 8
}
}
Device (PCI0)
{
Device (ISA)
{
Device (NIPM)
{
Name (_HID, EisaId ("IPI0001")) // _HID: Hardware ID
Method (_IFT, 0, NotSerialized) // _IFT: IPMI Interface Type
{
Return (0x01)
}
}
}
}
Current ACPI_IPMI code registers IPMI operation region handler on a
per-device basis, so for the above namespace the IPMI operation region
handler is registered only under the scope of \_SB.PCI0.ISA.NIPM. Thus
when an IPMI operation region field of \PMI0 is accessed, there are errors
reported on such platform:
ACPI Error: No handlers for Region [IPMI]
ACPI Error: Region IPMI(7) has no handler
The solution is to install an IPMI operation region handler from root node
so that every object that defines IPMI OperationRegion can get an address
space handler registered.
When an IPMI operation region field is accessed, the Network Function
(0x06 for SYSI and 0x30 for POWR) and the Command (SCMD, GCMD, GPMM) are
passed to the operation region handler, there is no system interface
specified by the BIOS. The patch tries to select one system interface by
monitoring the system interface notification. IPMI messages passed from
the ACPI codes are sent to this selected global IPMI system interface.
The ACPI_IPMI will always select the first registered IPMI interface
with an ACPI handle (i.e., defined in the ACPI namespace). It's hard to
determine the selection when there are multiple IPMI system interfaces
defined in the ACPI namespace. According to the IPMI specification:
A BMC device may make available multiple system interfaces, but only one
management controller is allowed to be 'active' BMC that provides BMC
functionality for the system (in case of a 'partitioned' system, there
can be only one active BMC per partition). Only the system interface(s)
for the active BMC allowed to respond to the 'Get Device Id' command.
According to the ipmi_si desigin:
The ipmi_si registeration notifications can only happen after a
successful "Get Device ID" command.
Thus it should be OK for non-partitioned systems to do such selection.
However, we do not have much knowledge on 'partitioned' systems.
References: https://bugzilla.kernel.org/show_bug.cgi?id=46741
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Reviewed-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-09-13 09:14:02 +04:00
if ( ACPI_FAILURE ( status ) ) {
pr_warn ( " Can't register IPMI opregion space handle \n " ) ;
return - EINVAL ;
}
2021-05-24 11:35:08 +03:00
2010-12-08 05:10:18 +03:00
result = ipmi_smi_watcher_register ( & driver_data . bmc_events ) ;
2021-05-24 11:35:08 +03:00
if ( result ) {
acpi_remove_address_space_handler ( ACPI_ROOT_OBJECT ,
ACPI_ADR_SPACE_IPMI ,
& acpi_ipmi_space_handler ) ;
ACPI / IPMI: Use global IPMI operation region handler
It is found on a real machine, in its ACPI namespace, the IPMI
OperationRegions (in the ACPI000D - ACPI power meter) are not defined under
the IPMI system interface device (the IPI0001 with KCS type returned from
_IFT control method):
Device (PMI0)
{
Name (_HID, "ACPI000D") // _HID: Hardware ID
OperationRegion (SYSI, IPMI, 0x0600, 0x0100)
Field (SYSI, BufferAcc, Lock, Preserve)
{
AccessAs (BufferAcc, 0x01),
Offset (0x58),
SCMD, 8,
GCMD, 8
}
OperationRegion (POWR, IPMI, 0x3000, 0x0100)
Field (POWR, BufferAcc, Lock, Preserve)
{
AccessAs (BufferAcc, 0x01),
Offset (0xB3),
GPMM, 8
}
}
Device (PCI0)
{
Device (ISA)
{
Device (NIPM)
{
Name (_HID, EisaId ("IPI0001")) // _HID: Hardware ID
Method (_IFT, 0, NotSerialized) // _IFT: IPMI Interface Type
{
Return (0x01)
}
}
}
}
Current ACPI_IPMI code registers IPMI operation region handler on a
per-device basis, so for the above namespace the IPMI operation region
handler is registered only under the scope of \_SB.PCI0.ISA.NIPM. Thus
when an IPMI operation region field of \PMI0 is accessed, there are errors
reported on such platform:
ACPI Error: No handlers for Region [IPMI]
ACPI Error: Region IPMI(7) has no handler
The solution is to install an IPMI operation region handler from root node
so that every object that defines IPMI OperationRegion can get an address
space handler registered.
When an IPMI operation region field is accessed, the Network Function
(0x06 for SYSI and 0x30 for POWR) and the Command (SCMD, GCMD, GPMM) are
passed to the operation region handler, there is no system interface
specified by the BIOS. The patch tries to select one system interface by
monitoring the system interface notification. IPMI messages passed from
the ACPI codes are sent to this selected global IPMI system interface.
The ACPI_IPMI will always select the first registered IPMI interface
with an ACPI handle (i.e., defined in the ACPI namespace). It's hard to
determine the selection when there are multiple IPMI system interfaces
defined in the ACPI namespace. According to the IPMI specification:
A BMC device may make available multiple system interfaces, but only one
management controller is allowed to be 'active' BMC that provides BMC
functionality for the system (in case of a 'partitioned' system, there
can be only one active BMC per partition). Only the system interface(s)
for the active BMC allowed to respond to the 'Get Device Id' command.
According to the ipmi_si desigin:
The ipmi_si registeration notifications can only happen after a
successful "Get Device ID" command.
Thus it should be OK for non-partitioned systems to do such selection.
However, we do not have much knowledge on 'partitioned' systems.
References: https://bugzilla.kernel.org/show_bug.cgi?id=46741
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Reviewed-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-09-13 09:14:02 +04:00
pr_err ( " Can't register IPMI system interface watcher \n " ) ;
2021-05-24 11:35:08 +03:00
}
2010-12-08 05:10:18 +03:00
return result ;
}
static void __exit acpi_ipmi_exit ( void )
{
2013-09-13 09:13:54 +04:00
struct acpi_ipmi_device * ipmi_device ;
2010-12-08 05:10:18 +03:00
if ( acpi_disabled )
return ;
ipmi_smi_watcher_unregister ( & driver_data . bmc_events ) ;
/*
* When one smi_watcher is unregistered , it is only deleted
* from the smi_watcher list . But the smi_gone callback function
* is not called . So explicitly uninstall the ACPI IPMI oregion
* handler and free it .
*/
mutex_lock ( & driver_data . ipmi_lock ) ;
2013-09-13 09:13:54 +04:00
while ( ! list_empty ( & driver_data . ipmi_devices ) ) {
ipmi_device = list_first_entry ( & driver_data . ipmi_devices ,
struct acpi_ipmi_device ,
head ) ;
__ipmi_dev_kill ( ipmi_device ) ;
mutex_unlock ( & driver_data . ipmi_lock ) ;
ipmi_flush_tx_msg ( ipmi_device ) ;
acpi_ipmi_dev_put ( ipmi_device ) ;
mutex_lock ( & driver_data . ipmi_lock ) ;
2010-12-08 05:10:18 +03:00
}
mutex_unlock ( & driver_data . ipmi_lock ) ;
ACPI / IPMI: Use global IPMI operation region handler
It is found on a real machine, in its ACPI namespace, the IPMI
OperationRegions (in the ACPI000D - ACPI power meter) are not defined under
the IPMI system interface device (the IPI0001 with KCS type returned from
_IFT control method):
Device (PMI0)
{
Name (_HID, "ACPI000D") // _HID: Hardware ID
OperationRegion (SYSI, IPMI, 0x0600, 0x0100)
Field (SYSI, BufferAcc, Lock, Preserve)
{
AccessAs (BufferAcc, 0x01),
Offset (0x58),
SCMD, 8,
GCMD, 8
}
OperationRegion (POWR, IPMI, 0x3000, 0x0100)
Field (POWR, BufferAcc, Lock, Preserve)
{
AccessAs (BufferAcc, 0x01),
Offset (0xB3),
GPMM, 8
}
}
Device (PCI0)
{
Device (ISA)
{
Device (NIPM)
{
Name (_HID, EisaId ("IPI0001")) // _HID: Hardware ID
Method (_IFT, 0, NotSerialized) // _IFT: IPMI Interface Type
{
Return (0x01)
}
}
}
}
Current ACPI_IPMI code registers IPMI operation region handler on a
per-device basis, so for the above namespace the IPMI operation region
handler is registered only under the scope of \_SB.PCI0.ISA.NIPM. Thus
when an IPMI operation region field of \PMI0 is accessed, there are errors
reported on such platform:
ACPI Error: No handlers for Region [IPMI]
ACPI Error: Region IPMI(7) has no handler
The solution is to install an IPMI operation region handler from root node
so that every object that defines IPMI OperationRegion can get an address
space handler registered.
When an IPMI operation region field is accessed, the Network Function
(0x06 for SYSI and 0x30 for POWR) and the Command (SCMD, GCMD, GPMM) are
passed to the operation region handler, there is no system interface
specified by the BIOS. The patch tries to select one system interface by
monitoring the system interface notification. IPMI messages passed from
the ACPI codes are sent to this selected global IPMI system interface.
The ACPI_IPMI will always select the first registered IPMI interface
with an ACPI handle (i.e., defined in the ACPI namespace). It's hard to
determine the selection when there are multiple IPMI system interfaces
defined in the ACPI namespace. According to the IPMI specification:
A BMC device may make available multiple system interfaces, but only one
management controller is allowed to be 'active' BMC that provides BMC
functionality for the system (in case of a 'partitioned' system, there
can be only one active BMC per partition). Only the system interface(s)
for the active BMC allowed to respond to the 'Get Device Id' command.
According to the ipmi_si desigin:
The ipmi_si registeration notifications can only happen after a
successful "Get Device ID" command.
Thus it should be OK for non-partitioned systems to do such selection.
However, we do not have much knowledge on 'partitioned' systems.
References: https://bugzilla.kernel.org/show_bug.cgi?id=46741
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Reviewed-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-09-13 09:14:02 +04:00
acpi_remove_address_space_handler ( ACPI_ROOT_OBJECT ,
2013-09-13 09:15:00 +04:00
ACPI_ADR_SPACE_IPMI ,
& acpi_ipmi_space_handler ) ;
2010-12-08 05:10:18 +03:00
}
module_init ( acpi_ipmi_init ) ;
module_exit ( acpi_ipmi_exit ) ;