* [PATCH v2 1/3] dmaengine: mpc512x: add device tree binding document
From: Alexander Popov @ 2014-06-18 10:48 UTC (permalink / raw)
To: Gerhard Sittig, Dan Williams, Vinod Koul, Lars-Peter Clausen,
Arnd Bergmann, Anatolij Gustschin, Andy Shevchenko,
Alexander Popov, linuxppc-dev, dmaengine, devicetree
In-Reply-To: <1403088492-15241-1-git-send-email-a13xp0p0v88@gmail.com>
Introduce a device tree binding document for the MPC512x DMA controller
Signed-off-by: Alexander Popov <a13xp0p0v88@gmail.com>
---
.../devicetree/bindings/dma/mpc512x-dma.txt | 31 ++++++++++++++++++++++
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/mpc512x-dma.txt
diff --git a/Documentation/devicetree/bindings/dma/mpc512x-dma.txt b/Documentation/devicetree/bindings/dma/mpc512x-dma.txt
new file mode 100644
index 0000000..95e2ca0
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/mpc512x-dma.txt
@@ -0,0 +1,31 @@
+* Freescale MPC512x and MPC8308 DMA Controller
+
+The DMA controller in Freescale MPC512x and MPC8308 SoCs can move
+blocks of memory contents between memory and peripherals or
+from memory to memory.
+
+Refer to "Generic DMA Controller and DMA request bindings" in
+the dma/dma.txt file for a more detailed description of binding.
+
+Required properties:
+- compatible: should be "fsl,mpc5121-dma" or "fsl,mpc8308-dma";
+- reg: should contain the DMA controller registers location and length;
+- interrupt for the DMA controller: syntax of interrupt client node
+ is described in interrupt-controller/interrupts.txt file.
+
+Optional properties:
+- #dma-cells: the length of the DMA specifier, must be <1>.
+ Each channel of this DMA controller has a peripheral request line,
+ the assignment is fixed in hardware. This one cell
+ in dmas property of a client device represents the channel number.
+
+Example:
+
+ dma0: dma@14000 {
+ compatible = "fsl,mpc5121-dma";
+ reg = <0x14000 0x1800>;
+ interrupts = <65 0x8>;
+ #dma-cells = <1>;
+ };
+
+DMA clients must use the format described in dma/dma.txt file.
--
1.8.4.2
^ permalink raw reply related
* [PATCH v2 0/3] dmaengine: mpc512x: add device tree binding document and DMA channel lookup
From: Alexander Popov @ 2014-06-18 10:48 UTC (permalink / raw)
To: Gerhard Sittig, Dan Williams, Vinod Koul, Lars-Peter Clausen,
Arnd Bergmann, Anatolij Gustschin, Andy Shevchenko,
Alexander Popov, linuxppc-dev, dmaengine, devicetree
This patch series introduces a device tree binding document for
the MPC512x DMA controller and adds device tree based DMA channel lookup
for it.
This version has improved device tree binding document.
Alexander Popov (3):
dmaengine: mpc512x: add device tree binding document
dmaengine: of: add common xlate function for matching by channel id
dmaengine: mpc512x: register for device tree channel lookup
.../devicetree/bindings/dma/mpc512x-dma.txt | 31 +++++++++++++++++++
arch/powerpc/boot/dts/mpc5121.dtsi | 1 +
drivers/dma/mpc512x_dma.c | 13 +++++++-
drivers/dma/of-dma.c | 35 ++++++++++++++++++++++
include/linux/of_dma.h | 4 +++
5 files changed, 83 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/dma/mpc512x-dma.txt
--
1.8.4.2
^ permalink raw reply
* Kernel 3.15: Boot problems with a PA6T board
From: Christian Zigotzky @ 2014-06-18 9:26 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev, Olof Johansson
In-Reply-To: <53A15492.3090604@xenosoft.de>
Am 18.06.14 10:57, schrieb Christian Zigotzky:
> Am 18.06.14 08:51, schrieb Michael Ellerman:
>> On Tue, 2014-06-10 at 15:20 +0200, Christian Zigotzky wrote:
>>> Hi All,
>>>
>>> Could you help me to remove the changes of the PCI code, please? Or
>>> which patches shall I remove to get the old PCI code?
>> Hi Christian,
>>
>> Thanks for doing the bisect. It wasn't clear why that change was
>> causing your
>> issue, so I guess we're a bit stuck.
>>
>> Olof (on CC), was going to try and look at it when he got some spare
>> time.
>> Please keep him on CC.
>>
>> cheers
>>
>>
>>
> Hi Michael,
>
> Thank you for your answer. Adrian told me the reason about this issue.
>
> Quote Adrian:
>
> As I recall, PCI resource allocation on Nemo was always a little
> strange due to using an AMD south bridge together with the PA6T north
> bridge. The south bridge does not behave as a standard PCIe device,
> but instead presents itself as multiple devices on the PCIe root bus.
> This is not compliant with the PCIe specification. We modified the
> core powerpc PCI code so that Nemo could boot, but the changes to PCI
> code in 3.15 have broken the old workaround. I don't understand the
> PCI changes in 3.15 enough to comment further at this point.
>
> Regards,
> Adrian
>
> Quote end
>
> Cheers,
>
> Christian
But my opinion is, that's normal for the SB600 south bridge to presents
itself as multiple devices on the PCIe bus on x86 PCs. I see a lot of
PCs with SB600 south bridge on the internet. And the Linux kernel works
with this south bridge. Or is it a powerpc issue?
- Christian
^ permalink raw reply
* Kernel 3.15: Boot problems with a PA6T board
From: Christian Zigotzky @ 2014-06-18 8:57 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev, Olof Johansson
In-Reply-To: <1403074303.32307.5.camel@concordia>
Am 18.06.14 08:51, schrieb Michael Ellerman:
> On Tue, 2014-06-10 at 15:20 +0200, Christian Zigotzky wrote:
>> Hi All,
>>
>> Could you help me to remove the changes of the PCI code, please? Or
>> which patches shall I remove to get the old PCI code?
> Hi Christian,
>
> Thanks for doing the bisect. It wasn't clear why that change was causing your
> issue, so I guess we're a bit stuck.
>
> Olof (on CC), was going to try and look at it when he got some spare time.
> Please keep him on CC.
>
> cheers
>
>
>
Hi Michael,
Thank you for your answer. Adrian told me the reason about this issue.
Quote Adrian:
As I recall, PCI resource allocation on Nemo was always a little strange
due to using an AMD south bridge together with the PA6T north bridge.
The south bridge does not behave as a standard PCIe device, but instead
presents itself as multiple devices on the PCIe root bus. This is not
compliant with the PCIe specification. We modified the core powerpc PCI
code so that Nemo could boot, but the changes to PCI code in 3.15 have
broken the old workaround. I don't understand the PCI changes in 3.15
enough to comment further at this point.
Regards,
Adrian
Quote end
Cheers,
Christian
^ permalink raw reply
* Re: Boot failure in Power7 pSeries
From: Mike Qiu @ 2014-06-18 9:02 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <1403078080.32307.6.camel@concordia>
On 06/18/2014 03:54 PM, Michael Ellerman wrote:
> On Wed, 2014-06-18 at 11:27 +0800, Mike Qiu wrote:
>> Anyone has a idea on this issue?
> Did it ever work? If so which kernel version?
It works for 3.15, but failed with linux version 3.16.0-rc1-next-20140617
The config file can be simply get from /boot/configxxx. and "make
menuconfig" and save without change anything(default).
> Can you attach your actual .config.
>
> You could try building without CONFIG_PPC_POWERNV.
Trying...., but it should work as default config from /boot/
Thanks
Mike
>
> cheers
>
>
>
^ permalink raw reply
* Re: Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
From: Masami Hiramatsu @ 2014-06-18 8:46 UTC (permalink / raw)
To: Michael Ellerman
Cc: Jeremy Fitzhardinge, linux-ia64, sparse,
Linux Kernel Mailing List, Paul Mackerras, H. Peter Anvin,
Thomas Gleixner, linux-tip-commits, anil.s.keshavamurthy,
Ingo Molnar, Suzuki K. Poulose, Fenghua Yu, Arnd Bergmann,
Rusty Russell, Chris Wright, yrl.pp-manager.tt, akataria,
Tony Luck, Kevin Hao, linuxppc-dev, rdunlap, Tony Luck, dl9pf,
Andrew Morton, Linus Torvalds, David S. Miller
In-Reply-To: <1403078179.32307.7.camel@concordia>
(2014/06/18 16:56), Michael Ellerman wrote:
> On Fri, 2014-06-06 at 15:38 +0900, Masami Hiramatsu wrote:
>> Ping?
>>
>> I guess this should go to 3.16 branch, shouldn't it?
>
>>> diff --git a/arch/powerpc/include/asm/types.h b/arch/powerpc/include/asm/types.h
>>> index bfb6ded..8b89d65 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 function_entry(fn) (((func_descr_t *)(fn))->entry)
>>> +#else
>>> +#define function_entry(fn) ((unsigned long)(fn))
>>> +#endif
>
> We already have ppc_function_entry(), can't you use that?
I'd like to ask you whether the address which ppc_function_entry() returns on
PPC ABIv2 is really same address in kallsyms or not.
As you can see, kprobes uses function_entry() to get the actual entry address
where kallsyms knows. I have not much information about that, but it seems that
the "global entry point" is the address which kallsyms knows, isn't it?
Thank you,
--
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 v2] powerpc/powernv: hwmon driver for power values, fan rpm and temperature
From: Neelesh Gupta @ 2014-06-18 8:43 UTC (permalink / raw)
To: Guenter Roeck, linuxppc-dev, jdelvare, lm-sensors; +Cc: sbhat
In-Reply-To: <53858F02.2020808@roeck-us.net>
>> +}
>> +
>> +static void __init 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);
>
> What if sscanf fails ? Might be an interesting exercise to try and create
> multiple sensors with index 0 (or, for that matter, with the same
> index value).
> Do you have any protection against bad input data ? Guess not; did you
> test
> what happens if you pass bad data to the driver (such as duplicate sensor
> entries) ?
We can't have duplicate entries in the device tree under the same node ?
But yes, rest other scenarios must be validated.
- Neelesh
>
>> + }
>> +
>> + strncpy(attr, dash_pos + 1, MAX_ATTR_LEN);
>> + }
>> + }
>> +}
>> +
>> +
>>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH v3] powerpc/powernv: hwmon driver for power, fan rpm, voltage and temperature
From: Neelesh Gupta @ 2014-06-18 8:35 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, voltage and temperature data on powernv platforms which will
be exported to user space through sysfs interface.
Test results:
-------------
[root@ltctul57a-p1 ~]# sensors
ibmpowernv-isa-0000
Adapter: ISA adapter
fan1: 5660 RPM (min = 0 RPM)
fan2: 5273 RPM (min = 0 RPM)
fan3: 5625 RPM (min = 0 RPM)
fan4: 5283 RPM (min = 0 RPM)
fan5: 5625 RPM (min = 0 RPM)
fan6: 5242 RPM (min = 0 RPM)
fan7: 5636 RPM (min = 0 RPM)
fan8: 5273 RPM (min = 0 RPM)
fan9: 4984 RPM (min = 0 RPM)
fan10: 4984 RPM (min = 0 RPM)
fan11: 4984 RPM (min = 0 RPM)
fan12: 4984 RPM (min = 0 RPM)
temp1: +24.0 C (high = +0.0 C)
power1: 573.00 W
[root@ltctul57a-p1 ~]#
[root@ltctul57a-p1 ~]# ls /sys/devices/platform/
alarmtimer ibmpowernv.0 rtc-generic serial8250 uevent
[root@ltctul57a-p1 ~]# ls /sys/devices/platform/ibmpowernv.0/hwmon/hwmon0/
device fan12_input fan3_fault fan5_min fan8_input in4_fault
fan10_fault fan12_min fan3_input fan6_fault fan8_min name
fan10_input fan1_fault fan3_min fan6_input fan9_fault power1_input
fan10_min fan1_input fan4_fault fan6_min fan9_input subsystem
fan11_fault fan1_min fan4_input fan7_fault fan9_min temp1_input
fan11_input fan2_fault fan4_min fan7_input in1_fault temp1_max
fan11_min fan2_input fan5_fault fan7_min in2_fault uevent
fan12_fault fan2_min fan5_input fan8_fault in3_fault
[root@ltctul57a-p1 ~]#
[root@ltctul57a-p1 ~]# ls /sys/class/hwmon/hwmon0/
device fan12_input fan3_fault fan5_min fan8_input in4_fault
fan10_fault fan12_min fan3_input fan6_fault fan8_min name
fan10_input fan1_fault fan3_min fan6_input fan9_fault power1_input
fan10_min fan1_input fan4_fault fan6_min fan9_input subsystem
fan11_fault fan1_min fan4_input fan7_fault fan9_min temp1_input
fan11_input fan2_fault fan4_min fan7_input in1_fault temp1_max
fan11_min fan2_input fan5_fault fan7_min in2_fault uevent
fan12_fault fan2_min fan5_input fan8_fault in3_fault
[root@ltctul57a-p1 ~]#
Signed-off-by: Neelesh Gupta <neelegup@linux.vnet.ibm.com>
---
Changes in V3
=========
- Fixed an endianness bug leading the driver to break on LE.
- Fixed a bug that when one of the 'attribute_group' not populated, following
groups attributes were dropped.
- Rewrite the get_sensor_index_attr() function to handle all the error scenarios
like 'sscanf' etc.
- Fixed all the errors/warnings related to coding style/whitespace.
- Added 'Documentation' files.
- Addressed remaining review comments on V2.
Changes in v2
=============
- Generic use of devm_* functions in hwmon like using devm_kzalloc() for dynamic
memory request, avoiding the need to explicit free of memory.
Adding 'struct attribute_group' as member of platform data structure to be
populated and then passed to devm_hwmon_device_register_with_groups().
Note: Having an array of pointers of 'attribute_group' and each group
corresponds to 'enum sensors' type. Not completely sure, if it's ideal or
could have just one group populated with attributes of sensor types?
- 'ibmpowernv' is not hot-pluggable device so moving 'platform_driver' callback
function (probe) as part of __init code.
- Fixed issues related to coding style.
- Other general comments in v1.
.../devicetree/bindings/hwmon/ibmpowernv.txt | 27 +
Documentation/hwmon/ibmpowernv | 41 ++
drivers/hwmon/Kconfig | 11 +
drivers/hwmon/Makefile | 1
drivers/hwmon/ibmpowernv.c | 366 ++++++++++++++++++++
5 files changed, 446 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/ibmpowernv.txt
create mode 100644 Documentation/hwmon/ibmpowernv
create mode 100644 drivers/hwmon/ibmpowernv.c
diff --git a/Documentation/devicetree/bindings/hwmon/ibmpowernv.txt b/Documentation/devicetree/bindings/hwmon/ibmpowernv.txt
new file mode 100644
index 0000000..e3bd1eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/ibmpowernv.txt
@@ -0,0 +1,27 @@
+IBM POWERNV platform sensors
+----------------------------
+
+Required node properties:
+- compatible: must be one of
+ "ibm,opal-sensor-cooling-fan"
+ "ibm,opal-sensor-amb-temp"
+ "ibm,opal-sensor-power-supply"
+ "ibm,opal-sensor-power"
+- sensor-id: an opaque id provided by the firmware to the kernel, identifies a
+ given sensor and its attribute data
+
+Example sensors node:
+
+cooling-fan#8-data {
+ sensor-id = <0x7052107>;
+ phandle = <0x10000028>;
+ linux,phandle = <0x10000028>;
+ compatible = "ibm,opal-sensor-cooling-fan";
+};
+
+amb-temp#1-thrs {
+ sensor-id = <0x5096000>;
+ phandle = <0x10000017>;
+ linux,phandle = <0x10000017>;
+ compatible = "ibm,opal-sensor-amb-temp";
+};
diff --git a/Documentation/hwmon/ibmpowernv b/Documentation/hwmon/ibmpowernv
new file mode 100644
index 0000000..d9ce50e
--- /dev/null
+++ b/Documentation/hwmon/ibmpowernv
@@ -0,0 +1,41 @@
+Kernel Driver IBMPOWENV
+=======================
+
+Supported systems:
+ * Any recent IBM P servers based on POWERNV platform
+
+Author: Neelesh Gupta
+
+Description
+-----------
+
+This driver implements reading the platform sensors data like temperature/fan/
+voltage/power for 'POWERNV' platform.
+
+The driver uses the platform device infrastructure. It probes the device tree
+for sensor devices during the __init phase and registers them with the 'hwmon'.
+'hwmon' populates the 'sysfs' tree having attribute files, each for a given
+sensor type and its attribute data.
+
+All the nodes in the DT appear under "/ibm,opal/sensors" and each valid node in
+the DT maps to an attribute file in 'sysfs'. The node exports unique 'sensor-id'
+which the driver uses to make an OPAL call to the firmware.
+
+Usage notes
+-----------
+The driver is built statically with the kernel by enabling the config
+CONFIG_SENSORS_IBMPOWERNV. It can also be built as module 'ibmpowernv'.
+
+Sysfs attributes
+----------------
+
+fanX_input Measured RPM value.
+fanX_min Threshold RPM for alert generation.
+fanX_fault 0: No fail condition
+ 1: Failing fan
+tempX_input Measured ambient temperature.
+tempX_max Threshold ambient temperature for alert generation.
+inX_input Measured power supply voltage
+inX_fault 0: No fail condition.
+ 1: Failing power supply.
+power1_input System power consumption (milliWatts)
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index bc196f4..fc69112 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -554,6 +554,17 @@ config SENSORS_IBMPEX
This driver can also be built as a module. If so, the module
will be called ibmpex.
+config SENSORS_IBMPOWERNV
+ tristate "IBM POWERNV platform sensors"
+ depends on PPC_POWERNV
+ default y
+ help
+ If you say yes here you get support for the temperature/fan/power
+ sensors on your platform.
+
+ This driver can also be built as a module. If so, the module
+ will be called ibmpowernv.
+
config SENSORS_IIO_HWMON
tristate "Hwmon driver that uses channels specified via iio maps"
depends on IIO
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 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..45c7f4b
--- /dev/null
+++ b/drivers/hwmon/ibmpowernv.c
@@ -0,0 +1,366 @@
+/*
+ * IBM PowerNV platform sensors for temperature/fan/voltage/power
+ * Copyright (C) 2014 IBM
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.
+ */
+
+#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 types of sensors in the POWERNV platform and does index
+ * into 'struct sensor_group'
+ */
+enum sensors {
+ FAN,
+ AMBIENT_TEMP,
+ POWER_SUPPLY,
+ POWER_INPUT,
+ MAX_SENSOR_TYPE,
+};
+
+static struct sensor_group {
+ const char *name;
+ const char *compatible;
+ struct attribute_group group;
+ u32 attr_count;
+} sensor_groups[] = {
+ {"fan", "ibm,opal-sensor-cooling-fan"},
+ {"temp", "ibm,opal-sensor-amb-temp"},
+ {"in", "ibm,opal-sensor-power-supply"},
+ {"power", "ibm,opal-sensor-power"}
+};
+
+struct sensor_data {
+ u32 id; /* An opaque id of the firmware for each sensor */
+ enum sensors type;
+ char name[MAX_ATTR_LEN];
+ struct device_attribute dev_attr;
+};
+
+struct platform_data {
+ const struct attribute_group *attr_groups[MAX_SENSOR_TYPE + 1];
+ u32 sensors_count; /* Total count of sensors from each group */
+};
+
+/* Platform device representing all the ibmpowernv sensors */
+static struct platform_device *pdevice;
+
+static ssize_t show_sensor(struct device *dev, struct device_attribute *devattr,
+ char *buf)
+{
+ struct sensor_data *sdata = container_of(devattr, struct sensor_data,
+ dev_attr);
+ ssize_t ret;
+ u32 x;
+
+ ret = opal_get_sensor_data(sdata->id, &x);
+ if (ret) {
+ pr_err("%s: Failed to get opal sensor data\n", __func__);
+ return ret;
+ }
+
+ /* Convert temperature to milli-degrees */
+ if (sdata->type == AMBIENT_TEMP)
+ x *= 1000;
+ /* Convert power to micro-watts */
+ else if (sdata->type == POWER_INPUT)
+ x *= 1000000;
+
+ return sprintf(buf, "%u\n", x);
+}
+
+static int __init get_sensor_index_attr(const char *name, u32 *index,
+ char *attr)
+{
+ char *hash_pos = strchr(name, '#');
+ char *dash_pos;
+ u32 copy_len;
+ char buf[8];
+
+ memset(buf, 0, sizeof(buf));
+
+ if (!hash_pos)
+ return -EINVAL;
+
+ dash_pos = strchr(hash_pos, '-');
+ if (!dash_pos)
+ return -EINVAL;
+
+ copy_len = dash_pos - hash_pos - 1;
+ if (copy_len >= sizeof(buf))
+ return -EINVAL;
+
+ strncpy(buf, hash_pos + 1, copy_len);
+ if (sscanf(buf, "%d", index) != 1)
+ return -EINVAL;
+
+ strncpy(attr, dash_pos + 1, MAX_ATTR_LEN);
+
+ return 0;
+}
+
+/*
+ * This function translates the DT node name into the 'hwmon' attribute name.
+ * IBMPOWERNV device node appear like cooling-fan#2-data, amb-temp#1-thrs etc.
+ * which need to be mapped as fan2_input, temp1_max respectively before
+ * populating them inside hwmon device class..
+ */
+static int __init create_hwmon_attr_name(enum sensors type,
+ const char *node_name,
+ char *hwmon_attr_name)
+{
+ char attr_suffix[MAX_ATTR_LEN];
+ char *attr_name;
+ u32 index;
+ int err;
+
+ err = get_sensor_index_attr(node_name, &index, attr_suffix);
+ if (err) {
+ pr_info("%s: Sensor device node name is invalid, name: %s\n",
+ __func__, node_name);
+ return err;
+ }
+
+ if (!strcmp(attr_suffix, DT_FAULT_ATTR_SUFFIX)) {
+ attr_name = "fault";
+ } else if (!strcmp(attr_suffix, DT_DATA_ATTR_SUFFIX)) {
+ attr_name = "input";
+ } else if (!strcmp(attr_suffix, DT_THRESHOLD_ATTR_SUFFIX)) {
+ if (type == AMBIENT_TEMP)
+ attr_name = "max";
+ else if (type == FAN)
+ attr_name = "min";
+ else
+ return -ENOENT;
+ } else {
+ return -ENOENT;
+ }
+
+ snprintf(hwmon_attr_name, MAX_ATTR_LEN, "%s%d_%s",
+ sensor_groups[type].name, index, attr_name);
+ return 0;
+}
+
+static int __init populate_attr_groups(struct platform_device *pdev)
+{
+ struct platform_data *pdata = platform_get_drvdata(pdev);
+ const struct attribute_group **pgroups = pdata->attr_groups;
+ struct device_node *opal, *np;
+ enum sensors type;
+
+ opal = of_find_node_by_path("/ibm,opal/sensors");
+ if (!opal) {
+ pr_err("%s: Opal 'sensors' node not found\n", __func__);
+ return -ENODEV;
+ }
+
+ for_each_child_of_node(opal, np) {
+ if (np->name == NULL)
+ continue;
+
+ for (type = 0; type < MAX_SENSOR_TYPE; type++)
+ if (of_device_is_compatible(np,
+ sensor_groups[type].compatible)) {
+ sensor_groups[type].attr_count++;
+ break;
+ }
+ }
+
+ of_node_put(opal);
+
+ for (type = 0; type < MAX_SENSOR_TYPE; type++) {
+ sensor_groups[type].group.attrs = devm_kzalloc(&pdev->dev,
+ sizeof(struct attribute *) *
+ (sensor_groups[type].attr_count + 1),
+ GFP_KERNEL);
+ if (!sensor_groups[type].group.attrs)
+ return -ENOMEM;
+
+ pgroups[type] = &sensor_groups[type].group;
+ pdata->sensors_count += sensor_groups[type].attr_count;
+ sensor_groups[type].attr_count = 0;
+ }
+
+ return 0;
+}
+
+/*
+ * Iterate through the device tree for each child of 'sensors' node, create
+ * a sysfs attribute file, the file is named by translating the DT node name
+ * to the name required by the higher 'hwmon' driver like fan1_input, temp1_max
+ * etc..
+ */
+static int __init create_device_attrs(struct platform_device *pdev)
+{
+ struct platform_data *pdata = platform_get_drvdata(pdev);
+ const struct attribute_group **pgroups = pdata->attr_groups;
+ struct device_node *opal, *np;
+ struct sensor_data *sdata;
+ const __be32 *sensor_id;
+ enum sensors type;
+ u32 count = 0;
+ int err = 0;
+
+ opal = of_find_node_by_path("/ibm,opal/sensors");
+ if (!opal) {
+ pr_err("%s: Opal 'sensors' node not found\n", __func__);
+ return -ENODEV;
+ }
+
+ sdata = devm_kzalloc(&pdev->dev, (pdata->sensors_count) *
+ sizeof(*sdata), GFP_KERNEL);
+ if (!sdata) {
+ err = -ENOMEM;
+ goto exit_put_node;
+ }
+
+ for_each_child_of_node(opal, np) {
+ if (np->name == NULL)
+ continue;
+
+ for (type = 0; type < MAX_SENSOR_TYPE; type++)
+ if (of_device_is_compatible(np,
+ sensor_groups[type].compatible))
+ break;
+
+ if (type == MAX_SENSOR_TYPE)
+ continue;
+
+ sensor_id = of_get_property(np, "sensor-id", NULL);
+ if (!sensor_id) {
+ pr_info("%s: 'sensor-id' property not present in %s\n",
+ __func__, np->name);
+ continue;
+ }
+
+ sdata[count].id = be32_to_cpup(sensor_id);
+ sdata[count].type = type;
+ err = create_hwmon_attr_name(type, np->name, sdata[count].name);
+ if (err)
+ goto exit_put_node;
+
+ sysfs_attr_init(&sdata[count].dev_attr.attr);
+ sdata[count].dev_attr.attr.name = sdata[count].name;
+ sdata[count].dev_attr.attr.mode = S_IRUGO;
+ sdata[count].dev_attr.show = show_sensor;
+
+ pgroups[type]->attrs[sensor_groups[type].attr_count++] =
+ &sdata[count++].dev_attr.attr;
+ }
+
+exit_put_node:
+ of_node_put(opal);
+ return err;
+}
+
+static int __init ibmpowernv_probe(struct platform_device *pdev)
+{
+ struct platform_data *pdata;
+ struct device *hwmon_dev;
+ int err;
+
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, pdata);
+ pdata->sensors_count = 0;
+ err = populate_attr_groups(pdev);
+ if (err)
+ return err;
+
+ /* Create sysfs attribute data for each sensor found in the DT */
+ err = create_device_attrs(pdev);
+ if (err)
+ return err;
+
+ /* Finally, register with hwmon */
+ hwmon_dev = devm_hwmon_device_register_with_groups(&pdev->dev, DRVNAME,
+ pdata,
+ pdata->attr_groups);
+
+ return PTR_ERR_OR_ZERO(hwmon_dev);
+}
+
+static struct platform_driver ibmpowernv_driver = {
+ .driver = {
+ .owner = THIS_MODULE,
+ .name = DRVNAME,
+ },
+};
+
+static int __init ibmpowernv_init(void)
+{
+ int err;
+
+ pdevice = platform_device_alloc(DRVNAME, 0);
+ if (!pdevice) {
+ pr_err("%s: Device allocation failed\n", __func__);
+ err = -ENOMEM;
+ goto exit;
+ }
+
+ err = platform_device_add(pdevice);
+ if (err) {
+ pr_err("%s: Device addition failed (%d)\n", __func__, err);
+ goto exit_device_put;
+ }
+
+ err = platform_driver_probe(&ibmpowernv_driver, ibmpowernv_probe);
+ if (err) {
+ pr_err("%s: Platfrom driver probe failed\n", __func__);
+ goto exit_device_del;
+ }
+
+ return 0;
+
+exit_device_del:
+ platform_device_del(pdevice);
+exit_device_put:
+ platform_device_put(pdevice);
+exit:
+ return err;
+}
+
+static void __exit ibmpowernv_exit(void)
+{
+ platform_driver_unregister(&ibmpowernv_driver);
+ platform_device_unregister(pdevice);
+}
+
+MODULE_AUTHOR("Neelesh Gupta <neelegup@linux.vnet.ibm.com>");
+MODULE_DESCRIPTION("IBM POWERNV platform sensors");
+MODULE_LICENSE("GPL");
+
+module_init(ibmpowernv_init);
+module_exit(ibmpowernv_exit);
^ permalink raw reply related
* Re: [PATCH] powerpc: Reduce scariness of interrupt frames in stack traces
From: Michael Ellerman @ 2014-06-18 8:20 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20140612065308.GB16578@drongo>
On Thu, 2014-06-12 at 16:53 +1000, Paul Mackerras wrote:
> Some people see things like "Exception: 501" in stack traces in dmesg
> and assume that means that something has gone badly wrong, when in
> fact "Exception: 501" just means a device interrupt was taken.
> This changes "Exception" to "interrupt" to make it clearer that we
> are just recording the fact of a change in control flow rather than
> some error condition.
Surely this would be preferable:
> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> index 31d0215..aa103dc 100644
> --- a/arch/powerpc/kernel/process.c
> +++ b/arch/powerpc/kernel/process.c
> @@ -1577,7 +1577,7 @@ void show_stack(struct task_struct *tsk, unsigned long *stack)
> struct pt_regs *regs = (struct pt_regs *)
> (sp + STACK_FRAME_OVERHEAD);
> lr = regs->link;
> - printk("--- Exception: %lx at %pS\n LR = %pS\n",
> + printk("--- 👋🌷🌹🌻🌼🐷🐰🐱💜: %lx at %pS\n LR = %pS\n",
> regs->trap, (void *)regs->nip, (void *)lr);
> firstframe = 1;
> }
^ permalink raw reply
* Re: [PATCH 0/6] powerpc/powernv: Applying it_page_shift to platform code
From: Alexey Kardashevskiy @ 2014-06-18 7:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Paul Mackerras, linuxppc-dev, linux-kernel, Alistair Popple
In-Reply-To: <1402044246-13650-1-git-send-email-aik@ozlabs.ru>
On 06/06/2014 06:44 PM, Alexey Kardashevskiy wrote:
> Here is what I got for powernv in order to support variable page size
> in iommu_table.
>
> I am very uncertain about Patch #4 "Add @it_owner to iommu_table struct"
> and wonder if there any better way to get PE from iommu_table.
>
> Please comment. Thanks.
Ben, these patches are really simple :)
>
>
> Alexey Kardashevskiy (6):
> powerpc/powernv: use it_page_shift for TCE invalidation
> powerpc/powernv: use it_page_shift in TCE build
> powerpc/powernv: Add a page size parameter to
> pnv_pci_setup_iommu_table()
> powerpc/powernv: Add @it_owner to iommu_table struct
> powerpc/powernv: Make set_bypass() callback a type
> powerpc/powernv: Make invalidate() callback an iommu_table callback
>
> arch/powerpc/include/asm/iommu.h | 13 ++++++-
> arch/powerpc/platforms/powernv/pci-ioda.c | 55 ++++++++++++++---------------
> arch/powerpc/platforms/powernv/pci-p5ioc2.c | 3 +-
> arch/powerpc/platforms/powernv/pci.c | 43 +++++++++++++++-------
> arch/powerpc/platforms/powernv/pci.h | 7 ++--
> 5 files changed, 74 insertions(+), 47 deletions(-)
>
--
Alexey
^ permalink raw reply
* Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
From: Michael Ellerman @ 2014-06-18 7:56 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Jeremy Fitzhardinge, linux-ia64, sparse,
Linux Kernel Mailing List, Paul Mackerras, H. Peter Anvin,
Thomas Gleixner, linux-tip-commits, anil.s.keshavamurthy,
Ingo Molnar, Suzuki K. Poulose, Fenghua Yu, Arnd Bergmann,
Rusty Russell, Chris Wright, yrl.pp-manager.tt, akataria,
Tony Luck, Kevin Hao, linuxppc-dev, rdunlap, Tony Luck, dl9pf,
Andrew Morton, Linus Torvalds, David S. Miller
In-Reply-To: <539161D6.7020508@hitachi.com>
On Fri, 2014-06-06 at 15:38 +0900, Masami Hiramatsu wrote:
> Ping?
>
> I guess this should go to 3.16 branch, shouldn't it?
> > diff --git a/arch/powerpc/include/asm/types.h b/arch/powerpc/include/asm/types.h
> > index bfb6ded..8b89d65 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 function_entry(fn) (((func_descr_t *)(fn))->entry)
> > +#else
> > +#define function_entry(fn) ((unsigned long)(fn))
> > +#endif
We already have ppc_function_entry(), can't you use that?
cheers
^ permalink raw reply
* Re: Boot failure in Power7 pSeries
From: Michael Ellerman @ 2014-06-18 7:54 UTC (permalink / raw)
To: Mike Qiu; +Cc: linuxppc-dev
In-Reply-To: <53A1070C.50106@linux.vnet.ibm.com>
On Wed, 2014-06-18 at 11:27 +0800, Mike Qiu wrote:
> Anyone has a idea on this issue?
Did it ever work? If so which kernel version?
Can you attach your actual .config.
You could try building without CONFIG_PPC_POWERNV.
cheers
^ permalink raw reply
* [PATCH v4] KVM: PPC: e500mc: Enhance tlb invalidation condition on vcpu schedule
From: Mihai Caraman @ 2014-06-18 7:15 UTC (permalink / raw)
To: kvm-ppc; +Cc: Scott Wood, Mihai Caraman, linuxppc-dev, kvm
On vcpu schedule, the condition checked for tlb pollution is too loose.
The tlb entries of a vcpu become polluted (vs stale) only when a different
vcpu within the same logical partition runs in-between. Optimize the tlb
invalidation condition keeping last_vcpu per logical partition id.
With the new invalidation condition, a guest shows 4% performance improvement
on P5020DS while running a memory stress application with the cpu oversubscribed,
the other guest running a cpu intensive workload.
Guest - old invalidation condition
real 3.89
user 3.87
sys 0.01
Guest - enhanced invalidation condition
real 3.75
user 3.73
sys 0.01
Host
real 3.70
user 1.85
sys 0.00
The memory stress application accesses 4KB pages backed by 75% of available
TLB0 entries:
char foo[ENTRIES][4096] __attribute__ ((aligned (4096)));
int main()
{
char bar;
int i, j;
for (i = 0; i < ITERATIONS; i++)
for (j = 0; j < ENTRIES; j++)
bar = foo[j][0];
return 0;
}
Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
Cc: Scott Wood <scottwood@freescale.com>
---
v4:
- rename last_vcpu_on_cpu to last_vcpu_of_lpid
- use "*[" syntax despite checkpatch error
v3:
- use existing logic while keeping last_cpu per lpid
arch/powerpc/kvm/e500mc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kvm/e500mc.c b/arch/powerpc/kvm/e500mc.c
index 17e4562..690499d 100644
--- a/arch/powerpc/kvm/e500mc.c
+++ b/arch/powerpc/kvm/e500mc.c
@@ -110,7 +110,7 @@ void kvmppc_mmu_msr_notify(struct kvm_vcpu *vcpu, u32 old_msr)
{
}
-static DEFINE_PER_CPU(struct kvm_vcpu *, last_vcpu_on_cpu);
+static DEFINE_PER_CPU(struct kvm_vcpu *[KVMPPC_NR_LPIDS], last_vcpu_of_lpid);
static void kvmppc_core_vcpu_load_e500mc(struct kvm_vcpu *vcpu, int cpu)
{
@@ -141,9 +141,9 @@ static void kvmppc_core_vcpu_load_e500mc(struct kvm_vcpu *vcpu, int cpu)
mtspr(SPRN_GESR, vcpu->arch.shared->esr);
if (vcpu->arch.oldpir != mfspr(SPRN_PIR) ||
- __get_cpu_var(last_vcpu_on_cpu) != vcpu) {
+ __get_cpu_var(last_vcpu_of_lpid)[vcpu->kvm->arch.lpid] != vcpu) {
kvmppc_e500_tlbil_all(vcpu_e500);
- __get_cpu_var(last_vcpu_on_cpu) = vcpu;
+ __get_cpu_var(last_vcpu_of_lpid)[vcpu->kvm->arch.lpid] = vcpu;
}
kvmppc_load_guest_fp(vcpu);
--
1.7.11.7
^ permalink raw reply related
* Re: Kernel 3.15: Boot problems with a PA6T board
From: Michael Ellerman @ 2014-06-18 6:51 UTC (permalink / raw)
To: Christian Zigotzky; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <5397060F.9010308@xenosoft.de>
On Tue, 2014-06-10 at 15:20 +0200, Christian Zigotzky wrote:
> Hi All,
>
> Could you help me to remove the changes of the PCI code, please? Or
> which patches shall I remove to get the old PCI code?
Hi Christian,
Thanks for doing the bisect. It wasn't clear why that change was causing your
issue, so I guess we're a bit stuck.
Olof (on CC), was going to try and look at it when he got some spare time.
Please keep him on CC.
cheers
^ permalink raw reply
* Re: Build regressions/improvements in v3.16-rc1
From: Guenter Roeck @ 2014-06-18 4:41 UTC (permalink / raw)
To: Geert Uytterhoeven, linux-kernel@vger.kernel.org
Cc: sparclinux, Linux MIPS Mailing List, Michal Simek,
linuxppc-dev@lists.ozlabs.org, Linux-sh list
In-Reply-To: <CAMuHMdU2DTt0va67uSKqhhqbVORuY+xEs3uGZ21sKjahE_MSXg@mail.gmail.com>
On 06/17/2014 08:23 AM, Geert Uytterhoeven wrote:
> On Tue, Jun 17, 2014 at 5:16 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
[...]
>
>> + /scratch/kisskb/src/sound/soc/fsl/fsl_dma.c: error: invalid use of undefined type 'struct ccsr_ssi': => 926:34, 927:34
>
> powerpc/mpc85xx_defconfig
>
Being fixed:
http://patchwork.ozlabs.org/patch/358500/
Guenter
^ permalink raw reply
* Re: Boot failure in Power7 pSeries
From: Mike Qiu @ 2014-06-18 3:27 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <53A00E2B.8030903@linux.vnet.ibm.com>
Anyone has a idea on this issue?
Thanks
Mike
On 06/17/2014 05:45 PM, Mike Qiu wrote:
> Hi all,
>
> I use newest linux-next( top commit:
> 5f295cdf5c5dbbb0c40f10f2ddae02ff46bbf773) to boot up my Power7
> machine, PowerVM mode(HypMode 01), use defualt config file in /boot/,
> it show error log below:
>
> OF stdout device is: /vdevice/vty@30000000
> Preparing to boot Linux version 3.16.0-rc1-next-20140617+ (root@shui)
> (gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC) ) #5 SMP Tue Jun
> 17 05:16:21 EDT 2014
> Detected machine type: 0000000000000101
> Max number of cores passed to firmware: 256 (NR_CPUS = 1024)
> Calling ibm,client-architecture-support... done
> command line: BOOT_IMAGE=/vmlinux-3.16.0-rc1-next-20140617+
> root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap rd.md=0 rd.dm=0
> vconsole.keymap=us rd.luks=0 vconsole.font=latarcyrheb-sun16 rd.lvt
> memory layout at init:
> memory_limit : 0000000000000000 (16 MB aligned)
> alloc_bottom : 0000000005910000
> alloc_top : 0000000010000000
> alloc_top_hi : 0000000010000000
> rmo_top : 0000000010000000
> ram_top : 0000000010000000
> instantiating rtas at 0x000000000ee80000... done
> Querying for OPAL presence... DEFAULT CATCH!, exception-handler=fff00700
> at %SRR0: 00000000041a1c14 %SRR1: 0000000000081002
> Open Firmware exception handler entered from non-OF code
>
> Client's Fix Pt Regs:
> 00 00000000042c017c 00000000042c2ce8 0000000004ae8d58 00000000042c2f38
> 04 000000000369aafc 00000000042c2f38 0000000001adc100 00000000042c2f38
> 08 0000000000000000 0000000004328d58 0000000028002024 0000000000001002
> 0c a000000000000001 0000000000000000 0000000001a9fd20 00000000041a7df8
> 10 00000000041a2130 00000000041a1e70 f821ff913d220005 0000000001a9fd20
> 14 0000000000007962 000000000ee80000 0000000001180000 000000000ee80000
> 18 00000000041a2610 0000000003690000 00000000042c3070 00000000041a1ce8
> 1c 00000000041a1ce0 00000000041b89f0 0000000000000003 0000000000000001
> Special Regs:
> %IV: 00000700 %CR: 48002024 %XER: 00000000 %DSISR: 40000000
> %SRR0: 00000000041a1c14 %SRR1: 0000000000081002
> %LR: 000000000369aafc %CTR: 0000000000000000
> %DAR: f821ff913d220035
> Virtual PID = 0
> ok
> 0 >
>
> Thanks
> Mike
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 23/38] mmc: sdhci: convert sdhci_set_uhs_signaling() into a library function
From: Russell King - ARM Linux @ 2014-06-17 23:42 UTC (permalink / raw)
To: Ulf Hansson
Cc: Barry Song, Anton Vorontsov, Stephen Warren, spear-devel,
linux-mmc, Chris Ball, Michal Simek, Thierry Reding, Viresh Kumar,
Ben Dooks, linux-tegra@vger.kernel.org, linuxppc-dev,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAPDyKFrp8JokqBbo3rg2i6WYykU1C9CuPF0FL7AOHh=Gcp5=hg@mail.gmail.com>
On Mon, Jun 16, 2014 at 02:17:30PM +0200, Ulf Hansson wrote:
> On 16 June 2014 12:46, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> > On Wed, Apr 23, 2014 at 08:08:07PM +0100, Russell King wrote:
> >> @@ -1507,25 +1529,7 @@ static void sdhci_do_set_ios(struct sdhci_host *host, struct mmc_ios *ios)
> >> host->ops->set_clock(host, host->clock);
> >> }
> >>
> >> - if (host->ops->set_uhs_signaling)
> >> - host->ops->set_uhs_signaling(host, ios->timing);
> >> - else {
> >> - ctrl_2 = sdhci_readw(host, SDHCI_HOST_CONTROL2);
> >> - /* Select Bus Speed Mode for host */
> >> - ctrl_2 &= ~SDHCI_CTRL_UHS_MASK;
> >> - if ((ios->timing == MMC_TIMING_MMC_HS200) ||
> >> - (ios->timing == MMC_TIMING_UHS_SDR104))
> >> - ctrl_2 |= SDHCI_CTRL_UHS_SDR104;
> >> - else if (ios->timing == MMC_TIMING_UHS_SDR12)
> >> - ctrl_2 |= SDHCI_CTRL_UHS_SDR12;
> >> - else if (ios->timing == MMC_TIMING_UHS_SDR25)
> >> - ctrl_2 |= SDHCI_CTRL_UHS_SDR25;
> >> - else if (ios->timing == MMC_TIMING_UHS_SDR50)
> >> - ctrl_2 |= SDHCI_CTRL_UHS_SDR50;
> >> - else if (ios->timing == MMC_TIMING_UHS_DDR50)
> >> - ctrl_2 |= SDHCI_CTRL_UHS_DDR50;
> >> - sdhci_writew(host, ctrl_2, SDHCI_HOST_CONTROL2);
> >> - }
> >> + host->ops->set_uhs_signaling(host, ios->timing);
> >>
> >> if (!(host->quirks2 & SDHCI_QUIRK2_PRESET_VALUE_BROKEN) &&
> >> ((ios->timing == MMC_TIMING_UHS_SDR12) ||
> >
> > Whoever decided to poorly pick these patches up against my will has
> > slightly messed this patch up - whereas my original patch left the
> > code correctly formatted, when whoever applied this patch did so, they
> > left an additional blank line in the above.
>
> Hi Russell,
>
> We kindly pinged you several times asking for your state and for the
> PR, but I suppose you were just too busy. Your PR were kind of
> blocking patches for sdhci, if you remember.
I wasn't "too busy". I had walked away from all kernel maintanence in
disgust at the way many in the ARM community ignores questions, and
ignores patches which need testing - I'm talking there about the L2C
patch series which was extremely poorly tested, and still, to this day,
has questions outstanding. Yes, the code now produces warnings. It
produces warnings /because/ people were not willing to help.
Those warnings serve as a reminder that there's still problems which
need solving there, and they're not going to go away until those
problems are solved.
While I don't like pushing unfinished code into mainline, in this case,
others deemed the patch set too important _not_ to go into mainline
even with these problems.
Now, it's been /soo/ long since I worked on that patch set that my
knowledge has now diminished... so it's now going to be _much_ harder
to resolve those issues than it would have been three months ago.
And I'm also holding a grudge, and I bear grudges for a long time, so
expect me to be "difficult" towards Linux stuff for a while yet.
> The mmc people were also very helping in sending patches to fixup
> related regressions, immediately after we merged your patchset. Thus
> together I think we managed to pull it off.
The formatting problem I refer to above is line 1532/1533 in sdhci.c -
there's an additional blank line which somehow got left behind, caused
presumably by insufficient attention paid to cleaning up a conflict
between my original patches and the state of the tree they were
applied to.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
^ permalink raw reply
* Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
From: Tony Luck @ 2014-06-17 23:03 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Jeremy Fitzhardinge, linux-ia64@vger.kernel.org, sparse,
Paul Mackerras, H. Peter Anvin, Thomas Gleixner,
linux-tip-commits, anil.s.keshavamurthy, Ingo Molnar,
Suzuki K. Poulose, Fenghua Yu, Arnd Bergmann, Rusty Russell,
Chris Wright, yrl.pp-manager.tt, akataria, Kevin Hao,
Linus Torvalds, rdunlap, Linux Kernel Mailing List, dl9pf,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <539161D6.7020508@hitachi.com>
On Thu, Jun 5, 2014 at 11:38 PM, Masami Hiramatsu
<masami.hiramatsu.pt@hitachi.com> wrote:
> Ping?
>
> I guess this should go to 3.16 branch, shouldn't it?
>
> (2014/05/30 12:18), 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
Yes please ... just found this problem on ia64 in mainline
and was happy to see this fix for it.
Tested-by: Tony Luck <tony.luck@intel.com>
-Tony
^ permalink raw reply
* Re: Build regressions/improvements in v3.16-rc1
From: Sam Ravnborg @ 2014-06-17 21:29 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux MIPS Mailing List, Michal Simek, Linux-sh list,
linux-kernel@vger.kernel.org, sparclinux,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CAMuHMdU2DTt0va67uSKqhhqbVORuY+xEs3uGZ21sKjahE_MSXg@mail.gmail.com>
>
> > + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_add' [-Werror=implicit-function-declaration]: => 176:2
> > + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_add_negative' [-Werror=implicit-function-declaration]: => 211:2
> > + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_add_return' [-Werror=implicit-function-declaration]: => 218:2
> > + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_dec' [-Werror=implicit-function-declaration]: => 169:2
> > + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_dec_and_test' [-Werror=implicit-function-declaration]: => 197:2
> > + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_dec_return' [-Werror=implicit-function-declaration]: => 239:2
> > + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_inc' [-Werror=implicit-function-declaration]: => 162:2
> > + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_inc_and_test' [-Werror=implicit-function-declaration]: => 204:2
> > + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_inc_return' [-Werror=implicit-function-declaration]: => 232:2
> > + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_set' [-Werror=implicit-function-declaration]: => 155:2
> > + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_sub' [-Werror=implicit-function-declaration]: => 183:2
> > + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_sub_and_test' [-Werror=implicit-function-declaration]: => 190:2
> > + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_sub_return' [-Werror=implicit-function-declaration]: => 225:2
> > + /scratch/kisskb/src/include/linux/atomic.h: error: implicit declaration of function '__atomic_add_unless' [-Werror=implicit-function-declaration]: => 53:2
> > + /scratch/kisskb/src/include/linux/atomic.h: error: implicit declaration of function 'atomic_cmpxchg' [-Werror=implicit-function-declaration]: => 89:3
> > + /scratch/kisskb/src/include/linux/atomic.h: error: implicit declaration of function 'atomic_read' [-Werror=implicit-function-declaration]: => 136:2
>
> sparc-allmodconfig
Not reproduceable here with linus latest. (-rc1 + two patches).
Can you help me with a pointer to the original build log?
Sam
^ permalink raw reply
* Re: Build regressions/improvements in v3.16-rc1
From: Geert Uytterhoeven @ 2014-06-17 21:32 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Linux MIPS Mailing List, Michal Simek, Linux-sh list,
linux-kernel@vger.kernel.org, sparclinux,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20140617212917.GA22353@ravnborg.org>
Hi Sam,
On Tue, Jun 17, 2014 at 11:29 PM, Sam Ravnborg <sam@ravnborg.org> wrote:
>> > + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_add' [-Werror=implicit-function-declaration]: => 176:2
>> > + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_add_negative' [-Werror=implicit-function-declaration]: => 211:2
>> > + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_add_return' [-Werror=implicit-function-declaration]: => 218:2
>> > + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_dec' [-Werror=implicit-function-declaration]: => 169:2
>> > + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_dec_and_test' [-Werror=implicit-function-declaration]: => 197:2
>> > + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_dec_return' [-Werror=implicit-function-declaration]: => 239:2
>> > + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_inc' [-Werror=implicit-function-declaration]: => 162:2
>> > + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_inc_and_test' [-Werror=implicit-function-declaration]: => 204:2
>> > + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_inc_return' [-Werror=implicit-function-declaration]: => 232:2
>> > + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_set' [-Werror=implicit-function-declaration]: => 155:2
>> > + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_sub' [-Werror=implicit-function-declaration]: => 183:2
>> > + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_sub_and_test' [-Werror=implicit-function-declaration]: => 190:2
>> > + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_sub_return' [-Werror=implicit-function-declaration]: => 225:2
>> > + /scratch/kisskb/src/include/linux/atomic.h: error: implicit declaration of function '__atomic_add_unless' [-Werror=implicit-function-declaration]: => 53:2
>> > + /scratch/kisskb/src/include/linux/atomic.h: error: implicit declaration of function 'atomic_cmpxchg' [-Werror=implicit-function-declaration]: => 89:3
>> > + /scratch/kisskb/src/include/linux/atomic.h: error: implicit declaration of function 'atomic_read' [-Werror=implicit-function-declaration]: => 136:2
>>
>> sparc-allmodconfig
> Not reproduceable here with linus latest. (-rc1 + two patches).
> Can you help me with a pointer to the original build log?
http://kisskb.ellerman.id.au/kisskb/buildresult/11340509/
They've been there since quite a while (in -next since Apr 22),
but lately I didn't have much time to dive into -next build failures.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3] KVM: PPC: e500mc: Enhance tlb invalidation condition on vcpu schedule
From: Alexander Graf @ 2014-06-17 20:42 UTC (permalink / raw)
To: mihai.caraman@freescale.com, Scott Wood, Alexander Graf
Cc: linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org,
kvm-ppc@vger.kernel.org
In-Reply-To: <074d849370834f748fe442ed851c0dad@BY2PR03MB508.namprd03.prod.outlook.com>
On 17.06.14 22:36, mihai.caraman@freescale.com wrote:
>> -----Original Message-----
>> From: Wood Scott-B07421
>> Sent: Tuesday, June 17, 2014 11:05 PM
>> To: Caraman Mihai Claudiu-B02008
>> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
>> dev@lists.ozlabs.org
>> Subject: Re: [PATCH v3] KVM: PPC: e500mc: Enhance tlb invalidation
>> condition on vcpu schedule
>>
>> On Tue, 2014-06-17 at 15:02 -0500, Caraman Mihai Claudiu-B02008 wrote:
>>>> -----Original Message-----
>>>> From: Wood Scott-B07421
>>>> Sent: Tuesday, June 17, 2014 10:48 PM
>>>> To: Caraman Mihai Claudiu-B02008
>>>> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
>>>> dev@lists.ozlabs.org
>>>> Subject: Re: [PATCH v3] KVM: PPC: e500mc: Enhance tlb invalidation
>>>> condition on vcpu schedule
>>>>
>>>> On Tue, 2014-06-17 at 14:42 -0500, Caraman Mihai Claudiu-B02008
>> wrote:
>>>>>>> -static DEFINE_PER_CPU(struct kvm_vcpu *, last_vcpu_on_cpu);
>>>>>>> +static DEFINE_PER_CPU(struct kvm_vcpu * [KVMPPC_NR_LPIDS],
>>>>>> last_vcpu_on_cpu);
>>>>>>
>>>>>> Hmm, I didn't know you could express types like that. Is this
>>>> special
>>>>>> syntax that only works for typeof?
>>>>> Yes, AFAIK.
>>>>>
>>>>>> No space after *
>>>>> Checkpatch complains about the missing space ;)
>>>> Checkpatch is wrong, which isn't surprising given that this is
>> unusual
>>>> syntax. We don't normally put a space after * when used to represent
>> a
>>>> pointer.
>>> This is not something new. See [PATCH 04/10] percpu: cleanup percpu
>> array
>>> definitions:
>>>
>>> https://lkml.org/lkml/2009/6/24/26
>> I didn't say it was new, just unusual, and checkpatch doesn't recognize
>> it. Checkpatch shouldn't be blindly and silently obeyed when it says
>> something strange.
> I agree with you about the syntax and I know other cases where checkpatch
> is a moron. For similar corner cases checkpatch maintainers did not wanted
> (or found it difficult) to make an exception. I would also like to see Alex
> opinion on this.
I usually like to apply common sense :).
Alex
^ permalink raw reply
* RE: [PATCH v3] KVM: PPC: e500mc: Enhance tlb invalidation condition on vcpu schedule
From: mihai.caraman @ 2014-06-17 20:36 UTC (permalink / raw)
To: Scott Wood, Alexander Graf
Cc: linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org,
kvm-ppc@vger.kernel.org
In-Reply-To: <1403035510.6603.801.camel@snotra.buserror.net>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBXb29kIFNjb3R0LUIwNzQyMQ0K
PiBTZW50OiBUdWVzZGF5LCBKdW5lIDE3LCAyMDE0IDExOjA1IFBNDQo+IFRvOiBDYXJhbWFuIE1p
aGFpIENsYXVkaXUtQjAyMDA4DQo+IENjOiBrdm0tcHBjQHZnZXIua2VybmVsLm9yZzsga3ZtQHZn
ZXIua2VybmVsLm9yZzsgbGludXhwcGMtDQo+IGRldkBsaXN0cy5vemxhYnMub3JnDQo+IFN1Ympl
Y3Q6IFJlOiBbUEFUQ0ggdjNdIEtWTTogUFBDOiBlNTAwbWM6IEVuaGFuY2UgdGxiIGludmFsaWRh
dGlvbg0KPiBjb25kaXRpb24gb24gdmNwdSBzY2hlZHVsZQ0KPiANCj4gT24gVHVlLCAyMDE0LTA2
LTE3IGF0IDE1OjAyIC0wNTAwLCBDYXJhbWFuIE1paGFpIENsYXVkaXUtQjAyMDA4IHdyb3RlOg0K
PiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IFdvb2QgU2NvdHQt
QjA3NDIxDQo+ID4gPiBTZW50OiBUdWVzZGF5LCBKdW5lIDE3LCAyMDE0IDEwOjQ4IFBNDQo+ID4g
PiBUbzogQ2FyYW1hbiBNaWhhaSBDbGF1ZGl1LUIwMjAwOA0KPiA+ID4gQ2M6IGt2bS1wcGNAdmdl
ci5rZXJuZWwub3JnOyBrdm1Admdlci5rZXJuZWwub3JnOyBsaW51eHBwYy0NCj4gPiA+IGRldkBs
aXN0cy5vemxhYnMub3JnDQo+ID4gPiBTdWJqZWN0OiBSZTogW1BBVENIIHYzXSBLVk06IFBQQzog
ZTUwMG1jOiBFbmhhbmNlIHRsYiBpbnZhbGlkYXRpb24NCj4gPiA+IGNvbmRpdGlvbiBvbiB2Y3B1
IHNjaGVkdWxlDQo+ID4gPg0KPiA+ID4gT24gVHVlLCAyMDE0LTA2LTE3IGF0IDE0OjQyIC0wNTAw
LCBDYXJhbWFuIE1paGFpIENsYXVkaXUtQjAyMDA4DQo+IHdyb3RlOg0KPiA+ID4gPiA+ID4gLXN0
YXRpYyBERUZJTkVfUEVSX0NQVShzdHJ1Y3Qga3ZtX3ZjcHUgKiwgbGFzdF92Y3B1X29uX2NwdSk7
DQo+ID4gPiA+ID4gPiArc3RhdGljIERFRklORV9QRVJfQ1BVKHN0cnVjdCBrdm1fdmNwdSAqIFtL
Vk1QUENfTlJfTFBJRFNdLA0KPiA+ID4gPiA+IGxhc3RfdmNwdV9vbl9jcHUpOw0KPiA+ID4gPiA+
DQo+ID4gPiA+ID4gSG1tLCBJIGRpZG4ndCBrbm93IHlvdSBjb3VsZCBleHByZXNzIHR5cGVzIGxp
a2UgdGhhdC4gIElzIHRoaXMNCj4gPiA+IHNwZWNpYWwNCj4gPiA+ID4gPiBzeW50YXggdGhhdCBv
bmx5IHdvcmtzIGZvciB0eXBlb2Y/DQo+ID4gPiA+DQo+ID4gPiA+IFllcywgQUZBSUsuDQo+ID4g
PiA+DQo+ID4gPiA+ID4gTm8gc3BhY2UgYWZ0ZXIgKg0KPiA+ID4gPg0KPiA+ID4gPiBDaGVja3Bh
dGNoIGNvbXBsYWlucyBhYm91dCB0aGUgbWlzc2luZyBzcGFjZSA7KQ0KPiA+ID4NCj4gPiA+IENo
ZWNrcGF0Y2ggaXMgd3JvbmcsIHdoaWNoIGlzbid0IHN1cnByaXNpbmcgZ2l2ZW4gdGhhdCB0aGlz
IGlzDQo+IHVudXN1YWwNCj4gPiA+IHN5bnRheC4gIFdlIGRvbid0IG5vcm1hbGx5IHB1dCBhIHNw
YWNlIGFmdGVyICogd2hlbiB1c2VkIHRvIHJlcHJlc2VudA0KPiBhDQo+ID4gPiBwb2ludGVyLg0K
PiA+DQo+ID4gVGhpcyBpcyBub3Qgc29tZXRoaW5nIG5ldy4gU2VlIFtQQVRDSCAwNC8xMF0gcGVy
Y3B1OiBjbGVhbnVwIHBlcmNwdQ0KPiBhcnJheQ0KPiA+IGRlZmluaXRpb25zOg0KPiA+DQo+ID4g
CWh0dHBzOi8vbGttbC5vcmcvbGttbC8yMDA5LzYvMjQvMjYNCj4gDQo+IEkgZGlkbid0IHNheSBp
dCB3YXMgbmV3LCBqdXN0IHVudXN1YWwsIGFuZCBjaGVja3BhdGNoIGRvZXNuJ3QgcmVjb2duaXpl
DQo+IGl0LiAgQ2hlY2twYXRjaCBzaG91bGRuJ3QgYmUgYmxpbmRseSBhbmQgc2lsZW50bHkgb2Jl
eWVkIHdoZW4gaXQgc2F5cw0KPiBzb21ldGhpbmcgc3RyYW5nZS4NCg0KSSBhZ3JlZSB3aXRoIHlv
dSBhYm91dCB0aGUgc3ludGF4IGFuZCBJIGtub3cgb3RoZXIgY2FzZXMgd2hlcmUgY2hlY2twYXRj
aA0KaXMgYSBtb3Jvbi4gRm9yIHNpbWlsYXIgY29ybmVyIGNhc2VzIGNoZWNrcGF0Y2ggbWFpbnRh
aW5lcnMgZGlkIG5vdCB3YW50ZWQNCihvciBmb3VuZCBpdCBkaWZmaWN1bHQpIHRvIG1ha2UgYW4g
ZXhjZXB0aW9uLiBJIHdvdWxkIGFsc28gbGlrZSB0byBzZWUgQWxleA0Kb3BpbmlvbiBvbiB0aGlz
Lg0KDQotTWlrZQ0KDQoNCg==
^ permalink raw reply
* Re: [PATCH v3] KVM: PPC: e500mc: Enhance tlb invalidation condition on vcpu schedule
From: Scott Wood @ 2014-06-17 20:05 UTC (permalink / raw)
To: Caraman Mihai Claudiu-B02008
Cc: linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org,
kvm-ppc@vger.kernel.org
In-Reply-To: <924c92bfa28a4d4096c3cbe0f7219123@BY2PR03MB508.namprd03.prod.outlook.com>
On Tue, 2014-06-17 at 15:02 -0500, Caraman Mihai Claudiu-B02008 wrote:
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Tuesday, June 17, 2014 10:48 PM
> > To: Caraman Mihai Claudiu-B02008
> > Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
> > dev@lists.ozlabs.org
> > Subject: Re: [PATCH v3] KVM: PPC: e500mc: Enhance tlb invalidation
> > condition on vcpu schedule
> >
> > On Tue, 2014-06-17 at 14:42 -0500, Caraman Mihai Claudiu-B02008 wrote:
> > > > > -static DEFINE_PER_CPU(struct kvm_vcpu *, last_vcpu_on_cpu);
> > > > > +static DEFINE_PER_CPU(struct kvm_vcpu * [KVMPPC_NR_LPIDS],
> > > > last_vcpu_on_cpu);
> > > >
> > > > Hmm, I didn't know you could express types like that. Is this
> > special
> > > > syntax that only works for typeof?
> > >
> > > Yes, AFAIK.
> > >
> > > > No space after *
> > >
> > > Checkpatch complains about the missing space ;)
> >
> > Checkpatch is wrong, which isn't surprising given that this is unusual
> > syntax. We don't normally put a space after * when used to represent a
> > pointer.
>
> This is not something new. See [PATCH 04/10] percpu: cleanup percpu array
> definitions:
>
> https://lkml.org/lkml/2009/6/24/26
I didn't say it was new, just unusual, and checkpatch doesn't recognize
it. Checkpatch shouldn't be blindly and silently obeyed when it says
something strange.
-Scott
^ permalink raw reply
* RE: [PATCH v3] KVM: PPC: e500mc: Enhance tlb invalidation condition on vcpu schedule
From: mihai.caraman @ 2014-06-17 20:02 UTC (permalink / raw)
To: Scott Wood
Cc: linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org,
kvm-ppc@vger.kernel.org
In-Reply-To: <1403034451.6603.788.camel@snotra.buserror.net>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBXb29kIFNjb3R0LUIwNzQyMQ0K
PiBTZW50OiBUdWVzZGF5LCBKdW5lIDE3LCAyMDE0IDEwOjQ4IFBNDQo+IFRvOiBDYXJhbWFuIE1p
aGFpIENsYXVkaXUtQjAyMDA4DQo+IENjOiBrdm0tcHBjQHZnZXIua2VybmVsLm9yZzsga3ZtQHZn
ZXIua2VybmVsLm9yZzsgbGludXhwcGMtDQo+IGRldkBsaXN0cy5vemxhYnMub3JnDQo+IFN1Ympl
Y3Q6IFJlOiBbUEFUQ0ggdjNdIEtWTTogUFBDOiBlNTAwbWM6IEVuaGFuY2UgdGxiIGludmFsaWRh
dGlvbg0KPiBjb25kaXRpb24gb24gdmNwdSBzY2hlZHVsZQ0KPiANCj4gT24gVHVlLCAyMDE0LTA2
LTE3IGF0IDE0OjQyIC0wNTAwLCBDYXJhbWFuIE1paGFpIENsYXVkaXUtQjAyMDA4IHdyb3RlOg0K
PiA+ID4gPiAtc3RhdGljIERFRklORV9QRVJfQ1BVKHN0cnVjdCBrdm1fdmNwdSAqLCBsYXN0X3Zj
cHVfb25fY3B1KTsNCj4gPiA+ID4gK3N0YXRpYyBERUZJTkVfUEVSX0NQVShzdHJ1Y3Qga3ZtX3Zj
cHUgKiBbS1ZNUFBDX05SX0xQSURTXSwNCj4gPiA+IGxhc3RfdmNwdV9vbl9jcHUpOw0KPiA+ID4N
Cj4gPiA+IEhtbSwgSSBkaWRuJ3Qga25vdyB5b3UgY291bGQgZXhwcmVzcyB0eXBlcyBsaWtlIHRo
YXQuICBJcyB0aGlzDQo+IHNwZWNpYWwNCj4gPiA+IHN5bnRheCB0aGF0IG9ubHkgd29ya3MgZm9y
IHR5cGVvZj8NCj4gPg0KPiA+IFllcywgQUZBSUsuDQo+ID4NCj4gPiA+IE5vIHNwYWNlIGFmdGVy
ICoNCj4gPg0KPiA+IENoZWNrcGF0Y2ggY29tcGxhaW5zIGFib3V0IHRoZSBtaXNzaW5nIHNwYWNl
IDspDQo+IA0KPiBDaGVja3BhdGNoIGlzIHdyb25nLCB3aGljaCBpc24ndCBzdXJwcmlzaW5nIGdp
dmVuIHRoYXQgdGhpcyBpcyB1bnVzdWFsDQo+IHN5bnRheC4gIFdlIGRvbid0IG5vcm1hbGx5IHB1
dCBhIHNwYWNlIGFmdGVyICogd2hlbiB1c2VkIHRvIHJlcHJlc2VudCBhDQo+IHBvaW50ZXIuDQoN
ClRoaXMgaXMgbm90IHNvbWV0aGluZyBuZXcuIFNlZSBbUEFUQ0ggMDQvMTBdIHBlcmNwdTogY2xl
YW51cCBwZXJjcHUgYXJyYXkNCmRlZmluaXRpb25zOg0KDQoJaHR0cHM6Ly9sa21sLm9yZy9sa21s
LzIwMDkvNi8yNC8yNg0KDQotTWlrZQ0K
^ permalink raw reply
* Re: [PATCH v3] KVM: PPC: e500mc: Enhance tlb invalidation condition on vcpu schedule
From: Scott Wood @ 2014-06-17 19:47 UTC (permalink / raw)
To: Caraman Mihai Claudiu-B02008
Cc: linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org,
kvm-ppc@vger.kernel.org
In-Reply-To: <37af68eb6855437892a438eec213d788@BY2PR03MB508.namprd03.prod.outlook.com>
On Tue, 2014-06-17 at 14:42 -0500, Caraman Mihai Claudiu-B02008 wrote:
> > > -static DEFINE_PER_CPU(struct kvm_vcpu *, last_vcpu_on_cpu);
> > > +static DEFINE_PER_CPU(struct kvm_vcpu * [KVMPPC_NR_LPIDS],
> > last_vcpu_on_cpu);
> >
> > Hmm, I didn't know you could express types like that. Is this special
> > syntax that only works for typeof?
>
> Yes, AFAIK.
>
> > No space after *
>
> Checkpatch complains about the missing space ;)
Checkpatch is wrong, which isn't surprising given that this is unusual
syntax. We don't normally put a space after * when used to represent a
pointer.
-Scott
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox