| Message ID | 1452069259-16917-1-git-send-email-clg@fr.ibm.com |
|---|---|
| State | Accepted |
| Headers | show |
Cédric Le Goater <clg@fr.ibm.com> writes: > The IPMI Specs document (29.7 Event Data Field Formats) describes the > Event Data 1 field for discrete sensor as follow : > > [7:6] - 00b = unspecified byte 2 > 01b = previous state and/or severity in byte 2 > 10b = OEM code in byte 2 > 11b = sensor-specific event extension code in byte 2 > [5:4] - 00b = unspecified byte 3 > 01b = reserved > 10b = OEM code in byte 3 > 11b = sensor-specific event extension code in byte 3 > [3:0] - Offset from Event/Reading Code for discrete event state > > The "System Firmware Progress" offset in the "System Firmware > Progress" Sensor being 0x02, we should be using 0xc2 in the event data > 1 field. > > Signed-off-by: Cédric Le Goater <clg@fr.ibm.com> > --- > Tested on a palmetto and under qemu > > hw/ipmi/ipmi-sensor.c | 1 + > 1 file changed, 1 insertion(+) Well spotted! Merged to master as of 67212eb3ca9fed121432b814b5e58fb8d2cfebae Should this also go to stable?
On 03/07/2016 08:19 AM, Stewart Smith wrote: > Cédric Le Goater <clg@fr.ibm.com> writes: >> The IPMI Specs document (29.7 Event Data Field Formats) describes the >> Event Data 1 field for discrete sensor as follow : >> >> [7:6] - 00b = unspecified byte 2 >> 01b = previous state and/or severity in byte 2 >> 10b = OEM code in byte 2 >> 11b = sensor-specific event extension code in byte 2 >> [5:4] - 00b = unspecified byte 3 >> 01b = reserved >> 10b = OEM code in byte 3 >> 11b = sensor-specific event extension code in byte 3 >> [3:0] - Offset from Event/Reading Code for discrete event state >> >> The "System Firmware Progress" offset in the "System Firmware >> Progress" Sensor being 0x02, we should be using 0xc2 in the event data >> 1 field. >> >> Signed-off-by: Cédric Le Goater <clg@fr.ibm.com> >> --- >> Tested on a palmetto and under qemu >> >> hw/ipmi/ipmi-sensor.c | 1 + >> 1 file changed, 1 insertion(+) > > Well spotted! Merged to master as of > 67212eb3ca9fed121432b814b5e58fb8d2cfebae > > Should this also go to stable? Well, the current systems [ palmetto - firestone ] on which I have given this fix a try behave fine. But, they also did before the fix, probably because the implementation of the IPMI 'set sensor reading' command is not strict enough. I would not unstabilize stable with it. Let's just keep the fix in the dev branch for newer IPMI implementation. C.
Index: skiboot.git/hw/ipmi/ipmi-sensor.c =================================================================== --- skiboot.git.orig/hw/ipmi/ipmi-sensor.c +++ skiboot.git/hw/ipmi/ipmi-sensor.c @@ -92,6 +92,7 @@ int ipmi_set_fw_progress_sensor(uint8_t request.sensor_number = fw_sensor_num; request.operation = 0xa0; /* Set event data bytes, assertion bits */ request.assertion_mask[0] = 0x04; /* Firmware progress offset */ + request.event_data[0] = 0xc2; request.event_data[1] = state; prlog(PR_INFO, "IPMI: setting fw progress sensor %02x to %02x\n",
The IPMI Specs document (29.7 Event Data Field Formats) describes the Event Data 1 field for discrete sensor as follow : [7:6] - 00b = unspecified byte 2 01b = previous state and/or severity in byte 2 10b = OEM code in byte 2 11b = sensor-specific event extension code in byte 2 [5:4] - 00b = unspecified byte 3 01b = reserved 10b = OEM code in byte 3 11b = sensor-specific event extension code in byte 3 [3:0] - Offset from Event/Reading Code for discrete event state The "System Firmware Progress" offset in the "System Firmware Progress" Sensor being 0x02, we should be using 0xc2 in the event data 1 field. Signed-off-by: Cédric Le Goater <clg@fr.ibm.com> --- Tested on a palmetto and under qemu hw/ipmi/ipmi-sensor.c | 1 + 1 file changed, 1 insertion(+)