Re: [PATCH v4 0/4] Application Data Integrity feature introduced by SPARC M7

[David Miller]

From: Dave Hansen 
Date: Wed, 11 Jan 2017 08:33:30 -0800

> Is there a cost in the hardware associated with doing this "ADI
> checking"?  For instance, instead of having this new mprotect()
> interface, why not just always set TTE.mcd on all PTEs?

If we did this then for every page mapped into userspace we'd have
to explicitly set all of the tags to zero, otherwise we'd get TAG
mismatch exceptions.

That would be like clearing the every mapped anonymous page twice, or
worse.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 0/4] Application Data Integrity feature introduced by SPARC M7

[David Miller]

From: Dave Hansen 
Date: Wed, 11 Jan 2017 10:13:54 -0800

> For memory shared by two different processes, do they have to agree on
> what the tags are, or can they differ?

Whoever allocates the memory (does the mmap()+mprotect() or whatever),
decides on the tag.  They set it, and this determines which virtual
address is valid to access that mapping.

It's like kmalloc() returns pointers with some weird bits set in the
upper bits of the address.  Behind the scenes kmalloc() sets the
TAG bits appropriately.

It doesn't, in that sense, matter where in the non-tagged virtual
address space the memory is mapped.  All that matters is that, for
a given page, the TAG bits in the virtual address used for loads
and stores to that mapping are set properly.

I think the fundamental thing being missed is that the TAG bits in the
virtual address are not interpreted by the TLB.  They are chopped off
before virtual address translation occurs.

The TAG bits of the virtual address serve only to indicate what ADI
value the load or store thinks is valid to use for access to that
piece of memory.

Or something like that... :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 4/4] sparc64: Add support for ADI (Application Data Integrity)

[David Miller]

From: Khalid Aziz 
Date: Wed, 11 Jan 2017 09:12:54 -0700

> + __asm__ __volatile__(
> + ".word 0xa1438000\n\t"  /* rd  %mcdper, %l0 */

Just use "rd %%asr14, %0" this way you don't have to play all of these
fixed register games which kill the code generated by gcc.  If you
forcefully clobber a windowed register like %l0 it means the function
being emitted can never be a leaf function, tail calls are no longer
allowed, etc.

> + ".word 0x9d800011\n\t"  /* wr  %g0, %l1, %mcdper */

Likewise use "wr %%g0, %0, %%asr14"

> + ".word 0xaf91\n\t"  /* wrpr  %g0, %g1, %pmcdper */

Hmmm, which %asr encodes %pmcdper?

> diff --git a/arch/sparc/kernel/mdesc.c b/arch/sparc/kernel/mdesc.c
> index 8a6982d..68b03bf 100644
> --- a/arch/sparc/kernel/mdesc.c
> +++ b/arch/sparc/kernel/mdesc.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /* Unlike the OBP device tree, the machine description is a full-on
>   * DAG.  An arbitrary number of ARCs are possible from one
> @@ -1104,5 +1105,8 @@ void __init sun4v_mdesc_init(void)
>  
>   cur_mdesc = hp;
>  
> +#ifdef CONFIG_SPARC64

mdesc.c is only built on sparc64, this ifdef is superfluous.

> +/* Update the state of MCDPER register in current task's mm context before
> + * dup so the dup'd task will inherit flags in this register correctly.
> + * Current task may have updated flags since it started running.
> + */
> +int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src)
> +{
> + if (adi_capable() && src->mm) {
> + register unsigned long tmp_mcdper;
> +
> + __asm__ __volatile__(
> + ".word 0x83438000\n\t"  /* rd %mcdper, %g1 */
> + "mov %%g1, %0\n\t"
> + : "=r" (tmp_mcdper)
> + :
> + : "g1");
> + src->mm->context.mcdper = tmp_mcdper;

I don't like the idea of duplicating 'mm' state using the task struct
copy.  Why do not the MM handling interfaces handle this properly?

Maybe it means you've abstracted the ADI register handling in the
wrong place.  Maybe it's a thread property which is "pushed" from
the MM context.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Documentation: dontdiff: Update with additional entries

[Florian Fainelli]

Add a bunch of entries reflective of programs that the kernel build:
sortextable, dtc. And while at it, expand the lex*.c entries to cover
e.g: dtc-lexer.c. Finally, exclude devicetable-offsets.h

Signed-off-by: Florian Fainelli 
---
 Documentation/dontdiff | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/Documentation/dontdiff b/Documentation/dontdiff
index a23edccd2059..77b92221f951 100644
--- a/Documentation/dontdiff
+++ b/Documentation/dontdiff
@@ -116,9 +116,11 @@ crc32table.h*
 cscope.*
 defkeymap.c
 devlist.h*
+devicetable-offsets.h
 dnotify_test
 docproc
 dslm
+dtc
 elf2ecoff
 elfconfig.h*
 evergreen_reg_safe.h
@@ -153,8 +155,8 @@ keywords.c
 ksym.c*
 ksym.h*
 kxgettext
-lex.c
-lex.*.c
+*lex.c
+*lex.*.c
 linux
 logo_*.c
 logo_*_clut224.c
@@ -215,6 +217,7 @@ series
 setup
 setup.bin
 setup.elf
+sortextable
 sImage
 sm_tbl*
 split-include
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH linux v3 1/6] hwmon: Add core On-Chip Controller support for POWER CPUs

[eajames . ibm]

From: "Edward A. James" 

Add core support for polling the OCC for it's sensor data and parsing that
data into sensor-specific information.

Signed-off-by: Edward A. James 
Signed-off-by: Andrew Jeffery 
---
 Documentation/hwmon/occ|  40 
 MAINTAINERS|   7 +
 drivers/hwmon/Kconfig  |   2 +
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/occ/Kconfig  |  15 ++
 drivers/hwmon/occ/Makefile |   1 +
 drivers/hwmon/occ/occ.c| 522 +
 drivers/hwmon/occ/occ.h|  81 +++
 drivers/hwmon/occ/scom.h   |  47 
 9 files changed, 716 insertions(+)
 create mode 100644 Documentation/hwmon/occ
 create mode 100644 drivers/hwmon/occ/Kconfig
 create mode 100644 drivers/hwmon/occ/Makefile
 create mode 100644 drivers/hwmon/occ/occ.c
 create mode 100644 drivers/hwmon/occ/occ.h
 create mode 100644 drivers/hwmon/occ/scom.h

diff --git a/Documentation/hwmon/occ b/Documentation/hwmon/occ
new file mode 100644
index 000..79d1642
--- /dev/null
+++ b/Documentation/hwmon/occ
@@ -0,0 +1,40 @@
+Kernel driver occ
+=
+
+Supported chips:
+ * ASPEED AST2400
+ * ASPEED AST2500
+
+Please note that the chip must be connected to a POWER8 or POWER9 processor
+(see the BMC - Host Communications section).
+
+Author: Eddie James 
+
+Description
+---
+
+This driver implements support for the OCC (On-Chip Controller) on the IBM
+POWER8 and POWER9 processors, from a BMC (Baseboard Management Controller). The
+OCC is an embedded processor that provides real time power and thermal
+monitoring.
+
+This driver provides an interface on a BMC to poll OCC sensor data, set user
+power caps, and perform some basic OCC error handling.
+
+Currently, all versions of the OCC support four types of sensor data: power,
+temperature, frequency, and "caps," which indicate limits and thresholds used
+internally on the OCC.
+
+BMC - Host Communications
+-
+
+For the POWER8 application, the BMC can communicate with the P8 over I2C bus.
+However, to access the OCC register space, any data transfer must use a SCOM
+operation. SCOM is a procedure to initiate a data transfer, typically of 8
+bytes. SCOMs consist of writing a 32-bit command register and then
+reading/writing two 32-bit data registers. This driver implements these
+SCOM operations over I2C bus in order to communicate with the OCC.
+
+For the POWER9 application, the BMC can communicate with the P9 over FSI bus
+and SBE engine. Once again, SCOM operations are required. This driver will
+implement SCOM ops over FSI/SBE. This will require the FSI driver.
diff --git a/MAINTAINERS b/MAINTAINERS
index 5f0420a..f5d4195 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9112,6 +9112,13 @@ T:   git git://linuxtv.org/media_tree.git
 S: Maintained
 F: drivers/media/i2c/ov7670.c
 
+ON-CHIP CONTROLLER HWMON DRIVER
+M: Eddie James 
+L: linux-hw...@vger.kernel.org
+S: Maintained
+F: Documentation/hwmon/occ
+F: drivers/hwmon/occ/
+
 ONENAND FLASH DRIVER
 M: Kyungmin Park 
 L: linux-...@lists.infradead.org
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 190d270..e80ca81 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1240,6 +1240,8 @@ config SENSORS_NSA320
  This driver can also be built as a module. If so, the module
  will be called nsa320-hwmon.
 
+source drivers/hwmon/occ/Kconfig
+
 config SENSORS_PCF8591
tristate "Philips PCF8591 ADC/DAC"
depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index d2cb7e8..c7ec5d4 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -169,6 +169,7 @@ obj-$(CONFIG_SENSORS_WM831X)+= wm831x-hwmon.o
 obj-$(CONFIG_SENSORS_WM8350)   += wm8350-hwmon.o
 obj-$(CONFIG_SENSORS_XGENE)+= xgene-hwmon.o
 
+obj-$(CONFIG_SENSORS_PPC_OCC)  += occ/
 obj-$(CONFIG_PMBUS)+= pmbus/
 
 ccflags-$(CONFIG_HWMON_DEBUG_CHIP) := -DDEBUG
diff --git a/drivers/hwmon/occ/Kconfig b/drivers/hwmon/occ/Kconfig
new file mode 100644
index 000..cdb64a7
--- /dev/null
+++ b/drivers/hwmon/occ/Kconfig
@@ -0,0 +1,15 @@
+#
+# On Chip Controller configuration
+#
+
+menuconfig SENSORS_PPC_OCC
+   bool "PPC On-Chip Controller"
+   help
+ If you say yes here you get support to monitor Power CPU
+ sensors via the On-Chip Controller (OCC).
+
+ Generally this is used by management controllers such as a BMC
+ on an OpenPower system.
+
+ This driver can also be built as a module. If so, the module
+ will be called occ.
diff --git a/drivers/hwmon/occ/Makefile b/drivers/hwmon/occ/Makefile
new file mode 100644
index 000..93cb52f
--- /dev/null
+++ b/drivers/hwmon/occ/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_SENSORS_PPC_OCC) += occ.o
diff --git a/drivers/hwmon/occ/occ.c 

[PATCH linux v3 3/6] hwmon: occ: Add I2C transport implementation for SCOM operations

[eajames . ibm]

From: "Edward A. James" 

Add functions to send SCOM operations over I2C bus. The BMC can
communicate with the Power8 host processor over I2C, but needs to use SCOM
operations in order to access the OCC register space.

Signed-off-by: Edward A. James 
Signed-off-by: Andrew Jeffery 
---
 drivers/hwmon/occ/occ_scom_i2c.c | 72 
 drivers/hwmon/occ/occ_scom_i2c.h | 26 +++
 2 files changed, 98 insertions(+)
 create mode 100644 drivers/hwmon/occ/occ_scom_i2c.c
 create mode 100644 drivers/hwmon/occ/occ_scom_i2c.h

diff --git a/drivers/hwmon/occ/occ_scom_i2c.c b/drivers/hwmon/occ/occ_scom_i2c.c
new file mode 100644
index 000..8b4ca13
--- /dev/null
+++ b/drivers/hwmon/occ/occ_scom_i2c.c
@@ -0,0 +1,72 @@
+/*
+ * occ_scom_i2c.c - hwmon OCC driver
+ *
+ * This file contains the functions for performing SCOM operations over I2C bus
+ * to access the OCC.
+ *
+ * Copyright 2016 IBM Corp.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include "occ_scom_i2c.h"
+#include "scom.h"
+
+int occ_i2c_getscom(void *bus, u32 address, u64 *data)
+{
+   ssize_t rc;
+   u64 buf;
+   struct i2c_client *client = bus;
+
+   rc = i2c_master_send(client, (const char *), sizeof(u32));
+   if (rc < 0)
+   return rc;
+   else if (rc != sizeof(u32))
+   return -EIO;
+
+   rc = i2c_master_recv(client, (char *), sizeof(u64));
+   if (rc < 0)
+   return rc;
+   else if (rc != sizeof(u64))
+   return -EIO;
+
+   *data = be64_to_cpu(buf);
+
+   return 0;
+}
+EXPORT_SYMBOL(occ_i2c_getscom);
+
+int occ_i2c_putscom(void *bus, u32 address, u32 data0, u32 data1)
+{
+   u32 buf[3];
+   ssize_t rc;
+   struct i2c_client *client = bus;
+
+   buf[0] = address;
+   buf[1] = data1;
+   buf[2] = data0;
+
+   rc = i2c_master_send(client, (const char *)buf, sizeof(u32) * 3);
+   if (rc < 0)
+   return rc;
+   else if (rc != sizeof(u32) * 3)
+   return -EIO;
+
+   return 0;
+}
+EXPORT_SYMBOL(occ_i2c_putscom);
+
+MODULE_AUTHOR("Eddie James ");
+MODULE_DESCRIPTION("I2C OCC SCOM transport");
+MODULE_LICENSE("GPL");
diff --git a/drivers/hwmon/occ/occ_scom_i2c.h b/drivers/hwmon/occ/occ_scom_i2c.h
new file mode 100644
index 000..945739c
--- /dev/null
+++ b/drivers/hwmon/occ/occ_scom_i2c.h
@@ -0,0 +1,26 @@
+/*
+ * occ_scom_i2c.h - hwmon OCC driver
+ *
+ * This file contains function protoypes for peforming SCOM operations over I2C
+ * bus to access the OCC.
+ *
+ * Copyright 2016 IBM Corp.
+ *
+ * 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.
+ */
+
+#ifndef __OCC_SCOM_I2C_H__
+#define __OCC_SCOM_I2C_H__
+
+int occ_i2c_getscom(void *bus, u32 address, u64 *data);
+int occ_i2c_putscom(void *bus, u32 address, u32 data0, u32 data1);
+
+#endif /* __OCC_SCOM_I2C_H__ */
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH linux v3 4/6] hwmon: occ: Add callbacks for parsing P8 OCC datastructures

[eajames . ibm]

From: "Edward A. James" 

Add functions to parse the data structures that are specific to the OCC on
the POWER8 processor. These are the sensor data structures, including
temperature, frequency, power, and "caps."

Signed-off-by: Edward A. James 
Signed-off-by: Andrew Jeffery 
---
 Documentation/hwmon/occ|   9 ++
 drivers/hwmon/occ/occ_p8.c | 247 +
 drivers/hwmon/occ/occ_p8.h |  30 ++
 3 files changed, 286 insertions(+)
 create mode 100644 drivers/hwmon/occ/occ_p8.c
 create mode 100644 drivers/hwmon/occ/occ_p8.h

diff --git a/Documentation/hwmon/occ b/Documentation/hwmon/occ
index d0bdf06..143951e 100644
--- a/Documentation/hwmon/occ
+++ b/Documentation/hwmon/occ
@@ -25,6 +25,15 @@ Currently, all versions of the OCC support four types of 
sensor data: power,
 temperature, frequency, and "caps," which indicate limits and thresholds used
 internally on the OCC.
 
+The format for the POWER8 OCC sensor data can be found in the P8 OCC
+specification:
+github.com/open-power/docs/blob/master/occ/OCC_OpenPwr_FW_Interfaces.pdf
+This document provides the details of the OCC sensors: power, frequency,
+temperature, and caps. These sensor formats are specific to the POWER8 OCC. A
+number of data structures, such as command format, response headers, and the
+like, are also defined in this specification, and are common to both POWER8 and
+POWER9 OCCs.
+
 sysfs Entries
 -
 
diff --git a/drivers/hwmon/occ/occ_p8.c b/drivers/hwmon/occ/occ_p8.c
new file mode 100644
index 000..32215ed
--- /dev/null
+++ b/drivers/hwmon/occ/occ_p8.c
@@ -0,0 +1,247 @@
+/*
+ * occ_p8.c - OCC hwmon driver
+ *
+ * This file contains the Power8-specific methods and data structures for
+ * the OCC hwmon driver.
+ *
+ * Copyright 2016 IBM Corp.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "occ.h"
+#include "occ_p8.h"
+
+/* P8 OCC sensor data format */
+struct p8_occ_sensor {
+   u16 sensor_id;
+   u16 value;
+};
+
+struct p8_power_sensor {
+   u16 sensor_id;
+   u32 update_tag;
+   u32 accumulator;
+   u16 value;
+};
+
+struct p8_caps_sensor {
+   u16 curr_powercap;
+   u16 curr_powerreading;
+   u16 norm_powercap;
+   u16 max_powercap;
+   u16 min_powercap;
+   u16 user_powerlimit;
+};
+
+static const u32 p8_sensor_hwmon_configs[MAX_OCC_SENSOR_TYPE] = {
+   HWMON_I_INPUT | HWMON_I_LABEL,  /* freq: value | label */
+   HWMON_T_INPUT | HWMON_T_LABEL,  /* temp: value | label */
+   /* power: value | label | accumulator | update_tag */
+   HWMON_P_INPUT | HWMON_P_LABEL | HWMON_P_AVERAGE |
+   HWMON_P_AVERAGE_INTERVAL,
+   /* caps: curr | max | min | norm | user */
+   HWMON_P_CAP | HWMON_P_CAP_MAX | HWMON_P_CAP_MIN | HWMON_P_MAX |
+   HWMON_P_ALARM,
+};
+
+void p8_parse_sensor(u8 *data, void *sensor, int sensor_type, int off,
+int snum)
+{
+   switch (sensor_type) {
+   case FREQ:
+   case TEMP:
+   {
+   struct p8_occ_sensor *os =
+   &(((struct p8_occ_sensor *)sensor)[snum]);
+
+   os->sensor_id = be16_to_cpu(get_unaligned((u16 *)[off]));
+   os->value = be16_to_cpu(get_unaligned((u16 *)[off + 2]));
+   }
+   break;
+   case POWER:
+   {
+   struct p8_power_sensor *ps =
+   &(((struct p8_power_sensor *)sensor)[snum]);
+
+   ps->sensor_id = be16_to_cpu(get_unaligned((u16 *)[off]));
+   ps->update_tag =
+   be32_to_cpu(get_unaligned((u32 *)[off + 2]));
+   ps->accumulator =
+   be32_to_cpu(get_unaligned((u32 *)[off + 6]));
+   ps->value = be16_to_cpu(get_unaligned((u16 *)[off + 10]));
+   }
+   break;
+   case CAPS:
+   {
+   struct p8_caps_sensor *cs =
+   &(((struct p8_caps_sensor *)sensor)[snum]);
+
+   cs->curr_powercap =
+   be16_to_cpu(get_unaligned((u16 *)[off]));
+   cs->curr_powerreading =
+   be16_to_cpu(get_unaligned((u16 *)[off + 2]));
+   cs->norm_powercap =
+   be16_to_cpu(get_unaligned((u16 *)[off + 4]));
+   cs->max_powercap =
+

[PATCH linux v3 2/6] hwmon: occ: Add sysfs interface

[eajames . ibm]

From: "Edward A. James" 

Add a generic mechanism to expose the sensors provided by the OCC in
sysfs.

Signed-off-by: Edward A. James 
Signed-off-by: Andrew Jeffery 
---
 Documentation/hwmon/occ   |  62 ++
 drivers/hwmon/occ/Makefile|   2 +-
 drivers/hwmon/occ/occ_sysfs.c | 271 ++
 drivers/hwmon/occ/occ_sysfs.h |  44 +++
 4 files changed, 378 insertions(+), 1 deletion(-)
 create mode 100644 drivers/hwmon/occ/occ_sysfs.c
 create mode 100644 drivers/hwmon/occ/occ_sysfs.h

diff --git a/Documentation/hwmon/occ b/Documentation/hwmon/occ
index 79d1642..d0bdf06 100644
--- a/Documentation/hwmon/occ
+++ b/Documentation/hwmon/occ
@@ -25,6 +25,68 @@ Currently, all versions of the OCC support four types of 
sensor data: power,
 temperature, frequency, and "caps," which indicate limits and thresholds used
 internally on the OCC.
 
+sysfs Entries
+-
+
+The OCC driver uses the hwmon sysfs framework to provide data to userspace.
+
+The driver exports a number of sysfs files for each type of sensor. The
+sensor-specific files vary depending on the processor type, though many of the
+attributes are common for both the POWER8 and POWER9.
+
+The hwmon interface cannot define every type of sensor that may be used.
+Therefore, the frequency sensor on the OCC uses the "input" type sensor defined
+by the hwmon interface, rather than defining a new type of custom sensor.
+
+Below are detailed the names and meaning of each sensor file for both types of
+processors. All sensors are read-only unless otherwise specified.  indicates
+the hwmon index. sensor id indicates the unique internal OCC identifer. Please
+see the POWER OCC specification for details on all these sensor values.
+
+frequency:
+   all processors:
+   in_input - frequency value
+   in_label - sensor id
+temperature:
+   POWER8:
+   temp_input - temperature value
+   temp_label - sensor id
+   POWER9 (in addition to above):
+   temp_type - FRU type
+
+power:
+   POWER8:
+   power_input - power value
+   power_label - sensor id
+   power_average - accumulator
+   power_average_interval - update tag (number of samples in
+   accumulator)
+   POWER9:
+   power_input - power value
+   power_label - sensor id
+   power_average_min - accumulator[0]
+   power_average_max - accumulator[1] (64 bits total)
+   power_average_interval - update tag
+   power_reset_history - (function_id | (apss_channel << 8)
+
+caps:
+   POWER8:
+   power_cap - current powercap
+   power_cap_max - max powercap
+   power_cap_min - min powercap
+   power_max - normal powercap
+   power_alarm - user powercap, r/w
+   POWER9:
+   power_cap_alarm - user powercap source
+
+The driver also provides two sysfs entries through hwmon to better
+control the driver and monitor the master OCC. Though there may be multiple
+OCCs present on the system, these two files are only present for the "master"
+OCC.
+   name - read the name of the driver
+   update_interval - read or write the minimum interval for polling the
+   OCC.
+
 BMC - Host Communications
 -
 
diff --git a/drivers/hwmon/occ/Makefile b/drivers/hwmon/occ/Makefile
index 93cb52f..a6881f9 100644
--- a/drivers/hwmon/occ/Makefile
+++ b/drivers/hwmon/occ/Makefile
@@ -1 +1 @@
-obj-$(CONFIG_SENSORS_PPC_OCC) += occ.o
+obj-$(CONFIG_SENSORS_PPC_OCC) += occ.o occ_sysfs.o
diff --git a/drivers/hwmon/occ/occ_sysfs.c b/drivers/hwmon/occ/occ_sysfs.c
new file mode 100644
index 000..2f20c40
--- /dev/null
+++ b/drivers/hwmon/occ/occ_sysfs.c
@@ -0,0 +1,271 @@
+/*
+ * occ_sysfs.c - OCC sysfs interface
+ *
+ * This file contains the methods and data structures for implementing the OCC
+ * hwmon sysfs entries.
+ *
+ * Copyright 2016 IBM Corp.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "occ.h"
+#include "occ_sysfs.h"
+
+#define RESP_RETURN_CMD_INVAL  0x13
+
+static int occ_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int channel, long *val)
+{
+   int rc 

[PATCH linux v3 6/6] hwmon: occ: Add callbacks for parsing P9 OCC datastructures

[eajames . ibm]

From: "Edward A. James" 

Add functions to parse the data structures that are specific to the OCC on
the POWER9 processor. These are the sensor data structures, including
temperature, frequency, power, and "caps."

Signed-off-by: Edward A. James 
Signed-off-by: Andrew Jeffery 
---
 Documentation/hwmon/occ|   3 +
 drivers/hwmon/occ/occ_p9.c | 308 +
 drivers/hwmon/occ/occ_p9.h |  30 +
 3 files changed, 341 insertions(+)
 create mode 100644 drivers/hwmon/occ/occ_p9.c
 create mode 100644 drivers/hwmon/occ/occ_p9.h

diff --git a/Documentation/hwmon/occ b/Documentation/hwmon/occ
index 143951e..6cea853 100644
--- a/Documentation/hwmon/occ
+++ b/Documentation/hwmon/occ
@@ -34,6 +34,9 @@ number of data structures, such as command format, response 
headers, and the
 like, are also defined in this specification, and are common to both POWER8 and
 POWER9 OCCs.
 
+There is currently no public P9 OCC specification, and the data structures
+defined in the POWER9 OCC driver are subject to change.
+
 sysfs Entries
 -
 
diff --git a/drivers/hwmon/occ/occ_p9.c b/drivers/hwmon/occ/occ_p9.c
new file mode 100644
index 000..d99a026
--- /dev/null
+++ b/drivers/hwmon/occ/occ_p9.c
@@ -0,0 +1,308 @@
+/*
+ * occ_p9.c - OCC hwmon driver
+ *
+ * This file contains the Power9-specific methods and data structures for
+ * the OCC hwmon driver.
+ *
+ * Copyright 2016 IBM Corp.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "occ.h"
+#include "occ_p9.h"
+
+/* P9 OCC sensor data format */
+struct p9_temp_sensor {
+   u32 sensor_id;
+   u8 fru_type;
+   u8 value;
+};
+
+struct p9_freq_sensor {
+   u32 sensor_id;
+   u16 value;
+};
+
+struct p9_power_sensor {
+   u32 sensor_id;
+   u8 function_id;
+   u8 apss_channel;
+   u16 reserved;
+   u32 update_tag;
+   u64 accumulator;
+   u16 value;
+};
+
+struct p9_caps_sensor {
+   u16 curr_powercap;
+   u16 curr_powerreading;
+   u16 norm_powercap;
+   u16 max_powercap;
+   u16 min_powercap;
+   u16 user_powerlimit;
+   u8 user_powerlimit_source;
+};
+
+static const u32 p9_sensor_hwmon_configs[MAX_OCC_SENSOR_TYPE] = {
+   HWMON_I_INPUT | HWMON_I_LABEL,  /* freq: value | label */
+   /* temp: value | label | fru_type */
+   HWMON_T_INPUT | HWMON_T_LABEL | HWMON_T_TYPE,
+   /* power: value | label | accum[0] | accum[1] | update_tag |
+*   (function_id | (apss_channel << 8))
+*/
+   HWMON_P_INPUT | HWMON_P_LABEL | HWMON_P_AVERAGE_MIN |
+   HWMON_P_AVERAGE_MAX | HWMON_P_AVERAGE_INTERVAL |
+   HWMON_P_RESET_HISTORY,
+   /* caps: curr | max | min | norm | user | source */
+   HWMON_P_CAP | HWMON_P_CAP_MAX | HWMON_P_CAP_MIN | HWMON_P_MAX |
+   HWMON_P_ALARM | HWMON_P_CAP_ALARM,
+};
+
+void p9_parse_sensor(u8 *data, void *sensor, int sensor_type, int off,
+int snum)
+{
+   switch (sensor_type) {
+   case FREQ:
+   {
+   struct p9_freq_sensor *fs =
+   &(((struct p9_freq_sensor *)sensor)[snum]);
+
+   fs->sensor_id = be32_to_cpu(get_unaligned((u32 *)[off]));
+   fs->value = be16_to_cpu(get_unaligned((u16 *)[off + 4]));
+   }
+   break;
+   case TEMP:
+   {
+   struct p9_temp_sensor *ts =
+   &(((struct p9_temp_sensor *)sensor)[snum]);
+
+   ts->sensor_id = be32_to_cpu(get_unaligned((u32 *)[off]));
+   fs->fru_type = data[off + 4];
+   fs->value = data[off + 5];
+   }
+   break;
+   case POWER:
+   {
+   struct p9_power_sensor *ps =
+   &(((struct p9_power_sensor *)sensor)[snum]);
+
+   ps->sensor_id = be32_to_cpu(get_unaligned((u32 *)[off]));
+   ps->function_id = data[off + 4];
+   ps->apss_channel = data[off + 5];
+   ps->update_tag =
+   be32_to_cpu(get_unaligned((u32 *)[off + 8]));
+   ps->accumulator =
+   be64_to_cpu(get_unaligned((u64 *)[off + 12]));
+   ps->value = be16_to_cpu(get_unaligned((u16 *)[off + 20]));
+   }
+   break;
+   case CAPS:
+   {
+   struct 

[PATCH linux v3 5/6] hwmon: occ: Add hwmon implementation for the P8 OCC

[eajames . ibm]

From: "Edward A. James" 

Add code to tie the hwmon sysfs code and the POWER8 OCC code together, as
well as probe the entire driver from the I2C bus. I2C is the communication
method between the BMC and the P8 OCC.

Signed-off-by: Edward A. James 
Signed-off-by: Andrew Jeffery 
---
 Documentation/devicetree/bindings/hwmon/occ.txt |  13 +++
 drivers/hwmon/occ/Kconfig   |  14 
 drivers/hwmon/occ/Makefile  |   1 +
 drivers/hwmon/occ/p8_occ_i2c.c  | 104 
 4 files changed, 132 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/occ.txt
 create mode 100644 drivers/hwmon/occ/p8_occ_i2c.c

diff --git a/Documentation/devicetree/bindings/hwmon/occ.txt 
b/Documentation/devicetree/bindings/hwmon/occ.txt
new file mode 100644
index 000..b0d2b36
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/occ.txt
@@ -0,0 +1,13 @@
+HWMON I2C driver for IBM POWER CPU OCC (On Chip Controller)
+
+Required properties:
+ - compatible: must be "ibm,p8-occ-i2c"
+ - reg: physical address
+
+Example:
+i2c3: i2c-bus@100 {
+   occ@50 {
+   compatible = "ibm,p8-occ-i2c";
+   reg = <0x50>;
+   };
+};
diff --git a/drivers/hwmon/occ/Kconfig b/drivers/hwmon/occ/Kconfig
index cdb64a7..3a5188f 100644
--- a/drivers/hwmon/occ/Kconfig
+++ b/drivers/hwmon/occ/Kconfig
@@ -13,3 +13,17 @@ menuconfig SENSORS_PPC_OCC
 
  This driver can also be built as a module. If so, the module
  will be called occ.
+
+if SENSORS_PPC_OCC
+
+config SENSORS_PPC_OCC_P8_I2C
+   tristate "POWER8 OCC hwmon support"
+   depends on I2C
+   help
+Provide a hwmon sysfs interface for the POWER8 On-Chip Controller,
+exposing temperature, frequency and power measurements.
+
+This driver can also be built as a module. If so, the module will be
+called p8-occ-i2c.
+
+endif
diff --git a/drivers/hwmon/occ/Makefile b/drivers/hwmon/occ/Makefile
index a6881f9..9294b58 100644
--- a/drivers/hwmon/occ/Makefile
+++ b/drivers/hwmon/occ/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_SENSORS_PPC_OCC) += occ.o occ_sysfs.o
+obj-$(CONFIG_SENSORS_PPC_OCC_P8_I2C) += occ_scom_i2c.o occ_p8.o p8_occ_i2c.o
diff --git a/drivers/hwmon/occ/p8_occ_i2c.c b/drivers/hwmon/occ/p8_occ_i2c.c
new file mode 100644
index 000..6273040
--- /dev/null
+++ b/drivers/hwmon/occ/p8_occ_i2c.c
@@ -0,0 +1,104 @@
+/*
+ * p8_occ_i2c.c - hwmon OCC driver
+ *
+ * This file contains the i2c layer for accessing the P8 OCC over i2c bus.
+ *
+ * Copyright 2016 IBM Corp.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "occ_p8.h"
+#include "occ_scom_i2c.h"
+#include "occ_sysfs.h"
+#include "scom.h"
+
+#define P8_OCC_I2C_NAME"p8-occ-i2c"
+
+int p8_i2c_getscom(void *bus, u32 address, u64 *data)
+{
+   /* P8 i2c slave requires address to be shifted by 1 */
+   address = address << 1;
+
+   return occ_i2c_getscom(bus, address, data);
+}
+
+int p8_i2c_putscom(void *bus, u32 address, u32 data0, u32 data1)
+{
+   /* P8 i2c slave requires address to be shifted by 1 */
+   address = address << 1;
+
+   return occ_i2c_putscom(bus, address, data0, data1);
+}
+
+static struct occ_bus_ops p8_bus_ops = {
+   .getscom = p8_i2c_getscom,
+   .putscom = p8_i2c_putscom,
+};
+
+static int p8_occ_probe(struct i2c_client *client,
+   const struct i2c_device_id *id)
+{
+   struct occ *occ;
+   struct occ_sysfs *hwmon;
+   const u32 *sensor_hwmon_configs = p8_get_sensor_hwmon_configs();
+
+   occ = p8_occ_start(>dev, client, _bus_ops);
+   if (IS_ERR(occ))
+   return PTR_ERR(occ);
+
+   hwmon = occ_sysfs_start(>dev, occ, sensor_hwmon_configs,
+   P8_OCC_I2C_NAME);
+   if (IS_ERR(hwmon))
+   return PTR_ERR(hwmon);
+
+   i2c_set_clientdata(client, occ);
+
+   return 0;
+}
+
+/* used by old-style board info. */
+static const struct i2c_device_id occ_ids[] = {
+   { P8_OCC_I2C_NAME, 0 },
+   {}
+};
+MODULE_DEVICE_TABLE(i2c, occ_ids);
+
+/* used by device table */
+static const struct of_device_id occ_of_match[] = {
+   { .compatible = "ibm,p8-occ-i2c" },
+   {}
+};
+MODULE_DEVICE_TABLE(of, occ_of_match);
+
+static struct i2c_driver p8_occ_driver = {
+   .class = I2C_CLASS_HWMON,
+   

[PATCH linux v3 0/6] drivers: hwmon: Add On-Chip Controller driver

[eajames . ibm]

From: "Edward A. James" 

This patchset adds a hwmon driver to support the OCC (On-Chip Controller)
on the IBM POWER8 and POWER9 processors, from a BMC (Baseboard Management
Controller). The OCC is an embedded processor that provides real time
power and thermal monitoring.

The driver provides an interface on a BMC to poll OCC sensor data, set
user power caps, and perform some basic OCC error handling. It interfaces
with userspace through hwmon.

The driver is currently functional only for the OCC on POWER8 chips.
Communicating with the POWER9 OCC requries FSI support.

Edward A. James (6):
  hwmon: Add core On-Chip Controller support for POWER CPUs
  hwmon: occ: Add sysfs interface
  hwmon: occ: Add I2C transport implementation for SCOM operations
  hwmon: occ: Add callbacks for parsing P8 OCC datastructures
  hwmon: occ: Add hwmon implementation for the P8 OCC
  hwmon: occ: Add callbacks for parsing P9 OCC datastructures

 Documentation/devicetree/bindings/hwmon/occ.txt |  13 +
 Documentation/hwmon/occ | 114 ++
 MAINTAINERS |   7 +
 drivers/hwmon/Kconfig   |   2 +
 drivers/hwmon/Makefile  |   1 +
 drivers/hwmon/occ/Kconfig   |  29 ++
 drivers/hwmon/occ/Makefile  |   2 +
 drivers/hwmon/occ/occ.c | 522 
 drivers/hwmon/occ/occ.h |  81 
 drivers/hwmon/occ/occ_p8.c  | 247 +++
 drivers/hwmon/occ/occ_p8.h  |  30 ++
 drivers/hwmon/occ/occ_p9.c  | 308 ++
 drivers/hwmon/occ/occ_p9.h  |  30 ++
 drivers/hwmon/occ/occ_scom_i2c.c|  72 
 drivers/hwmon/occ/occ_scom_i2c.h|  26 ++
 drivers/hwmon/occ/occ_sysfs.c   | 271 
 drivers/hwmon/occ/occ_sysfs.h   |  44 ++
 drivers/hwmon/occ/p8_occ_i2c.c  | 104 +
 drivers/hwmon/occ/scom.h|  47 +++
 19 files changed, 1950 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/occ.txt
 create mode 100644 Documentation/hwmon/occ
 create mode 100644 drivers/hwmon/occ/Kconfig
 create mode 100644 drivers/hwmon/occ/Makefile
 create mode 100644 drivers/hwmon/occ/occ.c
 create mode 100644 drivers/hwmon/occ/occ.h
 create mode 100644 drivers/hwmon/occ/occ_p8.c
 create mode 100644 drivers/hwmon/occ/occ_p8.h
 create mode 100644 drivers/hwmon/occ/occ_p9.c
 create mode 100644 drivers/hwmon/occ/occ_p9.h
 create mode 100644 drivers/hwmon/occ/occ_scom_i2c.c
 create mode 100644 drivers/hwmon/occ/occ_scom_i2c.h
 create mode 100644 drivers/hwmon/occ/occ_sysfs.c
 create mode 100644 drivers/hwmon/occ/occ_sysfs.h
 create mode 100644 drivers/hwmon/occ/p8_occ_i2c.c
 create mode 100644 drivers/hwmon/occ/scom.h

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 16/37] PCI: endpoint: Introduce configfs entry for configuring EP functions

[Christoph Hellwig]

On Mon, Jan 16, 2017 at 11:31:23AM +0530, Kishon Vijay Abraham I wrote:
> Actually not all devices have hardcoded headers. E.g the platform I'm using
> doesn't have hardcoded headers and it can be configured based on the function
> the user would like to use. If the devices are hardcoded, then using configfs
> can be skipped altogether. In such cases, APIs like pci_epf_create() can
> directly be used by the drivers instead of going via configfs.

That's exactly what I meant - the IDs need to be set by the driver for
the implemented PCI device, and it's not up to the gadget core to configur
e them, it's up to the implementation of the PCIe device which PCI it
exposes.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/5] arm64: Work around Falkor erratum 1003

[Christopher Covington]

Hi Mark,

On 01/11/2017 01:45 PM, Mark Rutland wrote:
> On Wed, Jan 11, 2017 at 12:40:42PM -0600, Timur Tabi wrote:
>> On 01/11/2017 12:37 PM, Mark Rutland wrote:
>>> The name, as it is, is perfectly descriptive.
>>>
>>> Let's not sacrifice legibility over a non-issue.
>>
>> I don't want to kick a dead horse or anything, but changing it to
>> QCOM_FLKR_ERRATUM_1003 would eliminate all the spacing problems
>> without sacrificing anything.
> 
> The CPU is called "Falkor", not "FLKR", and we're not coming up with an
> ACPI table name...
> 
> The ARM Ltd. erratum numbers are global to all parts, so we don't
> include the part name. Is the 1003 erratum number specific to Falkor?
>
> If it's global, you could use QCOM_ERRATUM_1003 instead.

E1003 is specific to Falkor, and hopefully just its first major revision.
Qualcomm Technology's first/previous generation ARMv8 custom
microarchitecture used errata numbers below 1000. I am not aware of
global coordination in the numbering, unfortunately.

> Otherwise, QCOM_FALKOR_ERRATUM_1003 is preferable.

Thanks,
Cov

-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 11/37] PCI: dwc: Split pcie-designware.c into host and core files

[Joao Pinto]

Às 11:30 AM de 1/16/2017, Kishon Vijay Abraham I escreveu:
> Hi Joao,
> 
> On Monday 16 January 2017 03:57 PM, Joao Pinto wrote:
>>
>> Hi,
>>
>> Às 5:21 AM de 1/16/2017, Kishon Vijay Abraham I escreveu:
>>> Hi Joao,
>>>
>>> On Friday 13 January 2017 10:19 PM, Joao Pinto wrote:
 Às 10:26 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
> Split pcie-designware.c into pcie-designware-host.c that contains
> the host specific parts of the driver and pcie-designware.c that
> contains the parts used by both host driver and endpoint driver.
>
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  drivers/pci/dwc/Makefile   |2 +-
>  drivers/pci/dwc/pcie-designware-host.c |  619 
> 
>  drivers/pci/dwc/pcie-designware.c  |  613 
> +--
>  drivers/pci/dwc/pcie-designware.h  |8 +
>  4 files changed, 634 insertions(+), 608 deletions(-)
>  create mode 100644 drivers/pci/dwc/pcie-designware-host.c
>
> diff --git a/drivers/pci/dwc/Makefile b/drivers/pci/dwc/Makefile
> index 7d27c14..3b57e55 100644
> --- a/drivers/pci/dwc/Makefile
> +++ b/drivers/pci/dwc/Makefile
> @@ -1,4 +1,4 @@

 (snip...)

> -static void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index,
> -   int type, u64 cpu_addr, u64 pci_addr,
> -   u32 size)
> +void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index, int type,
> +u64 cpu_addr, u64 pci_addr, u32 size)
>  {
>   u32 retries, val;
>  
> @@ -186,220 +151,6 @@ static void dw_pcie_prog_outbound_atu(struct 
> dw_pcie *pci, int index,
>   dev_err(pci->dev, "iATU is not being enabled\n");
>  }

 Kishon, iATU only makes sense in The Root Complex (host), so it should be 
 inside
 the pcie-designware-host.
>>>
>>> That is not true. Outbound ATU should be programmed to access host side 
>>> buffers
>>> and inbound ATU should be programmed for the host to access EP mem space.
>>
>> Sorry, I was not clear enough. What I was trying to suggest is, since the ATU
>> programming is done by the host, wouldn't be better to include it in the
>> pcie-designware-host? It is just an architectural detail.
> 
> ATU programming is required in EP mode. See "[PATCH 24/37] PCI: dwc:
> designware: Add EP mode support" in this patch series.
> 
> Anything that's required by both EP mode and RC mode, I've placed in
> pcie-designware.c

Agreed!

> 
> Thanks
> Kishon
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 11/37] PCI: dwc: Split pcie-designware.c into host and core files

[Kishon Vijay Abraham I]

Hi Joao,

On Monday 16 January 2017 03:57 PM, Joao Pinto wrote:
> 
> Hi,
> 
> Às 5:21 AM de 1/16/2017, Kishon Vijay Abraham I escreveu:
>> Hi Joao,
>>
>> On Friday 13 January 2017 10:19 PM, Joao Pinto wrote:
>>> Às 10:26 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
 Split pcie-designware.c into pcie-designware-host.c that contains
 the host specific parts of the driver and pcie-designware.c that
 contains the parts used by both host driver and endpoint driver.

 Signed-off-by: Kishon Vijay Abraham I 
 ---
  drivers/pci/dwc/Makefile   |2 +-
  drivers/pci/dwc/pcie-designware-host.c |  619 
 
  drivers/pci/dwc/pcie-designware.c  |  613 
 +--
  drivers/pci/dwc/pcie-designware.h  |8 +
  4 files changed, 634 insertions(+), 608 deletions(-)
  create mode 100644 drivers/pci/dwc/pcie-designware-host.c

 diff --git a/drivers/pci/dwc/Makefile b/drivers/pci/dwc/Makefile
 index 7d27c14..3b57e55 100644
 --- a/drivers/pci/dwc/Makefile
 +++ b/drivers/pci/dwc/Makefile
 @@ -1,4 +1,4 @@
>>>
>>> (snip...)
>>>
 -static void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index,
 -int type, u64 cpu_addr, u64 pci_addr,
 -u32 size)
 +void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index, int type,
 + u64 cpu_addr, u64 pci_addr, u32 size)
  {
u32 retries, val;
  
 @@ -186,220 +151,6 @@ static void dw_pcie_prog_outbound_atu(struct dw_pcie 
 *pci, int index,
dev_err(pci->dev, "iATU is not being enabled\n");
  }
>>>
>>> Kishon, iATU only makes sense in The Root Complex (host), so it should be 
>>> inside
>>> the pcie-designware-host.
>>
>> That is not true. Outbound ATU should be programmed to access host side 
>> buffers
>> and inbound ATU should be programmed for the host to access EP mem space.
> 
> Sorry, I was not clear enough. What I was trying to suggest is, since the ATU
> programming is done by the host, wouldn't be better to include it in the
> pcie-designware-host? It is just an architectural detail.

ATU programming is required in EP mode. See "[PATCH 24/37] PCI: dwc:
designware: Add EP mode support" in this patch series.

Anything that's required by both EP mode and RC mode, I've placed in
pcie-designware.c

Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 11/37] PCI: dwc: Split pcie-designware.c into host and core files

[Joao Pinto]

Hi,

Às 5:21 AM de 1/16/2017, Kishon Vijay Abraham I escreveu:
> Hi Joao,
> 
> On Friday 13 January 2017 10:19 PM, Joao Pinto wrote:
>> Às 10:26 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
>>> Split pcie-designware.c into pcie-designware-host.c that contains
>>> the host specific parts of the driver and pcie-designware.c that
>>> contains the parts used by both host driver and endpoint driver.
>>>
>>> Signed-off-by: Kishon Vijay Abraham I 
>>> ---
>>>  drivers/pci/dwc/Makefile   |2 +-
>>>  drivers/pci/dwc/pcie-designware-host.c |  619 
>>> 
>>>  drivers/pci/dwc/pcie-designware.c  |  613 
>>> +--
>>>  drivers/pci/dwc/pcie-designware.h  |8 +
>>>  4 files changed, 634 insertions(+), 608 deletions(-)
>>>  create mode 100644 drivers/pci/dwc/pcie-designware-host.c
>>>
>>> diff --git a/drivers/pci/dwc/Makefile b/drivers/pci/dwc/Makefile
>>> index 7d27c14..3b57e55 100644
>>> --- a/drivers/pci/dwc/Makefile
>>> +++ b/drivers/pci/dwc/Makefile
>>> @@ -1,4 +1,4 @@
>>
>> (snip...)
>>
>>> -static void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index,
>>> - int type, u64 cpu_addr, u64 pci_addr,
>>> - u32 size)
>>> +void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index, int type,
>>> +  u64 cpu_addr, u64 pci_addr, u32 size)
>>>  {
>>> u32 retries, val;
>>>  
>>> @@ -186,220 +151,6 @@ static void dw_pcie_prog_outbound_atu(struct dw_pcie 
>>> *pci, int index,
>>> dev_err(pci->dev, "iATU is not being enabled\n");
>>>  }
>>
>> Kishon, iATU only makes sense in The Root Complex (host), so it should be 
>> inside
>> the pcie-designware-host.
> 
> That is not true. Outbound ATU should be programmed to access host side 
> buffers
> and inbound ATU should be programmed for the host to access EP mem space.

Sorry, I was not clear enough. What I was trying to suggest is, since the ATU
programming is done by the host, wouldn't be better to include it in the
pcie-designware-host? It is just an architectural detail.

> 
> Thanks
> Kishon
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 09/37] PCI: dwc: designware: Parse *num-lanes* property in dw_pcie_setup_rc

[Joao Pinto]

Hi,

Às 5:19 AM de 1/16/2017, Kishon Vijay Abraham I escreveu:
> Hi,
> 
> On Friday 13 January 2017 10:43 PM, Joao Pinto wrote:
>> Hi,
>>
>> Às 10:25 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
>>> *num-lanes* dt property is parsed in dw_pcie_host_init. However
>>> *num-lanes* property is applicable to both root complex mode and
>>> endpoint mode. As a first step, move the parsing of this property
>>> outside dw_pcie_host_init. This is in preparation for splitting
>>> pcie-designware.c to pcie-designware.c and pcie-designware-host.c
>>>
>>> Signed-off-by: Kishon Vijay Abraham I 
>>> ---
>>>  drivers/pci/dwc/pcie-designware.c |   18 +++---
>>>  drivers/pci/dwc/pcie-designware.h |1 -
>>>  2 files changed, 11 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/pci/dwc/pcie-designware.c 
>>> b/drivers/pci/dwc/pcie-designware.c
>>> index 00a0fdc..89cdb6b 100644
>>> --- a/drivers/pci/dwc/pcie-designware.c
>>> +++ b/drivers/pci/dwc/pcie-designware.c
>>> @@ -551,10 +551,6 @@ int dw_pcie_host_init(struct pcie_port *pp)
>>> }
>>> }
>>>  
>>> -   ret = of_property_read_u32(np, "num-lanes", >lanes);
>>> -   if (ret)
>>> -   pci->lanes = 0;
>>> -
>>> ret = of_property_read_u32(np, "num-viewport", >num_viewport);
>>> if (ret)
>>> pci->num_viewport = 2;
>>> @@ -751,18 +747,26 @@ static int dw_pcie_wr_conf(struct pci_bus *bus, u32 
>>> devfn,
>>>  
>>>  void dw_pcie_setup_rc(struct pcie_port *pp)
>>>  {
>>> +   int ret;
>>> +   u32 lanes;
>>> u32 val;
>>> struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
>>> +   struct device *dev = pci->dev;
>>> +   struct device_node *np = dev->of_node;
>>>  
>>> /* get iATU unroll support */
>>> pci->iatu_unroll_enabled = dw_pcie_iatu_unroll_enabled(pci);
>>> dev_dbg(pci->dev, "iATU unroll: %s\n",
>>> pci->iatu_unroll_enabled ? "enabled" : "disabled");
>>>  
>>> +   ret = of_property_read_u32(np, "num-lanes", );
>>> +   if (ret)
>>> +   lanes = 0;
>>
>> You moved from host_init to root complex setup function, which in my opinion 
>> did
>> not improve (in this scope).
>>
>> I suggest that instead of making so much intermediary patches, which is nice 
>> to
>> understand your development sequence, but hard to review. Wouldn't be better 
>> to
>> condense some of the patches? We would have a cloear vision of the final 
>> product :)
> 
> I thought the other way. If squashing patches is easier to review, I'll do it.

I understand. To break it in small pieces is good to understand clearly what is
done and how was done, but I would break too much. That's a personal opinion of
course, lets see what others say :).

Thanks,
Joao

> 
> Btw, thanks for reviewing.
> 
> Cheers
> Kishon
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html