Currently the label says "Core" but lists the thread numbers. This
ends up looking like this:
# cat /sys/class/hwmon/hwmon0/temp[1-4]_label
Core 0-7
Core 8-15
Core 16-23
Core 24-31
This is misleading as it looks like it's cores 0-7 when it's actually
threads 0-7.
This changes the print to just give the core number, so the output now
looks like this:
# cat /sys/class/hwmon/hwmon0/temp[1-4]_label
Core 0
Core 8
Core 16
Core 24
Signed-off-by: Michael Neuling <mikey@neuling.org>
Acked-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Fix module autoload for IBM and Open power platforms.
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Fix
drivers/hwmon/ibmpowernv.c: In function 'get_logical_cpu':
drivers/hwmon/ibmpowernv.c:121:3:
error: implicit declaration of function 'get_hard_smp_processor_id'
seen for some configurations, possibly if SMP is not configured.
Fixes: 3df2f59f0a ("hwmon: (ibmpowernv) pretty print labels")
Cc: Cédric Le Goater <clg@fr.ibm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The new OPAL device tree adds a few properties which can be used to add
extra information on the sensor label.
In the case of a cpu core sensor, the firmware exposes the physical
identifier of the core in the "ibm,pir" property. The driver
translates this identifier in a linux cpu number and prints out a
range corresponding to the hardware threads of the core (as they
share the same sensor).
The numbering gives a hint on the localization of the core in the
system (which socket, which chip).
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Currently, sensors are only identified by their type and index.
The new OPAL device tree can expose extra properties to identify
some sensors by their name or location. This patch adds the creation
of a new hwmon *_label attribute when such properties are detected.
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The new OPAL device tree for sensors has a different layout and uses new
property names, for the type and for the handler used to capture the
sensor data.
This patch modifies the ibmpowernv driver to support such a tree in a
way preserving compatibility with older OPAL firmwares.
This is achieved by changing the error path of the routine parsing
an OPAL node name. The node is simply considered being from the new
device tree layout and fallback values are used.
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
This should shorten a bit the code necessary to create a hmwon attribute.
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The current OPAL firmware exposes the different sensors of an IBM Power
system using node names such as :
sensors/amb-temp#1-data
sensors/amb-temp#1-thrs
cooling-fan#1-data
cooling-fan#1-faulted
cooling-fan#1-thrs
cooling-fan#2-data
...
The ibmpowernv driver, when loaded, parses these names to extract the
sensor index and the sensor attribute name. Unfortunately, this scheme
makes it difficult to add sensors with a different layout (specially of
the same type, like temperature) as the sensor index calculated in OPAL
is directly used in the hwmon sysfs interface.
What this patch does is add a independent hwmon index for each sensor.
The increment of the hwmon index (temp, fan, power, etc.) is kept per
sensor type in the sensor_group table. The sensor_data table is used
to store the association of the hwmon and OPAL indexes, as we need to
have the same hwmon index for different attributes of a same sensor.
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
It simplifies the creation of the hwmon attributes and will help when
support for a new device tree layout is added. The patch also changes
the name of the routine to parse_opal_node_name().
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
It simplifies the create_hwmon_attr_name() routine and it clearly isolates
the conversion done between the OPAL node names and hwmon attributes names.
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
It will help in adding different compatible properties, coming from a
new device tree layout for example.
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Ambient is too restrictive as there can be other temperature channels :
core, memory, etc.
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Here's the set of driver core patches for 3.19-rc1.
They are dominated by the removal of the .owner field in platform
drivers. They touch a lot of files, but they are "simple" changes, just
removing a line in a structure.
Other than that, a few minor driver core and debugfs changes. There are
some ath9k patches coming in through this tree that have been acked by
the wireless maintainers as they relied on the debugfs changes.
Everything has been in linux-next for a while.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEABECAAYFAlSOD20ACgkQMUfUDdst+ylLPACg2QrW1oHhdTMT9WI8jihlHVRM
53kAoLeteByQ3iVwWurwwseRPiWa8+MI
=OVRS
-----END PGP SIGNATURE-----
Merge tag 'driver-core-3.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Pull driver core update from Greg KH:
"Here's the set of driver core patches for 3.19-rc1.
They are dominated by the removal of the .owner field in platform
drivers. They touch a lot of files, but they are "simple" changes,
just removing a line in a structure.
Other than that, a few minor driver core and debugfs changes. There
are some ath9k patches coming in through this tree that have been
acked by the wireless maintainers as they relied on the debugfs
changes.
Everything has been in linux-next for a while"
* tag 'driver-core-3.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (324 commits)
Revert "ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries"
fs: debugfs: add forward declaration for struct device type
firmware class: Deletion of an unnecessary check before the function call "vunmap"
firmware loader: fix hung task warning dump
devcoredump: provide a one-way disable function
device: Add dev_<level>_once variants
ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries
ath: use seq_file api for ath9k debugfs files
debugfs: add helper function to create device related seq_file
drivers/base: cacheinfo: remove noisy error boot message
Revert "core: platform: add warning if driver has no owner"
drivers: base: support cpu cache information interface to userspace via sysfs
drivers: base: add cpu_device_create to support per-cpu devices
topology: replace custom attribute macros with standard DEVICE_ATTR*
cpumask: factor out show_cpumap into separate helper function
driver core: Fix unbalanced device reference in drivers_probe
driver core: fix race with userland in device_add()
sysfs/kernfs: make read requests on pre-alloc files use the buffer.
sysfs/kernfs: allow attributes to request write buffer be pre-allocated.
fs: sysfs: return EGBIG on write if offset is larger than file size
...
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>
Because we build kernels with drivers built in for many platforms, it's
normal for the ibmpowernv driver to be loaded on systems that don't have
the appropriate hardware.
Currently the driver spams the log with:
ibmpowernv ibmpowernv.0: Opal node 'sensors' not found
ibmpowernv: Platfrom driver probe failed
But there is no error, this machine is not a powernv and doesn't have
the hardware. So change the sensors message to dev_dbg(), and only print
an error about the probe failing if it's not ENODEV.
Also fix the spelling of "Platfrom" and print the actual error value.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Simplify the code a bit and also improve readability.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Tested-by: Neelesh Gupta <neelegup@linux.vnet.ibm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
This reverts commit 0de7f8a917.
This driver wasn't merged via the proper maintainers (my fault ... ooops !)
and has serious issues so let's take it out for now and have a new better
one be merged the right way
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
This patch adds basic kernel enablement for reading power values, fan
speed rpm and temperature values on powernv platforms which will
be exported to user space through sysfs interface.
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
Signed-off-by: Neelesh Gupta <neelegup@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
