* Re: [PATCH 2/3] iommu/fsl: Fix the device domain attach condition.
From: Joerg Roedel @ 2014-07-04 10:54 UTC (permalink / raw)
To: Varun Sethi; +Cc: alex.williamson, iommu, linuxppc-dev, linux-kernel
In-Reply-To: <1403618237-26248-3-git-send-email-Varun.Sethi@freescale.com>
Hmm,
On Tue, Jun 24, 2014 at 07:27:16PM +0530, Varun Sethi wrote:
> - old_domain_info = find_domain(dev);
> + old_domain_info = dev->archdata.iommu_domain;
> if (old_domain_info && old_domain_info->domain != dma_domain) {
> spin_unlock_irqrestore(&device_domain_lock, flags);
> detach_device(dev, old_domain_info->domain);
Wouldn't this set dev->archdata.iommu_domain to NULL anyway, so that ...
> @@ -399,7 +394,7 @@ static void attach_device(struct fsl_dma_domain *dma_domain, int liodn, struct d
> * the info for the first LIODN as all
> * LIODNs share the same domain
> */
> - if (!old_domain_info)
> + if (!dev->archdata.iommu_domain)
> dev->archdata.iommu_domain = info;
We already know that it _must_ be NULL here?
> spin_unlock_irqrestore(&device_domain_lock, flags);
This would shrink down the patch to:
diff --git a/drivers/iommu/fsl_pamu_domain.c b/drivers/iommu/fsl_pamu_domain.c
index 93072ba..d21b554 100644
--- a/drivers/iommu/fsl_pamu_domain.c
+++ b/drivers/iommu/fsl_pamu_domain.c
@@ -399,8 +399,7 @@ static void attach_device(struct fsl_dma_domain *dma_domain, int liodn, struct d
* the info for the first LIODN as all
* LIODNs share the same domain
*/
- if (!old_domain_info)
- dev->archdata.iommu_domain = info;
+ dev->archdata.iommu_domain = info;
spin_unlock_irqrestore(&device_domain_lock, flags);
}
^ permalink raw reply related
* [PATCH v4] powerpc/powernv: hwmon driver for power, fan rpm, voltage and temperature
From: Neelesh Gupta @ 2014-07-04 11:02 UTC (permalink / raw)
To: linuxppc-dev, linux, jdelvare, lm-sensors; +Cc: sbhat
This patch adds basic kernel support for reading power values, fan
speed rpm, voltage and temperature data on powernv platforms which will
be exported to user space through sysfs interface.
Test results:
-------------
[root@tul163p1 ~]# sensors
ibmpowernv-isa-0000
Adapter: ISA adapter
fan1: 5567 RPM (min = 0 RPM)
fan2: 5232 RPM (min = 0 RPM)
fan3: 5532 RPM (min = 0 RPM)
fan4: 4945 RPM (min = 0 RPM)
fan5: 0 RPM (min = 0 RPM)
fan6: 0 RPM (min = 0 RPM)
fan7: 7392 RPM (min = 0 RPM)
fan8: 7936 RPM (min = 0 RPM)
temp1: +39.0°C (high = +0.0°C)
power1: 191.00 W
[root@tul163p1 ~]# ls /sys/devices/platform/
alarmtimer ibmpowernv.0 power rtc-generic serial8250 uevent
[root@tul163p1 ~]# ls /sys/devices/platform/ibmpowernv.0/hwmon/hwmon0/
device fan2_min fan4_min fan6_min fan8_min power
fan1_fault fan3_fault fan5_fault fan7_fault in1_fault power1_input
fan1_input fan3_input fan5_input fan7_input in2_fault subsystem
fan1_min fan3_min fan5_min fan7_min in3_fault temp1_input
fan2_fault fan4_fault fan6_fault fan8_fault in4_fault temp1_max
fan2_input fan4_input fan6_input fan8_input name uevent
[root@tul163p1 ~]#
[root@tul163p1 ~]# ls /sys/class/hwmon/hwmon0/
device fan2_min fan4_min fan6_min fan8_min power
fan1_fault fan3_fault fan5_fault fan7_fault in1_fault power1_input
fan1_input fan3_input fan5_input fan7_input in2_fault subsystem
fan1_min fan3_min fan5_min fan7_min in3_fault temp1_input
fan2_fault fan4_fault fan6_fault fan8_fault in4_fault temp1_max
fan2_input fan4_input fan6_input fan8_input name uevent
[root@tul163p1 ~]#
Signed-off-by: Neelesh Gupta <neelegup@linux.vnet.ibm.com>
---
Changes in v4
=============
- Replaced pr_err() with dev_err() for loggin print messages.
- Using kstrtou32() function for converting string to u32 instead of sscanf().
Changes in v3
=============
- Fixed an endianness bug leading the driver to break on LE.
- Fixed a bug that when one of the 'attribute_group' not populated, following
groups attributes were dropped.
- Rewrite the get_sensor_index_attr() function to handle all the error scenarios
like 'sscanf' etc.
- Fixed all the errors/warnings related to coding style/whitespace.
- Added 'Documentation' files.
- Addressed remaining review comments on V2.
Changes in v2
=============
- Generic use of devm_* functions in hwmon like using devm_kzalloc() for dynamic
memory request, avoiding the need to explicit free of memory.
Adding 'struct attribute_group' as member of platform data structure to be
populated and then passed to devm_hwmon_device_register_with_groups().
Note: Having an array of pointers of 'attribute_group' and each group
corresponds to 'enum sensors' type. Not completely sure, if it's ideal or
could have just one group populated with attributes of sensor types?
- 'ibmpowernv' is not hot-pluggable device so moving 'platform_driver' callback
function (probe) as part of __init code.
- Fixed issues related to coding style.
- Other general comments in v1.
.../devicetree/bindings/hwmon/ibmpowernv.txt | 27 +
Documentation/hwmon/ibmpowernv | 41 ++
drivers/hwmon/Kconfig | 11 +
drivers/hwmon/Makefile | 1
drivers/hwmon/ibmpowernv.c | 362 ++++++++++++++++++++
5 files changed, 442 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/ibmpowernv.txt
create mode 100644 Documentation/hwmon/ibmpowernv
create mode 100644 drivers/hwmon/ibmpowernv.c
diff --git a/Documentation/devicetree/bindings/hwmon/ibmpowernv.txt b/Documentation/devicetree/bindings/hwmon/ibmpowernv.txt
new file mode 100644
index 0000000..e3bd1eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/ibmpowernv.txt
@@ -0,0 +1,27 @@
+IBM POWERNV platform sensors
+----------------------------
+
+Required node properties:
+- compatible: must be one of
+ "ibm,opal-sensor-cooling-fan"
+ "ibm,opal-sensor-amb-temp"
+ "ibm,opal-sensor-power-supply"
+ "ibm,opal-sensor-power"
+- sensor-id: an opaque id provided by the firmware to the kernel, identifies a
+ given sensor and its attribute data
+
+Example sensors node:
+
+cooling-fan#8-data {
+ sensor-id = <0x7052107>;
+ phandle = <0x10000028>;
+ linux,phandle = <0x10000028>;
+ compatible = "ibm,opal-sensor-cooling-fan";
+};
+
+amb-temp#1-thrs {
+ sensor-id = <0x5096000>;
+ phandle = <0x10000017>;
+ linux,phandle = <0x10000017>;
+ compatible = "ibm,opal-sensor-amb-temp";
+};
diff --git a/Documentation/hwmon/ibmpowernv b/Documentation/hwmon/ibmpowernv
new file mode 100644
index 0000000..644245a
--- /dev/null
+++ b/Documentation/hwmon/ibmpowernv
@@ -0,0 +1,41 @@
+Kernel Driver IBMPOWENV
+=======================
+
+Supported systems:
+ * Any recent IBM P servers based on POWERNV platform
+
+Author: Neelesh Gupta
+
+Description
+-----------
+
+This driver implements reading the platform sensors data like temperature/fan/
+voltage/power for 'POWERNV' platform.
+
+The driver uses the platform device infrastructure. It probes the device tree
+for sensor devices during the __init phase and registers them with the 'hwmon'.
+'hwmon' populates the 'sysfs' tree having attribute files, each for a given
+sensor type and its attribute data.
+
+All the nodes in the DT appear under "/ibm,opal/sensors" and each valid node in
+the DT maps to an attribute file in 'sysfs'. The node exports unique 'sensor-id'
+which the driver uses to make an OPAL call to the firmware.
+
+Usage notes
+-----------
+The driver is built statically with the kernel by enabling the config
+CONFIG_SENSORS_IBMPOWERNV. It can also be built as module 'ibmpowernv'.
+
+Sysfs attributes
+----------------
+
+fanX_input Measured RPM value.
+fanX_min Threshold RPM for alert generation.
+fanX_fault 0: No fail condition
+ 1: Failing fan
+tempX_input Measured ambient temperature.
+tempX_max Threshold ambient temperature for alert generation.
+inX_input Measured power supply voltage
+inX_fault 0: No fail condition.
+ 1: Failing power supply.
+power1_input System power consumption (microWatt)
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 02d3d85..29c3fcb 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -554,6 +554,17 @@ config SENSORS_IBMPEX
This driver can also be built as a module. If so, the module
will be called ibmpex.
+config SENSORS_IBMPOWERNV
+ tristate "IBM POWERNV platform sensors"
+ depends on PPC_POWERNV
+ default y
+ help
+ If you say yes here you get support for the temperature/fan/power
+ sensors on your PowerNV platform.
+
+ This driver can also be built as a module. If so, the module
+ will be called ibmpowernv.
+
config SENSORS_IIO_HWMON
tristate "Hwmon driver that uses channels specified via iio maps"
depends on IIO
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 3dc0f02..fc4ed26 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -71,6 +71,7 @@ obj-$(CONFIG_SENSORS_ULTRA45) += ultra45_env.o
obj-$(CONFIG_SENSORS_I5K_AMB) += i5k_amb.o
obj-$(CONFIG_SENSORS_IBMAEM) += ibmaem.o
obj-$(CONFIG_SENSORS_IBMPEX) += ibmpex.o
+obj-$(CONFIG_SENSORS_IBMPOWERNV)+= ibmpowernv.o
obj-$(CONFIG_SENSORS_IIO_HWMON) += iio_hwmon.o
obj-$(CONFIG_SENSORS_INA209) += ina209.o
obj-$(CONFIG_SENSORS_INA2XX) += ina2xx.o
diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
new file mode 100644
index 0000000..44dcd99
--- /dev/null
+++ b/drivers/hwmon/ibmpowernv.c
@@ -0,0 +1,362 @@
+/*
+ * IBM PowerNV platform sensors for temperature/fan/voltage/power
+ * Copyright (C) 2014 IBM
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.
+ */
+
+#define DRVNAME "ibmpowernv"
+#define pr_fmt(fmt) DRVNAME ": " fmt
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/hwmon.h>
+#include <linux/hwmon-sysfs.h>
+#include <linux/of.h>
+#include <linux/slab.h>
+
+#include <linux/platform_device.h>
+#include <asm/opal.h>
+#include <linux/err.h>
+
+#define MAX_ATTR_LEN 32
+
+/* Sensor suffix name from DT */
+#define DT_FAULT_ATTR_SUFFIX "faulted"
+#define DT_DATA_ATTR_SUFFIX "data"
+#define DT_THRESHOLD_ATTR_SUFFIX "thrs"
+
+/*
+ * Enumerates all the types of sensors in the POWERNV platform and does index
+ * into 'struct sensor_group'
+ */
+enum sensors {
+ FAN,
+ AMBIENT_TEMP,
+ POWER_SUPPLY,
+ POWER_INPUT,
+ MAX_SENSOR_TYPE,
+};
+
+static struct sensor_group {
+ const char *name;
+ const char *compatible;
+ struct attribute_group group;
+ u32 attr_count;
+} sensor_groups[] = {
+ {"fan", "ibm,opal-sensor-cooling-fan"},
+ {"temp", "ibm,opal-sensor-amb-temp"},
+ {"in", "ibm,opal-sensor-power-supply"},
+ {"power", "ibm,opal-sensor-power"}
+};
+
+struct sensor_data {
+ u32 id; /* An opaque id of the firmware for each sensor */
+ enum sensors type;
+ char name[MAX_ATTR_LEN];
+ struct device_attribute dev_attr;
+};
+
+struct platform_data {
+ const struct attribute_group *attr_groups[MAX_SENSOR_TYPE + 1];
+ u32 sensors_count; /* Total count of sensors from each group */
+};
+
+/* Platform device representing all the ibmpowernv sensors */
+static struct platform_device *pdevice;
+
+static ssize_t show_sensor(struct device *dev, struct device_attribute *devattr,
+ char *buf)
+{
+ struct sensor_data *sdata = container_of(devattr, struct sensor_data,
+ dev_attr);
+ ssize_t ret;
+ u32 x;
+
+ ret = opal_get_sensor_data(sdata->id, &x);
+ if (ret)
+ return ret;
+
+ /* Convert temperature to milli-degrees */
+ if (sdata->type == AMBIENT_TEMP)
+ x *= 1000;
+ /* Convert power to micro-watts */
+ else if (sdata->type == POWER_INPUT)
+ x *= 1000000;
+
+ return sprintf(buf, "%u\n", x);
+}
+
+static int __init get_sensor_index_attr(const char *name, u32 *index,
+ char *attr)
+{
+ char *hash_pos = strchr(name, '#');
+ char buf[8] = { 0 };
+ char *dash_pos;
+ u32 copy_len;
+
+ if (!hash_pos)
+ return -EINVAL;
+
+ dash_pos = strchr(hash_pos, '-');
+ if (!dash_pos)
+ return -EINVAL;
+
+ copy_len = dash_pos - hash_pos - 1;
+ if (copy_len >= sizeof(buf))
+ return -EINVAL;
+
+ strncpy(buf, hash_pos + 1, copy_len);
+
+ if (kstrtou32(buf, 10, index))
+ return -EINVAL;
+
+ strncpy(attr, dash_pos + 1, MAX_ATTR_LEN);
+
+ return 0;
+}
+
+/*
+ * This function translates the DT node name into the 'hwmon' attribute name.
+ * IBMPOWERNV device node appear like cooling-fan#2-data, amb-temp#1-thrs etc.
+ * which need to be mapped as fan2_input, temp1_max respectively before
+ * populating them inside hwmon device class.
+ */
+static int __init create_hwmon_attr_name(struct device *dev, enum sensors type,
+ const char *node_name,
+ char *hwmon_attr_name)
+{
+ char attr_suffix[MAX_ATTR_LEN];
+ char *attr_name;
+ u32 index;
+ int err;
+
+ err = get_sensor_index_attr(node_name, &index, attr_suffix);
+ if (err) {
+ dev_err(dev, "Sensor device node name '%s' is invalid\n",
+ node_name);
+ return err;
+ }
+
+ if (!strcmp(attr_suffix, DT_FAULT_ATTR_SUFFIX)) {
+ attr_name = "fault";
+ } else if (!strcmp(attr_suffix, DT_DATA_ATTR_SUFFIX)) {
+ attr_name = "input";
+ } else if (!strcmp(attr_suffix, DT_THRESHOLD_ATTR_SUFFIX)) {
+ if (type == AMBIENT_TEMP)
+ attr_name = "max";
+ else if (type == FAN)
+ attr_name = "min";
+ else
+ return -ENOENT;
+ } else {
+ return -ENOENT;
+ }
+
+ snprintf(hwmon_attr_name, MAX_ATTR_LEN, "%s%d_%s",
+ sensor_groups[type].name, index, attr_name);
+ return 0;
+}
+
+static int __init populate_attr_groups(struct platform_device *pdev)
+{
+ struct platform_data *pdata = platform_get_drvdata(pdev);
+ const struct attribute_group **pgroups = pdata->attr_groups;
+ struct device_node *opal, *np;
+ enum sensors type;
+
+ opal = of_find_node_by_path("/ibm,opal/sensors");
+ if (!opal) {
+ dev_err(&pdev->dev, "Opal node 'sensors' not found\n");
+ return -ENODEV;
+ }
+
+ for_each_child_of_node(opal, np) {
+ if (np->name == NULL)
+ continue;
+
+ for (type = 0; type < MAX_SENSOR_TYPE; type++)
+ if (of_device_is_compatible(np,
+ sensor_groups[type].compatible)) {
+ sensor_groups[type].attr_count++;
+ break;
+ }
+ }
+
+ of_node_put(opal);
+
+ for (type = 0; type < MAX_SENSOR_TYPE; type++) {
+ sensor_groups[type].group.attrs = devm_kzalloc(&pdev->dev,
+ sizeof(struct attribute *) *
+ (sensor_groups[type].attr_count + 1),
+ GFP_KERNEL);
+ if (!sensor_groups[type].group.attrs)
+ return -ENOMEM;
+
+ pgroups[type] = &sensor_groups[type].group;
+ pdata->sensors_count += sensor_groups[type].attr_count;
+ sensor_groups[type].attr_count = 0;
+ }
+
+ return 0;
+}
+
+/*
+ * Iterate through the device tree for each child of 'sensors' node, create
+ * a sysfs attribute file, the file is named by translating the DT node name
+ * to the name required by the higher 'hwmon' driver like fan1_input, temp1_max
+ * etc..
+ */
+static int __init create_device_attrs(struct platform_device *pdev)
+{
+ struct platform_data *pdata = platform_get_drvdata(pdev);
+ const struct attribute_group **pgroups = pdata->attr_groups;
+ struct device_node *opal, *np;
+ struct sensor_data *sdata;
+ const __be32 *sensor_id;
+ enum sensors type;
+ u32 count = 0;
+ int err = 0;
+
+ opal = of_find_node_by_path("/ibm,opal/sensors");
+ sdata = devm_kzalloc(&pdev->dev, pdata->sensors_count * sizeof(*sdata),
+ GFP_KERNEL);
+ if (!sdata) {
+ err = -ENOMEM;
+ goto exit_put_node;
+ }
+
+ for_each_child_of_node(opal, np) {
+ if (np->name == NULL)
+ continue;
+
+ for (type = 0; type < MAX_SENSOR_TYPE; type++)
+ if (of_device_is_compatible(np,
+ sensor_groups[type].compatible))
+ break;
+
+ if (type == MAX_SENSOR_TYPE)
+ continue;
+
+ sensor_id = of_get_property(np, "sensor-id", NULL);
+ if (!sensor_id) {
+ dev_info(&pdev->dev,
+ "'sensor-id' missing in the node '%s'\n",
+ np->name);
+ continue;
+ }
+
+ sdata[count].id = be32_to_cpup(sensor_id);
+ sdata[count].type = type;
+ err = create_hwmon_attr_name(&pdev->dev, type, np->name,
+ sdata[count].name);
+ if (err)
+ goto exit_put_node;
+
+ sysfs_attr_init(&sdata[count].dev_attr.attr);
+ sdata[count].dev_attr.attr.name = sdata[count].name;
+ sdata[count].dev_attr.attr.mode = S_IRUGO;
+ sdata[count].dev_attr.show = show_sensor;
+
+ pgroups[type]->attrs[sensor_groups[type].attr_count++] =
+ &sdata[count++].dev_attr.attr;
+ }
+
+exit_put_node:
+ of_node_put(opal);
+ return err;
+}
+
+static int __init ibmpowernv_probe(struct platform_device *pdev)
+{
+ struct platform_data *pdata;
+ struct device *hwmon_dev;
+ int err;
+
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, pdata);
+ pdata->sensors_count = 0;
+ err = populate_attr_groups(pdev);
+ if (err)
+ return err;
+
+ /* Create sysfs attribute data for each sensor found in the DT */
+ err = create_device_attrs(pdev);
+ if (err)
+ return err;
+
+ /* Finally, register with hwmon */
+ hwmon_dev = devm_hwmon_device_register_with_groups(&pdev->dev, DRVNAME,
+ pdata,
+ pdata->attr_groups);
+
+ return PTR_ERR_OR_ZERO(hwmon_dev);
+}
+
+static struct platform_driver ibmpowernv_driver = {
+ .driver = {
+ .owner = THIS_MODULE,
+ .name = DRVNAME,
+ },
+};
+
+static int __init ibmpowernv_init(void)
+{
+ int err;
+
+ pdevice = platform_device_alloc(DRVNAME, 0);
+ if (!pdevice) {
+ pr_err("Device allocation failed\n");
+ err = -ENOMEM;
+ goto exit;
+ }
+
+ err = platform_device_add(pdevice);
+ if (err) {
+ pr_err("Device addition failed (%d)\n", err);
+ goto exit_device_put;
+ }
+
+ err = platform_driver_probe(&ibmpowernv_driver, ibmpowernv_probe);
+ if (err) {
+ pr_err("Platfrom driver probe failed\n");
+ goto exit_device_del;
+ }
+
+ return 0;
+
+exit_device_del:
+ platform_device_del(pdevice);
+exit_device_put:
+ platform_device_put(pdevice);
+exit:
+ return err;
+}
+
+static void __exit ibmpowernv_exit(void)
+{
+ platform_driver_unregister(&ibmpowernv_driver);
+ platform_device_unregister(pdevice);
+}
+
+MODULE_AUTHOR("Neelesh Gupta <neelegup@linux.vnet.ibm.com>");
+MODULE_DESCRIPTION("IBM POWERNV platform sensors");
+MODULE_LICENSE("GPL");
+
+module_init(ibmpowernv_init);
+module_exit(ibmpowernv_exit);
^ permalink raw reply related
* RE: [PATCH 1/3] iommu/fsl: Fix PAMU window size check.
From: Varun Sethi @ 2014-07-04 12:47 UTC (permalink / raw)
To: Joerg Roedel
Cc: alex.williamson@redhat.com, iommu@lists.linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <20140704104430.GD13434@8bytes.org>
> -----Original Message-----
> From: Joerg Roedel [mailto:joro@8bytes.org]
> Sent: Friday, July 04, 2014 4:15 PM
> To: Sethi Varun-B16395
> Cc: iommu@lists.linux-foundation.org; linux-kernel@vger.kernel.org;
> linuxppc-dev@lists.ozlabs.org; alex.williamson@redhat.com
> Subject: Re: [PATCH 1/3] iommu/fsl: Fix PAMU window size check.
>=20
> On Tue, Jun 24, 2014 at 07:27:15PM +0530, Varun Sethi wrote:
> > /* window size is 2^(WSE+1) bytes */
> > - return __ffs(addrspace_size) - 1;
> > + return fls64(addrspace_size) - 2;
>=20
> This looks bogus, why do you replace ffs (find-first-bit) by fls (find-
> last-bit)?
>=20
Address space size is always a power of 2. This change was required to hand=
le address sizes > 32bit width on 32 bit architectures.
-Varun
^ permalink raw reply
* RE: [PATCH 2/3] iommu/fsl: Fix the device domain attach condition.
From: Varun Sethi @ 2014-07-04 12:50 UTC (permalink / raw)
To: Joerg Roedel
Cc: alex.williamson@redhat.com, iommu@lists.linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <20140704105430.GE13434@8bytes.org>
> -----Original Message-----
> From: Joerg Roedel [mailto:joro@8bytes.org]
> Sent: Friday, July 04, 2014 4:25 PM
> To: Sethi Varun-B16395
> Cc: iommu@lists.linux-foundation.org; linux-kernel@vger.kernel.org;
> linuxppc-dev@lists.ozlabs.org; alex.williamson@redhat.com
> Subject: Re: [PATCH 2/3] iommu/fsl: Fix the device domain attach
> condition.
>=20
> Hmm,
>=20
> On Tue, Jun 24, 2014 at 07:27:16PM +0530, Varun Sethi wrote:
> > - old_domain_info =3D find_domain(dev);
> > + old_domain_info =3D dev->archdata.iommu_domain;
> > if (old_domain_info && old_domain_info->domain !=3D dma_domain) {
> > spin_unlock_irqrestore(&device_domain_lock, flags);
> > detach_device(dev, old_domain_info->domain);
>=20
> Wouldn't this set dev->archdata.iommu_domain to NULL anyway, so that ...
>=20
Not for the case where device has multiple LIODNs.
> > @@ -399,7 +394,7 @@ static void attach_device(struct fsl_dma_domain
> *dma_domain, int liodn, struct d
> > * the info for the first LIODN as all
> > * LIODNs share the same domain
> > */
> > - if (!old_domain_info)
> > + if (!dev->archdata.iommu_domain)
> > dev->archdata.iommu_domain =3D info;
>=20
> We already know that it _must_ be NULL here?
>=20
That won't be true for devices having multiple LIODNs
> > spin_unlock_irqrestore(&device_domain_lock, flags);
>=20
> This would shrink down the patch to:
>=20
> diff --git a/drivers/iommu/fsl_pamu_domain.c
> b/drivers/iommu/fsl_pamu_domain.c index 93072ba..d21b554 100644
> --- a/drivers/iommu/fsl_pamu_domain.c
> +++ b/drivers/iommu/fsl_pamu_domain.c
> @@ -399,8 +399,7 @@ static void attach_device(struct fsl_dma_domain
> *dma_domain, int liodn, struct d
> * the info for the first LIODN as all
> * LIODNs share the same domain
> */
> - if (!old_domain_info)
> - dev->archdata.iommu_domain =3D info;
> + dev->archdata.iommu_domain =3D info;
For devices having multiple LIODNs, we don't want to overwrite the info.
-Varun
^ permalink raw reply
* Re: [PATCH v2 1/3] dmaengine: mpc512x: add device tree binding document
From: Mark Rutland @ 2014-07-04 17:04 UTC (permalink / raw)
To: Alexander Popov
Cc: devicetree@vger.kernel.org, Lars-Peter Clausen, Arnd Bergmann,
Vinod Koul, Gerhard Sittig, Andy Shevchenko,
dmaengine@vger.kernel.org, Dan Williams, Anatolij Gustschin,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CAF0T0X5LPRtm6_Q5i0ncpA3NTWckYUwqXgBxGn5ydPMq40VHBQ@mail.gmail.com>
Hi Alexander,
Apologies for the late reply. DT-related email is somewhat a firehose
and unfortunately I lose track of things.
On Thu, Jun 19, 2014 at 02:59:19PM +0100, Alexander Popov wrote:
> 2014-06-18 18:56 GMT+04:00 Alexander Popov <a13xp0p0v88@gmail.com>:
> > 2014-06-18 17:37 GMT+04:00 Mark Rutland <mark.rutland@arm.com>:
> >> On Wed, Jun 18, 2014 at 11:48:10AM +0100, Alexander Popov wrote:
> >>> Introduce a device tree binding document for the MPC512x DMA controller
> >>> +Optional properties:
> >>> +- #dma-cells: the length of the DMA specifier, must be <1>.
> >>> + Each channel of this DMA controller has a peripheral request line,
> >>> + the assignment is fixed in hardware. This one cell
> >>> + in dmas property of a client device represents the channel number.
> >>
> >> Surely this is required to be able to refer to DMA channels on the
> >> device?
> >
> > Excuse me, I didn't understand your question.
> > Do you inquire about the reason of making #dma-cells an optional property?
> > It's optional because device tree based lookup support is made
> > optional (part 3/3).
>
> Mark, did I answer your question?
> Should I fix anything in this patch series?
I would move it under required properties even if we happen to not use
it in certain edge cases.
Moving forwards everything should be DT-driven, so it'll be necessary.
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCH] powerpc: Disable RELOCATABLE for COMPILE_TEST with PPC64
From: Guenter Roeck @ 2014-07-04 19:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <1404153930-26568-1-git-send-email-linux@roeck-us.net>
ping ...
Guenter
On 06/30/2014 11:45 AM, Guenter Roeck wrote:
> powerpc:allmodconfig has been failing for some time with the following
> error.
>
> arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
> arch/powerpc/kernel/exceptions-64s.S:1312: Error: attempt to move .org backwards
> make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1
>
> A number of attempts to fix the problem by moving around code have been
> unsuccessful and resulted in failed builds for some configurations and
> the discovery of toolchain bugs.
>
> Fix the problem by disabling RELOCATABLE for COMPILE_TEST builds instead.
> While this is less than perfect, it avoids substantial code changes
> which would otherwise be necessary just to make COMPILE_TEST builds
> happy and might have undesired side effects.
>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> ---
> arch/powerpc/Kconfig | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index bd6dd6e..fefe7c8 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -414,7 +414,7 @@ config KEXEC
> config CRASH_DUMP
> bool "Build a kdump crash kernel"
> depends on PPC64 || 6xx || FSL_BOOKE || (44x && !SMP)
> - select RELOCATABLE if PPC64 || 44x || FSL_BOOKE
> + select RELOCATABLE if (PPC64 && !COMPILE_TEST) || 44x || FSL_BOOKE
> help
> Build a kernel suitable for use as a kdump capture kernel.
> The same kernel binary can be used as production kernel and dump
> @@ -1017,6 +1017,7 @@ endmenu
> if PPC64
> config RELOCATABLE
> bool "Build a relocatable kernel"
> + depends on !COMPILE_TEST
> select NONSTATIC_KERNEL
> help
> This builds a kernel image that is capable of running anywhere
>
^ permalink raw reply
* Re: [PATCH v2] powerpc/kvm: support to handle sw breakpoint
From: Madhavan Srinivasan @ 2014-07-04 4:34 UTC (permalink / raw)
To: Alexander Graf, benh, paulus; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <53B543C5.0@suse.de>
On Thursday 03 July 2014 05:21 PM, Alexander Graf wrote:
>
> On 01.07.14 10:41, Madhavan Srinivasan wrote:
>> This patch adds kernel side support for software breakpoint.
>> Design is that, by using an illegal instruction, we trap to hypervisor
>> via Emulation Assistance interrupt, where we check for the illegal
>> instruction
>> and accordingly we return to Host or Guest. Patch also adds support for
>> software breakpoint in PR KVM.
>>
>> Patch mandates use of "abs" instruction as sw breakpoint instruction
>> (primary opcode 31 and extended opcode 360). Based on PowerISA v2.01,
>> ABS instruction has been dropped from the architecture and treated an
>> illegal instruction.
>>
>> Changes v1->v2:
>>
>> Moved the debug instruction #def to kvm_book3s.h. This way PR_KVM
>> can also share it.
>> Added code to use KVM get one reg infrastructure to get debug opcode.
>> Updated emulate.c to include emulation of debug instruction incase
>> of PR_KVM.
>> Made changes to commit message.
>>
>> Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
>> ---
>> arch/powerpc/include/asm/kvm_book3s.h | 8 ++++++++
>> arch/powerpc/include/asm/ppc-opcode.h | 5 +++++
>> arch/powerpc/kvm/book3s.c | 3 ++-
>> arch/powerpc/kvm/book3s_hv.c | 9 +++++++++
>> arch/powerpc/kvm/book3s_pr.c | 3 +++
>> arch/powerpc/kvm/emulate.c | 10 ++++++++++
>> 6 files changed, 37 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/include/asm/kvm_book3s.h
>> b/arch/powerpc/include/asm/kvm_book3s.h
>> index f52f656..180d549 100644
>> --- a/arch/powerpc/include/asm/kvm_book3s.h
>> +++ b/arch/powerpc/include/asm/kvm_book3s.h
>> @@ -24,6 +24,14 @@
>> #include <linux/kvm_host.h>
>> #include <asm/kvm_book3s_asm.h>
>> +/*
>> + * KVMPPC_INST_BOOK3S_DEBUG is debug Instruction for supporting
>> Software Breakpoint.
>> + * Instruction mnemonic is ABS, primary opcode is 31 and extended
>> opcode is 360.
>> + * Based on PowerISA v2.01, ABS instruction has been dropped from the
>> architecture
>> + * and treated an illegal instruction.
>> + */
>> +#define KVMPPC_INST_BOOK3S_DEBUG 0x7c0002d0
>
> This will still break with LE guests.
>
I am told to try with all 0s opcode. So rewriting the patch.
>> +
>> struct kvmppc_bat {
>> u64 raw;
>> u32 bepi;
>> diff --git a/arch/powerpc/include/asm/ppc-opcode.h
>> b/arch/powerpc/include/asm/ppc-opcode.h
>> index 3132bb9..3fbb4c1 100644
>> --- a/arch/powerpc/include/asm/ppc-opcode.h
>> +++ b/arch/powerpc/include/asm/ppc-opcode.h
>> @@ -111,6 +111,11 @@
>> #define OP_31_XOP_LHBRX 790
>> #define OP_31_XOP_STHBRX 918
>> +/* KVMPPC_INST_BOOK3S_DEBUG -- Software breakpoint Instruction
>> + * Instruction mnemonic is ABS, primary opcode is 31 and extended
>> opcode is 360.
>> + */
>> +#define OP_31_XOP_ABS 360
>> +
>> #define OP_LWZ 32
>> #define OP_LD 58
>> #define OP_LWZU 33
>> diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
>> index c254c27..b40fe5d 100644
>> --- a/arch/powerpc/kvm/book3s.c
>> +++ b/arch/powerpc/kvm/book3s.c
>> @@ -789,7 +789,8 @@ int kvm_arch_vcpu_ioctl_translate(struct kvm_vcpu
>> *vcpu,
>> int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
>> struct kvm_guest_debug *dbg)
>> {
>> - return -EINVAL;
>> + vcpu->guest_debug = dbg->control;
>> + return 0;
>> }
>> void kvmppc_decrementer_func(unsigned long data)
>> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
>> index 7a12edb..402c1ec 100644
>> --- a/arch/powerpc/kvm/book3s_hv.c
>> +++ b/arch/powerpc/kvm/book3s_hv.c
>> @@ -725,8 +725,14 @@ static int kvmppc_handle_exit_hv(struct kvm_run
>> *run, struct kvm_vcpu *vcpu,
>> * we don't emulate any guest instructions at this stage.
>> */
>> case BOOK3S_INTERRUPT_H_EMUL_ASSIST:
>> + if (kvmppc_get_last_inst(vcpu) == KVMPPC_INST_BOOK3S_DEBUG ) {
>> + run->exit_reason = KVM_EXIT_DEBUG;
>> + run->debug.arch.address = kvmppc_get_pc(vcpu);
>> + r = RESUME_HOST;
>
> Phew - why can't we just go into the normal instruction emulator for
> EMUL_ASSIST?
>
IIUC, using the emulation_assist_interrupt function (kernel/trap.c) ?
Thanks for review
Regards
Maddy
>
> Alex
>
^ permalink raw reply
* Re: [PATCH v4] powerpc/powernv: hwmon driver for power, fan rpm, voltage and temperature
From: Guenter Roeck @ 2014-07-05 2:25 UTC (permalink / raw)
To: Neelesh Gupta, linuxppc-dev, jdelvare, lm-sensors
Cc: sbhat, devicetree@vger.kernel.org
In-Reply-To: <20140704105343.22437.52125.stgit@localhost.localdomain>
On 07/04/2014 04:02 AM, Neelesh Gupta wrote:
> This patch adds basic kernel support for reading power values, fan
> speed rpm, voltage and temperature data on powernv platforms which will
> be exported to user space through sysfs interface.
>
Hi Neelesh,
Copying devicetree mailing list. Please copy it on the next (hopefully final)
revision; devicetree maintainers at least need a chance to comment.
[ Yes, I understand this is a shipping product, but still ... ]
I am ok with the code except for a couple of minor nitpicks (see below).
Thanks,
Guenter
> Test results:
> -------------
> [root@tul163p1 ~]# sensors
> ibmpowernv-isa-0000
> Adapter: ISA adapter
> fan1: 5567 RPM (min = 0 RPM)
> fan2: 5232 RPM (min = 0 RPM)
> fan3: 5532 RPM (min = 0 RPM)
> fan4: 4945 RPM (min = 0 RPM)
> fan5: 0 RPM (min = 0 RPM)
> fan6: 0 RPM (min = 0 RPM)
> fan7: 7392 RPM (min = 0 RPM)
> fan8: 7936 RPM (min = 0 RPM)
> temp1: +39.0°C (high = +0.0°C)
> power1: 191.00 W
>
> [root@tul163p1 ~]# ls /sys/devices/platform/
> alarmtimer ibmpowernv.0 power rtc-generic serial8250 uevent
> [root@tul163p1 ~]# ls /sys/devices/platform/ibmpowernv.0/hwmon/hwmon0/
> device fan2_min fan4_min fan6_min fan8_min power
> fan1_fault fan3_fault fan5_fault fan7_fault in1_fault power1_input
> fan1_input fan3_input fan5_input fan7_input in2_fault subsystem
> fan1_min fan3_min fan5_min fan7_min in3_fault temp1_input
> fan2_fault fan4_fault fan6_fault fan8_fault in4_fault temp1_max
> fan2_input fan4_input fan6_input fan8_input name uevent
> [root@tul163p1 ~]#
> [root@tul163p1 ~]# ls /sys/class/hwmon/hwmon0/
> device fan2_min fan4_min fan6_min fan8_min power
> fan1_fault fan3_fault fan5_fault fan7_fault in1_fault power1_input
> fan1_input fan3_input fan5_input fan7_input in2_fault subsystem
> fan1_min fan3_min fan5_min fan7_min in3_fault temp1_input
> fan2_fault fan4_fault fan6_fault fan8_fault in4_fault temp1_max
> fan2_input fan4_input fan6_input fan8_input name uevent
> [root@tul163p1 ~]#
>
> Signed-off-by: Neelesh Gupta <neelegup@linux.vnet.ibm.com>
> ---
>
> Changes in v4
> =============
> - Replaced pr_err() with dev_err() for loggin print messages.
> - Using kstrtou32() function for converting string to u32 instead of sscanf().
>
> Changes in v3
> =============
> - Fixed an endianness bug leading the driver to break on LE.
> - Fixed a bug that when one of the 'attribute_group' not populated, following
> groups attributes were dropped.
> - Rewrite the get_sensor_index_attr() function to handle all the error scenarios
> like 'sscanf' etc.
> - Fixed all the errors/warnings related to coding style/whitespace.
> - Added 'Documentation' files.
> - Addressed remaining review comments on V2.
>
> Changes in v2
> =============
> - Generic use of devm_* functions in hwmon like using devm_kzalloc() for dynamic
> memory request, avoiding the need to explicit free of memory.
> Adding 'struct attribute_group' as member of platform data structure to be
> populated and then passed to devm_hwmon_device_register_with_groups().
>
> Note: Having an array of pointers of 'attribute_group' and each group
> corresponds to 'enum sensors' type. Not completely sure, if it's ideal or
> could have just one group populated with attributes of sensor types?
>
> - 'ibmpowernv' is not hot-pluggable device so moving 'platform_driver' callback
> function (probe) as part of __init code.
> - Fixed issues related to coding style.
> - Other general comments in v1.
>
> .../devicetree/bindings/hwmon/ibmpowernv.txt | 27 +
> Documentation/hwmon/ibmpowernv | 41 ++
> drivers/hwmon/Kconfig | 11 +
> drivers/hwmon/Makefile | 1
> drivers/hwmon/ibmpowernv.c | 362 ++++++++++++++++++++
> 5 files changed, 442 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/ibmpowernv.txt
> create mode 100644 Documentation/hwmon/ibmpowernv
> create mode 100644 drivers/hwmon/ibmpowernv.c
>
> diff --git a/Documentation/devicetree/bindings/hwmon/ibmpowernv.txt b/Documentation/devicetree/bindings/hwmon/ibmpowernv.txt
> new file mode 100644
> index 0000000..e3bd1eb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/ibmpowernv.txt
> @@ -0,0 +1,27 @@
> +IBM POWERNV platform sensors
> +----------------------------
> +
> +Required node properties:
> +- compatible: must be one of
> + "ibm,opal-sensor-cooling-fan"
> + "ibm,opal-sensor-amb-temp"
> + "ibm,opal-sensor-power-supply"
> + "ibm,opal-sensor-power"
> +- sensor-id: an opaque id provided by the firmware to the kernel, identifies a
> + given sensor and its attribute data
> +
> +Example sensors node:
> +
> +cooling-fan#8-data {
> + sensor-id = <0x7052107>;
> + phandle = <0x10000028>;
> + linux,phandle = <0x10000028>;
> + compatible = "ibm,opal-sensor-cooling-fan";
phandle and linux-phandle are neither documented nor used. Either document or drop.
> +};
> +
> +amb-temp#1-thrs {
> + sensor-id = <0x5096000>;
> + phandle = <0x10000017>;
> + linux,phandle = <0x10000017>;
> + compatible = "ibm,opal-sensor-amb-temp";
> +};
> diff --git a/Documentation/hwmon/ibmpowernv b/Documentation/hwmon/ibmpowernv
> new file mode 100644
> index 0000000..644245a
> --- /dev/null
> +++ b/Documentation/hwmon/ibmpowernv
> @@ -0,0 +1,41 @@
> +Kernel Driver IBMPOWENV
> +=======================
> +
> +Supported systems:
> + * Any recent IBM P servers based on POWERNV platform
> +
> +Author: Neelesh Gupta
> +
> +Description
> +-----------
> +
> +This driver implements reading the platform sensors data like temperature/fan/
> +voltage/power for 'POWERNV' platform.
> +
> +The driver uses the platform device infrastructure. It probes the device tree
> +for sensor devices during the __init phase and registers them with the 'hwmon'.
> +'hwmon' populates the 'sysfs' tree having attribute files, each for a given
> +sensor type and its attribute data.
> +
> +All the nodes in the DT appear under "/ibm,opal/sensors" and each valid node in
> +the DT maps to an attribute file in 'sysfs'. The node exports unique 'sensor-id'
> +which the driver uses to make an OPAL call to the firmware.
> +
> +Usage notes
> +-----------
> +The driver is built statically with the kernel by enabling the config
> +CONFIG_SENSORS_IBMPOWERNV. It can also be built as module 'ibmpowernv'.
> +
> +Sysfs attributes
> +----------------
> +
> +fanX_input Measured RPM value.
> +fanX_min Threshold RPM for alert generation.
> +fanX_fault 0: No fail condition
> + 1: Failing fan
> +tempX_input Measured ambient temperature.
> +tempX_max Threshold ambient temperature for alert generation.
> +inX_input Measured power supply voltage
> +inX_fault 0: No fail condition.
> + 1: Failing power supply.
> +power1_input System power consumption (microWatt)
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 02d3d85..29c3fcb 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -554,6 +554,17 @@ config SENSORS_IBMPEX
> This driver can also be built as a module. If so, the module
> will be called ibmpex.
>
> +config SENSORS_IBMPOWERNV
> + tristate "IBM POWERNV platform sensors"
> + depends on PPC_POWERNV
> + default y
> + help
> + If you say yes here you get support for the temperature/fan/power
> + sensors on your PowerNV platform.
> +
> + This driver can also be built as a module. If so, the module
> + will be called ibmpowernv.
> +
> config SENSORS_IIO_HWMON
> tristate "Hwmon driver that uses channels specified via iio maps"
> depends on IIO
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index 3dc0f02..fc4ed26 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -71,6 +71,7 @@ obj-$(CONFIG_SENSORS_ULTRA45) += ultra45_env.o
> obj-$(CONFIG_SENSORS_I5K_AMB) += i5k_amb.o
> obj-$(CONFIG_SENSORS_IBMAEM) += ibmaem.o
> obj-$(CONFIG_SENSORS_IBMPEX) += ibmpex.o
> +obj-$(CONFIG_SENSORS_IBMPOWERNV)+= ibmpowernv.o
> obj-$(CONFIG_SENSORS_IIO_HWMON) += iio_hwmon.o
> obj-$(CONFIG_SENSORS_INA209) += ina209.o
> obj-$(CONFIG_SENSORS_INA2XX) += ina2xx.o
> diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
> new file mode 100644
> index 0000000..44dcd99
> --- /dev/null
> +++ b/drivers/hwmon/ibmpowernv.c
> @@ -0,0 +1,362 @@
> +/*
> + * IBM PowerNV platform sensors for temperature/fan/voltage/power
> + * Copyright (C) 2014 IBM
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.
> + */
> +
> +#define DRVNAME "ibmpowernv"
> +#define pr_fmt(fmt) DRVNAME ": " fmt
> +
> +#include <linux/init.h>
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/hwmon.h>
> +#include <linux/hwmon-sysfs.h>
> +#include <linux/of.h>
> +#include <linux/slab.h>
> +
> +#include <linux/platform_device.h>
> +#include <asm/opal.h>
> +#include <linux/err.h>
> +
> +#define MAX_ATTR_LEN 32
> +
> +/* Sensor suffix name from DT */
> +#define DT_FAULT_ATTR_SUFFIX "faulted"
> +#define DT_DATA_ATTR_SUFFIX "data"
> +#define DT_THRESHOLD_ATTR_SUFFIX "thrs"
> +
> +/*
> + * Enumerates all the types of sensors in the POWERNV platform and does index
> + * into 'struct sensor_group'
> + */
> +enum sensors {
> + FAN,
> + AMBIENT_TEMP,
> + POWER_SUPPLY,
> + POWER_INPUT,
> + MAX_SENSOR_TYPE,
> +};
> +
> +static struct sensor_group {
> + const char *name;
> + const char *compatible;
> + struct attribute_group group;
> + u32 attr_count;
> +} sensor_groups[] = {
> + {"fan", "ibm,opal-sensor-cooling-fan"},
> + {"temp", "ibm,opal-sensor-amb-temp"},
> + {"in", "ibm,opal-sensor-power-supply"},
> + {"power", "ibm,opal-sensor-power"}
> +};
> +
> +struct sensor_data {
> + u32 id; /* An opaque id of the firmware for each sensor */
> + enum sensors type;
> + char name[MAX_ATTR_LEN];
> + struct device_attribute dev_attr;
> +};
> +
> +struct platform_data {
> + const struct attribute_group *attr_groups[MAX_SENSOR_TYPE + 1];
> + u32 sensors_count; /* Total count of sensors from each group */
> +};
> +
> +/* Platform device representing all the ibmpowernv sensors */
> +static struct platform_device *pdevice;
> +
> +static ssize_t show_sensor(struct device *dev, struct device_attribute *devattr,
> + char *buf)
> +{
> + struct sensor_data *sdata = container_of(devattr, struct sensor_data,
> + dev_attr);
> + ssize_t ret;
> + u32 x;
> +
> + ret = opal_get_sensor_data(sdata->id, &x);
> + if (ret)
> + return ret;
> +
> + /* Convert temperature to milli-degrees */
> + if (sdata->type == AMBIENT_TEMP)
> + x *= 1000;
> + /* Convert power to micro-watts */
> + else if (sdata->type == POWER_INPUT)
> + x *= 1000000;
> +
> + return sprintf(buf, "%u\n", x);
> +}
> +
> +static int __init get_sensor_index_attr(const char *name, u32 *index,
> + char *attr)
> +{
> + char *hash_pos = strchr(name, '#');
> + char buf[8] = { 0 };
> + char *dash_pos;
> + u32 copy_len;
> +
> + if (!hash_pos)
> + return -EINVAL;
> +
> + dash_pos = strchr(hash_pos, '-');
> + if (!dash_pos)
> + return -EINVAL;
> +
> + copy_len = dash_pos - hash_pos - 1;
> + if (copy_len >= sizeof(buf))
> + return -EINVAL;
> +
> + strncpy(buf, hash_pos + 1, copy_len);
> +
> + if (kstrtou32(buf, 10, index))
> + return -EINVAL;
> +
smatch isn't going to like that. Please use
int err;
...
err = kstrtou32(buf, 10, index));
if (err)
return err;
> + strncpy(attr, dash_pos + 1, MAX_ATTR_LEN);
> +
> + return 0;
> +}
> +
> +/*
> + * This function translates the DT node name into the 'hwmon' attribute name.
> + * IBMPOWERNV device node appear like cooling-fan#2-data, amb-temp#1-thrs etc.
> + * which need to be mapped as fan2_input, temp1_max respectively before
> + * populating them inside hwmon device class.
> + */
> +static int __init create_hwmon_attr_name(struct device *dev, enum sensors type,
> + const char *node_name,
> + char *hwmon_attr_name)
> +{
> + char attr_suffix[MAX_ATTR_LEN];
> + char *attr_name;
> + u32 index;
> + int err;
> +
> + err = get_sensor_index_attr(node_name, &index, attr_suffix);
> + if (err) {
> + dev_err(dev, "Sensor device node name '%s' is invalid\n",
> + node_name);
> + return err;
> + }
> +
> + if (!strcmp(attr_suffix, DT_FAULT_ATTR_SUFFIX)) {
> + attr_name = "fault";
> + } else if (!strcmp(attr_suffix, DT_DATA_ATTR_SUFFIX)) {
> + attr_name = "input";
> + } else if (!strcmp(attr_suffix, DT_THRESHOLD_ATTR_SUFFIX)) {
> + if (type == AMBIENT_TEMP)
> + attr_name = "max";
> + else if (type == FAN)
> + attr_name = "min";
> + else
> + return -ENOENT;
> + } else {
> + return -ENOENT;
> + }
> +
> + snprintf(hwmon_attr_name, MAX_ATTR_LEN, "%s%d_%s",
> + sensor_groups[type].name, index, attr_name);
> + return 0;
> +}
> +
> +static int __init populate_attr_groups(struct platform_device *pdev)
> +{
> + struct platform_data *pdata = platform_get_drvdata(pdev);
> + const struct attribute_group **pgroups = pdata->attr_groups;
> + struct device_node *opal, *np;
> + enum sensors type;
> +
> + opal = of_find_node_by_path("/ibm,opal/sensors");
> + if (!opal) {
> + dev_err(&pdev->dev, "Opal node 'sensors' not found\n");
> + return -ENODEV;
> + }
> +
> + for_each_child_of_node(opal, np) {
> + if (np->name == NULL)
> + continue;
> +
> + for (type = 0; type < MAX_SENSOR_TYPE; type++)
> + if (of_device_is_compatible(np,
> + sensor_groups[type].compatible)) {
> + sensor_groups[type].attr_count++;
> + break;
> + }
> + }
> +
> + of_node_put(opal);
> +
> + for (type = 0; type < MAX_SENSOR_TYPE; type++) {
> + sensor_groups[type].group.attrs = devm_kzalloc(&pdev->dev,
> + sizeof(struct attribute *) *
> + (sensor_groups[type].attr_count + 1),
> + GFP_KERNEL);
> + if (!sensor_groups[type].group.attrs)
> + return -ENOMEM;
> +
> + pgroups[type] = &sensor_groups[type].group;
> + pdata->sensors_count += sensor_groups[type].attr_count;
> + sensor_groups[type].attr_count = 0;
> + }
> +
> + return 0;
> +}
> +
> +/*
> + * Iterate through the device tree for each child of 'sensors' node, create
> + * a sysfs attribute file, the file is named by translating the DT node name
> + * to the name required by the higher 'hwmon' driver like fan1_input, temp1_max
> + * etc..
> + */
> +static int __init create_device_attrs(struct platform_device *pdev)
> +{
> + struct platform_data *pdata = platform_get_drvdata(pdev);
> + const struct attribute_group **pgroups = pdata->attr_groups;
> + struct device_node *opal, *np;
> + struct sensor_data *sdata;
> + const __be32 *sensor_id;
> + enum sensors type;
> + u32 count = 0;
> + int err = 0;
> +
> + opal = of_find_node_by_path("/ibm,opal/sensors");
> + sdata = devm_kzalloc(&pdev->dev, pdata->sensors_count * sizeof(*sdata),
> + GFP_KERNEL);
> + if (!sdata) {
> + err = -ENOMEM;
> + goto exit_put_node;
> + }
> +
> + for_each_child_of_node(opal, np) {
> + if (np->name == NULL)
> + continue;
> +
> + for (type = 0; type < MAX_SENSOR_TYPE; type++)
> + if (of_device_is_compatible(np,
> + sensor_groups[type].compatible))
> + break;
> +
> + if (type == MAX_SENSOR_TYPE)
> + continue;
> +
> + sensor_id = of_get_property(np, "sensor-id", NULL);
> + if (!sensor_id) {
> + dev_info(&pdev->dev,
> + "'sensor-id' missing in the node '%s'\n",
> + np->name);
> + continue;
> + }
> +
> + sdata[count].id = be32_to_cpup(sensor_id);
> + sdata[count].type = type;
> + err = create_hwmon_attr_name(&pdev->dev, type, np->name,
> + sdata[count].name);
> + if (err)
> + goto exit_put_node;
> +
> + sysfs_attr_init(&sdata[count].dev_attr.attr);
> + sdata[count].dev_attr.attr.name = sdata[count].name;
> + sdata[count].dev_attr.attr.mode = S_IRUGO;
> + sdata[count].dev_attr.show = show_sensor;
> +
> + pgroups[type]->attrs[sensor_groups[type].attr_count++] =
> + &sdata[count++].dev_attr.attr;
> + }
> +
> +exit_put_node:
> + of_node_put(opal);
> + return err;
> +}
> +
> +static int __init ibmpowernv_probe(struct platform_device *pdev)
> +{
> + struct platform_data *pdata;
> + struct device *hwmon_dev;
> + int err;
> +
> + pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, pdata);
> + pdata->sensors_count = 0;
> + err = populate_attr_groups(pdev);
> + if (err)
> + return err;
> +
> + /* Create sysfs attribute data for each sensor found in the DT */
> + err = create_device_attrs(pdev);
> + if (err)
> + return err;
> +
> + /* Finally, register with hwmon */
> + hwmon_dev = devm_hwmon_device_register_with_groups(&pdev->dev, DRVNAME,
> + pdata,
> + pdata->attr_groups);
> +
> + return PTR_ERR_OR_ZERO(hwmon_dev);
> +}
> +
> +static struct platform_driver ibmpowernv_driver = {
> + .driver = {
> + .owner = THIS_MODULE,
> + .name = DRVNAME,
> + },
> +};
> +
> +static int __init ibmpowernv_init(void)
> +{
> + int err;
> +
> + pdevice = platform_device_alloc(DRVNAME, 0);
> + if (!pdevice) {
> + pr_err("Device allocation failed\n");
> + err = -ENOMEM;
> + goto exit;
> + }
> +
> + err = platform_device_add(pdevice);
> + if (err) {
> + pr_err("Device addition failed (%d)\n", err);
> + goto exit_device_put;
> + }
> +
> + err = platform_driver_probe(&ibmpowernv_driver, ibmpowernv_probe);
> + if (err) {
> + pr_err("Platfrom driver probe failed\n");
> + goto exit_device_del;
> + }
> +
> + return 0;
> +
> +exit_device_del:
> + platform_device_del(pdevice);
> +exit_device_put:
> + platform_device_put(pdevice);
> +exit:
> + return err;
> +}
> +
> +static void __exit ibmpowernv_exit(void)
> +{
> + platform_driver_unregister(&ibmpowernv_driver);
> + platform_device_unregister(pdevice);
> +}
> +
> +MODULE_AUTHOR("Neelesh Gupta <neelegup@linux.vnet.ibm.com>");
> +MODULE_DESCRIPTION("IBM POWERNV platform sensors");
> +MODULE_LICENSE("GPL");
> +
> +module_init(ibmpowernv_init);
> +module_exit(ibmpowernv_exit);
>
>
>
^ permalink raw reply
* [PATCH] powerpc/fsl-pci: Correct use of ! and &
From: Himangi Saraogi @ 2014-07-05 14:33 UTC (permalink / raw)
To: Kumar Gala, Benjamin Herrenschmidt, Paul Mackerras, linuxppc-dev,
linux-kernel
Cc: julia.lawall
In commit ae91d60ba88ef0bdb1b5e9b2363bd52fc45d2af7, a bug was fixed that
involved converting !x & y to !(x & y). The code below shows the same
pattern, and thus should perhaps be fixed in the same way.
The Coccinelle semantic patch that makes this change is as follows:
// <smpl>
@@ expression E1,E2; @@
(
!E1 & !E2
|
- !E1 & E2
+ !(E1 & E2)
)
// </smpl>
Signed-off-by: Himangi Saraogi <himangi774@gmail.com>
---
This is not tested and clearly changes the semantics, so it is only
something to consider.
arch/powerpc/sysdev/fsl_pci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 4bd091a..c507767 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -853,8 +853,8 @@ u64 fsl_pci_immrbar_base(struct pci_controller *hose)
in = pcie->cfg_type0 + PEX_RC_INWIN_BASE;
for (i = 0; i < 4; i++) {
/* not enabled, skip */
- if (!in_le32(&in[i].ar) & PEX_RCIWARn_EN)
- continue;
+ if (!(in_le32(&in[i].ar) & PEX_RCIWARn_EN))
+ continue;
if (get_immrbase() == in_le32(&in[i].tar))
return (u64)in_le32(&in[i].barh) << 32 |
--
1.9.1
^ permalink raw reply related
* [PATCH] powerpc/mpic_msgr: Use kcalloc and correct the argument to sizeof
From: Himangi Saraogi @ 2014-07-06 16:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, linuxppc-dev,
linux-kernel
Cc: julia.lawall
mpic_msgrs has type struct mpic_msgr **, not struct mpic_msgr *, so the
elements of the array should have pointer type, not structure type.
The advantage of kcalloc is, that will prevent integer overflows which
could result from the multiplication of number of elements and size and
it is also a bit nicer to read.
The Coccinelle semantic patch that makes the first change is as follows:
// <smpl>
@disable sizeof_type_expr@
type T;
T **x;
@@
x =
<+...sizeof(
- T
+ *x
)...+>
// </smpl>
Signed-off-by: Himangi Saraogi <himangi774@gmail.com>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
---
arch/powerpc/sysdev/mpic_msgr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/sysdev/mpic_msgr.c b/arch/powerpc/sysdev/mpic_msgr.c
index 2c9b52a..7bdf3cc 100644
--- a/arch/powerpc/sysdev/mpic_msgr.c
+++ b/arch/powerpc/sysdev/mpic_msgr.c
@@ -184,7 +184,7 @@ static int mpic_msgr_probe(struct platform_device *dev)
dev_info(&dev->dev, "Found %d message registers\n",
mpic_msgr_count);
- mpic_msgrs = kzalloc(sizeof(struct mpic_msgr) * mpic_msgr_count,
+ mpic_msgrs = kcalloc(mpic_msgr_count, sizeof(*mpic_msgrs),
GFP_KERNEL);
if (!mpic_msgrs) {
dev_err(&dev->dev,
--
1.9.1
^ permalink raw reply related
* [PATCH v10 4/7] powerpc: add pmd_[dirty|mkclean] for THP
From: Minchan Kim @ 2014-07-07 0:53 UTC (permalink / raw)
To: Andrew Morton
Cc: Jason Evans, Rik van Riel, Minchan Kim, Aneesh Kumar K.V,
Linux API, Hugh Dickins, linux-kernel, linux-mm, Zhang Yanfei,
Michael Kerrisk, KOSAKI Motohiro, Johannes Weiner,
Kirill A. Shutemov, linuxppc-dev, Paul Mackerras, Mel Gorman
In-Reply-To: <1404694438-10272-1-git-send-email-minchan@kernel.org>
MADV_FREE needs pmd_dirty and pmd_mkclean for detecting recent
overwrite of the contents since MADV_FREE syscall is called for
THP page.
This patch adds pmd_dirty and pmd_mkclean for THP page MADV_FREE
support.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Minchan Kim <minchan@kernel.org>
---
arch/powerpc/include/asm/pgtable-ppc64.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h b/arch/powerpc/include/asm/pgtable-ppc64.h
index eb9261024f51..c9a4bbe8e179 100644
--- a/arch/powerpc/include/asm/pgtable-ppc64.h
+++ b/arch/powerpc/include/asm/pgtable-ppc64.h
@@ -468,9 +468,11 @@ static inline pte_t *pmdp_ptep(pmd_t *pmd)
#define pmd_pfn(pmd) pte_pfn(pmd_pte(pmd))
#define pmd_young(pmd) pte_young(pmd_pte(pmd))
+#define pmd_dirty(pmd) pte_dirty(pmd_pte(pmd))
#define pmd_mkold(pmd) pte_pmd(pte_mkold(pmd_pte(pmd)))
#define pmd_wrprotect(pmd) pte_pmd(pte_wrprotect(pmd_pte(pmd)))
#define pmd_mkdirty(pmd) pte_pmd(pte_mkdirty(pmd_pte(pmd)))
+#define pmd_mkclean(pmd) pte_pmd(pte_mkclean(pmd_pte(pmd)))
#define pmd_mkyoung(pmd) pte_pmd(pte_mkyoung(pmd_pte(pmd)))
#define pmd_mkwrite(pmd) pte_pmd(pte_mkwrite(pmd_pte(pmd)))
--
2.0.0
^ permalink raw reply related
* Re: [PATCH v4] powerpc/powernv: hwmon driver for power, fan rpm, voltage and temperature
From: Benjamin Herrenschmidt @ 2014-07-07 6:56 UTC (permalink / raw)
To: Guenter Roeck
Cc: devicetree@vger.kernel.org, lm-sensors, sbhat, Neelesh Gupta,
linuxppc-dev, jdelvare
In-Reply-To: <53B76220.9090900@roeck-us.net>
On Fri, 2014-07-04 at 19:25 -0700, Guenter Roeck wrote:
> > +cooling-fan#8-data {
> > + sensor-id = <0x7052107>;
> > + phandle = <0x10000028>;
> > + linux,phandle = <0x10000028>;
> > + compatible = "ibm,opal-sensor-cooling-fan";
>
> phandle and linux-phandle are neither documented nor used. Either
> document or drop.
They are core device-tree stuff, as such they are used potentially
anywhere and afaik can be / are generated by DTC but yes, this is
not the place to document them.
Or rather, "phandle" is, "linux,phandle" is an older variant used
for backward compatibility that our firmware still generates but
definitely something we can strip from the doc.
Cheers,
Ben,
^ permalink raw reply
* Re: [PATCH 0/3] iommu/fsl: Fixes for the PAMU driver.
From: Joerg Roedel @ 2014-07-07 8:32 UTC (permalink / raw)
To: Varun Sethi; +Cc: alex.williamson, iommu, linuxppc-dev, linux-kernel
In-Reply-To: <1403618237-26248-1-git-send-email-Varun.Sethi@freescale.com>
On Tue, Jun 24, 2014 at 07:27:14PM +0530, Varun Sethi wrote:
> This patch set contains fixes for the PAMU driver.
> The patches are based on 3.16-rc1.
>
> Varun Sethi (3):
> Fix PAMU window size check.
> Fix the device domain attach condition.
> Fix the error condition during iommu group creation.
>
> drivers/iommu/fsl_pamu.c | 8 ++++----
> drivers/iommu/fsl_pamu_domain.c | 19 +++++++++----------
> 2 files changed, 13 insertions(+), 14 deletions(-)
Applied to iommu/fixes, thanks.
^ permalink raw reply
* [PATCH] devicetree/bindings/powerpc/fsl: Add binding for board
From: Priyanka Jain @ 2014-07-07 8:36 UTC (permalink / raw)
To: devicetree, linuxppc-dev, scottwood; +Cc: Priyanka Jain
Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
---
.../devicetree/bindings/powerpc/fsl/board.txt | 17 ++++++++++++++++-
1 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/board.txt b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
index f35f295..7800729 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/board.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
@@ -1,8 +1,23 @@
Freescale Reference Board Bindings
-This document describes device tree bindings for various devices that
+This document describes device tree bindings for board and various devices that
exist on some Freescale reference boards.
+* Board node
+Required properties:
+
+ - model : Should be "fsl,<board>"
+ - compatible : Should be "fsl,<board>"
+ example: "fsl,T1040RDB", "fsl,T1042RDB", "fsl,T1042RDB_PI"
+ "fsl,T1040QDS", "fsl,T1042QDS"
+
+Example:
+
+/ {
+ model = "fsl,T1040RDB";
+ compatible = "fsl,T1040RDB";
+};
+
* Board Control and Status (BCSR)
Required properties:
--
1.7.4.1
^ permalink raw reply related
* RE: [PATCH 0/3] iommu/fsl: Fixes for the PAMU driver.
From: Varun Sethi @ 2014-07-07 8:55 UTC (permalink / raw)
To: Joerg Roedel
Cc: alex.williamson@redhat.com, iommu@lists.linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <20140707083216.GA1958@8bytes.org>
Thanks Joerg.
> -----Original Message-----
> From: Joerg Roedel [mailto:joro@8bytes.org]
> Sent: Monday, July 07, 2014 2:02 PM
> To: Sethi Varun-B16395
> Cc: iommu@lists.linux-foundation.org; linux-kernel@vger.kernel.org;
> linuxppc-dev@lists.ozlabs.org; alex.williamson@redhat.com
> Subject: Re: [PATCH 0/3] iommu/fsl: Fixes for the PAMU driver.
>=20
> On Tue, Jun 24, 2014 at 07:27:14PM +0530, Varun Sethi wrote:
> > This patch set contains fixes for the PAMU driver.
> > The patches are based on 3.16-rc1.
> >
> > Varun Sethi (3):
> > Fix PAMU window size check.
> > Fix the device domain attach condition.
> > Fix the error condition during iommu group creation.
> >
> > drivers/iommu/fsl_pamu.c | 8 ++++----
> > drivers/iommu/fsl_pamu_domain.c | 19 +++++++++----------
> > 2 files changed, 13 insertions(+), 14 deletions(-)
>=20
> Applied to iommu/fixes, thanks.
>=20
^ permalink raw reply
* [PATCH] of: Add vendor prefix for EON Corporation
From: Shengzhou Liu @ 2014-07-07 9:29 UTC (permalink / raw)
To: linuxppc-dev, scottwood; +Cc: Shengzhou Liu
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 1a6793b..3c10a21 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -42,6 +42,7 @@ ebv EBV Elektronik
edt Emerging Display Technologies
emmicro EM Microelectronic
epfl Ecole Polytechnique Fédérale de Lausanne
+eon Eon Silicon Solution, Inc.
epson Seiko Epson Corp.
est ESTeem Wireless Modems
eukrea Eukréa Electromatique
--
1.8.0
^ permalink raw reply related
* RE: [3/3,v4] powerpc/t2080rdb: Add T2080RDB board support
From: Shengzhou.Liu @ 2014-07-07 10:26 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20140625233450.GA13860@home.buserror.net>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Thursday, June 26, 2014 7:35 AM
> To: Liu Shengzhou-B36685
> Cc: linuxppc-dev@lists.ozlabs.org
> Subject: Re: [3/3,v4] powerpc/t2080rdb: Add T2080RDB board support
>=20
> On Wed, Jun 11, 2014 at 06:10:06PM +0800, Shengzhou Liu wrote:
> > + i2c@0 {
> > + #address-cells =3D <1>;
> > + #size-cells =3D <0>;
> > + reg =3D <0x0>;
> > +
> > + sfp@50 {
> > + compatible =3D "optics,sfp";
> > + reg =3D <0x50>;
> > + };
> > + };
>=20
> What is "sfp"? Please use generic node names when possible.
>=20
> I'm not able to easily find what chip this is referring to by googling
> "optics sfp". I suspect this compatible is too vague -- what is the
> actual part number? Could you provide a URL to a description of the chip=
?
>=20
> If "optics" is the correct vendor name, it needs to go into vendor-prefix=
es.txt.
>=20
> -Scott
[Shengzhou] SFP is "Small Form-factor Pluggable transceiver" for 10Gpbs opt=
ics module. Actually, there is no a specific vendor for this case, it is a=
general sfp cage to which we can plug in different optics module from diff=
erent vendors. And there is no need to configure it by SW. =20
^ permalink raw reply
* Re: [PATCH v4] powerpc/powernv: hwmon driver for power, fan rpm, voltage and temperature
From: Guenter Roeck @ 2014-07-07 12:59 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: devicetree@vger.kernel.org, lm-sensors, sbhat, Neelesh Gupta,
linuxppc-dev, jdelvare
In-Reply-To: <1404716172.16156.8.camel@pasglop>
On 07/06/2014 11:56 PM, Benjamin Herrenschmidt wrote:
> On Fri, 2014-07-04 at 19:25 -0700, Guenter Roeck wrote:
>>> +cooling-fan#8-data {
>>> + sensor-id = <0x7052107>;
>>> + phandle = <0x10000028>;
>>> + linux,phandle = <0x10000028>;
>>> + compatible = "ibm,opal-sensor-cooling-fan";
>>
>> phandle and linux-phandle are neither documented nor used. Either
>> document or drop.
>
> They are core device-tree stuff, as such they are used potentially
> anywhere and afaik can be / are generated by DTC but yes, this is
> not the place to document them.
>
Turns out they are documented elsewhere. See
Documentation/devicetree/booting-without-of.txt.
> Or rather, "phandle" is, "linux,phandle" is an older variant used
> for backward compatibility that our firmware still generates but
> definitely something we can strip from the doc.
>
Both are not mentioned in any other bindings, so my take is they should
not be mentioned here either.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH] of: Add vendor prefix for EON Corporation
From: Scott Wood @ 2014-07-07 18:55 UTC (permalink / raw)
To: Shengzhou Liu; +Cc: linuxppc-dev
In-Reply-To: <1404725359-6754-1-git-send-email-Shengzhou.Liu@freescale.com>
On Mon, 2014-07-07 at 17:29 +0800, Shengzhou Liu wrote:
> Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
Again, please CC all relevant mailing lists. Where is the devicetree
list? And mention why this patch is relevant to PPC.
-Scott
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 1a6793b..3c10a21 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -42,6 +42,7 @@ ebv EBV Elektronik
> edt Emerging Display Technologies
> emmicro EM Microelectronic
> epfl Ecole Polytechnique Fédérale de Lausanne
> +eon Eon Silicon Solution, Inc.
> epson Seiko Epson Corp.
> est ESTeem Wireless Modems
> eukrea Eukréa Electromatique
^ permalink raw reply
* Re: [PATCH 1/3] PCI/MSI: Add pci_enable_msi_partial()
From: Bjorn Helgaas @ 2014-07-07 19:26 UTC (permalink / raw)
To: Alexander Gordeev
Cc: linux-mips@linux-mips.org, linux-s390@vger.kernel.org,
linux-doc@vger.kernel.org, linux-pci@vger.kernel.org,
x86@kernel.org, linux-kernel@vger.kernel.org,
linux-ide@vger.kernel.org, iommu@lists.linux-foundation.org,
David Laight, xen-devel@lists.xenproject.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20140704085816.GB12247@dhcp-26-207.brq.redhat.com>
On Fri, Jul 4, 2014 at 2:58 AM, Alexander Gordeev <agordeev@redhat.com> wrote:
> On Thu, Jul 03, 2014 at 09:20:52AM +0000, David Laight wrote:
>> From: Bjorn Helgaas
>> > On Tue, Jun 10, 2014 at 03:10:30PM +0200, Alexander Gordeev wrote:
>> > > There are PCI devices that require a particular value written
>> > > to the Multiple Message Enable (MME) register while aligned on
>> > > power of 2 boundary value of actually used MSI vectors 'nvec'
>> > > is a lesser of that MME value:
>> > >
>> > > roundup_pow_of_two(nvec) < 'Multiple Message Enable'
>> > >
>> > > However the existing pci_enable_msi_block() interface is not
>> > > able to configure such devices, since the value written to the
>> > > MME register is calculated from the number of requested MSIs
>> > > 'nvec':
>> > >
>> > > 'Multiple Message Enable' = roundup_pow_of_two(nvec)
>> >
>> > For MSI, software learns how many vectors a device requests by reading
>> > the Multiple Message Capable (MMC) field. This field is encoded, so a
>> > device can only request 1, 2, 4, 8, etc., vectors. It's impossible
>> > for a device to request 3 vectors; it would have to round up that up
>> > to a power of two and request 4 vectors.
>> >
>> > Software writes similarly encoded values to MME to tell the device how
>> > many vectors have been allocated for its use. For example, it's
>> > impossible to tell the device that it can use 3 vectors; the OS has to
>> > round that up and tell the device it can use 4 vectors.
>> >
>> > So if I understand correctly, the point of this series is to take
>> > advantage of device-specific knowledge, e.g., the device requests 4
>> > vectors via MMC, but we "know" the device is only capable of using 3.
>> > Moreover, we tell the device via MME that 4 vectors are available, but
>> > we've only actually set up 3 of them.
>> ...
>>
>> Even if you do that, you ought to write valid interrupt information
>> into the 4th slot (maybe replicating one of the earlier interrupts).
>> Then, if the device does raise the 'unexpected' interrupt you don't
>> get a write to a random kernel location.
>
> I might be missing something, but we are talking of MSI address space
> here, aren't we? I am not getting how we could end up with a 'write'
> to a random kernel location when a unclaimed MSI vector sent. We could
> only expect a spurious interrupt at worst, which is handled and reported.
Yes, that's how I understand it. With MSI, the OS specifies the a
single Message Address, e.g., a LAPIC address, and a single Message
Data value, e.g., a vector number that will be written to the LAPIC.
The device is permitted to modify some low-order bits of the Message
Data to send one of several vector numbers (the MME value tells the
device how many bits it can modify).
Bottom line, I think a spurious interrupt is the failure we'd expect
if a device used more vectors than the OS expects it to.
Bjorn
^ permalink raw reply
* Re: [PATCH 1/3] PCI/MSI: Add pci_enable_msi_partial()
From: Bjorn Helgaas @ 2014-07-07 19:40 UTC (permalink / raw)
To: Alexander Gordeev
Cc: linux-mips@linux-mips.org, linux-s390, linux-pci@vger.kernel.org,
x86@kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org,
open list:INTEL IOMMU (VT-d), xen-devel, linuxppc-dev
In-Reply-To: <20140704085741.GA12247@dhcp-26-207.brq.redhat.com>
On Fri, Jul 4, 2014 at 2:57 AM, Alexander Gordeev <agordeev@redhat.com> wrote:
> On Wed, Jul 02, 2014 at 02:22:01PM -0600, Bjorn Helgaas wrote:
>> On Tue, Jun 10, 2014 at 03:10:30PM +0200, Alexander Gordeev wrote:
>> > There are PCI devices that require a particular value written
>> > to the Multiple Message Enable (MME) register while aligned on
>> > power of 2 boundary value of actually used MSI vectors 'nvec'
>> > is a lesser of that MME value:
>> >
>> > roundup_pow_of_two(nvec) < 'Multiple Message Enable'
>> >
>> > However the existing pci_enable_msi_block() interface is not
>> > able to configure such devices, since the value written to the
>> > MME register is calculated from the number of requested MSIs
>> > 'nvec':
>> >
>> > 'Multiple Message Enable' = roundup_pow_of_two(nvec)
>>
>> For MSI, software learns how many vectors a device requests by reading
>> the Multiple Message Capable (MMC) field. This field is encoded, so a
>> device can only request 1, 2, 4, 8, etc., vectors. It's impossible
>> for a device to request 3 vectors; it would have to round up that up
>> to a power of two and request 4 vectors.
>>
>> Software writes similarly encoded values to MME to tell the device how
>> many vectors have been allocated for its use. For example, it's
>> impossible to tell the device that it can use 3 vectors; the OS has to
>> round that up and tell the device it can use 4 vectors.
>
> Nod.
>
>> So if I understand correctly, the point of this series is to take
>> advantage of device-specific knowledge, e.g., the device requests 4
>> vectors via MMC, but we "know" the device is only capable of using 3.
>> Moreover, we tell the device via MME that 4 vectors are available, but
>> we've only actually set up 3 of them.
>
> Exactly.
>
>> This makes me uneasy because we're lying to the device, and the device
>> is perfectly within spec to use all 4 of those vectors. If anything
>> changes the number of vectors the device uses (new device revision,
>> firmware upgrade, etc.), this is liable to break.
>
> If a device committed via non-MSI specific means to send only 3 vectors
> out of 4 available why should we expect it to send 4? The probability of
> a firmware sending 4/4 vectors in this case is equal to the probability
> of sending 5/4 or 16/4, with the very same reason - a bug in the firmware.
> Moreover, even vector 4/4 would be unexpected by the device driver, though
> it is perfectly within the spec.
>
> As of new device revision or firmware update etc. - it is just yet another
> case of device driver vs the firmware match/mismatch. Not including this
> change does not help here at all IMHO.
>
>> Can you quantify the benefit of this? Can't a device already use
>> MSI-X to request exactly the number of vectors it can use? (I know
>
> A Intel AHCI chipset requires 16 vectors written to MME while advertises
> (via AHCI registers) and uses only 6. Even attempt to init 8 vectors results
> in device's fallback to 1 (!).
Is the fact that it uses only 6 vectors documented in the public spec?
Is this a chipset erratum? Are there newer versions of the chipset
that fix this, e.g., by requesting 8 vectors and using 6, or by also
supporting MSI-X?
I know this conserves vector numbers. What does that mean in real
user-visible terms? Are there systems that won't boot because of this
issue, and this patch fixes them? Does it enable bigger
configurations, e.g., more I/O devices, than before?
Do you know how Windows handles this? Does it have a similar interface?
As you can tell, I'm a little skeptical about this. It's a fairly big
change, it affects the arch interface, it seems to be targeted for
only a single chipset (though it's widely used), and we already
support a standard solution (MSI-X, reducing the number of vectors
requested, or even operating with 1 vector).
Bjorn
^ permalink raw reply
* Re: [PATCH 1/3] PCI/MSI: Add pci_enable_msi_partial()
From: Alexander Gordeev @ 2014-07-07 20:42 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-mips@linux-mips.org, linux-s390, linux-pci@vger.kernel.org,
x86@kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org,
open list:INTEL IOMMU (VT-d), xen-devel, linuxppc-dev
In-Reply-To: <CAErSpo6f6RXWv0DEtLBZX0jXoSUYJeWrSm7mubSJ_F-O7tQp6w@mail.gmail.com>
On Mon, Jul 07, 2014 at 01:40:48PM -0600, Bjorn Helgaas wrote:
> As you can tell, I'm a little skeptical about this. It's a fairly big
> change, it affects the arch interface, it seems to be targeted for
> only a single chipset (though it's widely used), and we already
> support a standard solution (MSI-X, reducing the number of vectors
> requested, or even operating with 1 vector).
Bjorn,
I surely understand your concerns. I am answering this "summary"
question right away.
Even though an extra parameter is introduced, functionally this update
is rather small. It is only the new pci_enable_msi_partial() function
that could exploit a custom 'nvec_mme' parameter. By contrast, existing
pci_enable_msi_range() function (and therefore all device drivers) is
unaffected - it just rounds up 'nvec' to the nearest power of two and
continues exactly as it has been. All archs besides x86 just ignore it.
And x86 change is fairly small as well - all necessary functionality is
already in.
Thus, at the moment it is only AHCI of concern. And no, AHCI can not do MSI-X..
Thanks!
> Bjorn
--
Regards,
Alexander Gordeev
agordeev@redhat.com
^ permalink raw reply
* Re: [PATCH] devicetree/bindings: Add binding for micron n25q512a memory
From: Scott Wood @ 2014-07-07 21:25 UTC (permalink / raw)
To: Jain Priyanka-B32167
Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-mtd@lists.infradead.org, linux-spi@vger.kernel.org
In-Reply-To: <b7e1d3bf1675492585121d9e7950f05a@BLUPR03MB135.namprd03.prod.outlook.com>
On Thu, 2014-07-03 at 23:08 -0500, Jain Priyanka-B32167 wrote:
>
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Friday, July 04, 2014 3:40 AM
> > To: Jain Priyanka-B32167
> > Cc: devicetree@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; linux-
> > spi@vger.kernel.org; linux-mtd@lists.infradead.org
> > Subject: Re: [PATCH] devicetree/bindings: Add binding for micron n25q512a
> > memory
> >
> > On Thu, 2014-07-03 at 15:42 +0530, Priyanka Jain wrote:
> > > -Micron n25q512a memory is supported by m25p80 driver.
> > > Add compatible field required to support n25q512a in m25p80.txt -Add
> > > micron to the vendor-prefixes.txt file
> > >
> > > Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
> > > ---
> > > Documentation/devicetree/bindings/mtd/m25p80.txt | 1 +
> > > .../devicetree/bindings/vendor-prefixes.txt | 1 +
> > > 2 files changed, 2 insertions(+), 0 deletions(-)
> >
> > Why did you send this to the ppc list but not the spi or mtd lists?
> >
> [Jain Priyanka-B32167] Sorry, I missed that
> > I'm having a hard time following the flow of how these SPI devices get
> > bound -- is the compatible involved at all? I don't see this string
> > (with vendor prefix included) in the driver. I do see a table that
> > contains what looks like device IDs. If the device can report its id,
> > shouldn't we rely on that rather than device tree compatible?
> >
> > -Scott
> [Jain Priyanka-B32167]
> Spi driver has a check to device name corresponding to device-id and compare to what is passed in dts string.
Please go into more detail. I don't see where the string
"micron,n25q512a" appears in the current kernel. I do see "n25q512a",
but how does that compare successfully with the version of the string
that has a vendor compatible?
Again, is there a device ID that can be read at runtime? Is there a
compatible string that represents a common programming interface?
> New checkpatch script search for exact string match in binding folder. So, I have added this in example.
That check has a lot of false positives when it comes to compatible
strings for specific chips that don't need to be specifically mentioned
in a more generic binding.
-Scott
^ permalink raw reply
* Re: [PATCH][v2] devicetree/binding/powerpc/fsl: Add binding for CPLD
From: Scott Wood @ 2014-07-07 21:29 UTC (permalink / raw)
To: Priyanka Jain; +Cc: devicetree, linuxppc-dev
In-Reply-To: <1404448395-6513-1-git-send-email-Priyanka.Jain@freescale.com>
On Fri, 2014-07-04 at 10:03 +0530, Priyanka Jain wrote:
> Some Freescale boards like T1040RDB have on board CPLD connected on
> the IFC bus. Add binding for this in board.txt file
>
> Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
> ---
> Changes for v2:
> convert board name to lower-case based on Scott's suggestions
>
> .../devicetree/bindings/powerpc/fsl/board.txt | 19 +++++++++++++++++++
> 1 files changed, 19 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/board.txt b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
> index 700dec4..f35f295 100644
> --- a/Documentation/devicetree/bindings/powerpc/fsl/board.txt
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
> @@ -84,3 +84,22 @@ Example:
> compatible = "fsl,bsc9132qds-fpga", "fsl,fpga-qixis-i2c";
> reg = <0x66>;
> };
> +
> +* Freescale on-board CPLD
> +
> +Some Freescale boards like T1040RDB have on board CPLD connected on
> +the IFC bus.
> +
> +Required properties:
> +- compatible: Should be a board-specific string like "fsl,<board>-cpld"
> + Example:
> + "fsl,t1040rdb-cpld", "fsl,t1042rdb-cpld", "fsl,t1042rdb_pi-cpld"
> +- reg: Should contain the chip select, address offset and length of the CPLD
We don't say "chip select, address offset and length" anywhere else in
this document. The reg format expected by the parent node should be
documented in the binding for the parent node (e.g. you could find the
node with a different reg format if for some reason it's not under a
localbus node, such as may happen in certain virtualization
scenarios).
All you need to say here is that there is one reg region, which
describes the CPLD registers.
> +Example:
> + cpld@3,0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
Why do you need #address-cells/#size-cells?
If you do need them, where is ranges and/or a description of what the
child reg format is?
-Scott
^ permalink raw reply
* Re: [PATCH] devicetree/bindings/powerpc/fsl: Add binding for board
From: Scott Wood @ 2014-07-07 21:30 UTC (permalink / raw)
To: Priyanka Jain; +Cc: devicetree, linuxppc-dev
In-Reply-To: <1404722194-8103-1-git-send-email-Priyanka.Jain@freescale.com>
On Mon, 2014-07-07 at 14:06 +0530, Priyanka Jain wrote:
> Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
> ---
> .../devicetree/bindings/powerpc/fsl/board.txt | 17 ++++++++++++++++-
> 1 files changed, 16 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/board.txt b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
> index f35f295..7800729 100644
> --- a/Documentation/devicetree/bindings/powerpc/fsl/board.txt
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
> @@ -1,8 +1,23 @@
> Freescale Reference Board Bindings
>
> -This document describes device tree bindings for various devices that
> +This document describes device tree bindings for board and various devices that
> exist on some Freescale reference boards.
>
> +* Board node
> +Required properties:
> +
> + - model : Should be "fsl,<board>"
> + - compatible : Should be "fsl,<board>"
> + example: "fsl,T1040RDB", "fsl,T1042RDB", "fsl,T1042RDB_PI"
> + "fsl,T1040QDS", "fsl,T1042QDS"
> +
> +Example:
> +
> +/ {
> + model = "fsl,T1040RDB";
> + compatible = "fsl,T1040RDB";
> +};
We really don't need to do this for every board just to satisfy
checkpatch.
-Scott
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox