Documentation/driver-api/ipmi.rst

84 option.  You can also enable these dynamically by setting the module
85 parameter named "panic_op" in the ipmi_msghandler module to "event"
94 code.  These chunks (by module name) are:
288 Once you are done, call ipmi_destroy_user() to get rid of the user.
312 read() to get them, you must call the IPMICTL_RECEIVE_MSG with the
313 ipmi_recv_t structure to actually get the message.  Remember that you
318 If the message cannot fit into the data you provide, you will get an
320 queue.  If you want to get it and have it truncate the message, us
395 You can specify up to four interfaces on the module load line and
396 control some module parameters::
448 the data to get to the actual IPMI data.
478 It works the same as the module parameters of the same names.
484 is in progress.  The force_kipmid module parameter will all the user to
507 The "op"s are::
531 at module load time (for a module) with::
583 These are the same options as on the module command line.
588 patches and driver modifications.  You can get those at the openipmi
613 Loading the module will not result in the driver automatcially
667 watchdog timer interface.  It has three module parameters that can be
723 The options are the same as the module parameter options.
746 'Generate a panic event to all BMCs on a panic' option, you will get
749 also get a bunch of OEM events holding the panic string.
793 is in the ipmi_poweroff module.  When the system requests a powerdown,
797 There is a module parameter named "poweroff_powercycle" that may