* Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
From: Alan Modra @ 2014-05-14 5:42 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Guenter Roeck
In-Reply-To: <20140514133434.13b66009@canb.auug.org.au>
On Wed, May 14, 2014 at 01:34:34PM +1000, Stephen Rothwell wrote:
> OK, this appears to be an assembler bug.
Agreed. Upgrade binutils!
> $ cat test.s
> .text
> x:
> .pushsection b, "a"
> beq y
> .popsection
> .=0x80000
> y:
> $ /opt/cross/gcc-4.6.3-nolibc/powerpc64-linux/bin/powerpc64-linux-as --version
> GNU assembler (GNU Binutils) 2.22
> This assembler was configured for a target of `powerpc64-linux'.
> $ /opt/cross/gcc-4.6.3-nolibc/powerpc64-linux/bin/powerpc64-linux-as -o test.o test.s
> test.s: Assembler messages:
> test.s:4: Error: operand out of range (0x0000000000080000 is not between 0xffffffffffff8000 and 0x0000000000007ffc)
> $ /opt/cross/gcc-4.8.1-nolibc/powerpc64-linux/bin/powerpc64-linux-as --version
> GNU assembler (GNU Binutils) 2.23.52.20130512
> This assembler was configured for a target of `powerpc64-linux'.
> $ /opt/cross/gcc-4.8.1-nolibc/powerpc64-linux/bin/powerpc64-linux-as -o test.o test.s
> (no error)
>
> Alan, can you shed light on when it was fixed?
2012-11-05
https://sourceware.org/ml/binutils/2012-11/msg00043.html
git show 3b8b57a9495016b2b02fbc2612dd1607d4b6f9ba
The part that actually fixes this problem is "Leave insn field zero...".
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply
* Re: [PATCH V2 2/3] powerpc, ptrace: Enable support for transactional memory register sets
From: Anshuman Khandual @ 2014-05-14 5:46 UTC (permalink / raw)
To: Pedro Alves; +Cc: mikey, avagin, oleg, linux-kernel, michael, linuxppc-dev
In-Reply-To: <537252C0.6090005@redhat.com>
On 05/13/2014 10:43 PM, Pedro Alves wrote:
> On 05/05/14 08:54, Anshuman Khandual wrote:
>> This patch enables get and set of transactional memory related register
>> sets through PTRACE_GETREGSET/PTRACE_SETREGSET interface by implementing
>> four new powerpc specific register sets i.e REGSET_TM_SPR, REGSET_TM_CGPR,
>> REGSET_TM_CFPR, REGSET_CVMX support corresponding to these following new
>> ELF core note types added previously in this regard.
>>
>> (1) NT_PPC_TM_SPR
>> (2) NT_PPC_TM_CGPR
>> (3) NT_PPC_TM_CFPR
>> (4) NT_PPC_TM_CVMX
>
> Sorry that I couldn't tell this from the code, but, what does the
> kernel return when the ptracer requests these registers and the
> program is not in a transaction? Specifically I'm wondering whether
> this follows the same semantics as the s390 port.
>
Right now, it still returns the saved state of the registers from thread
struct. I had assumed that the user must know the state of the transaction
before initiating the ptrace request. I guess its better to check for
the transaction status before processing the request. In case if TM is not
active on that thread, we should return -EINVAL.
I am not familiar with the s390 side of code. But if we look at the
s390_tdb_get function it checks for (regs->int_code & 0x200) before
processing the request. Not sure what 0x200 signifies though.
^ permalink raw reply
* Re: [PATCH V2 2/3] powerpc, ptrace: Enable support for transactional memory register sets
From: Anshuman Khandual @ 2014-05-14 5:49 UTC (permalink / raw)
To: Pedro Alves
Cc: mikey, avagin, Roland McGrath, linux-kernel, oleg, michael,
linuxppc-dev
In-Reply-To: <5372547D.8040209@redhat.com>
On 05/13/2014 10:51 PM, Pedro Alves wrote:
> I wonder whether people are getting Roland's address from?
>
> It's frequent that ptrace related patches end up CCed to
> roland@redhat.com, but, he's not been at Red Hat for a few years
> now. Roland, do you still want to be CCed on ptrace-related
> issues? If so, there's probably a script somewhere in the
> kernel that needs updating. If not, well, it'd be good
> if it were updated anyway. :-)
>
> It's a little annoying, as Red Hat's servers outright reject
> email sent from a @redhat.com address if one tries to send
> an email that includes a CC/FROM to a user that no longer
> exists in the @redhat.com domain.
Got the email address from some of the previous ptrace related
commits.
^ permalink raw reply
* Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
From: Alan Modra @ 2014-05-14 5:52 UTC (permalink / raw)
To: Guenter Roeck; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <5372FC43.6010707@roeck-us.net>
On Tue, May 13, 2014 at 10:16:51PM -0700, Guenter Roeck wrote:
> any idea what might cause this one, by any chance ?
>
> arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e':
> (.text+0x165ee): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_base_book3e' defined in .text section in arch/powerpc/kernel/built-in.o
> arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e':
> (.text+0x16602): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_end_book3e' defined in .text section in arch/powerpc/kernel/built-in.o
> arch/powerpc/kernel/built-in.o: In function `exc_debug_debug_book3e':
>
> I see this if I try to build powerpc:ppc64e_defconfig or powerpc:chroma_defconfig
> with gcc 4.8.2 and binutils 2.24.
Blame me. I changed the ABI, something that had to be done but
unfortunately happens to break the booke kernel code. When building
up a 64-bit value with lis, ori, shl, oris, ori or similar sequences,
you now should use @high and @higha in place of @h and @ha. @h and
@ha (and their associated relocs R_PPC64_ADDR16_HI and
R_PPC64_ADDR16_HA) now report overflow if the value is out of 32-bit
signed range. ie. @h and @ha assume you're building a 32-bit value.
This is needed to report out-of-range -mcmodel=medium toc pointer
offsets in @toc@h and @toc@ha expressions, and for consistency I did
the same for all other @h and @ha relocs.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply
* [PATCH] powerpc/powernv: hwmon driver for power values, fan rpm and temperature
From: Neelesh Gupta @ 2014-05-14 6:01 UTC (permalink / raw)
To: linuxppc-dev, linux, jdelvare, lm-sensors; +Cc: sbhat
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.
Test results:
-------------
[root@tul163p1 ~]# sensors
ibmpowernv-isa-0000
Adapter: ISA adapter
fan1: 5294 RPM (min = 0 RPM)
fan2: 4945 RPM (min = 0 RPM)
fan3: 5831 RPM (min = 0 RPM)
fan4: 5212 RPM (min = 0 RPM)
fan5: 0 RPM (min = 0 RPM)
fan6: 0 RPM (min = 0 RPM)
fan7: 7472 RPM (min = 0 RPM)
fan8: 7920 RPM (min = 0 RPM)
temp1: +39.0°C (high = +0.0°C)
power1: 192.00 W
[root@tul163p1 ~]#
[root@tul163p1 ~]# ls /sys/devices/platform/ibmpowernv.0/
driver fan2_min fan4_min fan6_min fan8_min modalias uevent
fan1_fault fan3_fault fan5_fault fan7_fault hwmon name
fan1_input fan3_input fan5_input fan7_input in1_fault power1_input
fan1_min fan3_min fan5_min fan7_min in2_fault subsystem
fan2_fault fan4_fault fan6_fault fan8_fault in3_fault temp1_input
fan2_input fan4_input fan6_input fan8_input in4_fault temp1_max
[root@tul163p1 ~]#
[root@tul163p1 ~]# ls /sys/class/hwmon/hwmon0/device/
driver fan2_min fan4_min fan6_min fan8_min modalias uevent
fan1_fault fan3_fault fan5_fault fan7_fault hwmon name
fan1_input fan3_input fan5_input fan7_input in1_fault power1_input
fan1_min fan3_min fan5_min fan7_min in2_fault subsystem
fan2_fault fan4_fault fan6_fault fan8_fault in3_fault temp1_input
fan2_input fan4_input fan6_input fan8_input in4_fault temp1_max
[root@tul163p1 ~]#
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
Signed-off-by: Neelesh Gupta <neelegup@linux.vnet.ibm.com>
---
drivers/hwmon/Kconfig | 8 +
drivers/hwmon/Makefile | 1
drivers/hwmon/ibmpowernv.c | 386 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 395 insertions(+)
create mode 100644 drivers/hwmon/ibmpowernv.c
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index bc196f4..3e308fa 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -554,6 +554,14 @@ 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 platform.
+
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 c48f987..199c401 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..e5cffce
--- /dev/null
+++ b/drivers/hwmon/ibmpowernv.c
@@ -0,0 +1,386 @@
+/*
+ * IBM PowerNV platform sensors for temperature/fan/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; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#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 DRVNAME "ibmpowernv"
+#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 sensors in the POWERNV platform and also index into
+ * 'struct sensor_name'
+ */
+enum sensors {
+ FAN,
+ AMBIENT_TEMP,
+ POWERSUPPLY,
+ POWER,
+ MAX_SENSOR_TYPE,
+};
+
+static struct sensor_name {
+ char *name;
+ char *compatible;
+} sensor_names[] = {
+ {"fan", "ibm,opal-sensor-cooling-fan"},
+ {"temp", "ibm,opal-sensor-amb-temp"},
+ {"in", "ibm,opal-sensor-power-supply"},
+ {"power", "ibm,opal-sensor-power"}
+};
+
+struct platform_data {
+ struct device *hwmon_dev;
+ struct device_attribute name_attr;
+ struct list_head attr_list;
+};
+
+struct sensor_data {
+ u32 id;
+ enum sensors stype;
+ char name[MAX_ATTR_LEN];
+ struct sensor_device_attribute sd_attr;
+ struct list_head list;
+};
+
+/* Platform device representing all the ibmpowernv sensors */
+static struct platform_device *pdevice;
+
+static void get_sensor_index_attr(const char *name, u32 *index, char *attr)
+{
+ char *hash_pos = strchr(name, '#');
+ char *dash_pos;
+ u32 copy_len;
+ char buf[8];
+
+ memset(buf, 0, sizeof(buf));
+ *index = 0;
+ *attr = '\0';
+
+ if (hash_pos) {
+ dash_pos = strchr(hash_pos, '-');
+ if (dash_pos) {
+ copy_len = dash_pos - hash_pos - 1;
+ if (copy_len < sizeof(buf)) {
+ strncpy(buf, hash_pos + 1, copy_len);
+ sscanf(buf, "%d", index);
+ }
+
+ strncpy(attr, dash_pos + 1, MAX_ATTR_LEN);
+ }
+ }
+}
+
+/*
+ * 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 create_hwmon_attr_name(enum sensors stype, const char *node_name,
+ char *hwmon_attr_name)
+{
+ char attr_suffix[MAX_ATTR_LEN];
+ char *attr_name;
+ u32 index;
+
+ get_sensor_index_attr(node_name, &index, attr_suffix);
+ if (!index || !strlen(attr_suffix)) {
+ pr_info("%s: Sensor device node name is invalid, name: %s\n",
+ __func__, node_name);
+ return -EINVAL;
+ }
+
+ 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 (stype == AMBIENT_TEMP)
+ attr_name = "max";
+ else if (stype == FAN)
+ attr_name = "min";
+ else
+ return -ENOENT;
+ } else
+ return -ENOENT;
+
+ snprintf(hwmon_attr_name, MAX_ATTR_LEN, "%s%d_%s",
+ sensor_names[stype].name, index, attr_name);
+ return 0;
+}
+
+static ssize_t show_sensor(struct device *dev, struct device_attribute *devattr,
+ char *buf)
+{
+ struct sensor_device_attribute *sd_attr = to_sensor_dev_attr(devattr);
+ struct sensor_data *sdata = container_of(sd_attr, struct sensor_data,
+ sd_attr);
+ int err;
+ u32 x;
+
+ err = opal_get_sensor_data(sdata->id, &x);
+ if (err) {
+ pr_err("%s: Failed to get opal sensor data\n", __func__);
+ x = -1;
+ }
+
+ /* Convert temperature to milli-degrees */
+ if (sdata->stype == AMBIENT_TEMP && x > 0)
+ x *= 1000;
+ /* Convert power to micro-watts */
+ else if (sdata->stype == POWER && x > 0)
+ x *= 1000000;
+
+ return sprintf(buf, "%d\n", x);
+}
+
+static void remove_device_attrs(struct platform_device *pdev)
+{
+ struct platform_data *pdata = platform_get_drvdata(pdev);
+ struct device *dev = &pdev->dev;
+ struct sensor_data *s, *next;
+
+ list_for_each_entry_safe(s, next, &pdata->attr_list, list) {
+ device_remove_file(dev, &s->sd_attr.dev_attr);
+ list_del(&s->list);
+ kfree(s);
+ }
+}
+
+/*
+ * Iterate through the device tree and for each child of sensor 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 create_device_attrs(struct platform_device *pdev)
+{
+ struct platform_data *pdata = platform_get_drvdata(pdev);
+ struct device *dev = &pdev->dev;
+ struct device_node *opal, *np;
+ struct sensor_data *sdata;
+ const u32 *sensor_id;
+ enum sensors stype;
+ int err;
+
+ opal = of_find_node_by_path("/ibm,opal/sensors");
+ if (!opal) {
+ pr_err("%s: Opal 'sensors' node not found\n", __func__);
+ err = -ENXIO;
+ goto exit;
+ }
+
+ for_each_child_of_node(opal, np) {
+ if (np->name == NULL)
+ continue;
+
+ for (stype = 0; stype < MAX_SENSOR_TYPE; stype++)
+ if (of_device_is_compatible(np,
+ sensor_names[stype].compatible))
+ break;
+
+ if (stype == MAX_SENSOR_TYPE)
+ continue;
+
+ sensor_id = of_get_property(np, "sensor-id", NULL);
+ if (!sensor_id) {
+ pr_info("%s: %s doesn't have sensor-id\n", __func__,
+ np->name);
+ continue;
+ }
+
+ sdata = kzalloc(sizeof(*sdata), GFP_KERNEL);
+ if (!sdata) {
+ pr_err("%s: Failed to allocate memory for sensor_data",
+ __func__);
+ err = -ENOMEM;
+ goto exit_put_node;
+ }
+
+ sdata->id = *sensor_id;
+ sdata->stype = stype;
+ err = create_hwmon_attr_name(stype, np->name, sdata->name);
+ if (err) {
+ pr_err("%s: Failed to create the hwmon attribute name\n",
+ __func__);
+ goto exit_free_sdata;
+ }
+
+ sysfs_attr_init(&sdata->sd_attr.dev_attr.attr);
+ sdata->sd_attr.dev_attr.attr.name = sdata->name;
+ sdata->sd_attr.dev_attr.attr.mode = S_IRUGO;
+ sdata->sd_attr.dev_attr.show = show_sensor;
+
+ /* Create sysfs attribute file */
+ err = device_create_file(dev, &sdata->sd_attr.dev_attr);
+ if (err)
+ goto exit_free_sdata;
+
+ list_add_tail(&sdata->list, &pdata->attr_list);
+ }
+
+ of_node_put(opal);
+ return 0;
+
+exit_free_sdata:
+ kfree(sdata);
+exit_put_node:
+ of_node_put(opal);
+ remove_device_attrs(pdev);
+exit:
+ return err;
+}
+
+static ssize_t show_name(struct device *dev, struct device_attribute *devattr,
+ char *buf)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ return sprintf(buf, "%s\n", pdev->name);
+}
+
+static int ibmpowernv_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct platform_data *pdata;
+ int err;
+
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ err = -ENOMEM;
+ goto exit;
+ }
+
+ INIT_LIST_HEAD(&pdata->attr_list);
+ platform_set_drvdata(pdev, pdata);
+
+ /* Create platform device 'name' attribute */
+ sysfs_attr_init(&pdata->name_attr.attr);
+ pdata->name_attr.attr.name = "name";
+ pdata->name_attr.attr.mode = S_IRUGO;
+ pdata->name_attr.show = show_name;
+ err = device_create_file(dev, &pdata->name_attr);
+ if (err)
+ goto exit;
+
+ /* Create sysfs attribute file for each sensor found in the DT */
+ err = create_device_attrs(pdev);
+ if (err) {
+ pr_err("%s: Failed to create the device attributes\n",
+ __func__);
+ goto exit_remove_name;
+ }
+
+ /* Finally, register with hwmon */
+ pdata->hwmon_dev = devm_hwmon_device_register_with_groups(dev, DRVNAME,
+ pdata, NULL);
+ if (IS_ERR(pdata->hwmon_dev)) {
+ err = PTR_ERR(pdata->hwmon_dev);
+ goto exit_remove_devattrs;
+ }
+
+ return 0;
+
+exit_remove_devattrs:
+ remove_device_attrs(pdev);
+exit_remove_name:
+ device_remove_file(dev, &pdata->name_attr);
+exit:
+ return err;
+}
+
+static int ibmpowernv_remove(struct platform_device *pdev)
+{
+ struct platform_data *pdata = platform_get_drvdata(pdev);
+ struct device *dev = &pdev->dev;
+
+ remove_device_attrs(pdev);
+ device_remove_file(dev, &pdata->name_attr);
+
+ return 0;
+}
+
+
+static struct platform_driver ibmpowernv_driver = {
+ .driver = {
+ .owner = THIS_MODULE,
+ .name = DRVNAME,
+ },
+ .probe = ibmpowernv_probe,
+ .remove = ibmpowernv_remove,
+};
+
+
+static int __init ibmpowernv_init(void)
+{
+ int err;
+
+
+ err = platform_driver_register(&ibmpowernv_driver);
+ if (err)
+ goto exit;
+
+
+ pdevice = platform_device_alloc(DRVNAME, 0);
+ if (!pdevice) {
+ pr_err("%s: Device allocation failed\n", __func__);
+ err = -ENOMEM;
+ goto exit_driver_unreg;
+ }
+
+ err = platform_device_add(pdevice);
+ if (err) {
+ pr_err("%s: Device addition failed (%d)\n", __func__, err);
+ goto exit_device_put;
+ }
+
+ return 0;
+
+exit_device_put:
+ platform_device_put(pdevice);
+exit_driver_unreg:
+ platform_driver_unregister(&ibmpowernv_driver);
+exit:
+ return err;
+}
+
+static void __exit ibmpowernv_exit(void)
+{
+ platform_device_unregister(pdevice);
+ platform_driver_unregister(&ibmpowernv_driver);
+}
+
+MODULE_DESCRIPTION("IBM POWERNV platform sensors");
+MODULE_LICENSE("GPL");
+
+module_init(ibmpowernv_init);
+module_exit(ibmpowernv_exit);
^ permalink raw reply related
* Re: Re: [RFT PATCH -next ] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
From: Masami Hiramatsu @ 2014-05-14 8:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Tony Luck
Cc: Jeremy Fitzhardinge, linux-ia64, sparse, H. Peter Anvin,
Thomas Gleixner, linux-tip-commits, anil.s.keshavamurthy,
Ingo Molnar, Fenghua Yu, Arnd Bergmann, Rusty Russell,
Chris Wright, yrl.pp-manager.tt, akataria, Tony Luck, Kevin Hao,
Linus Torvalds, rdunlap, Linux Kernel Mailing List, dl9pf,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <536A2013.8020609@hitachi.com>
(2014/05/07 20:59), Masami Hiramatsu wrote:
> Hi Tony, Benjamin and Paul,
>
> I've tried to fix this bug, but since I don't have either ppc64 nor ia64,
> this patch is not tested on those archs. Please review and test it on
> those machines.
Ping?
I need your help since I don't have test environment.
Thank you,
>
> Thank you,
>
> (2014/05/07 20:55), Masami Hiramatsu wrote:
>> On ia64 and ppc64, the function pointer does not point the
>> entry address of the function, but the address of function
>> discriptor (which contains the entry address and misc
>> data.) Since the kprobes passes the function pointer stored
>> by NOKPROBE_SYMBOL() to kallsyms_lookup_size_offset() for
>> initalizing its blacklist, it fails and reports many errors
>> as below.
>>
>> Failed to find blacklist 0001013168300000
>> Failed to find blacklist 0001013000f0a000
>> Failed to find blacklist 000101315f70a000
>> Failed to find blacklist 000101324c80a000
>> Failed to find blacklist 0001013063f0a000
>> Failed to find blacklist 000101327800a000
>> Failed to find blacklist 0001013277f0a000
>> Failed to find blacklist 000101315a70a000
>> Failed to find blacklist 0001013277e0a000
>> Failed to find blacklist 000101305a20a000
>> Failed to find blacklist 0001013277d0a000
>> Failed to find blacklist 00010130bdc0a000
>> Failed to find blacklist 00010130dc20a000
>> Failed to find blacklist 000101309a00a000
>> Failed to find blacklist 0001013277c0a000
>> Failed to find blacklist 0001013277b0a000
>> Failed to find blacklist 0001013277a0a000
>> Failed to find blacklist 000101327790a000
>> Failed to find blacklist 000101303140a000
>> Failed to find blacklist 0001013a3280a000
>>
>> To fix this bug, this introduces function_entry() macro to
>> retrieve the entry address from the given function pointer,
>> and uses it in NOKPROBE_SYMBOL().
>>
>>
>> Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
>> Reported-by: Tony Luck <tony.luck@gmail.com>
>> Cc: Tony Luck <tony.luck@intel.com>
>> Cc: Fenghua Yu <fenghua.yu@intel.com>
>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> Cc: Paul Mackerras <paulus@samba.org>
>> Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
>> Cc: Kevin Hao <haokexin@gmail.com>
>> Cc: linux-ia64@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Cc: linuxppc-dev@lists.ozlabs.org
>> ---
>> arch/ia64/include/asm/types.h | 2 ++
>> arch/powerpc/include/asm/types.h | 11 +++++++++++
>> include/linux/kprobes.h | 3 ++-
>> include/linux/types.h | 4 ++++
>> 4 files changed, 19 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/ia64/include/asm/types.h b/arch/ia64/include/asm/types.h
>> index 4c351b1..6ab7b6c 100644
>> --- a/arch/ia64/include/asm/types.h
>> +++ b/arch/ia64/include/asm/types.h
>> @@ -27,5 +27,7 @@ struct fnptr {
>> unsigned long gp;
>> };
>>
>> +#define constant_function_entry(fn) (((struct fnptr *)(fn))->ip)
>> +
>> #endif /* !__ASSEMBLY__ */
>> #endif /* _ASM_IA64_TYPES_H */
>> diff --git a/arch/powerpc/include/asm/types.h b/arch/powerpc/include/asm/types.h
>> index bfb6ded..fd297b8 100644
>> --- a/arch/powerpc/include/asm/types.h
>> +++ b/arch/powerpc/include/asm/types.h
>> @@ -25,6 +25,17 @@ typedef struct {
>> unsigned long env;
>> } func_descr_t;
>>
>> +#if defined(CONFIG_PPC64) && (!defined(_CALL_ELF) || _CALL_ELF == 1)
>> +/*
>> + * On PPC64 ABIv1 the function pointer actually points to the
>> + * function's descriptor. The first entry in the descriptor is the
>> + * address of the function text.
>> + */
>> +#define constant_function_entry(fn) (((func_descr_t *)(fn))->entry)
>> +#else
>> +#define constant_function_entry(fn) ((unsigned long)(fn))
>> +#endif
>> +
>> #endif /* __ASSEMBLY__ */
>>
>> #endif /* _ASM_POWERPC_TYPES_H */
>> diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h
>> index e059507..637eafe 100644
>> --- a/include/linux/kprobes.h
>> +++ b/include/linux/kprobes.h
>> @@ -40,6 +40,7 @@
>> #include <linux/rcupdate.h>
>> #include <linux/mutex.h>
>> #include <linux/ftrace.h>
>> +#include <linux/types.h>
>>
>> #ifdef CONFIG_KPROBES
>> #include <asm/kprobes.h>
>> @@ -485,7 +486,7 @@ static inline int enable_jprobe(struct jprobe *jp)
>> #define __NOKPROBE_SYMBOL(fname) \
>> static unsigned long __used \
>> __attribute__((section("_kprobe_blacklist"))) \
>> - _kbl_addr_##fname = (unsigned long)fname;
>> + _kbl_addr_##fname = constant_function_entry(fname);
>> #define NOKPROBE_SYMBOL(fname) __NOKPROBE_SYMBOL(fname)
>> #else
>> #define NOKPROBE_SYMBOL(fname)
>> diff --git a/include/linux/types.h b/include/linux/types.h
>> index 4d118ba..78e2d7d 100644
>> --- a/include/linux/types.h
>> +++ b/include/linux/types.h
>> @@ -212,5 +212,9 @@ struct callback_head {
>> };
>> #define rcu_head callback_head
>>
>> +#ifndef constant_function_entry
>> +#define constant_function_entry(fn) ((unsigned long)(fn))
>> +#endif
>> +
>> #endif /* __ASSEMBLY__ */
>> #endif /* _LINUX_TYPES_H */
>>
>>
>>
>
>
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
^ permalink raw reply
* Re: [PATCH] pci-scan: Fix setting the limit
From: Nikunj A Dadhania @ 2014-05-14 9:52 UTC (permalink / raw)
To: Alexey Kardashevskiy, linuxppc-dev
Cc: Alexey Kardashevskiy, Paul Mackerras, Thomas Huth
In-Reply-To: <1399978118-10298-1-git-send-email-aik@ozlabs.ru>
Alexey Kardashevskiy <aik@ozlabs.ru> writes:
> PCI spec says that lower 20 bits are assumed 0xFFFFF. The existing code
> seems to get it right in pci-bridge-set-mem-limit.
>
> However pci-bridge-set-mem-base does not account 0xFFFFF and poison
> the limit. Since the limit is not stored anywhere in SLOF and only
> besides in the config space, it remains broken.
>
> This fixes pci-bridge-set-mem-base.
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
>
> I have doubts this is the right fix as I tried to "fix"
> pci-bridge-set-mmio-base (while I am here) and it broke the guest.
>
> The problem I am fixing by this is that QEMU started as below is
> unable to initialize virtio-net device because there are overlapping
> virtio's BAR and bridge's "ranges" property. Note that virtio-net is
> attached to the PHB, not that additional bridge.
>
> /home/aik/qemu-system-ppc64 \
> -enable-kvm \
> -m 1024 \
> -machine pseries \
> -nographic \
> -vga none \
> -device pci-bridge,id=id0,bus=pci.0,addr=5.0,chassis_nr=7 \
> -netdev tap,id=id1,ifname=tap1,script=ifup.sh,downscript=ifdown.sh \
> -device virtio-net-pci,id=id2,netdev=id1 \
> -initrd 1.cpio \
> -kernel vml315rc3 \
The problem that I saw here is the brigde device does not have a
downstream pci device. Before probing, we are setting the ranges
property to the max limit, and the probe is done. Once the probe is over
we would update the ranges property.
In this particular case, when we come to update the " ranges" property,
we do not have any range and we skip updating it. Because of this the
old max range property remains there, which is not correct.
Something like the below solves this particular problem. But what would
happen when someone tries to hotplug a pci device to this bridge, will
the pci-hotplug code take care of updating the ranges property?
diff --git a/slof/fs/pci-properties.fs b/slof/fs/pci-properties.fs
index f88a571..f5e934d 100644
--- a/slof/fs/pci-properties.fs
+++ b/slof/fs/pci-properties.fs
@@ -410,6 +410,7 @@
dup IF \ IF any space present (propsize>0)
s" ranges" property \ | write it into the device tree
ELSE \ ELSE
+ s" " s" ranges" property
2drop \ | forget the properties
THEN \ FI
drop \ forget the address
So I do not see the problem when there is a device allocated downstream
to the pci-bridge.
Regards
Nikunj
^ permalink raw reply related
* Re: [PATCH V2 2/3] powerpc, ptrace: Enable support for transactional memory register sets
From: Pedro Alves @ 2014-05-14 11:15 UTC (permalink / raw)
To: Anshuman Khandual, Pedro Alves
Cc: mikey, avagin, oleg, linux-kernel, michael, linuxppc-dev
In-Reply-To: <53730326.6000400@linux.vnet.ibm.com>
On 05/14/14 06:46, Anshuman Khandual wrote:
> On 05/13/2014 10:43 PM, Pedro Alves wrote:
>> On 05/05/14 08:54, Anshuman Khandual wrote:
>>> This patch enables get and set of transactional memory related register
>>> sets through PTRACE_GETREGSET/PTRACE_SETREGSET interface by implementing
>>> four new powerpc specific register sets i.e REGSET_TM_SPR, REGSET_TM_CGPR,
>>> REGSET_TM_CFPR, REGSET_CVMX support corresponding to these following new
>>> ELF core note types added previously in this regard.
>>>
>>> (1) NT_PPC_TM_SPR
>>> (2) NT_PPC_TM_CGPR
>>> (3) NT_PPC_TM_CFPR
>>> (4) NT_PPC_TM_CVMX
>>
>> Sorry that I couldn't tell this from the code, but, what does the
>> kernel return when the ptracer requests these registers and the
>> program is not in a transaction? Specifically I'm wondering whether
>> this follows the same semantics as the s390 port.
>>
>
> Right now, it still returns the saved state of the registers from thread
> struct. I had assumed that the user must know the state of the transaction
> before initiating the ptrace request. I guess its better to check for
> the transaction status before processing the request. In case if TM is not
> active on that thread, we should return -EINVAL.
I think s390 returns ENODATA in that case.
https://sourceware.org/ml/gdb-patches/2013-06/msg00273.html
We'll want some way to tell whether the system actually
supports this. That could be ENODATA vs something-else (EINVAL
or perhaps better EIO for "request is invalid").
s390 actually screwed that, though it got away because
there's a bit in HWCAP to signal transactions support. See:
https://sourceware.org/ml/gdb-patches/2013-11/msg00080.html
Are you adding something to HWCAP too?
>
> I am not familiar with the s390 side of code. But if we look at the
> s390_tdb_get function it checks for (regs->int_code & 0x200) before
> processing the request. Not sure what 0x200 signifies though.
--
Pedro Alves
^ permalink raw reply
* Re: [PATCH V2 2/3] powerpc, ptrace: Enable support for transactional memory register sets
From: Michael Neuling @ 2014-05-14 11:18 UTC (permalink / raw)
To: Pedro Alves
Cc: avagin, oleg, linux-kernel, michael, Linux PPC dev,
Anshuman Khandual
In-Reply-To: <53735044.5030008@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 259 bytes --]
> s390 actually screwed that, though it got away because
> there's a bit in HWCAP to signal transactions support. See:
>
> https://sourceware.org/ml/gdb-patches/2013-11/msg00080.html
>
> Are you adding something to HWCAP too?
Yes but it's in HWCAP2
Mikey
[-- Attachment #2: Type: text/html, Size: 438 bytes --]
^ permalink raw reply
* Re: [PATCH V2 2/3] powerpc, ptrace: Enable support for transactional memory register sets
From: Pedro Alves @ 2014-05-14 11:22 UTC (permalink / raw)
To: Michael Neuling
Cc: avagin, oleg, linux-kernel, michael, Linux PPC dev,
Anshuman Khandual
In-Reply-To: <CAEjGV6y8-zOtOgxcg-6viNQh-RuzQCAy8JvJ+m-dc7XQnAkJmA@mail.gmail.com>
On 05/14/14 12:18, Michael Neuling wrote:
>
>> s390 actually screwed that, though it got away because
>> there's a bit in HWCAP to signal transactions support. See:
>>
>> https://sourceware.org/ml/gdb-patches/2013-11/msg00080.html
>>
>> Are you adding something to HWCAP too?
>
> Yes but it's in HWCAP2
That's fine.
--
Pedro Alves
^ permalink raw reply
* Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
From: Guenter Roeck @ 2014-05-14 15:34 UTC (permalink / raw)
To: Alan Modra; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <20140514055219.GL5162@bubble.grove.modra.org>
On Wed, May 14, 2014 at 03:22:19PM +0930, Alan Modra wrote:
> On Tue, May 13, 2014 at 10:16:51PM -0700, Guenter Roeck wrote:
> > any idea what might cause this one, by any chance ?
> >
> > arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e':
> > (.text+0x165ee): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_base_book3e' defined in .text section in arch/powerpc/kernel/built-in.o
> > arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e':
> > (.text+0x16602): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_end_book3e' defined in .text section in arch/powerpc/kernel/built-in.o
> > arch/powerpc/kernel/built-in.o: In function `exc_debug_debug_book3e':
> >
> > I see this if I try to build powerpc:ppc64e_defconfig or powerpc:chroma_defconfig
> > with gcc 4.8.2 and binutils 2.24.
>
> Blame me. I changed the ABI, something that had to be done but
> unfortunately happens to break the booke kernel code. When building
> up a 64-bit value with lis, ori, shl, oris, ori or similar sequences,
> you now should use @high and @higha in place of @h and @ha. @h and
> @ha (and their associated relocs R_PPC64_ADDR16_HI and
> R_PPC64_ADDR16_HA) now report overflow if the value is out of 32-bit
> signed range. ie. @h and @ha assume you're building a 32-bit value.
> This is needed to report out-of-range -mcmodel=medium toc pointer
> offsets in @toc@h and @toc@ha expressions, and for consistency I did
> the same for all other @h and @ha relocs.
>
Bummer. Confirmed, if I replace "@h" with "@high" in just one place,
the builds pass with binutils 2.24. Unfortunately the same builds then
fails with binutils 2.23.
Any idea how to get it to compile with both old and new versions ?
Is there some predefined constant which I could possibly use for
something like
.if as_version_below_2.24_
oris reg,reg,(expr)@h;
.else
oris reg,reg,(expr)@high;
.endif
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH] powerpc/powernv: hwmon driver for power values, fan rpm and temperature
From: Guenter Roeck @ 2014-05-14 17:09 UTC (permalink / raw)
To: Neelesh Gupta; +Cc: lm-sensors, sbhat, linuxppc-dev, jdelvare
In-Reply-To: <20140514055859.16148.35534.stgit@neelegup-tp-t420.in.ibm.com>
On Wed, May 14, 2014 at 11:31:53AM +0530, Neelesh Gupta wrote:
> 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.
>
> Test results:
> -------------
> [root@tul163p1 ~]# sensors
> ibmpowernv-isa-0000
> Adapter: ISA adapter
> fan1: 5294 RPM (min = 0 RPM)
> fan2: 4945 RPM (min = 0 RPM)
> fan3: 5831 RPM (min = 0 RPM)
> fan4: 5212 RPM (min = 0 RPM)
> fan5: 0 RPM (min = 0 RPM)
> fan6: 0 RPM (min = 0 RPM)
> fan7: 7472 RPM (min = 0 RPM)
> fan8: 7920 RPM (min = 0 RPM)
> temp1: +39.0°C (high = +0.0°C)
> power1: 192.00 W
>
> [root@tul163p1 ~]#
> [root@tul163p1 ~]# ls /sys/devices/platform/ibmpowernv.0/
> driver fan2_min fan4_min fan6_min fan8_min modalias uevent
> fan1_fault fan3_fault fan5_fault fan7_fault hwmon name
> fan1_input fan3_input fan5_input fan7_input in1_fault power1_input
> fan1_min fan3_min fan5_min fan7_min in2_fault subsystem
> fan2_fault fan4_fault fan6_fault fan8_fault in3_fault temp1_input
> fan2_input fan4_input fan6_input fan8_input in4_fault temp1_max
> [root@tul163p1 ~]#
> [root@tul163p1 ~]# ls /sys/class/hwmon/hwmon0/device/
> driver fan2_min fan4_min fan6_min fan8_min modalias uevent
> fan1_fault fan3_fault fan5_fault fan7_fault hwmon name
> fan1_input fan3_input fan5_input fan7_input in1_fault power1_input
> fan1_min fan3_min fan5_min fan7_min in2_fault subsystem
> fan2_fault fan4_fault fan6_fault fan8_fault in3_fault temp1_input
> fan2_input fan4_input fan6_input fan8_input in4_fault temp1_max
> [root@tul163p1 ~]#
>
> Signed-off-by: Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
> Signed-off-by: Neelesh Gupta <neelegup@linux.vnet.ibm.com>
> ---
> drivers/hwmon/Kconfig | 8 +
> drivers/hwmon/Makefile | 1
> drivers/hwmon/ibmpowernv.c | 386 ++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 395 insertions(+)
> create mode 100644 drivers/hwmon/ibmpowernv.c
>
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index bc196f4..3e308fa 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -554,6 +554,14 @@ 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 platform.
> +
> 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 c48f987..199c401 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..e5cffce
> --- /dev/null
> +++ b/drivers/hwmon/ibmpowernv.c
> @@ -0,0 +1,386 @@
> +/*
> + * IBM PowerNV platform sensors for temperature/fan/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; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Please drop the FSF address; it can change, and we don't want to update the
driver each time it does.
> + */
> +
> +#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 DRVNAME "ibmpowernv"
> +#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 sensors in the POWERNV platform and also index into
> + * 'struct sensor_name'
Comment coding style, please (this is not the networking subsystem ;-)
> + */
> +enum sensors {
> + FAN,
> + AMBIENT_TEMP,
> + POWERSUPPLY,
> + POWER,
> + MAX_SENSOR_TYPE,
> +};
> +
> +static struct sensor_name {
const ?
> + char *name;
> + char *compatible;
> +} sensor_names[] = {
> + {"fan", "ibm,opal-sensor-cooling-fan"},
> + {"temp", "ibm,opal-sensor-amb-temp"},
> + {"in", "ibm,opal-sensor-power-supply"},
> + {"power", "ibm,opal-sensor-power"}
> +};
> +
> +struct platform_data {
> + struct device *hwmon_dev;
Not needed.
> + struct device_attribute name_attr;
> + struct list_head attr_list;
> +};
> +
> +struct sensor_data {
> + u32 id;
> + enum sensors stype;
> + char name[MAX_ATTR_LEN];
> + struct sensor_device_attribute sd_attr;
> + struct list_head list;
> +};
> +
> +/* Platform device representing all the ibmpowernv sensors */
> +static struct platform_device *pdevice;
> +
> +static void get_sensor_index_attr(const char *name, u32 *index, char *attr)
> +{
> + char *hash_pos = strchr(name, '#');
> + char *dash_pos;
> + u32 copy_len;
> + char buf[8];
> +
> + memset(buf, 0, sizeof(buf));
> + *index = 0;
> + *attr = '\0';
> +
> + if (hash_pos) {
> + dash_pos = strchr(hash_pos, '-');
> + if (dash_pos) {
> + copy_len = dash_pos - hash_pos - 1;
> + if (copy_len < sizeof(buf)) {
> + strncpy(buf, hash_pos + 1, copy_len);
> + sscanf(buf, "%d", index);
> + }
> +
> + strncpy(attr, dash_pos + 1, MAX_ATTR_LEN);
> + }
> + }
> +}
> +
> +/*
> + * 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 create_hwmon_attr_name(enum sensors stype, const char *node_name,
> + char *hwmon_attr_name)
Please follow CodingStyle for continuation line alignment.
> +{
> + char attr_suffix[MAX_ATTR_LEN];
> + char *attr_name;
> + u32 index;
> +
> + get_sensor_index_attr(node_name, &index, attr_suffix);
> + if (!index || !strlen(attr_suffix)) {
> + pr_info("%s: Sensor device node name is invalid, name: %s\n",
> + __func__, node_name);
> + return -EINVAL;
> + }
> +
> + 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 (stype == AMBIENT_TEMP)
> + attr_name = "max";
> + else if (stype == FAN)
> + attr_name = "min";
> + else
> + return -ENOENT;
> + } else
> + return -ENOENT;
> +
> + snprintf(hwmon_attr_name, MAX_ATTR_LEN, "%s%d_%s",
> + sensor_names[stype].name, index, attr_name);
> + return 0;
> +}
> +
> +static ssize_t show_sensor(struct device *dev, struct device_attribute *devattr,
> + char *buf)
> +{
> + struct sensor_device_attribute *sd_attr = to_sensor_dev_attr(devattr);
> + struct sensor_data *sdata = container_of(sd_attr, struct sensor_data,
> + sd_attr);
> + int err;
> + u32 x;
> +
> + err = opal_get_sensor_data(sdata->id, &x);
> + if (err) {
> + pr_err("%s: Failed to get opal sensor data\n", __func__);
> + x = -1;
Unusual. Why not report the error to user space ?
Reporting <maxuint> on error doesn't seem to be very useful.
> + }
> +
> + /* Convert temperature to milli-degrees */
> + if (sdata->stype == AMBIENT_TEMP && x > 0)
> + x *= 1000;
> + /* Convert power to micro-watts */
> + else if (sdata->stype == POWER && x > 0)
> + x *= 1000000;
> +
Is there an overflow concern ? Guess not ... overflow happens at ~17KW.
Just wondering.
> + return sprintf(buf, "%d\n", x);
> +}
> +
> +static void remove_device_attrs(struct platform_device *pdev)
> +{
> + struct platform_data *pdata = platform_get_drvdata(pdev);
> + struct device *dev = &pdev->dev;
> + struct sensor_data *s, *next;
> +
> + list_for_each_entry_safe(s, next, &pdata->attr_list, list) {
> + device_remove_file(dev, &s->sd_attr.dev_attr);
> + list_del(&s->list);
This is unnecessary since you always remove the entire list anyway.
Actually, I don't think you need the list in the first place.
You only use it to delete entries, but that can be handled automatically
by the infrastructure. All you really need is an array pointing to the device
attributes so you can create all attribute files with a single operation.
> + kfree(s);
> + }
> +}
> +
> +/*
> + * Iterate through the device tree and for each child of sensor 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 create_device_attrs(struct platform_device *pdev)
> +{
> + struct platform_data *pdata = platform_get_drvdata(pdev);
> + struct device *dev = &pdev->dev;
> + struct device_node *opal, *np;
> + struct sensor_data *sdata;
> + const u32 *sensor_id;
> + enum sensors stype;
> + int err;
> +
> + opal = of_find_node_by_path("/ibm,opal/sensors");
> + if (!opal) {
> + pr_err("%s: Opal 'sensors' node not found\n", __func__);
> + err = -ENXIO;
ENODEV ?
> + goto exit;
I would suggest to simply return here.
> + }
> +
> + for_each_child_of_node(opal, np) {
> + if (np->name == NULL)
> + continue;
> +
> + for (stype = 0; stype < MAX_SENSOR_TYPE; stype++)
> + if (of_device_is_compatible(np,
> + sensor_names[stype].compatible))
> + break;
> +
> + if (stype == MAX_SENSOR_TYPE)
> + continue;
> +
> + sensor_id = of_get_property(np, "sensor-id", NULL);
> + if (!sensor_id) {
> + pr_info("%s: %s doesn't have sensor-id\n", __func__,
> + np->name);
> + continue;
> + }
> +
> + sdata = kzalloc(sizeof(*sdata), GFP_KERNEL);
Can you use devm_kzalloc() ?
> + if (!sdata) {
> + pr_err("%s: Failed to allocate memory for sensor_data",
> + __func__);
> + err = -ENOMEM;
> + goto exit_put_node;
> + }
> +
> + sdata->id = *sensor_id;
> + sdata->stype = stype;
> + err = create_hwmon_attr_name(stype, np->name, sdata->name);
> + if (err) {
> + pr_err("%s: Failed to create the hwmon attribute name\n",
> + __func__);
create_hwmon_attr_name() (sometimes) already creates an error message.
Would be nice if you can avoid duplicate error messages.
> + goto exit_free_sdata;
> + }
> +
> + sysfs_attr_init(&sdata->sd_attr.dev_attr.attr);
> + sdata->sd_attr.dev_attr.attr.name = sdata->name;
> + sdata->sd_attr.dev_attr.attr.mode = S_IRUGO;
> + sdata->sd_attr.dev_attr.show = show_sensor;
Since you are not using the index value from sensor_device_attribute,
but use your own 'id' variable instead, you don't need sensor_device_attribute
but can use device_attribute instead (or drop 'id' and use
sd_attr.index instead).
> +
> + /* Create sysfs attribute file */
> + err = device_create_file(dev, &sdata->sd_attr.dev_attr);
> + if (err)
> + goto exit_free_sdata;
> +
Please don't create the attribute files here but just a list of attributes
instead. See below for more details.
> + list_add_tail(&sdata->list, &pdata->attr_list);
> + }
> +
> + of_node_put(opal);
> + return 0;
> +
> +exit_free_sdata:
> + kfree(sdata);
> +exit_put_node:
> + of_node_put(opal);
> + remove_device_attrs(pdev);
> +exit:
> + return err;
> +}
> +
> +static ssize_t show_name(struct device *dev, struct device_attribute *devattr,
> + char *buf)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + return sprintf(buf, "%s\n", pdev->name);
> +}
Not necessary; see below.
> +
> +static int ibmpowernv_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct platform_data *pdata;
> + int err;
> +
> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata) {
> + err = -ENOMEM;
> + goto exit;
> + }
> +
> + INIT_LIST_HEAD(&pdata->attr_list);
> + platform_set_drvdata(pdev, pdata);
> +
> + /* Create platform device 'name' attribute */
> + sysfs_attr_init(&pdata->name_attr.attr);
> + pdata->name_attr.attr.name = "name";
> + pdata->name_attr.attr.mode = S_IRUGO;
> + pdata->name_attr.show = show_name;
> + err = device_create_file(dev, &pdata->name_attr);
You don't need to create a name attribute.
devm_hwmon_device_register_with_groups does it for you (from the second
argument).
> + if (err)
> + goto exit;
> +
> + /* Create sysfs attribute file for each sensor found in the DT */
> + err = create_device_attrs(pdev);
That defeats the purpose of using devm_hwmon_device_register_with_groups.
The idea here is to build a list of attributes, which you can do in
create_device_attrs(), but not create the actual device entries.
Then also create an attribute_group as well as a list of groups,
and pass that as last argument to devm_hwmon_device_register_with_groups().
drivers/hwmon/pmbus/pmbus_core.c does something similar; maybe you can
use a similar approach.
With that, you also don't need the remove functions, since the hwmon
subsystem will auto-remove the attributes. If you do it correctly
(ie use devm_kzalloc() for allocating memory) you should not need a
remove function at all.
> + if (err) {
> + pr_err("%s: Failed to create the device attributes\n",
> + __func__);
> + goto exit_remove_name;
> + }
> +
> + /* Finally, register with hwmon */
> + pdata->hwmon_dev = devm_hwmon_device_register_with_groups(dev, DRVNAME,
> + pdata, NULL);
> + if (IS_ERR(pdata->hwmon_dev)) {
> + err = PTR_ERR(pdata->hwmon_dev);
> + goto exit_remove_devattrs;
> + }
> +
> + return 0;
> +
> +exit_remove_devattrs:
> + remove_device_attrs(pdev);
> +exit_remove_name:
> + device_remove_file(dev, &pdata->name_attr);
> +exit:
> + return err;
If you do it right you should be able to reduce this to something like
hwmon_dev = devm_hwmon_device_register_with_groups(dev, DRVNAME, pdata,
pdata->attr_groups);
return PTR_ERR_OR_ZERO(hwmon_dev);
...
> +}
> +
> +static int ibmpowernv_remove(struct platform_device *pdev)
> +{
> + struct platform_data *pdata = platform_get_drvdata(pdev);
> + struct device *dev = &pdev->dev;
> +
> + remove_device_attrs(pdev);
> + device_remove_file(dev, &pdata->name_attr);
> +
> + return 0;
> +}
... and you should be able to remove this entire function.
> +
> +
No double empty lines please.
> +static struct platform_driver ibmpowernv_driver = {
> + .driver = {
> + .owner = THIS_MODULE,
> + .name = DRVNAME,
> + },
> + .probe = ibmpowernv_probe,
> + .remove = ibmpowernv_remove,
> +};
> +
> +
Excessive empty lines.
> +static int __init ibmpowernv_init(void)
> +{
> + int err;
> +
> +
Excessive empty lines.
> + err = platform_driver_register(&ibmpowernv_driver);
> + if (err)
> + goto exit;
Sometimes you create an error message, sometimes not. I'd prefer no error
message to start with (the module loader will create one anyway), but
at least please be consistent.
> +
> +
Excessive empty lines.
> + pdevice = platform_device_alloc(DRVNAME, 0);
> + if (!pdevice) {
> + pr_err("%s: Device allocation failed\n", __func__);
> + err = -ENOMEM;
> + goto exit_driver_unreg;
> + }
> +
> + err = platform_device_add(pdevice);
> + if (err) {
> + pr_err("%s: Device addition failed (%d)\n", __func__, err);
> + goto exit_device_put;
> + }
> +
Can you use platform_driver_probe() here ?
> + return 0;
> +
> +exit_device_put:
> + platform_device_put(pdevice);
> +exit_driver_unreg:
> + platform_driver_unregister(&ibmpowernv_driver);
> +exit:
> + return err;
> +}
> +
> +static void __exit ibmpowernv_exit(void)
> +{
> + platform_device_unregister(pdevice);
> + platform_driver_unregister(&ibmpowernv_driver);
> +}
> +
> +MODULE_DESCRIPTION("IBM POWERNV platform sensors");
> +MODULE_LICENSE("GPL");
> +
> +module_init(ibmpowernv_init);
> +module_exit(ibmpowernv_exit);
>
>
Empty lines at end.
^ permalink raw reply
* Re: [PATCH v2] powerpc: Add cpu family documentation
From: James Yang @ 2014-05-14 18:04 UTC (permalink / raw)
To: Scott Wood; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <1398882547.24575.211.camel@snotra.buserror.net>
On Wed, 30 Apr 2014, Scott Wood wrote:
> On Wed, 2014-04-30 at 16:45 +1000, Michael Ellerman wrote:
> > On Tue, 2014-02-04 at 16:43 -0600, Scott Wood wrote:
> > > > +Motorola/Freescale 8xx
> > > > +----------------------
> > > > +
> > > > + - Software loaded with hardware assist.
> > > > + - All 32 bit
> > > > +
> > > > + +--------------+
> > > > + | 8xx |
> > > > + +--------------+
> > > > + |
> > > > + |
> > > > + v
> > > > + +--------------+
> > > > + | 850 |
> > > > + +--------------+
> > >
> > > Is the core of MPC850 different from other MPC8xx?
> >
> > Dunno, maybe someone who works at Freescale knows ;)
>
> I think they're the same -- I was just wondering if you had some
> difference in mind that led you to single it out.
They are the same.
There should not be a separate box that singles out 850. (Still don't
know why the diagram was drawn to single out 850 in the first place.)
The CPU core should be called "MPC8xx Core".
^ permalink raw reply
* [PATCH 02/27] powerpc: Override defaults from generic/tlb.h
From: Richard Weinberger @ 2014-05-14 18:59 UTC (permalink / raw)
To: linux-arch, arnd, linux-kernel
Cc: Richard Weinberger, Paul Mackerras, linuxppc-dev
In-Reply-To: <1400093999-18703-1-git-send-email-richard@nod.at>
Make sure to not conflict with the defaults provided
by generic/tlb.h.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Richard Weinberger <richard@nod.at>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Richard Weinberger <richard@nod.at>
---
arch/powerpc/include/asm/pgalloc.h | 1 -
arch/powerpc/include/asm/tlb.h | 4 ++++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/pgalloc.h b/arch/powerpc/include/asm/pgalloc.h
index e9a9f60..5fddba7 100644
--- a/arch/powerpc/include/asm/pgalloc.h
+++ b/arch/powerpc/include/asm/pgalloc.h
@@ -3,7 +3,6 @@
#ifdef __KERNEL__
#include <linux/mm.h>
-#include <asm-generic/tlb.h>
#ifdef CONFIG_PPC_BOOK3E
extern void tlb_flush_pgtable(struct mmu_gather *tlb, unsigned long address);
diff --git a/arch/powerpc/include/asm/tlb.h b/arch/powerpc/include/asm/tlb.h
index e2b428b..392e5ef 100644
--- a/arch/powerpc/include/asm/tlb.h
+++ b/arch/powerpc/include/asm/tlb.h
@@ -30,6 +30,10 @@
extern void tlb_flush(struct mmu_gather *tlb);
+/* These defines are needed to override the defaults from asm-generic/tlb.h */
+#define tlb_flush tlb_flush
+#define __tlb_remove_tlb_entry __tlb_remove_tlb_entry
+
/* Get the generic bits... */
#include <asm-generic/tlb.h>
--
1.8.4.2
^ permalink raw reply related
* [PATCH 20/27] powerpc: Use common bits from generic tlb.h
From: Richard Weinberger @ 2014-05-14 18:59 UTC (permalink / raw)
To: linux-arch, arnd, linux-kernel
Cc: Richard Weinberger, Paul Mackerras, linuxppc-dev
In-Reply-To: <1400093999-18703-1-git-send-email-richard@nod.at>
It is no longer needed to define them on our own.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Richard Weinberger <richard@nod.at>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Richard Weinberger <richard@nod.at>
---
arch/powerpc/include/asm/tlb.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/powerpc/include/asm/tlb.h b/arch/powerpc/include/asm/tlb.h
index 392e5ef..bdea7f5 100644
--- a/arch/powerpc/include/asm/tlb.h
+++ b/arch/powerpc/include/asm/tlb.h
@@ -25,9 +25,6 @@
#include <linux/pagemap.h>
-#define tlb_start_vma(tlb, vma) do { } while (0)
-#define tlb_end_vma(tlb, vma) do { } while (0)
-
extern void tlb_flush(struct mmu_gather *tlb);
/* These defines are needed to override the defaults from asm-generic/tlb.h */
--
1.8.4.2
^ permalink raw reply related
* roundup_pow_of_two() may not handle 64-bit integers
From: Brian Norris @ 2014-05-15 2:22 UTC (permalink / raw)
To: Linux Kernel
Cc: David Howells, Paul Mackerras, Andrew Morton, Brian Norris,
linuxppc-dev
Hi,
I'm looking to use roundup_pow_of_two() (actually, order_base_2())
from <linux/log2.h>, but it seems that it only supports 64-bit integers
if your toolchain uses a 64-bit 'unsigned long' type. This is strange,
considering that ilog2() is explicitly designed for 32-bit or 64-bit
compatibility.
I also note that there is at least one location in which this limitation
currently might be problematic: in pnv_pci_ioda2_set_bypass()
(arch/powerpc/platforms/powernv/pci-ioda.c). It looks like this could be
a problem if using large amounts of DRAM on a 32-bit PPC build, with
64-bit physical addresses.
(There may be other cases like this one, but I haven't closely studied
all callers of roundup_pow_of_two().)
I'm thinking of cooking a patch to improve roundup_pow_of_two() (and
thus order_base_2()), but I'd like to solicit comments on the basic
problem first.
Regards,
Brian
P.S. And of course, rounddown_pow_of_two() has the same issue.
^ permalink raw reply
* Re: [PATCH RFC v3 0/8] EEH Support for VFIO PCI device
From: Mike Qiu @ 2014-05-15 6:34 UTC (permalink / raw)
To: Gavin Shan; +Cc: aik, agraf, kvm-ppc, alex.williamson, linuxppc-dev
In-Reply-To: <1400040722-29608-1-git-send-email-gwshan@linux.vnet.ibm.com>
Hi Gavin,
Can error injection be done if EEH is not enbaled?
Thanks
Mike
On 05/14/2014 12:11 PM, Gavin Shan wrote:
> The series of patches intends to support EEH for PCI devices, which are
> passed through to PowerKVM based guest via VFIO. The implementation is
> straightforward based on the issues or problems we have to resolve to
> support EEH for PowerKVM based guest.
>
> - Emulation for EEH RTAS requests. All EEH RTAS requests goes to QEMU firstly.
> If QEMU can't handle it, the request will be sent to host via newly introduced
> VFIO container IOCTL command (VFIO_EEH_INFO) and gets handled in host kernel.
>
> - The error injection infrastructure need support request from the userland
> utility "errinjct" and PowerKVM based guest. The userland utility "errinjct"
> works on pSeries platform well with dedicated syscall, which helps invoking
> RTAS service to fulfil error injection in kernel. From the perspective, it's
> reasonable to extend the syscall to support PowerNV platform so that OPAL call
> can be invoked in host kernel for injecting errors. The data transported
> between userland and kerenl is still following "struct rtas_args" for both
> cases of PowerNV (OPAL) and pSeries (RTAS).
>
> The series of patches requires corresponding firmware changes from Mike Qiu to
> support error injection and QEMU changes to support EEH for guest. QEMU patchset
> will be sent separately.
>
> Change log
> ==========
> v1 -> v2:
> * EEH RTAS requests are routed to QEMU, and then possiblly to host kerenl.
> The mechanism KVM in-kernel handling is dropped.
> * Error injection is reimplemented based syscall, instead of KVM in-kerenl
> handling. The logic for error injection token management is moved to
> QEMU. The error injection request is routed to QEMU and then possiblly
> to host kernel.
> v2 -> v3:
> * Make the fields in struct eeh_vfio_pci_addr, struct vfio_eeh_info based
> on the comments from Alexey.
> * Define macros for EEH VFIO operations (Alexey).
> * Clear frozen state after successful PE reset.
> * Merge original [PATCH 1/2/3] to one.
>
> Testing on P7
> =============
>
> - Emulex adapter
>
> Testing on P8
> =============
>
> - Need more testing after design is finalized.
>
> -----
>
> Gavin Shan (8):
> drivers/vfio: Introduce CONFIG_VFIO_EEH
> powerpc/eeh: Info to trace passed devices
> drivers/vfio: New IOCTL command VFIO_EEH_INFO
> powerpc/eeh: Avoid event on passed PE
> powerpc/powernv: Sync OPAL header file with firmware
> powerpc: Extend syscall ppc_rtas()
> powerpc/powernv: Implement ppc_call_opal()
> powerpc/powernv: Error injection infrastructure
>
> arch/powerpc/include/asm/eeh.h | 52 +++
> arch/powerpc/include/asm/opal.h | 74 ++-
> arch/powerpc/include/asm/rtas.h | 10 +-
> arch/powerpc/include/asm/syscalls.h | 2 +-
> arch/powerpc/include/asm/systbl.h | 2 +-
> arch/powerpc/include/uapi/asm/unistd.h | 2 +-
> arch/powerpc/kernel/eeh.c | 8 +
> arch/powerpc/kernel/eeh_pe.c | 80 ++++
> arch/powerpc/kernel/rtas.c | 57 +--
> arch/powerpc/kernel/syscalls.c | 50 +++
> arch/powerpc/platforms/powernv/Makefile | 3 +-
> arch/powerpc/platforms/powernv/eeh-ioda.c | 3 +-
> arch/powerpc/platforms/powernv/eeh-vfio.c | 593 +++++++++++++++++++++++++
> arch/powerpc/platforms/powernv/errinject.c | 224 ++++++++++
> arch/powerpc/platforms/powernv/opal-wrappers.S | 1 +
> arch/powerpc/platforms/powernv/opal.c | 93 ++++
> drivers/vfio/Kconfig | 6 +
> drivers/vfio/vfio_iommu_spapr_tce.c | 12 +
> include/uapi/linux/vfio.h | 57 +++
> kernel/sys_ni.c | 2 +-
> 20 files changed, 1278 insertions(+), 53 deletions(-)
> create mode 100644 arch/powerpc/platforms/powernv/eeh-vfio.c
> create mode 100644 arch/powerpc/platforms/powernv/errinject.c
>
> Thanks,
> Gavin
>
^ permalink raw reply
* Re: [PATCH RFC v3 0/8] EEH Support for VFIO PCI device
From: Gavin Shan @ 2014-05-15 7:43 UTC (permalink / raw)
To: Mike Qiu; +Cc: aik, Gavin Shan, kvm-ppc, agraf, alex.williamson, linuxppc-dev
In-Reply-To: <53745FF3.6050102@linux.vnet.ibm.com>
On Thu, May 15, 2014 at 02:34:27PM +0800, Mike Qiu wrote:
>Hi Gavin,
>
>Can error injection be done if EEH is not enbaled?
>
Yes, utility "errinject" still can inject PCI errors to host for
testing purpose. Since the PCI errors injected by "errinjct" is
mainly for EEH testing. it would be meaningless to do PCI error
injection without EEH support. So for the case, the hooks doing
real work is being protected by CONFIG_EEH.
The hooks for another case (error injection from "errinject"
utility running on guest) are protected by CONFIG_EEH_VFIO
Thanks,
Gavin
>On 05/14/2014 12:11 PM, Gavin Shan wrote:
>>The series of patches intends to support EEH for PCI devices, which are
>>passed through to PowerKVM based guest via VFIO. The implementation is
>>straightforward based on the issues or problems we have to resolve to
>>support EEH for PowerKVM based guest.
>>
>>- Emulation for EEH RTAS requests. All EEH RTAS requests goes to QEMU firstly.
>> If QEMU can't handle it, the request will be sent to host via newly introduced
>> VFIO container IOCTL command (VFIO_EEH_INFO) and gets handled in host kernel.
>>
>>- The error injection infrastructure need support request from the userland
>> utility "errinjct" and PowerKVM based guest. The userland utility "errinjct"
>> works on pSeries platform well with dedicated syscall, which helps invoking
>> RTAS service to fulfil error injection in kernel. From the perspective, it's
>> reasonable to extend the syscall to support PowerNV platform so that OPAL call
>> can be invoked in host kernel for injecting errors. The data transported
>> between userland and kerenl is still following "struct rtas_args" for both
>> cases of PowerNV (OPAL) and pSeries (RTAS).
>>
>>The series of patches requires corresponding firmware changes from Mike Qiu to
>>support error injection and QEMU changes to support EEH for guest. QEMU patchset
>>will be sent separately.
>>
>>Change log
>>==========
>>v1 -> v2:
>> * EEH RTAS requests are routed to QEMU, and then possiblly to host kerenl.
>> The mechanism KVM in-kernel handling is dropped.
>> * Error injection is reimplemented based syscall, instead of KVM in-kerenl
>> handling. The logic for error injection token management is moved to
>> QEMU. The error injection request is routed to QEMU and then possiblly
>> to host kernel.
>>v2 -> v3:
>> * Make the fields in struct eeh_vfio_pci_addr, struct vfio_eeh_info based
>> on the comments from Alexey.
>> * Define macros for EEH VFIO operations (Alexey).
>> * Clear frozen state after successful PE reset.
>> * Merge original [PATCH 1/2/3] to one.
>>
>>Testing on P7
>>=============
>>
>>- Emulex adapter
>>
>>Testing on P8
>>=============
>>
>>- Need more testing after design is finalized.
>>
>>-----
>>
>>Gavin Shan (8):
>> drivers/vfio: Introduce CONFIG_VFIO_EEH
>> powerpc/eeh: Info to trace passed devices
>> drivers/vfio: New IOCTL command VFIO_EEH_INFO
>> powerpc/eeh: Avoid event on passed PE
>> powerpc/powernv: Sync OPAL header file with firmware
>> powerpc: Extend syscall ppc_rtas()
>> powerpc/powernv: Implement ppc_call_opal()
>> powerpc/powernv: Error injection infrastructure
>>
>> arch/powerpc/include/asm/eeh.h | 52 +++
>> arch/powerpc/include/asm/opal.h | 74 ++-
>> arch/powerpc/include/asm/rtas.h | 10 +-
>> arch/powerpc/include/asm/syscalls.h | 2 +-
>> arch/powerpc/include/asm/systbl.h | 2 +-
>> arch/powerpc/include/uapi/asm/unistd.h | 2 +-
>> arch/powerpc/kernel/eeh.c | 8 +
>> arch/powerpc/kernel/eeh_pe.c | 80 ++++
>> arch/powerpc/kernel/rtas.c | 57 +--
>> arch/powerpc/kernel/syscalls.c | 50 +++
>> arch/powerpc/platforms/powernv/Makefile | 3 +-
>> arch/powerpc/platforms/powernv/eeh-ioda.c | 3 +-
>> arch/powerpc/platforms/powernv/eeh-vfio.c | 593 +++++++++++++++++++++++++
>> arch/powerpc/platforms/powernv/errinject.c | 224 ++++++++++
>> arch/powerpc/platforms/powernv/opal-wrappers.S | 1 +
>> arch/powerpc/platforms/powernv/opal.c | 93 ++++
>> drivers/vfio/Kconfig | 6 +
>> drivers/vfio/vfio_iommu_spapr_tce.c | 12 +
>> include/uapi/linux/vfio.h | 57 +++
>> kernel/sys_ni.c | 2 +-
>> 20 files changed, 1278 insertions(+), 53 deletions(-)
>> create mode 100644 arch/powerpc/platforms/powernv/eeh-vfio.c
>> create mode 100644 arch/powerpc/platforms/powernv/errinject.c
>>
>>Thanks,
>>Gavin
>>
>
^ permalink raw reply
* [PATCH][v2] powerpc/mpc85xx: Add BSC9132 QDS Support
From: Harninder Rai @ 2014-05-15 7:45 UTC (permalink / raw)
To: scottwood; +Cc: Harninder Rai, linuxppc-dev, Ruchika Gupta
- BSC9132 is an integrated device that targets Femto base station market.
It combines Power Architecture e500v2 and DSP StarCore SC3850 technologies
with MAPLE-B2F baseband acceleration processing elements
- BSC9132QDS Overview
2Gbyte DDR3 (on board DDR)
32Mbyte 16bit NOR flash
128Mbyte 2K page size NAND Flash
256 Kbit M24256 I2C EEPROM
128 Mbit SPI Flash memory
SD slot
eTSEC1: Connected to SGMII PHY
eTSEC2: Connected to SGMII PHY
DUART interface: supports one UARTs up to 115200 bps for console display
Signed-off-by: Harninder Rai <harninder.rai@freescale.com>
Signed-off-by: Ruchika Gupta <ruchika.gupta@freescale.com>
---
Changes since base version:
Incorporated Scott's comment
- Remove flash partition information from device tree
.../devicetree/bindings/powerpc/fsl/board.txt | 17 ++
arch/powerpc/boot/dts/bsc9132qds.dts | 35 ++++
arch/powerpc/boot/dts/bsc9132qds.dtsi | 101 +++++++++++
arch/powerpc/boot/dts/fsl/bsc9132si-post.dtsi | 185 ++++++++++++++++++++
arch/powerpc/boot/dts/fsl/bsc9132si-pre.dtsi | 66 +++++++
arch/powerpc/platforms/85xx/Kconfig | 9 +
arch/powerpc/platforms/85xx/Makefile | 1 +
arch/powerpc/platforms/85xx/bsc913x_qds.c | 74 ++++++++
8 files changed, 488 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/bsc9132qds.dts
create mode 100644 arch/powerpc/boot/dts/bsc9132qds.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/bsc9132si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/bsc9132si-pre.dtsi
create mode 100644 arch/powerpc/platforms/85xx/bsc913x_qds.c
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/board.txt b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
index 380914e..700dec4 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/board.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
@@ -67,3 +67,20 @@ Example:
gpio-controller;
};
};
+
+* Freescale on-board FPGA connected on I2C bus
+
+Some Freescale boards like BSC9132QDS have on board FPGA connected on
+the i2c bus.
+
+Required properties:
+- compatible: Should be a board-specific string followed by a string
+ indicating the type of FPGA. Example:
+ "fsl,<board>-fpga", "fsl,fpga-qixis-i2c"
+- reg: Should contain the address of the FPGA
+
+Example:
+ fpga: fpga@66 {
+ compatible = "fsl,bsc9132qds-fpga", "fsl,fpga-qixis-i2c";
+ reg = <0x66>;
+ };
diff --git a/arch/powerpc/boot/dts/bsc9132qds.dts b/arch/powerpc/boot/dts/bsc9132qds.dts
new file mode 100644
index 0000000..6cab106
--- /dev/null
+++ b/arch/powerpc/boot/dts/bsc9132qds.dts
@@ -0,0 +1,35 @@
+/*
+ * BSC9132 QDS Device Tree Source
+ *
+ * Copyright 2014 Freescale Semiconductor Inc.
+ *
+ * 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.
+ */
+
+/include/ "fsl/bsc9132si-pre.dtsi"
+
+/ {
+ model = "fsl,bsc9132qds";
+ compatible = "fsl,bsc9132qds";
+
+ memory {
+ device_type = "memory";
+ };
+
+ ifc: ifc@ff71e000 {
+ /* NOR, NAND Flash on board */
+ ranges = <0x0 0x0 0x0 0x88000000 0x08000000
+ 0x1 0x0 0x0 0xff800000 0x00010000>;
+ reg = <0x0 0xff71e000 0x0 0x2000>;
+ };
+
+ soc: soc@ff700000 {
+ ranges = <0x0 0x0 0xff700000 0x100000>;
+ };
+};
+
+/include/ "bsc9132qds.dtsi"
+/include/ "fsl/bsc9132si-post.dtsi"
diff --git a/arch/powerpc/boot/dts/bsc9132qds.dtsi b/arch/powerpc/boot/dts/bsc9132qds.dtsi
new file mode 100644
index 0000000..af8e888
--- /dev/null
+++ b/arch/powerpc/boot/dts/bsc9132qds.dtsi
@@ -0,0 +1,101 @@
+/*
+ * BSC9132 QDS Device Tree Source stub (no addresses or top-level ranges)
+ *
+ * Copyright 2014 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+&ifc {
+ nor@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0x0 0x0 0x8000000>;
+ bank-width = <2>;
+ device-width = <1>;
+ };
+
+ nand@1,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,ifc-nand";
+ reg = <0x1 0x0 0x4000>;
+ };
+};
+
+&soc {
+ spi@7000 {
+ flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "spansion,s25sl12801";
+ reg = <0>;
+ spi-max-frequency = <30000000>;
+ };
+ };
+
+ i2c@3000 {
+ fpga: fpga@66 {
+ compatible = "fsl,bsc9132qds-fpga", "fsl,fpga-qixis-i2c";
+ reg = <0x66>;
+ };
+ };
+
+ usb@22000 {
+ phy_type = "ulpi";
+ };
+
+ mdio@24000 {
+ phy0: ethernet-phy@0 {
+ reg = <0x0>;
+ };
+
+ phy1: ethernet-phy@1 {
+ reg = <0x1>;
+ };
+
+ tbi0: tbi-phy@11 {
+ reg = <0x1f>;
+ device_type = "tbi-phy";
+ };
+ };
+
+ enet0: ethernet@b0000 {
+ phy-handle = <&phy0>;
+ tbi-handle = <&tbi0>;
+ phy-connection-type = "sgmii";
+ };
+
+ enet1: ethernet@b1000 {
+ phy-handle = <&phy1>;
+ tbi-handle = <&tbi0>;
+ phy-connection-type = "sgmii";
+ };
+};
diff --git a/arch/powerpc/boot/dts/fsl/bsc9132si-post.dtsi b/arch/powerpc/boot/dts/fsl/bsc9132si-post.dtsi
new file mode 100644
index 0000000..c723071
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/bsc9132si-post.dtsi
@@ -0,0 +1,185 @@
+/*
+ * BSC9132 Silicon/SoC Device Tree Source (post include)
+ *
+ * Copyright 2014 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+&ifc {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,ifc", "simple-bus";
+ /* FIXME: Test whether interrupts are split */
+ interrupts = <16 2 0 0 20 2 0 0>;
+};
+
+&soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ compatible = "fsl,bsc9132-immr", "simple-bus";
+ bus-frequency = <0>; // Filled out by uboot.
+
+ ecm-law@0 {
+ compatible = "fsl,ecm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <12>;
+ };
+
+ ecm@1000 {
+ compatible = "fsl,bsc9132-ecm", "fsl,ecm";
+ reg = <0x1000 0x1000>;
+ interrupts = <16 2 0 0>;
+ };
+
+ memory-controller@2000 {
+ compatible = "fsl,bsc9132-memory-controller";
+ reg = <0x2000 0x1000>;
+ interrupts = <16 2 1 8>;
+ };
+
+/include/ "pq3-i2c-0.dtsi"
+ i2c@3000 {
+ interrupts = <17 2 0 0>;
+ };
+
+/include/ "pq3-i2c-1.dtsi"
+ i2c@3100 {
+ interrupts = <17 2 0 0>;
+ };
+
+/include/ "pq3-duart-0.dtsi"
+ serial0: serial@4500 {
+ interrupts = <18 2 0 0>;
+ };
+
+ serial1: serial@4600 {
+ interrupts = <18 2 0 0 >;
+ };
+/include/ "pq3-espi-0.dtsi"
+ spi0: spi@7000 {
+ fsl,espi-num-chipselects = <1>;
+ interrupts = <22 0x2 0 0>;
+ };
+
+/include/ "pq3-gpio-0.dtsi"
+ gpio-controller@f000 {
+ interrupts = <19 0x2 0 0>;
+ };
+
+ L2: l2-cache-controller@20000 {
+ compatible = "fsl,bsc9132-l2-cache-controller";
+ reg = <0x20000 0x1000>;
+ cache-line-size = <32>; // 32 bytes
+ cache-size = <0x40000>; // L2,256K
+ interrupts = <16 2 1 0>;
+ };
+
+/include/ "pq3-dma-0.dtsi"
+
+dma@21300 {
+
+ dma-channel@0 {
+ interrupts = <62 2 0 0>;
+ };
+
+ dma-channel@80 {
+ interrupts = <63 2 0 0>;
+ };
+
+ dma-channel@100 {
+ interrupts = <64 2 0 0>;
+ };
+
+ dma-channel@180 {
+ interrupts = <65 2 0 0>;
+ };
+};
+
+/include/ "pq3-usb2-dr-0.dtsi"
+usb@22000 {
+ compatible = "fsl-usb2-dr","fsl-usb2-dr-v2.2";
+ interrupts = <40 0x2 0 0>;
+};
+
+/include/ "pq3-esdhc-0.dtsi"
+ sdhc@2e000 {
+ fsl,sdhci-auto-cmd12;
+ interrupts = <41 0x2 0 0>;
+ };
+
+/include/ "pq3-sec4.4-0.dtsi"
+crypto@30000 {
+ interrupts = <57 2 0 0>;
+
+ sec_jr0: jr@1000 {
+ interrupts = <58 2 0 0>;
+ };
+
+ sec_jr1: jr@2000 {
+ interrupts = <59 2 0 0>;
+ };
+
+ sec_jr2: jr@3000 {
+ interrupts = <60 2 0 0>;
+ };
+
+ sec_jr3: jr@4000 {
+ interrupts = <61 2 0 0>;
+ };
+};
+
+/include/ "pq3-mpic.dtsi"
+/include/ "pq3-mpic-timer-B.dtsi"
+
+/include/ "pq3-etsec2-0.dtsi"
+enet0: ethernet@b0000 {
+ queue-group@b0000 {
+ fsl,rx-bit-map = <0xff>;
+ fsl,tx-bit-map = <0xff>;
+ interrupts = <26 2 0 0 27 2 0 0 28 2 0 0>;
+ };
+};
+
+/include/ "pq3-etsec2-1.dtsi"
+enet1: ethernet@b1000 {
+ queue-group@b1000 {
+ fsl,rx-bit-map = <0xff>;
+ fsl,tx-bit-map = <0xff>;
+ interrupts = <33 2 0 0 34 2 0 0 35 2 0 0>;
+ };
+};
+
+global-utilities@e0000 {
+ compatible = "fsl,bsc9132-guts";
+ reg = <0xe0000 0x1000>;
+ fsl,has-rstcr;
+ };
+};
diff --git a/arch/powerpc/boot/dts/fsl/bsc9132si-pre.dtsi b/arch/powerpc/boot/dts/fsl/bsc9132si-pre.dtsi
new file mode 100644
index 0000000..301a9db
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/bsc9132si-pre.dtsi
@@ -0,0 +1,66 @@
+/*
+ * BSC9132 Silicon/SoC Device Tree Source (pre include)
+ *
+ * Copyright 2014 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/dts-v1/;
+
+/include/ "e500v2_power_isa.dtsi"
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-parent = <&mpic>;
+
+ aliases {
+ serial0 = &serial0;
+ ethernet0 = &enet0;
+ ethernet1 = &enet1;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: PowerPC,e500v2@0 {
+ device_type = "cpu";
+ reg = <0x0>;
+ next-level-cache = <&L2>;
+ };
+
+ cpu1: PowerPC,e500v2@1 {
+ device_type = "cpu";
+ reg = <0x1>;
+ next-level-cache = <&L2>;
+ };
+ };
+};
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index c17aae8..4bd7223 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -38,6 +38,15 @@ config C293_PCIE
help
This option enables support for the C293PCIE board
+config BSC9132_QDS
+ bool "Freescale BSC9132QDS"
+ select DEFAULT_UIMAGE
+ help
+ This option enables support for the Freescale BSC9132 QDS board.
+ BSC9132 is a heterogeneous SoC containing dual e500v2 powerpc cores
+ and dual StarCore SC3850 DSP cores.
+ Manufacturer : Freescale Semiconductor, Inc
+
config MPC8540_ADS
bool "Freescale MPC8540 ADS"
select DEFAULT_UIMAGE
diff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/85xx/Makefile
index 25cebe7..c19beb9 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_SMP) += smp.o
obj-y += common.o
obj-$(CONFIG_BSC9131_RDB) += bsc913x_rdb.o
+obj-$(CONFIG_BSC9132_QDS) += bsc913x_qds.o
obj-$(CONFIG_C293_PCIE) += c293pcie.o
obj-$(CONFIG_MPC8540_ADS) += mpc85xx_ads.o
obj-$(CONFIG_MPC8560_ADS) += mpc85xx_ads.o
diff --git a/arch/powerpc/platforms/85xx/bsc913x_qds.c b/arch/powerpc/platforms/85xx/bsc913x_qds.c
new file mode 100644
index 0000000..f0927e5
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/bsc913x_qds.c
@@ -0,0 +1,74 @@
+/*
+ * BSC913xQDS Board Setup
+ *
+ * Author:
+ * Harninder Rai <harninder.rai@freescale.com>
+ * Priyanka Jain <Priyanka.Jain@freescale.com>
+ *
+ * Copyright 2014 Freescale Semiconductor Inc.
+ *
+ * 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.
+ */
+
+#include <linux/of_platform.h>
+#include <linux/pci.h>
+#include <asm/mpic.h>
+#include <sysdev/fsl_soc.h>
+#include <asm/udbg.h>
+
+#include "mpc85xx.h"
+#include "smp.h"
+
+void __init bsc913x_qds_pic_init(void)
+{
+ struct mpic *mpic = mpic_alloc(NULL, 0, MPIC_BIG_ENDIAN |
+ MPIC_SINGLE_DEST_CPU,
+ 0, 256, " OpenPIC ");
+
+ if (!mpic)
+ pr_err("bsc913x: Failed to allocate MPIC structure\n");
+ else
+ mpic_init(mpic);
+}
+
+/*
+ * Setup the architecture
+ */
+static void __init bsc913x_qds_setup_arch(void)
+{
+ if (ppc_md.progress)
+ ppc_md.progress("bsc913x_qds_setup_arch()", 0);
+
+#if defined(CONFIG_SMP)
+ mpc85xx_smp_init();
+#endif
+
+ pr_info("bsc913x board from Freescale Semiconductor\n");
+}
+
+machine_device_initcall(bsc9132_qds, mpc85xx_common_publish_devices);
+
+/*
+ * Called very early, device-tree isn't unflattened
+ */
+
+static int __init bsc9132_qds_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ return of_flat_dt_is_compatible(root, "fsl,bsc9132qds");
+}
+
+define_machine(bsc9132_qds) {
+ .name = "BSC9132 QDS",
+ .probe = bsc9132_qds_probe,
+ .setup_arch = bsc913x_qds_setup_arch,
+ .init_IRQ = bsc913x_qds_pic_init,
+ .get_irq = mpic_get_irq,
+ .restart = fsl_rstcr_restart,
+ .calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
+};
--
1.7.6.GIT
^ permalink raw reply related
* Re: [PATCH V4 0/2] mm: FAULT_AROUND_ORDER patchset performance data for powerpc
From: Madhavan Srinivasan @ 2014-05-15 8:25 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev, linux-mm, linux-arch, x86
Cc: riel, ak, peterz, rusty, dave.hansen, paulus, mgorman, akpm,
mingo, kirill.shutemov
In-Reply-To: <1399541296-18810-1-git-send-email-maddy@linux.vnet.ibm.com>
Hi Ingo,
Do you have any comments for the latest version of the patchset. If
not, kindly can you pick it up as is.
With regards
Maddy
> Kirill A. Shutemov with 8c6e50b029 commit introduced
> vm_ops->map_pages() for mapping easy accessible pages around
> fault address in hope to reduce number of minor page faults.
>
> This patch creates infrastructure to modify the FAULT_AROUND_ORDER
> value using mm/Kconfig. This will enable architecture maintainers
> to decide on suitable FAULT_AROUND_ORDER value based on
> performance data for that architecture. First patch also defaults
> FAULT_AROUND_ORDER Kconfig element to 4. Second patch list
> out the performance numbers for powerpc (platform pseries) and
> initialize the fault around order variable for pseries platform of
> powerpc.
>
> V4 Changes:
> Replaced the BUILD_BUG_ON with VM_BUG_ON.
> Moved fault_around_pages() and fault_around_mask() functions outside of
> #ifdef CONFIG_DEBUG_FS.
>
> V3 Changes:
> Replaced FAULT_AROUND_ORDER macro to a variable to support arch's that
> supports sub platforms.
> Made changes in commit messages.
>
> V2 Changes:
> Created Kconfig parameter for FAULT_AROUND_ORDER
> Added check in do_read_fault to handle FAULT_AROUND_ORDER value of 0
> Made changes in commit messages.
>
> Madhavan Srinivasan (2):
> mm: move FAULT_AROUND_ORDER to arch/
> powerpc/pseries: init fault_around_order for pseries
>
> arch/powerpc/platforms/pseries/pseries.h | 2 ++
> arch/powerpc/platforms/pseries/setup.c | 5 +++++
> mm/Kconfig | 8 ++++++++
> mm/memory.c | 25 ++++++-------------------
> 4 files changed, 21 insertions(+), 19 deletions(-)
>
^ permalink raw reply
* Re: [PATCH V2 2/3] powerpc, ptrace: Enable support for transactional memory register sets
From: Anshuman Khandual @ 2014-05-15 8:25 UTC (permalink / raw)
To: Pedro Alves; +Cc: mikey, avagin, linux-kernel, oleg, michael, linuxppc-dev
In-Reply-To: <53735044.5030008@redhat.com>
On 05/14/2014 04:45 PM, Pedro Alves wrote:
> On 05/14/14 06:46, Anshuman Khandual wrote:
>> On 05/13/2014 10:43 PM, Pedro Alves wrote:
>>> On 05/05/14 08:54, Anshuman Khandual wrote:
>>>> This patch enables get and set of transactional memory related register
>>>> sets through PTRACE_GETREGSET/PTRACE_SETREGSET interface by implementing
>>>> four new powerpc specific register sets i.e REGSET_TM_SPR, REGSET_TM_CGPR,
>>>> REGSET_TM_CFPR, REGSET_CVMX support corresponding to these following new
>>>> ELF core note types added previously in this regard.
>>>>
>>>> (1) NT_PPC_TM_SPR
>>>> (2) NT_PPC_TM_CGPR
>>>> (3) NT_PPC_TM_CFPR
>>>> (4) NT_PPC_TM_CVMX
>>>
>>> Sorry that I couldn't tell this from the code, but, what does the
>>> kernel return when the ptracer requests these registers and the
>>> program is not in a transaction? Specifically I'm wondering whether
>>> this follows the same semantics as the s390 port.
>>>
>>
>> Right now, it still returns the saved state of the registers from thread
>> struct. I had assumed that the user must know the state of the transaction
>> before initiating the ptrace request. I guess its better to check for
>> the transaction status before processing the request. In case if TM is not
>> active on that thread, we should return -EINVAL.
>
> I think s390 returns ENODATA in that case.
>
> https://sourceware.org/ml/gdb-patches/2013-06/msg00273.html
>
> We'll want some way to tell whether the system actually
> supports this. That could be ENODATA vs something-else (EINVAL
> or perhaps better EIO for "request is invalid").
As Mickey has pointed out, the transaction memory support in the system can be
checked from the HWCAP2 flags. So when the transaction is not active, we will
return ENODATA instead for TM related ptrace regset requests.
^ permalink raw reply
* Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
From: Alan Modra @ 2014-05-15 9:47 UTC (permalink / raw)
To: Guenter Roeck; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <20140514153430.GA28553@roeck-us.net>
On Wed, May 14, 2014 at 08:34:30AM -0700, Guenter Roeck wrote:
> Bummer. Confirmed, if I replace "@h" with "@high" in just one place,
> the builds pass with binutils 2.24. Unfortunately the same builds then
> fails with binutils 2.23.
>
> Any idea how to get it to compile with both old and new versions ?
The standard way with GNU software would be to write a configure test,
that checks for @high support in the assembler, and defines a macro
if the assembler passes the check. I'm not that familiar with the
linux kernel these days, but a little grepping around says that
something like
ashigh := $(call as-instr,lis 9$(comma)foo@high,-DHAVE_AS_ATHIGH=1)
KBUILD_AFLAGS += $(ashigh)
might work.
> Is there some predefined constant which I could possibly use for
> something like
>
> .if as_version_below_2.24_
> oris reg,reg,(expr)@h;
> .else
> oris reg,reg,(expr)@high;
> .endif
>
> Thanks,
> Guenter
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply
* Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
From: Guenter Roeck @ 2014-05-15 10:46 UTC (permalink / raw)
To: Alan Modra; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <20140515094716.GQ5162@bubble.grove.modra.org>
On 05/15/2014 02:47 AM, Alan Modra wrote:
> On Wed, May 14, 2014 at 08:34:30AM -0700, Guenter Roeck wrote:
>> Bummer. Confirmed, if I replace "@h" with "@high" in just one place,
>> the builds pass with binutils 2.24. Unfortunately the same builds then
>> fails with binutils 2.23.
>>
>> Any idea how to get it to compile with both old and new versions ?
>
> The standard way with GNU software would be to write a configure test,
> that checks for @high support in the assembler, and defines a macro
> if the assembler passes the check. I'm not that familiar with the
> linux kernel these days, but a little grepping around says that
> something like
>
> ashigh := $(call as-instr,lis 9$(comma)foo@high,-DHAVE_AS_ATHIGH=1)
> KBUILD_AFLAGS += $(ashigh)
>
> might work.
>
Yes, it does.
Thanks!
Guenter
^ permalink raw reply
* Re: [PATCH V2 2/3] powerpc, ptrace: Enable support for transactional memory register sets
From: Pedro Alves @ 2014-05-15 12:08 UTC (permalink / raw)
To: Anshuman Khandual
Cc: mikey, avagin, linux-kernel, oleg, michael, linuxppc-dev
In-Reply-To: <537479FD.2010200@linux.vnet.ibm.com>
On 05/15/2014 09:25 AM, Anshuman Khandual wrote:
> On 05/14/2014 04:45 PM, Pedro Alves wrote:
>> On 05/14/14 06:46, Anshuman Khandual wrote:
>>> On 05/13/2014 10:43 PM, Pedro Alves wrote:
>>>> On 05/05/14 08:54, Anshuman Khandual wrote:
>>>>> This patch enables get and set of transactional memory related register
>>>>> sets through PTRACE_GETREGSET/PTRACE_SETREGSET interface by implementing
>>>>> four new powerpc specific register sets i.e REGSET_TM_SPR, REGSET_TM_CGPR,
>>>>> REGSET_TM_CFPR, REGSET_CVMX support corresponding to these following new
>>>>> ELF core note types added previously in this regard.
>>>>>
>>>>> (1) NT_PPC_TM_SPR
>>>>> (2) NT_PPC_TM_CGPR
>>>>> (3) NT_PPC_TM_CFPR
>>>>> (4) NT_PPC_TM_CVMX
>>>>
>>>> Sorry that I couldn't tell this from the code, but, what does the
>>>> kernel return when the ptracer requests these registers and the
>>>> program is not in a transaction? Specifically I'm wondering whether
>>>> this follows the same semantics as the s390 port.
>>>>
>>>
>>> Right now, it still returns the saved state of the registers from thread
>>> struct. I had assumed that the user must know the state of the transaction
>>> before initiating the ptrace request. I guess its better to check for
>>> the transaction status before processing the request. In case if TM is not
>>> active on that thread, we should return -EINVAL.
>>
>> I think s390 returns ENODATA in that case.
>>
>> https://sourceware.org/ml/gdb-patches/2013-06/msg00273.html
>>
>> We'll want some way to tell whether the system actually
>> supports this. That could be ENODATA vs something-else (EINVAL
>> or perhaps better EIO for "request is invalid").
>
> As Mickey has pointed out, the transaction memory support in the system can be
> checked from the HWCAP2 flags. So when the transaction is not active, we will
> return ENODATA instead for TM related ptrace regset requests.
Returning ENODATA when the transaction is not active, like
s390 is great. Thank you.
But I think it's worth it to consider what should the kernel
return when the machine doesn't have these registers at all.
Sure, for this case we happen to have the hwcap flag. But in
general, I don't know whether we will always have a hwcap bit
for each register set that is added. Maybe we will, so that
the info ends up in core dumps.
Still, I think it's worth to consider this case in the
general sense, irrespective of hwcap.
That is, what should PTRACE_GETREGSET/PTRACE_SETREGSET return
when the machine doesn't have the registers at all. We shouldn't
need to consult something elsewhere (like hwcap) to determine
what ENODATA means. The kernel knows it right there. I think
s390 goofed here.
Taking a look at x86, for example, we see:
[REGSET_XSTATE] = {
.core_note_type = NT_X86_XSTATE,
.size = sizeof(u64), .align = sizeof(u64),
.active = xstateregs_active, .get = xstateregs_get,
.set = xstateregs_set
},
Note that it installs the ".active" hook.
24 /**
25 * user_regset_active_fn - type of @active function in &struct user_regset
26 * @target: thread being examined
27 * @regset: regset being examined
28 *
29 * Return -%ENODEV if not available on the hardware found.
30 * Return %0 if no interesting state in this thread.
31 * Return >%0 number of @size units of interesting state.
32 * Any get call fetching state beyond that number will
33 * see the default initialization state for this data,
34 * so a caller that knows what the default state is need
35 * not copy it all out.
36 * This call is optional; the pointer is %NULL if there
37 * is no inexpensive check to yield a value < @n.
38 */
39 typedef int user_regset_active_fn(struct task_struct *target,
40 const struct user_regset *regset);
41
Note the mention of ENODEV.
I couldn't actually find any arch that currently returns -ENODEV in
the "active" hook. I see that binfmt_elf.c doesn't handle
regset->active() returning < 0. Guess that may be why. Looks like
something that could be cleaned up, to me.
Anyway, notice x86's REGSET_XSTATE regset->get hook:
int xstateregs_get(struct task_struct *target, const struct user_regset *regset,
unsigned int pos, unsigned int count,
void *kbuf, void __user *ubuf)
{
int ret;
if (!cpu_has_xsave)
return -ENODEV;
^^^^^^^^^^^^^^^^^^^^^^
And then we see that xfpregs_get has a similar ENODEV case.
So in sum, it very much looks like the intention is for
PTRACE_GETREGSET/PTRACE_SETREGSET to return ENODEV in the
case the regset doesn't exist on the running machine, and then
it looks like at least x86 works that way.
--
Pedro Alves
^ permalink raw reply
* Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
From: Benjamin Herrenschmidt @ 2014-05-15 12:22 UTC (permalink / raw)
To: Guenter Roeck; +Cc: Stephen Rothwell, linuxppc-dev, Alan Modra
In-Reply-To: <53749B0E.4050900@roeck-us.net>
On Thu, 2014-05-15 at 03:46 -0700, Guenter Roeck wrote:
> On 05/15/2014 02:47 AM, Alan Modra wrote:
> > On Wed, May 14, 2014 at 08:34:30AM -0700, Guenter Roeck wrote:
> >> Bummer. Confirmed, if I replace "@h" with "@high" in just one place,
> >> the builds pass with binutils 2.24. Unfortunately the same builds then
> >> fails with binutils 2.23.
> >>
> >> Any idea how to get it to compile with both old and new versions ?
> >
> > The standard way with GNU software would be to write a configure test,
> > that checks for @high support in the assembler, and defines a macro
> > if the assembler passes the check. I'm not that familiar with the
> > linux kernel these days, but a little grepping around says that
> > something like
> >
> > ashigh := $(call as-instr,lis 9$(comma)foo@high,-DHAVE_AS_ATHIGH=1)
> > KBUILD_AFLAGS += $(ashigh)
> >
> > might work.
> >
>
> Yes, it does.
Care to send a patch ? :-)
Cheers,
Ben.
^ 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