summaryrefslogtreecommitdiff
path: root/arch/powerpc/platforms/powernv/opal-sensor.c
AgeCommit message (Collapse)Author
2016-06-29powerpc/opal: Add inline function to get rc from an ASYNC_COMP opal_msgSuraj Jitindar Singh
An opal_msg of type OPAL_MSG_ASYNC_COMP contains the return code in the params[1] struct member. However this isn't intuitive or obvious when reading the code and requires that a user look at the skiboot documentation or opal-api.h to verify this. Add an inline function to get the return code from an opal_msg and update call sites accordingly. Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2015-05-22powerpc/powernv: Reorder OPAL subsystem initialisationAlistair Popple
Most of the OPAL subsystems are always compiled in for PowerNV and many of them need to be initialised before or after other OPAL subsystems. Rather than trying to control this ordering through machine initcalls it is clearer and easier to control initialisation order with explicit calls in opal_init. Signed-off-by: Alistair Popple <alistair@popple.id.au> Cc: Mahesh Jagannath Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2015-03-31powerpc/powernv: handle OPAL_SUCCESS return in opal_sensor_readCédric Le Goater
Currently, when a sensor value is read, the kernel calls OPAL, which in turn builds a message for the FSP, and waits for a message back. The new device tree for OPAL sensors [1] adds new sensors that can be read synchronously (core temperatures for instance) and that don't need to wait for a response. This patch modifies the opal call to accept an OPAL_SUCCESS return value and cover the case above. [1] https://lists.ozlabs.org/pipermail/skiboot/2015-March/000639.html Signed-off-by: Cédric Le Goater <clg@fr.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2015-03-31powerpc/powernv: convert codes returned by OPAL callsCédric Le Goater
OPAL has its own list of return codes. The patch provides a translation of such codes in errnos for the opal_sensor_read call, and possibly others if needed. Signed-off-by: Cédric Le Goater <clg@fr.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2014-11-30hwmon: (ibmpowernv) Use platform 'id_table' to probe the deviceNeelesh Gupta
The current driver probe() function assumes the sensor device to be always present and gets executed every time if the driver is loaded, but the appropriate hardware could not be present. So, move the platform device creation as part of platform init code and use the 'id_table' to check if the device is present or not. Signed-off-by: Neelesh Gupta <neelegup@linux.vnet.ibm.com> Acked-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2014-04-09powerpc/powernv: Fix endian issues with sensor codeAnton Blanchard
One OPAL call and one device tree property needed byte swapping. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2014-04-07powerpc/powernv: Fix endian issues with OPAL async codeAnton Blanchard
OPAL defines opal_msg as a big endian struct so we have to byte swap it on little endian builds. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2014-03-24powerpc/powernv: Enable fetching of platform sensor dataNeelesh Gupta
This patch enables fetching of various platform sensor data through OPAL and expects a sensor handle from the driver to pass to OPAL. Signed-off-by: Neelesh Gupta <neelegup@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>