Re: [PATCH v1 10/10] mm/memory_hotplug: allow online/offline memory by a kernel module

[David Hildenbrand]

On 23.05.2018 21:51, Christoph Hellwig wrote:
> On Wed, May 23, 2018 at 05:11:51PM +0200, David Hildenbrand wrote:
>> Kernel modules that want to control how/when memory is onlined/offlined
>> need a proper interface to these functions. Also, for adding memory
>> properly, memory_block_size_bytes is required.
> 
> Which module?  Please send it along with the enabling code.

Hi,

as indicated in the cover letter, it is called "virtio-mem".
I sent it yesterday as a separate series (RFC).

Cover letter: https://lkml.org/lkml/2018/5/23/800
Relevant patch: https://lkml.org/lkml/2018/5/23/803

> 
>> --- a/drivers/base/memory.c
>> +++ b/drivers/base/memory.c
>> @@ -88,6 +88,7 @@ unsigned long __weak memory_block_size_bytes(void)
>>  {
>>  return MIN_MEMORY_BLOCK_SIZE;
>>  }
>> +EXPORT_SYMBOL(memory_block_size_bytes);
> 
>> +EXPORT_SYMBOL(mem_hotplug_begin);
> 
>> +EXPORT_SYMBOL(mem_hotplug_done);
> 
> EXPORT_SYMBOL_GPL for any deep down VM internals, please.
> 

I continued using what was being used for symbols in this file. If there
are not other opinions, I'll switch to EXPORT_SYMBOL_GPL. Thanks!

-- 

Thanks,

David / dhildenb

Re: [PATCH v1 10/10] mm/memory_hotplug: allow online/offline memory by a kernel module

[David Hildenbrand]

On 23.05.2018 21:51, Christoph Hellwig wrote:
> On Wed, May 23, 2018 at 05:11:51PM +0200, David Hildenbrand wrote:
>> Kernel modules that want to control how/when memory is onlined/offlined
>> need a proper interface to these functions. Also, for adding memory
>> properly, memory_block_size_bytes is required.
> 
> Which module?  Please send it along with the enabling code.

Hi,

as indicated in the cover letter, it is called "virtio-mem".
I sent it yesterday as a separate series (RFC).

Cover letter: https://lkml.org/lkml/2018/5/23/800
Relevant patch: https://lkml.org/lkml/2018/5/23/803

> 
>> --- a/drivers/base/memory.c
>> +++ b/drivers/base/memory.c
>> @@ -88,6 +88,7 @@ unsigned long __weak memory_block_size_bytes(void)
>>  {
>>  return MIN_MEMORY_BLOCK_SIZE;
>>  }
>> +EXPORT_SYMBOL(memory_block_size_bytes);
> 
>> +EXPORT_SYMBOL(mem_hotplug_begin);
> 
>> +EXPORT_SYMBOL(mem_hotplug_done);
> 
> EXPORT_SYMBOL_GPL for any deep down VM internals, please.
> 

I continued using what was being used for symbols in this file. If there
are not other opinions, I'll switch to EXPORT_SYMBOL_GPL. Thanks!

-- 

Thanks,

David / dhildenb

[PATCH 5/9] clk: bd71837: Devicetree bindings for ROHM BD71837 PMIC

[Matti Vaittinen]

Document devicetree bindings for ROHM BD71837 PMIC clock output.

Signed-off-by: Matti Vaittinen 
---
 .../bindings/clock/rohm,bd71837-clock.txt  | 37 ++
 1 file changed, 37 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/clock/rohm,bd71837-clock.txt

diff --git a/Documentation/devicetree/bindings/clock/rohm,bd71837-clock.txt 
b/Documentation/devicetree/bindings/clock/rohm,bd71837-clock.txt
new file mode 100644
index ..9759fd145781
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/rohm,bd71837-clock.txt
@@ -0,0 +1,37 @@
+ROHM BD71837 Power Management Integrated Circuit clock bindings
+
+BD71837 clock node should be sub node of the BD71837 MFD node.
+See BD71837 MFD bindings at
+Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.txt
+
+Required properties:
+- compatible   : Should be "rohm,bd71837-clk"
+- clock-frequency  : Should be 32768
+- #clock-cells : Should be 0
+
+Optional properties:
+- clock-output-names   : Should contain name for output clock.
+  Name "bd71837-32k-out" is used if this is not given.
+
+
+Example:
+
+pmic: bd71837@4b {
+   compatible = "rohm,bd71837";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x4b>;
+   interrupt-parent = <>;
+   interrupts = <29 GPIO_ACTIVE_LOW>;
+   interrupt-names = "irq";
+   #interrupt-cells = <1>;
+   interrupt-controller;
+
+   /* Clock node */
+   clk: bd71837-32k-out {
+   compatible = "rohm,bd71837-clk";
+   #clock-cells = <0>;
+   clock-frequency  = <32768>;
+   clock-output-names = "bd71837-32k-out";
+   };
+};
-- 
2.14.3

[PATCH 5/9] clk: bd71837: Devicetree bindings for ROHM BD71837 PMIC

[Matti Vaittinen]

Document devicetree bindings for ROHM BD71837 PMIC clock output.

Signed-off-by: Matti Vaittinen 
---
 .../bindings/clock/rohm,bd71837-clock.txt  | 37 ++
 1 file changed, 37 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/clock/rohm,bd71837-clock.txt

diff --git a/Documentation/devicetree/bindings/clock/rohm,bd71837-clock.txt 
b/Documentation/devicetree/bindings/clock/rohm,bd71837-clock.txt
new file mode 100644
index ..9759fd145781
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/rohm,bd71837-clock.txt
@@ -0,0 +1,37 @@
+ROHM BD71837 Power Management Integrated Circuit clock bindings
+
+BD71837 clock node should be sub node of the BD71837 MFD node.
+See BD71837 MFD bindings at
+Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.txt
+
+Required properties:
+- compatible   : Should be "rohm,bd71837-clk"
+- clock-frequency  : Should be 32768
+- #clock-cells : Should be 0
+
+Optional properties:
+- clock-output-names   : Should contain name for output clock.
+  Name "bd71837-32k-out" is used if this is not given.
+
+
+Example:
+
+pmic: bd71837@4b {
+   compatible = "rohm,bd71837";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x4b>;
+   interrupt-parent = <>;
+   interrupts = <29 GPIO_ACTIVE_LOW>;
+   interrupt-names = "irq";
+   #interrupt-cells = <1>;
+   interrupt-controller;
+
+   /* Clock node */
+   clk: bd71837-32k-out {
+   compatible = "rohm,bd71837-clk";
+   #clock-cells = <0>;
+   clock-frequency  = <32768>;
+   clock-output-names = "bd71837-32k-out";
+   };
+};
-- 
2.14.3

[PATCH 4/9] regulator: bd71837: Devicetree bindings for BD71837 regulators

[Matti Vaittinen]

Document devicetree bindings for ROHM BD71837 PMIC regulators.

Signed-off-by: Matti Vaittinen 
---
 .../bindings/regulator/rohm,bd71837-regulator.txt  | 124 +
 1 file changed, 124 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.txt

diff --git 
a/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.txt 
b/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.txt
new file mode 100644
index ..a43230143b66
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.txt
@@ -0,0 +1,124 @@
+ROHM BD71837 Power Management Integrated Circuit (PMIC) regulator bindings
+
+BD71837MWV is a programmable Power Management
+IC (PMIC) for powering single-core, dual-core, and
+quad-core SoC’s such as NXP-i.MX 8M. It is optimized
+for low BOM cost and compact solution footprint. It
+integrates 8 Buck regulators and 7 LDO’s to provide all
+the power rails required by the SoC and the commonly
+used peripherals.
+
+Required properties:
+ - compatible: should be "rohm,bd71837-pmic".
+ - regulator-name: should be "buck1", ..., "buck8" and "ldo1", ..., "ldo7"
+
+List of regulators provided by this controller. BD71837 regulators node
+should be sub node of the BD71837 MFD node. See BD71837 MFD bindings at
+Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.txt
+Regulator nodes should be named to BUCK_ and LDO_. The
+definition for each of these nodes is defined using the standard
+binding for regulators at
+Documentation/devicetree/bindings/regulator/regulator.txt.
+
+The valid names for regulators are:
+BUCK1, BUCK2, BUCK3, BUCK4, BUCK5, BUCK6, BUCK7, BUCK8
+LDO1, LDO2, LDO3, LDO4, LDO5, LDO6, LDO7
+
+Optional properties:
+- Any optional property defined in bindings/regulator/regulator.txt
+
+Example:
+regulators {
+   compatible = "rohm,bd71837-pmic";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   buck1: BUCK1 {
+   pmic-supply = <_fixed>;
+   regulator-name = "buck1";
+   regulator-min-microvolt = <70>;
+   regulator-max-microvolt = <130>;
+   regulator-boot-on;
+   regulator-ramp-delay = <1250>;
+   };
+   buck2: BUCK2 {
+   regulator-name = "buck2";
+   regulator-min-microvolt = <70>;
+   regulator-max-microvolt = <130>;
+   regulator-boot-on;
+   regulator-always-on;
+   regulator-ramp-delay = <1250>;
+   };
+   buck3: BUCK3 {
+   regulator-name = "buck3";
+   regulator-min-microvolt = <70>;
+   regulator-max-microvolt = <130>;
+   regulator-boot-on;
+   };
+   buck4: BUCK4 {
+   regulator-name = "buck4";
+   regulator-min-microvolt = <70>;
+   regulator-max-microvolt = <130>;
+   regulator-boot-on;
+   };
+   buck5: BUCK5 {
+   regulator-name = "buck5";
+   regulator-min-microvolt = <70>;
+   regulator-max-microvolt = <135>;
+   regulator-boot-on;
+   };
+   buck6: BUCK6 {
+   regulator-name = "buck6";
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <330>;
+   };
+   buck7: BUCK7 {
+   regulator-name = "buck7";
+   regulator-min-microvolt = <1605000>;
+   regulator-max-microvolt = <1995000>;
+   };
+   buck8: BUCK8 {
+   regulator-name = "buck8";
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <140>;
+   };
+
+   ldo1: LDO1 {
+   regulator-name = "ldo1";
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <330>;
+   regulator-boot-on;
+   };
+   ldo2: LDO2 {
+   regulator-name = "ldo2";
+   regulator-min-microvolt = <90>;
+   regulator-max-microvolt = <90>;
+   regulator-boot-on;
+   };
+   ldo3: LDO3 {
+   regulator-name = "ldo3";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+   };
+   ldo4: LDO4 {
+   regulator-name = "ldo4";
+   regulator-min-microvolt = <90>;
+   regulator-max-microvolt = <180>;
+   };
+   ldo5: LDO5 {
+   regulator-name = "ldo5";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+   };
+   ldo6: LDO6 {
+   regulator-name = "ldo6";
+   regulator-min-microvolt = <90>;
+   regulator-max-microvolt = <180>;
+   };
+   ldo7_reg: LDO7 {
+   regulator-name = 

[PATCH 4/9] regulator: bd71837: Devicetree bindings for BD71837 regulators

[Matti Vaittinen]

Document devicetree bindings for ROHM BD71837 PMIC regulators.

Signed-off-by: Matti Vaittinen 
---
 .../bindings/regulator/rohm,bd71837-regulator.txt  | 124 +
 1 file changed, 124 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.txt

diff --git 
a/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.txt 
b/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.txt
new file mode 100644
index ..a43230143b66
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.txt
@@ -0,0 +1,124 @@
+ROHM BD71837 Power Management Integrated Circuit (PMIC) regulator bindings
+
+BD71837MWV is a programmable Power Management
+IC (PMIC) for powering single-core, dual-core, and
+quad-core SoC’s such as NXP-i.MX 8M. It is optimized
+for low BOM cost and compact solution footprint. It
+integrates 8 Buck regulators and 7 LDO’s to provide all
+the power rails required by the SoC and the commonly
+used peripherals.
+
+Required properties:
+ - compatible: should be "rohm,bd71837-pmic".
+ - regulator-name: should be "buck1", ..., "buck8" and "ldo1", ..., "ldo7"
+
+List of regulators provided by this controller. BD71837 regulators node
+should be sub node of the BD71837 MFD node. See BD71837 MFD bindings at
+Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.txt
+Regulator nodes should be named to BUCK_ and LDO_. The
+definition for each of these nodes is defined using the standard
+binding for regulators at
+Documentation/devicetree/bindings/regulator/regulator.txt.
+
+The valid names for regulators are:
+BUCK1, BUCK2, BUCK3, BUCK4, BUCK5, BUCK6, BUCK7, BUCK8
+LDO1, LDO2, LDO3, LDO4, LDO5, LDO6, LDO7
+
+Optional properties:
+- Any optional property defined in bindings/regulator/regulator.txt
+
+Example:
+regulators {
+   compatible = "rohm,bd71837-pmic";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   buck1: BUCK1 {
+   pmic-supply = <_fixed>;
+   regulator-name = "buck1";
+   regulator-min-microvolt = <70>;
+   regulator-max-microvolt = <130>;
+   regulator-boot-on;
+   regulator-ramp-delay = <1250>;
+   };
+   buck2: BUCK2 {
+   regulator-name = "buck2";
+   regulator-min-microvolt = <70>;
+   regulator-max-microvolt = <130>;
+   regulator-boot-on;
+   regulator-always-on;
+   regulator-ramp-delay = <1250>;
+   };
+   buck3: BUCK3 {
+   regulator-name = "buck3";
+   regulator-min-microvolt = <70>;
+   regulator-max-microvolt = <130>;
+   regulator-boot-on;
+   };
+   buck4: BUCK4 {
+   regulator-name = "buck4";
+   regulator-min-microvolt = <70>;
+   regulator-max-microvolt = <130>;
+   regulator-boot-on;
+   };
+   buck5: BUCK5 {
+   regulator-name = "buck5";
+   regulator-min-microvolt = <70>;
+   regulator-max-microvolt = <135>;
+   regulator-boot-on;
+   };
+   buck6: BUCK6 {
+   regulator-name = "buck6";
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <330>;
+   };
+   buck7: BUCK7 {
+   regulator-name = "buck7";
+   regulator-min-microvolt = <1605000>;
+   regulator-max-microvolt = <1995000>;
+   };
+   buck8: BUCK8 {
+   regulator-name = "buck8";
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <140>;
+   };
+
+   ldo1: LDO1 {
+   regulator-name = "ldo1";
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <330>;
+   regulator-boot-on;
+   };
+   ldo2: LDO2 {
+   regulator-name = "ldo2";
+   regulator-min-microvolt = <90>;
+   regulator-max-microvolt = <90>;
+   regulator-boot-on;
+   };
+   ldo3: LDO3 {
+   regulator-name = "ldo3";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+   };
+   ldo4: LDO4 {
+   regulator-name = "ldo4";
+   regulator-min-microvolt = <90>;
+   regulator-max-microvolt = <180>;
+   };
+   ldo5: LDO5 {
+   regulator-name = "ldo5";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+   };
+   ldo6: LDO6 {
+   regulator-name = "ldo6";
+   regulator-min-microvolt = <90>;
+   regulator-max-microvolt = <180>;
+   };
+   ldo7_reg: LDO7 {
+   regulator-name = "ldo7";
+   

[PATCH 3/9] mfd: bd71837: Devicetree bindings for ROHM BD71837 PMIC

[Matti Vaittinen]

Document devicetree bindings for ROHM BD71837 PMIC MFD.

Signed-off-by: Matti Vaittinen 
---
 .../devicetree/bindings/mfd/rohm,bd71837-pmic.txt  | 55 ++
 1 file changed, 55 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.txt

diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.txt 
b/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.txt
new file mode 100644
index ..b00c3753b454
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.txt
@@ -0,0 +1,55 @@
+* ROHM BD71837 Power Management Integrated Circuit bindings
+
+BD71837MWV is a programmable Power Management IC for powering single-core,
+dual-core, and quad-core SoC’s such as NXP-i.MX 8M. It is optimized for
+low BOM cost and compact solution footprint. It integrates 8 Buck
+egulators and 7 LDO’s to provide all the power rails required by the SoC and
+the commonly used peripherals.
+
+Required properties:
+ - compatible  : Should be "rohm,bd71837".
+ - reg : I2C slave address.
+ - interrupt-parent: Phandle to the parent interrupt controller.
+ - interrupts  : The interrupt line the device is connected to.
+ - interrupt-controller: Marks the device node as an interrupt 
controller.
+ - #interrupt-cells: The number of cells to describe an IRQ, should be 1 
or 2.
+   The first cell is the IRQ number.
+   The second cell if present is the flags, encoded as 
trigger
+   masks from ../interrupt-controller/interrupts.txt.
+ - regulators: : List of child nodes that specify the regulators
+ Please see ../regulator/rohm,bd71837-regulator.txt
+ - clock:  : Please see ../clock/rohm,bd71837-clock.txt
+
+Example:
+
+   pmic: bd71837@4b {
+   compatible = "rohm,bd71837";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x4b>;
+   interrupt-parent = <>;
+   interrupts = <29 GPIO_ACTIVE_LOW>;
+   interrupt-names = "irq";
+   #interrupt-cells = <1>;
+   interrupt-controller;
+
+   regulators {
+   compatible = "rohm,bd71837-pmic";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   buck1: BUCK1 {
+   regulator-name = "buck1";
+   regulator-min-microvolt = <70>;
+   regulator-max-microvolt = <130>;
+   regulator-boot-on;
+   regulator-ramp-delay = <1250>;
+   };
+   ...
+   };
+   clk: bd71837-32k-out {
+   compatible = "rohm,bd71837-clk";
+   #clock-cells = <0>;
+   clock-frequency = <32768>;
+   clock-output-names = "bd71837-32k-out";
+   };
+   };
-- 
2.14.3

[PATCH 3/9] mfd: bd71837: Devicetree bindings for ROHM BD71837 PMIC

[Matti Vaittinen]

Document devicetree bindings for ROHM BD71837 PMIC MFD.

Signed-off-by: Matti Vaittinen 
---
 .../devicetree/bindings/mfd/rohm,bd71837-pmic.txt  | 55 ++
 1 file changed, 55 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.txt

diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.txt 
b/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.txt
new file mode 100644
index ..b00c3753b454
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.txt
@@ -0,0 +1,55 @@
+* ROHM BD71837 Power Management Integrated Circuit bindings
+
+BD71837MWV is a programmable Power Management IC for powering single-core,
+dual-core, and quad-core SoC’s such as NXP-i.MX 8M. It is optimized for
+low BOM cost and compact solution footprint. It integrates 8 Buck
+egulators and 7 LDO’s to provide all the power rails required by the SoC and
+the commonly used peripherals.
+
+Required properties:
+ - compatible  : Should be "rohm,bd71837".
+ - reg : I2C slave address.
+ - interrupt-parent: Phandle to the parent interrupt controller.
+ - interrupts  : The interrupt line the device is connected to.
+ - interrupt-controller: Marks the device node as an interrupt 
controller.
+ - #interrupt-cells: The number of cells to describe an IRQ, should be 1 
or 2.
+   The first cell is the IRQ number.
+   The second cell if present is the flags, encoded as 
trigger
+   masks from ../interrupt-controller/interrupts.txt.
+ - regulators: : List of child nodes that specify the regulators
+ Please see ../regulator/rohm,bd71837-regulator.txt
+ - clock:  : Please see ../clock/rohm,bd71837-clock.txt
+
+Example:
+
+   pmic: bd71837@4b {
+   compatible = "rohm,bd71837";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x4b>;
+   interrupt-parent = <>;
+   interrupts = <29 GPIO_ACTIVE_LOW>;
+   interrupt-names = "irq";
+   #interrupt-cells = <1>;
+   interrupt-controller;
+
+   regulators {
+   compatible = "rohm,bd71837-pmic";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   buck1: BUCK1 {
+   regulator-name = "buck1";
+   regulator-min-microvolt = <70>;
+   regulator-max-microvolt = <130>;
+   regulator-boot-on;
+   regulator-ramp-delay = <1250>;
+   };
+   ...
+   };
+   clk: bd71837-32k-out {
+   compatible = "rohm,bd71837-clk";
+   #clock-cells = <0>;
+   clock-frequency = <32768>;
+   clock-output-names = "bd71837-32k-out";
+   };
+   };
-- 
2.14.3

[PATCH 1/9] mfd: bd71837: mfd driver for ROHM BD71837 PMIC

[Matti Vaittinen]

ROHM BD71837 PMIC MFD driver providing interrupts and support
for two subsystems:
- clk
- Regulators

Signed-off-by: Matti Vaittinen 
---
 drivers/mfd/bd71837.c   | 238 +
 include/linux/mfd/bd71837.h | 316 
 2 files changed, 554 insertions(+)
 create mode 100644 drivers/mfd/bd71837.c
 create mode 100644 include/linux/mfd/bd71837.h

diff --git a/drivers/mfd/bd71837.c b/drivers/mfd/bd71837.c
new file mode 100644
index ..231442c823bd
--- /dev/null
+++ b/drivers/mfd/bd71837.c
@@ -0,0 +1,238 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (C) 2018 ROHM Semiconductors */
+/*
+ * bd71837.c  --  ROHM BD71837MWV mfd driver
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* bd71837 multi function cells */
+static struct mfd_cell bd71837_mfd_cells[] = {
+   {
+   .name = "bd71837-clk",
+   .of_compatible = "rohm,bd71837-clk",
+   }, {
+   .name = "bd71837-pmic",
+   .of_compatible = "rohm,bd71837-pmic",
+   },
+};
+
+static const struct regmap_irq bd71837_irqs[] = {
+   [BD71837_INT_SWRST] = {
+   .mask = BD71837_INT_SWRST_MASK,
+   },
+   [BD71837_INT_PWRBTN_S] = {
+   .mask = BD71837_INT_PWRBTN_S_MASK,
+   },
+   [BD71837_INT_PWRBTN_L] = {
+   .mask = BD71837_INT_PWRBTN_L_MASK,
+   },
+   [BD71837_INT_PWRBTN] = {
+   .mask = BD71837_INT_PWRBTN_MASK,
+   },
+   [BD71837_INT_WDOG] = {
+   .mask = BD71837_INT_WDOG_MASK,
+   },
+   [BD71837_INT_ON_REQ] = {
+   .mask = BD71837_INT_ON_REQ_MASK,
+   },
+   [BD71837_INT_STBY_REQ] = {
+   .mask = BD71837_INT_STBY_REQ_MASK,
+   },
+};
+
+static struct regmap_irq_chip bd71837_irq_chip = {
+   .name = "bd71837-irq",
+   .irqs = bd71837_irqs,
+   .num_irqs = ARRAY_SIZE(bd71837_irqs),
+   .num_regs = 1,
+   .irq_reg_stride = 1,
+   .status_base = BD71837_REG_IRQ,
+   .mask_base = BD71837_REG_MIRQ,
+   .mask_invert = false,
+};
+
+static int bd71837_irq_exit(struct bd71837 *bd71837)
+{
+   if (bd71837->chip_irq > 0)
+   regmap_del_irq_chip(bd71837->chip_irq, bd71837->irq_data);
+   return 0;
+}
+
+static const struct regmap_range pmic_status_range = {
+   .range_min = BD71837_REG_IRQ,
+   .range_max = BD71837_REG_POW_STATE,
+};
+
+static const struct regmap_access_table volatile_regs = {
+   .yes_ranges = _status_range,
+   .n_yes_ranges = 1,
+};
+
+static const struct regmap_config bd71837_regmap_config = {
+   .reg_bits = 8,
+   .val_bits = 8,
+   .volatile_table = _regs,
+   .max_register = BD71837_MAX_REGISTER - 1,
+   .cache_type = REGCACHE_RBTREE,
+};
+
+#ifdef CONFIG_OF
+static const struct of_device_id bd71837_of_match[] = {
+   { .compatible = "rohm,bd71837", .data = (void *)0},
+   { },
+};
+MODULE_DEVICE_TABLE(of, bd71837_of_match);
+
+static int bd71837_parse_dt(struct i2c_client *client, struct bd71837_board 
**b)
+{
+   struct device_node *np = client->dev.of_node;
+   struct bd71837_board *board_info;
+   unsigned int prop;
+   int r;
+   int rv = -ENOMEM;
+
+   board_info = devm_kzalloc(>dev, sizeof(*board_info),
+   GFP_KERNEL);
+   if (!board_info)
+   goto err_out;
+
+   if (client->irq) {
+   dev_dbg(>dev, "Got irq %d\n", client->irq);
+   board_info->gpio_intr = client->irq;
+   } else {
+   dev_err(>dev, "no pmic intr pin available\n");
+   rv = -ENOENT;
+   goto err_intr;
+   }
+   r = of_property_read_u32(np, "irq_base", );
+   if (!r)
+   board_info->irq_base = prop;
+   else
+   board_info->irq_base = 0;
+
+   rv = 0;
+   *b = board_info;
+   if (0) {
+err_intr:
+   devm_kfree(>dev, board_info);
+err_out:
+   dev_err(>dev, "failed to parse device-tree (%d)\n", rv);
+   }
+   return rv;
+}
+#endif //CONFIG_OF
+
+static int bd71837_i2c_probe(struct i2c_client *i2c,
+   const struct i2c_device_id *id)
+{
+   struct bd71837 *bd71837;
+   struct bd71837_board *pmic_plat_data;
+   int ret = -EINVAL;
+
+   pmic_plat_data = dev_get_platdata(>dev);
+
+   if (!pmic_plat_data && i2c->dev.of_node)
+   ret = bd71837_parse_dt(i2c, _plat_data);
+
+   if (!pmic_plat_data)
+   return ret;
+
+   bd71837 = devm_kzalloc(>dev, sizeof(struct bd71837), GFP_KERNEL);
+   if (bd71837 == NULL)
+   return -ENOMEM;
+
+   bd71837->of_plat_data = pmic_plat_data;
+   i2c_set_clientdata(i2c, bd71837);
+   bd71837->dev = >dev;
+   

[PATCH 1/9] mfd: bd71837: mfd driver for ROHM BD71837 PMIC

[Matti Vaittinen]

ROHM BD71837 PMIC MFD driver providing interrupts and support
for two subsystems:
- clk
- Regulators

Signed-off-by: Matti Vaittinen 
---
 drivers/mfd/bd71837.c   | 238 +
 include/linux/mfd/bd71837.h | 316 
 2 files changed, 554 insertions(+)
 create mode 100644 drivers/mfd/bd71837.c
 create mode 100644 include/linux/mfd/bd71837.h

diff --git a/drivers/mfd/bd71837.c b/drivers/mfd/bd71837.c
new file mode 100644
index ..231442c823bd
--- /dev/null
+++ b/drivers/mfd/bd71837.c
@@ -0,0 +1,238 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (C) 2018 ROHM Semiconductors */
+/*
+ * bd71837.c  --  ROHM BD71837MWV mfd driver
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* bd71837 multi function cells */
+static struct mfd_cell bd71837_mfd_cells[] = {
+   {
+   .name = "bd71837-clk",
+   .of_compatible = "rohm,bd71837-clk",
+   }, {
+   .name = "bd71837-pmic",
+   .of_compatible = "rohm,bd71837-pmic",
+   },
+};
+
+static const struct regmap_irq bd71837_irqs[] = {
+   [BD71837_INT_SWRST] = {
+   .mask = BD71837_INT_SWRST_MASK,
+   },
+   [BD71837_INT_PWRBTN_S] = {
+   .mask = BD71837_INT_PWRBTN_S_MASK,
+   },
+   [BD71837_INT_PWRBTN_L] = {
+   .mask = BD71837_INT_PWRBTN_L_MASK,
+   },
+   [BD71837_INT_PWRBTN] = {
+   .mask = BD71837_INT_PWRBTN_MASK,
+   },
+   [BD71837_INT_WDOG] = {
+   .mask = BD71837_INT_WDOG_MASK,
+   },
+   [BD71837_INT_ON_REQ] = {
+   .mask = BD71837_INT_ON_REQ_MASK,
+   },
+   [BD71837_INT_STBY_REQ] = {
+   .mask = BD71837_INT_STBY_REQ_MASK,
+   },
+};
+
+static struct regmap_irq_chip bd71837_irq_chip = {
+   .name = "bd71837-irq",
+   .irqs = bd71837_irqs,
+   .num_irqs = ARRAY_SIZE(bd71837_irqs),
+   .num_regs = 1,
+   .irq_reg_stride = 1,
+   .status_base = BD71837_REG_IRQ,
+   .mask_base = BD71837_REG_MIRQ,
+   .mask_invert = false,
+};
+
+static int bd71837_irq_exit(struct bd71837 *bd71837)
+{
+   if (bd71837->chip_irq > 0)
+   regmap_del_irq_chip(bd71837->chip_irq, bd71837->irq_data);
+   return 0;
+}
+
+static const struct regmap_range pmic_status_range = {
+   .range_min = BD71837_REG_IRQ,
+   .range_max = BD71837_REG_POW_STATE,
+};
+
+static const struct regmap_access_table volatile_regs = {
+   .yes_ranges = _status_range,
+   .n_yes_ranges = 1,
+};
+
+static const struct regmap_config bd71837_regmap_config = {
+   .reg_bits = 8,
+   .val_bits = 8,
+   .volatile_table = _regs,
+   .max_register = BD71837_MAX_REGISTER - 1,
+   .cache_type = REGCACHE_RBTREE,
+};
+
+#ifdef CONFIG_OF
+static const struct of_device_id bd71837_of_match[] = {
+   { .compatible = "rohm,bd71837", .data = (void *)0},
+   { },
+};
+MODULE_DEVICE_TABLE(of, bd71837_of_match);
+
+static int bd71837_parse_dt(struct i2c_client *client, struct bd71837_board 
**b)
+{
+   struct device_node *np = client->dev.of_node;
+   struct bd71837_board *board_info;
+   unsigned int prop;
+   int r;
+   int rv = -ENOMEM;
+
+   board_info = devm_kzalloc(>dev, sizeof(*board_info),
+   GFP_KERNEL);
+   if (!board_info)
+   goto err_out;
+
+   if (client->irq) {
+   dev_dbg(>dev, "Got irq %d\n", client->irq);
+   board_info->gpio_intr = client->irq;
+   } else {
+   dev_err(>dev, "no pmic intr pin available\n");
+   rv = -ENOENT;
+   goto err_intr;
+   }
+   r = of_property_read_u32(np, "irq_base", );
+   if (!r)
+   board_info->irq_base = prop;
+   else
+   board_info->irq_base = 0;
+
+   rv = 0;
+   *b = board_info;
+   if (0) {
+err_intr:
+   devm_kfree(>dev, board_info);
+err_out:
+   dev_err(>dev, "failed to parse device-tree (%d)\n", rv);
+   }
+   return rv;
+}
+#endif //CONFIG_OF
+
+static int bd71837_i2c_probe(struct i2c_client *i2c,
+   const struct i2c_device_id *id)
+{
+   struct bd71837 *bd71837;
+   struct bd71837_board *pmic_plat_data;
+   int ret = -EINVAL;
+
+   pmic_plat_data = dev_get_platdata(>dev);
+
+   if (!pmic_plat_data && i2c->dev.of_node)
+   ret = bd71837_parse_dt(i2c, _plat_data);
+
+   if (!pmic_plat_data)
+   return ret;
+
+   bd71837 = devm_kzalloc(>dev, sizeof(struct bd71837), GFP_KERNEL);
+   if (bd71837 == NULL)
+   return -ENOMEM;
+
+   bd71837->of_plat_data = pmic_plat_data;
+   i2c_set_clientdata(i2c, bd71837);
+   bd71837->dev = >dev;
+   bd71837->i2c_client = i2c;
+   

[PATCH 2/9] mfd: bd71837: build BD71837 PMIC MFD driver

[Matti Vaittinen]

Configuration options and Makefile for BD71837 PMIC MFD driver

Signed-off-by: Matti Vaittinen 
---
 drivers/mfd/Kconfig  | 13 +
 drivers/mfd/Makefile |  1 +
 2 files changed, 14 insertions(+)

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index b860eb5aa194..7aa05fc9ed8e 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1787,6 +1787,19 @@ config MFD_STW481X
  in various ST Microelectronics and ST-Ericsson embedded
  Nomadik series.
 
+config MFD_BD71837
+   bool "BD71837 Power Management chip"
+   depends on I2C=y
+   depends on OF
+   select REGMAP_I2C
+   select REGMAP_IRQ
+   select MFD_CORE
+   help
+ Select this option to get support for the ROHM BD71837
+ Power Management chips. BD71837 is designed to power processors like
+ NXP i.MX8. It contains 8 BUCK outputs and 7 LDOs, voltage monitoring
+ and emergency shut down as well as 32,768KHz clock output.
+
 config MFD_STM32_LPTIMER
tristate "Support for STM32 Low-Power Timer"
depends on (ARCH_STM32 && OF) || COMPILE_TEST
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index e9fd20dba18d..09dc9eb3782c 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -227,4 +227,5 @@ obj-$(CONFIG_MFD_STM32_TIMERS)  += stm32-timers.o
 obj-$(CONFIG_MFD_MXS_LRADC) += mxs-lradc.o
 obj-$(CONFIG_MFD_SC27XX_PMIC)  += sprd-sc27xx-spi.o
 obj-$(CONFIG_RAVE_SP_CORE) += rave-sp.o
+obj-$(CONFIG_MFD_BD71837)  += bd71837.o
 
-- 
2.14.3

[PATCH 2/9] mfd: bd71837: build BD71837 PMIC MFD driver

[Matti Vaittinen]

Configuration options and Makefile for BD71837 PMIC MFD driver

Signed-off-by: Matti Vaittinen 
---
 drivers/mfd/Kconfig  | 13 +
 drivers/mfd/Makefile |  1 +
 2 files changed, 14 insertions(+)

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index b860eb5aa194..7aa05fc9ed8e 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1787,6 +1787,19 @@ config MFD_STW481X
  in various ST Microelectronics and ST-Ericsson embedded
  Nomadik series.
 
+config MFD_BD71837
+   bool "BD71837 Power Management chip"
+   depends on I2C=y
+   depends on OF
+   select REGMAP_I2C
+   select REGMAP_IRQ
+   select MFD_CORE
+   help
+ Select this option to get support for the ROHM BD71837
+ Power Management chips. BD71837 is designed to power processors like
+ NXP i.MX8. It contains 8 BUCK outputs and 7 LDOs, voltage monitoring
+ and emergency shut down as well as 32,768KHz clock output.
+
 config MFD_STM32_LPTIMER
tristate "Support for STM32 Low-Power Timer"
depends on (ARCH_STM32 && OF) || COMPILE_TEST
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index e9fd20dba18d..09dc9eb3782c 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -227,4 +227,5 @@ obj-$(CONFIG_MFD_STM32_TIMERS)  += stm32-timers.o
 obj-$(CONFIG_MFD_MXS_LRADC) += mxs-lradc.o
 obj-$(CONFIG_MFD_SC27XX_PMIC)  += sprd-sc27xx-spi.o
 obj-$(CONFIG_RAVE_SP_CORE) += rave-sp.o
+obj-$(CONFIG_MFD_BD71837)  += bd71837.o
 
-- 
2.14.3

[PATCH 0/9] mfd/regulator/clk: bd71837: ROHM BD71837 PMIC driver

[Matti Vaittinen]

Patch series adding support for ROHM BD71837 PMIC.

BD71837 is a programmable Power Management IC for powering single-core,
dual-core, and quad-core SoC’s such as NXP-i.MX 8M. It is optimized for
low BOM cost and compact solution footprint. It integrates 8 buck
regulators and 7 LDO’s to provide all the power rails required by the
SoC and the commonly used peripherals.

The driver aims to not limit the usage of PMIC. Thus the buck and LDO
naming is generic and not tied to any specific purposes. However there
is following limitations which make it mostly suitable for use cases
where the processor where PMIC driver is running is powered by the PMIC:

- The PMIC is not re-initialized if it resets. PMIC may reset as a
  result of voltage monitoring (over/under voltage) or due to reset
  request. Driver is only initializing PMIC at probe. This is not
  problem as long as processor controlling PMIC is powered by PMIC.

- The PMIC internal state machine is ignored by driver. Driver assumes
  the PMIC is wired so that it is always in "run" state when controlled
  by the driver.

patch 1: 
MFD driver and definitions bringing interrupt support and
enabling clk and regulator subsystems.
Patch 2:
Kconfig and Makefiles for MFD.
Patches 3, 4 and 5:
device tree binding documents.
Patch 6:
clock subsystem and support for gated clock.
Patch 7:
Kconfig and Makefiles for clock.
Patch 8:
regulator driver supporting 8 bucks and 7 LDOs.
Patch 9: 
Kconfig and Makefiles for regulators

This patch series is based on for-mfd-next

---

Matti Vaittinen (9):
  mfd: bd71837: mfd driver for ROHM BD71837 PMIC
  mfd: bd71837: build BD71837 PMIC MFD driver
  mfd: bd71837: Devicetree bindings for ROHM BD71837 PMIC
  regulator: bd71837: Devicetree bindings for BD71837 regulators
  clk: bd71837: Devicetree bindings for ROHM BD71837 PMIC
  clk: bd71837: Add driver for BD71837 PMIC clock
  clk: bd71837: Build ROHM BD71837 PMIC clock driver
  regulator: bd71837: BD71837 PMIC regulator driver
  regulator: bd71837: Build BD71837 regulator driver

 .../bindings/clock/rohm,bd71837-clock.txt  |  37 ++
 .../devicetree/bindings/mfd/rohm,bd71837-pmic.txt  |  55 ++
 .../bindings/regulator/rohm,bd71837-regulator.txt  | 124 
 drivers/clk/Kconfig|   9 +
 drivers/clk/Makefile   |   1 +
 drivers/clk/clk-bd71837.c  | 155 +
 drivers/mfd/Kconfig|  13 +
 drivers/mfd/Makefile   |   1 +
 drivers/mfd/bd71837.c  | 238 +++
 drivers/regulator/Kconfig  |  11 +
 drivers/regulator/Makefile |   1 +
 drivers/regulator/bd71837-regulator.c  | 683 +
 include/linux/mfd/bd71837.h| 316 ++
 13 files changed, 1644 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/clock/rohm,bd71837-clock.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.txt
 create mode 100644 
Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.txt
 create mode 100644 drivers/clk/clk-bd71837.c
 create mode 100644 drivers/mfd/bd71837.c
 create mode 100644 drivers/regulator/bd71837-regulator.c
 create mode 100644 include/linux/mfd/bd71837.h

-- 
2.14.3

[PATCH 0/9] mfd/regulator/clk: bd71837: ROHM BD71837 PMIC driver

[Matti Vaittinen]

Patch series adding support for ROHM BD71837 PMIC.

BD71837 is a programmable Power Management IC for powering single-core,
dual-core, and quad-core SoC’s such as NXP-i.MX 8M. It is optimized for
low BOM cost and compact solution footprint. It integrates 8 buck
regulators and 7 LDO’s to provide all the power rails required by the
SoC and the commonly used peripherals.

The driver aims to not limit the usage of PMIC. Thus the buck and LDO
naming is generic and not tied to any specific purposes. However there
is following limitations which make it mostly suitable for use cases
where the processor where PMIC driver is running is powered by the PMIC:

- The PMIC is not re-initialized if it resets. PMIC may reset as a
  result of voltage monitoring (over/under voltage) or due to reset
  request. Driver is only initializing PMIC at probe. This is not
  problem as long as processor controlling PMIC is powered by PMIC.

- The PMIC internal state machine is ignored by driver. Driver assumes
  the PMIC is wired so that it is always in "run" state when controlled
  by the driver.

patch 1: 
MFD driver and definitions bringing interrupt support and
enabling clk and regulator subsystems.
Patch 2:
Kconfig and Makefiles for MFD.
Patches 3, 4 and 5:
device tree binding documents.
Patch 6:
clock subsystem and support for gated clock.
Patch 7:
Kconfig and Makefiles for clock.
Patch 8:
regulator driver supporting 8 bucks and 7 LDOs.
Patch 9: 
Kconfig and Makefiles for regulators

This patch series is based on for-mfd-next

---

Matti Vaittinen (9):
  mfd: bd71837: mfd driver for ROHM BD71837 PMIC
  mfd: bd71837: build BD71837 PMIC MFD driver
  mfd: bd71837: Devicetree bindings for ROHM BD71837 PMIC
  regulator: bd71837: Devicetree bindings for BD71837 regulators
  clk: bd71837: Devicetree bindings for ROHM BD71837 PMIC
  clk: bd71837: Add driver for BD71837 PMIC clock
  clk: bd71837: Build ROHM BD71837 PMIC clock driver
  regulator: bd71837: BD71837 PMIC regulator driver
  regulator: bd71837: Build BD71837 regulator driver

 .../bindings/clock/rohm,bd71837-clock.txt  |  37 ++
 .../devicetree/bindings/mfd/rohm,bd71837-pmic.txt  |  55 ++
 .../bindings/regulator/rohm,bd71837-regulator.txt  | 124 
 drivers/clk/Kconfig|   9 +
 drivers/clk/Makefile   |   1 +
 drivers/clk/clk-bd71837.c  | 155 +
 drivers/mfd/Kconfig|  13 +
 drivers/mfd/Makefile   |   1 +
 drivers/mfd/bd71837.c  | 238 +++
 drivers/regulator/Kconfig  |  11 +
 drivers/regulator/Makefile |   1 +
 drivers/regulator/bd71837-regulator.c  | 683 +
 include/linux/mfd/bd71837.h| 316 ++
 13 files changed, 1644 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/clock/rohm,bd71837-clock.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.txt
 create mode 100644 
Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.txt
 create mode 100644 drivers/clk/clk-bd71837.c
 create mode 100644 drivers/mfd/bd71837.c
 create mode 100644 drivers/regulator/bd71837-regulator.c
 create mode 100644 include/linux/mfd/bd71837.h

-- 
2.14.3

Re: [PATCH v2 3/5] mfd: cros-ec: Introduce CEC commands and events definitions.

[Benson Leung]

Hi Neil, Hi Stefan,

On Fri, May 18, 2018 at 03:05:02PM +0200, Neil Armstrong wrote:
> The EC can expose a CEC bus, this patch adds the CEC related definitions
> needed by the cros-ec-cec driver.
> Having a 16 byte mkbp event size makes it possible to send CEC
> messages from the EC to the AP directly inside the mkbp event
> instead of first doing a notification and then a read.
> 
> Signed-off-by: Stefan Adolfsson 
> Signed-off-by: Neil Armstrong 

It looks like this change squashes together this chromeos-4.4 CL
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1061879
and some other new changes to add cec to cros_ec_commands.

Could you separate the two? One patch that's as close to Stefan's
which introduces the 16 byte mkbp, and a second one that
adds the HDMI CEC commands? 

Thanks,
Benson
> ---
>  drivers/platform/chrome/cros_ec_proto.c | 40 +
>  include/linux/mfd/cros_ec.h |  2 +-
>  include/linux/mfd/cros_ec_commands.h| 80 
> +
>  3 files changed, 112 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/platform/chrome/cros_ec_proto.c 
> b/drivers/platform/chrome/cros_ec_proto.c
> index e7bbdf9..c4f6c44 100644
> --- a/drivers/platform/chrome/cros_ec_proto.c
> +++ b/drivers/platform/chrome/cros_ec_proto.c
> @@ -504,10 +504,31 @@ int cros_ec_cmd_xfer_status(struct cros_ec_device 
> *ec_dev,
>  }
>  EXPORT_SYMBOL(cros_ec_cmd_xfer_status);
>  
> +static int get_next_event_xfer(struct cros_ec_device *ec_dev,
> +struct cros_ec_command *msg,
> +int version, uint32_t size)
> +{
> + int ret;
> +
> + msg->version = version;
> + msg->command = EC_CMD_GET_NEXT_EVENT;
> + msg->insize = size;
> + msg->outsize = 0;
> +
> + ret = cros_ec_cmd_xfer(ec_dev, msg);
> + if (ret > 0) {
> + ec_dev->event_size = ret - 1;
> + memcpy(_dev->event_data, msg->data, ec_dev->event_size);
> + }
> +
> + return ret;
> +}
> +
>  static int get_next_event(struct cros_ec_device *ec_dev)
>  {
>   u8 buffer[sizeof(struct cros_ec_command) + sizeof(ec_dev->event_data)];
>   struct cros_ec_command *msg = (struct cros_ec_command *)
> + static int cmd_version = 1;
>   int ret;
>  
>   if (ec_dev->suspended) {
> @@ -515,18 +536,19 @@ static int get_next_event(struct cros_ec_device *ec_dev)
>   return -EHOSTDOWN;
>   }
>  
> - msg->version = 0;
> - msg->command = EC_CMD_GET_NEXT_EVENT;
> - msg->insize = sizeof(ec_dev->event_data);
> - msg->outsize = 0;
> + if (cmd_version == 1) {
> + ret = get_next_event_xfer(ec_dev, msg, cmd_version,
> + sizeof(struct ec_response_get_next_event_v1));
> + if (ret < 0 || msg->result != EC_RES_INVALID_VERSION)
> + return ret;
>  
> - ret = cros_ec_cmd_xfer(ec_dev, msg);
> - if (ret > 0) {
> - ec_dev->event_size = ret - 1;
> - memcpy(_dev->event_data, msg->data,
> -sizeof(ec_dev->event_data));
> + /* Fallback to version 0 for future send attempts */
> + cmd_version = 0;
>   }
>  
> + ret = get_next_event_xfer(ec_dev, msg, cmd_version,
> +   sizeof(struct ec_response_get_next_event));
> +
>   return ret;
>  }
>  
> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index f36125e..32caef3 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -147,7 +147,7 @@ struct cros_ec_device {
>   bool mkbp_event_supported;
>   struct blocking_notifier_head event_notifier;
>  
> - struct ec_response_get_next_event event_data;
> + struct ec_response_get_next_event_v1 event_data;
>   int event_size;
>   u32 host_event_wake_mask;
>  };
> diff --git a/include/linux/mfd/cros_ec_commands.h 
> b/include/linux/mfd/cros_ec_commands.h
> index f2edd99..16c3a2b 100644
> --- a/include/linux/mfd/cros_ec_commands.h
> +++ b/include/linux/mfd/cros_ec_commands.h
> @@ -804,6 +804,8 @@ enum ec_feature_code {
>   EC_FEATURE_MOTION_SENSE_FIFO = 24,
>   /* EC has RTC feature that can be controlled by host commands */
>   EC_FEATURE_RTC = 27,
> + /* EC supports CEC commands */
> + EC_FEATURE_CEC = 35,
>  };
>  
>  #define EC_FEATURE_MASK_0(event_code) (1UL << (event_code % 32))
> @@ -2078,6 +2080,12 @@ enum ec_mkbp_event {
>   /* EC sent a sysrq command */
>   EC_MKBP_EVENT_SYSRQ = 6,
>  
> + /* Notify the AP that something happened on CEC */
> + EC_MKBP_CEC_EVENT = 8,
> +
> + /* Send an incoming CEC message to the AP */
> + EC_MKBP_EVENT_CEC_MESSAGE = 9,
> +
>   /* Number of MKBP events */
>   EC_MKBP_EVENT_COUNT,
>  };
> @@ -2093,12 +2101,31 @@ union ec_response_get_next_data {
>   uint32_t   sysrq;
>  } __packed;
>  
> +union 

Re: [PATCH v2 3/5] mfd: cros-ec: Introduce CEC commands and events definitions.

[Benson Leung]

Hi Neil, Hi Stefan,

On Fri, May 18, 2018 at 03:05:02PM +0200, Neil Armstrong wrote:
> The EC can expose a CEC bus, this patch adds the CEC related definitions
> needed by the cros-ec-cec driver.
> Having a 16 byte mkbp event size makes it possible to send CEC
> messages from the EC to the AP directly inside the mkbp event
> instead of first doing a notification and then a read.
> 
> Signed-off-by: Stefan Adolfsson 
> Signed-off-by: Neil Armstrong 

It looks like this change squashes together this chromeos-4.4 CL
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1061879
and some other new changes to add cec to cros_ec_commands.

Could you separate the two? One patch that's as close to Stefan's
which introduces the 16 byte mkbp, and a second one that
adds the HDMI CEC commands? 

Thanks,
Benson
> ---
>  drivers/platform/chrome/cros_ec_proto.c | 40 +
>  include/linux/mfd/cros_ec.h |  2 +-
>  include/linux/mfd/cros_ec_commands.h| 80 
> +
>  3 files changed, 112 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/platform/chrome/cros_ec_proto.c 
> b/drivers/platform/chrome/cros_ec_proto.c
> index e7bbdf9..c4f6c44 100644
> --- a/drivers/platform/chrome/cros_ec_proto.c
> +++ b/drivers/platform/chrome/cros_ec_proto.c
> @@ -504,10 +504,31 @@ int cros_ec_cmd_xfer_status(struct cros_ec_device 
> *ec_dev,
>  }
>  EXPORT_SYMBOL(cros_ec_cmd_xfer_status);
>  
> +static int get_next_event_xfer(struct cros_ec_device *ec_dev,
> +struct cros_ec_command *msg,
> +int version, uint32_t size)
> +{
> + int ret;
> +
> + msg->version = version;
> + msg->command = EC_CMD_GET_NEXT_EVENT;
> + msg->insize = size;
> + msg->outsize = 0;
> +
> + ret = cros_ec_cmd_xfer(ec_dev, msg);
> + if (ret > 0) {
> + ec_dev->event_size = ret - 1;
> + memcpy(_dev->event_data, msg->data, ec_dev->event_size);
> + }
> +
> + return ret;
> +}
> +
>  static int get_next_event(struct cros_ec_device *ec_dev)
>  {
>   u8 buffer[sizeof(struct cros_ec_command) + sizeof(ec_dev->event_data)];
>   struct cros_ec_command *msg = (struct cros_ec_command *)
> + static int cmd_version = 1;
>   int ret;
>  
>   if (ec_dev->suspended) {
> @@ -515,18 +536,19 @@ static int get_next_event(struct cros_ec_device *ec_dev)
>   return -EHOSTDOWN;
>   }
>  
> - msg->version = 0;
> - msg->command = EC_CMD_GET_NEXT_EVENT;
> - msg->insize = sizeof(ec_dev->event_data);
> - msg->outsize = 0;
> + if (cmd_version == 1) {
> + ret = get_next_event_xfer(ec_dev, msg, cmd_version,
> + sizeof(struct ec_response_get_next_event_v1));
> + if (ret < 0 || msg->result != EC_RES_INVALID_VERSION)
> + return ret;
>  
> - ret = cros_ec_cmd_xfer(ec_dev, msg);
> - if (ret > 0) {
> - ec_dev->event_size = ret - 1;
> - memcpy(_dev->event_data, msg->data,
> -sizeof(ec_dev->event_data));
> + /* Fallback to version 0 for future send attempts */
> + cmd_version = 0;
>   }
>  
> + ret = get_next_event_xfer(ec_dev, msg, cmd_version,
> +   sizeof(struct ec_response_get_next_event));
> +
>   return ret;
>  }
>  
> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index f36125e..32caef3 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -147,7 +147,7 @@ struct cros_ec_device {
>   bool mkbp_event_supported;
>   struct blocking_notifier_head event_notifier;
>  
> - struct ec_response_get_next_event event_data;
> + struct ec_response_get_next_event_v1 event_data;
>   int event_size;
>   u32 host_event_wake_mask;
>  };
> diff --git a/include/linux/mfd/cros_ec_commands.h 
> b/include/linux/mfd/cros_ec_commands.h
> index f2edd99..16c3a2b 100644
> --- a/include/linux/mfd/cros_ec_commands.h
> +++ b/include/linux/mfd/cros_ec_commands.h
> @@ -804,6 +804,8 @@ enum ec_feature_code {
>   EC_FEATURE_MOTION_SENSE_FIFO = 24,
>   /* EC has RTC feature that can be controlled by host commands */
>   EC_FEATURE_RTC = 27,
> + /* EC supports CEC commands */
> + EC_FEATURE_CEC = 35,
>  };
>  
>  #define EC_FEATURE_MASK_0(event_code) (1UL << (event_code % 32))
> @@ -2078,6 +2080,12 @@ enum ec_mkbp_event {
>   /* EC sent a sysrq command */
>   EC_MKBP_EVENT_SYSRQ = 6,
>  
> + /* Notify the AP that something happened on CEC */
> + EC_MKBP_CEC_EVENT = 8,
> +
> + /* Send an incoming CEC message to the AP */
> + EC_MKBP_EVENT_CEC_MESSAGE = 9,
> +
>   /* Number of MKBP events */
>   EC_MKBP_EVENT_COUNT,
>  };
> @@ -2093,12 +2101,31 @@ union ec_response_get_next_data {
>   uint32_t   sysrq;
>  } __packed;
>  
> +union ec_response_get_next_data_v1 {
> + uint8_t   

Re: [PATCH v2 1/2] dt-bindings: cpufreq: Introduce QCOM CPUFREQ FW bindings

[Taniya Das]

On 5/23/2018 8:43 PM, Sudeep Holla wrote:



On 19/05/18 18:34, Taniya Das wrote:

Add QCOM cpufreq firmware device bindings for Qualcomm Technology Inc's
SoCs. This is required for managing the cpu frequency transitions which are
controlled by firmware.

Signed-off-by: Taniya Das 
---
  .../bindings/cpufreq/cpufreq-qcom-fw.txt   | 68 ++
  1 file changed, 68 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt

diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt 
b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt
new file mode 100644
index 000..bc912f4
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt
@@ -0,0 +1,68 @@
+Qualcomm Technologies, Inc. CPUFREQ Bindings
+
+CPUFREQ FW is a hardware engine used by some Qualcomm Technologies, Inc. (QTI)
+SoCs to manage frequency in hardware. It is capable of controlling frequency
+for multiple clusters.
+
+Properties:
+- compatible
+   Usage:  required
+   Value type: 
+   Definition: must be "qcom,cpufreq-fw".
+


If the firmware is referred with some other name, better to use that
than cpufreq

+Note that #address-cells, #size-cells, and ranges shall be present to ensure
+the cpufreq can address a freq-domain registers.
+
+A freq-domain sub-node would be defined for the cpus with the following
+properties:
+
+- compatible:
+   Usage:  required
+   Value type: 
+   Definition: must be "cpufreq".
+
+- reg
+   Usage:  required
+   Value type: 
+   Definition: Addresses and sizes for the memory of the perf_base
+   , lut_base and en_base.


Can you explicitly define each one of them ? Either here or in reg-names.



Sure will define each of them in the next series.


+- reg-names
+   Usage:  required
+   Value type: 
+   Definition: Address names. Must be "perf_base", "lut_base",
+   "en_base".
+   Must be specified in the same order as the
+   corresponding addresses are specified in the reg
+   property.
+
+- qcom,cpulist
+   Usage:  required
+   Value type: 
+   Definition: List of related cpu handles which are under a cluster.
+


As already mentioned by Rob and Viresh, better to align with OPP style
to avoid phandle list of CPUs.



I have put down an example device tree node for Rob & Viresh to review.


Also I see similar bindings for devfreq, can't they be aligned ?
E.g. lut_base here while it's ftbl_base in devfreq.



It is actually the look up table, thus was the name given as "lut". Will 
check with Saravana for devfreq and align accordingly.



--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.

--

Re: [PATCH v2 1/2] dt-bindings: cpufreq: Introduce QCOM CPUFREQ FW bindings

[Taniya Das]

On 5/23/2018 8:43 PM, Sudeep Holla wrote:



On 19/05/18 18:34, Taniya Das wrote:

Add QCOM cpufreq firmware device bindings for Qualcomm Technology Inc's
SoCs. This is required for managing the cpu frequency transitions which are
controlled by firmware.

Signed-off-by: Taniya Das 
---
  .../bindings/cpufreq/cpufreq-qcom-fw.txt   | 68 ++
  1 file changed, 68 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt

diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt 
b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt
new file mode 100644
index 000..bc912f4
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt
@@ -0,0 +1,68 @@
+Qualcomm Technologies, Inc. CPUFREQ Bindings
+
+CPUFREQ FW is a hardware engine used by some Qualcomm Technologies, Inc. (QTI)
+SoCs to manage frequency in hardware. It is capable of controlling frequency
+for multiple clusters.
+
+Properties:
+- compatible
+   Usage:  required
+   Value type: 
+   Definition: must be "qcom,cpufreq-fw".
+


If the firmware is referred with some other name, better to use that
than cpufreq

+Note that #address-cells, #size-cells, and ranges shall be present to ensure
+the cpufreq can address a freq-domain registers.
+
+A freq-domain sub-node would be defined for the cpus with the following
+properties:
+
+- compatible:
+   Usage:  required
+   Value type: 
+   Definition: must be "cpufreq".
+
+- reg
+   Usage:  required
+   Value type: 
+   Definition: Addresses and sizes for the memory of the perf_base
+   , lut_base and en_base.


Can you explicitly define each one of them ? Either here or in reg-names.



Sure will define each of them in the next series.


+- reg-names
+   Usage:  required
+   Value type: 
+   Definition: Address names. Must be "perf_base", "lut_base",
+   "en_base".
+   Must be specified in the same order as the
+   corresponding addresses are specified in the reg
+   property.
+
+- qcom,cpulist
+   Usage:  required
+   Value type: 
+   Definition: List of related cpu handles which are under a cluster.
+


As already mentioned by Rob and Viresh, better to align with OPP style
to avoid phandle list of CPUs.



I have put down an example device tree node for Rob & Viresh to review.


Also I see similar bindings for devfreq, can't they be aligned ?
E.g. lut_base here while it's ftbl_base in devfreq.



It is actually the look up table, thus was the name given as "lut". Will 
check with Saravana for devfreq and align accordingly.



--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.

--

[tip:perf/core] perf kcore_copy: Amend the offset of sections that remap kernel text

[tip-bot for Adrian Hunter]

Commit-ID:  22916fdb9c50e8fb303bdcedca88fd8798a85844
Gitweb: https://git.kernel.org/tip/22916fdb9c50e8fb303bdcedca88fd8798a85844
Author: Adrian Hunter 
AuthorDate: Tue, 22 May 2018 13:54:45 +0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 23 May 2018 10:26:44 -0300

perf kcore_copy: Amend the offset of sections that remap kernel text

x86 PTI entry trampolines all map to the same physical page. If that is
reflected in the program headers of /proc/kcore, then do the same for the
copy of kcore.

Signed-off-by: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Andy Lutomirski 
Cc: Dave Hansen 
Cc: H. Peter Anvin 
Cc: Jiri Olsa 
Cc: Joerg Roedel 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: x...@kernel.org
Link: 
http://lkml.kernel.org/r/1526986485-6562-18-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/symbol-elf.c | 53 ++--
 1 file changed, 51 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 584966913aeb..29770ea61768 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -1390,6 +1390,7 @@ struct phdr_data {
u64 addr;
u64 len;
struct list_head node;
+   struct phdr_data *remaps;
 };
 
 struct sym_data {
@@ -1597,16 +1598,62 @@ static int kcore_copy__read_maps(struct kcore_copy_info 
*kci, Elf *elf)
return 0;
 }
 
+static void kcore_copy__find_remaps(struct kcore_copy_info *kci)
+{
+   struct phdr_data *p, *k = NULL;
+   u64 kend;
+
+   if (!kci->stext)
+   return;
+
+   /* Find phdr that corresponds to the kernel map (contains stext) */
+   kcore_copy__for_each_phdr(kci, p) {
+   u64 pend = p->addr + p->len - 1;
+
+   if (p->addr <= kci->stext && pend >= kci->stext) {
+   k = p;
+   break;
+   }
+   }
+
+   if (!k)
+   return;
+
+   kend = k->offset + k->len;
+
+   /* Find phdrs that remap the kernel */
+   kcore_copy__for_each_phdr(kci, p) {
+   u64 pend = p->offset + p->len;
+
+   if (p == k)
+   continue;
+
+   if (p->offset >= k->offset && pend <= kend)
+   p->remaps = k;
+   }
+}
+
 static void kcore_copy__layout(struct kcore_copy_info *kci)
 {
struct phdr_data *p;
off_t rel = 0;
 
+   kcore_copy__find_remaps(kci);
+
kcore_copy__for_each_phdr(kci, p) {
-   p->rel = rel;
-   rel += p->len;
+   if (!p->remaps) {
+   p->rel = rel;
+   rel += p->len;
+   }
kci->phnum += 1;
}
+
+   kcore_copy__for_each_phdr(kci, p) {
+   struct phdr_data *k = p->remaps;
+
+   if (k)
+   p->rel = p->offset - k->offset + k->rel;
+   }
 }
 
 static int kcore_copy__calc_maps(struct kcore_copy_info *kci, const char *dir,
@@ -1821,6 +1868,8 @@ int kcore_copy(const char *from_dir, const char *to_dir)
kcore_copy__for_each_phdr(, p) {
off_t offs = p->rel + offset;
 
+   if (p->remaps)
+   continue;
if (copy_bytes(kcore.fd, p->offset, extract.fd, offs, p->len))
goto out_extract_close;
}

[tip:perf/core] perf kcore_copy: Amend the offset of sections that remap kernel text

[tip-bot for Adrian Hunter]

Commit-ID:  22916fdb9c50e8fb303bdcedca88fd8798a85844
Gitweb: https://git.kernel.org/tip/22916fdb9c50e8fb303bdcedca88fd8798a85844
Author: Adrian Hunter 
AuthorDate: Tue, 22 May 2018 13:54:45 +0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 23 May 2018 10:26:44 -0300

perf kcore_copy: Amend the offset of sections that remap kernel text

x86 PTI entry trampolines all map to the same physical page. If that is
reflected in the program headers of /proc/kcore, then do the same for the
copy of kcore.

Signed-off-by: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Andy Lutomirski 
Cc: Dave Hansen 
Cc: H. Peter Anvin 
Cc: Jiri Olsa 
Cc: Joerg Roedel 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: x...@kernel.org
Link: 
http://lkml.kernel.org/r/1526986485-6562-18-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/symbol-elf.c | 53 ++--
 1 file changed, 51 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 584966913aeb..29770ea61768 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -1390,6 +1390,7 @@ struct phdr_data {
u64 addr;
u64 len;
struct list_head node;
+   struct phdr_data *remaps;
 };
 
 struct sym_data {
@@ -1597,16 +1598,62 @@ static int kcore_copy__read_maps(struct kcore_copy_info 
*kci, Elf *elf)
return 0;
 }
 
+static void kcore_copy__find_remaps(struct kcore_copy_info *kci)
+{
+   struct phdr_data *p, *k = NULL;
+   u64 kend;
+
+   if (!kci->stext)
+   return;
+
+   /* Find phdr that corresponds to the kernel map (contains stext) */
+   kcore_copy__for_each_phdr(kci, p) {
+   u64 pend = p->addr + p->len - 1;
+
+   if (p->addr <= kci->stext && pend >= kci->stext) {
+   k = p;
+   break;
+   }
+   }
+
+   if (!k)
+   return;
+
+   kend = k->offset + k->len;
+
+   /* Find phdrs that remap the kernel */
+   kcore_copy__for_each_phdr(kci, p) {
+   u64 pend = p->offset + p->len;
+
+   if (p == k)
+   continue;
+
+   if (p->offset >= k->offset && pend <= kend)
+   p->remaps = k;
+   }
+}
+
 static void kcore_copy__layout(struct kcore_copy_info *kci)
 {
struct phdr_data *p;
off_t rel = 0;
 
+   kcore_copy__find_remaps(kci);
+
kcore_copy__for_each_phdr(kci, p) {
-   p->rel = rel;
-   rel += p->len;
+   if (!p->remaps) {
+   p->rel = rel;
+   rel += p->len;
+   }
kci->phnum += 1;
}
+
+   kcore_copy__for_each_phdr(kci, p) {
+   struct phdr_data *k = p->remaps;
+
+   if (k)
+   p->rel = p->offset - k->offset + k->rel;
+   }
 }
 
 static int kcore_copy__calc_maps(struct kcore_copy_info *kci, const char *dir,
@@ -1821,6 +1868,8 @@ int kcore_copy(const char *from_dir, const char *to_dir)
kcore_copy__for_each_phdr(, p) {
off_t offs = p->rel + offset;
 
+   if (p->remaps)
+   continue;
if (copy_bytes(kcore.fd, p->offset, extract.fd, offs, p->len))
goto out_extract_close;
}

[tip:perf/core] perf kcore_copy: Copy x86 PTI entry trampoline sections

[tip-bot for Adrian Hunter]

Commit-ID:  a1a3a0624e6cd0e2c46a7400800a5e687521a504
Gitweb: https://git.kernel.org/tip/a1a3a0624e6cd0e2c46a7400800a5e687521a504
Author: Adrian Hunter 
AuthorDate: Tue, 22 May 2018 13:54:44 +0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 23 May 2018 10:26:43 -0300

perf kcore_copy: Copy x86 PTI entry trampoline sections

Identify and copy any sections for x86 PTI entry trampolines.

Signed-off-by: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Andy Lutomirski 
Cc: Dave Hansen 
Cc: H. Peter Anvin 
Cc: Jiri Olsa 
Cc: Joerg Roedel 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: x...@kernel.org
Link: 
http://lkml.kernel.org/r/1526986485-6562-17-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/symbol-elf.c | 42 ++
 1 file changed, 42 insertions(+)

diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 37d9324c277c..584966913aeb 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -1392,6 +1392,11 @@ struct phdr_data {
struct list_head node;
 };
 
+struct sym_data {
+   u64 addr;
+   struct list_head node;
+};
+
 struct kcore_copy_info {
u64 stext;
u64 etext;
@@ -1401,6 +1406,7 @@ struct kcore_copy_info {
u64 last_module_symbol;
size_t phnum;
struct list_head phdrs;
+   struct list_head syms;
 };
 
 #define kcore_copy__for_each_phdr(k, p) \
@@ -1441,6 +1447,29 @@ static void kcore_copy__free_phdrs(struct 
kcore_copy_info *kci)
}
 }
 
+static struct sym_data *kcore_copy__new_sym(struct kcore_copy_info *kci,
+   u64 addr)
+{
+   struct sym_data *s = zalloc(sizeof(*s));
+
+   if (s) {
+   s->addr = addr;
+   list_add_tail(>node, >syms);
+   }
+
+   return s;
+}
+
+static void kcore_copy__free_syms(struct kcore_copy_info *kci)
+{
+   struct sym_data *s, *tmp;
+
+   list_for_each_entry_safe(s, tmp, >syms, node) {
+   list_del(>node);
+   free(s);
+   }
+}
+
 static int kcore_copy__process_kallsyms(void *arg, const char *name, char type,
u64 start)
 {
@@ -1471,6 +1500,9 @@ static int kcore_copy__process_kallsyms(void *arg, const 
char *name, char type,
return 0;
}
 
+   if (is_entry_trampoline(name) && !kcore_copy__new_sym(kci, start))
+   return -1;
+
return 0;
 }
 
@@ -1538,6 +1570,7 @@ static int kcore_copy__read_map(u64 start, u64 len, u64 
pgoff, void *data)
 {
struct kcore_copy_info *kci = data;
u64 end = start + len;
+   struct sym_data *sdat;
 
if (kcore_copy__map(kci, start, end, pgoff, kci->stext, kci->etext))
return -1;
@@ -1546,6 +1579,13 @@ static int kcore_copy__read_map(u64 start, u64 len, u64 
pgoff, void *data)
kci->last_module_symbol))
return -1;
 
+   list_for_each_entry(sdat, >syms, node) {
+   u64 s = round_down(sdat->addr, page_size);
+
+   if (kcore_copy__map(kci, start, end, pgoff, s, s + len))
+   return -1;
+   }
+
return 0;
 }
 
@@ -1740,6 +1780,7 @@ int kcore_copy(const char *from_dir, const char *to_dir)
struct phdr_data *p;
 
INIT_LIST_HEAD();
+   INIT_LIST_HEAD();
 
if (kcore_copy__copy_file(from_dir, to_dir, "kallsyms"))
return -1;
@@ -1806,6 +1847,7 @@ out_unlink_kallsyms:
kcore_copy__unlink(to_dir, "kallsyms");
 
kcore_copy__free_phdrs();
+   kcore_copy__free_syms();
 
return err;
 }

[tip:perf/core] perf kcore_copy: Copy x86 PTI entry trampoline sections

[tip-bot for Adrian Hunter]

Commit-ID:  a1a3a0624e6cd0e2c46a7400800a5e687521a504
Gitweb: https://git.kernel.org/tip/a1a3a0624e6cd0e2c46a7400800a5e687521a504
Author: Adrian Hunter 
AuthorDate: Tue, 22 May 2018 13:54:44 +0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 23 May 2018 10:26:43 -0300

perf kcore_copy: Copy x86 PTI entry trampoline sections

Identify and copy any sections for x86 PTI entry trampolines.

Signed-off-by: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Andy Lutomirski 
Cc: Dave Hansen 
Cc: H. Peter Anvin 
Cc: Jiri Olsa 
Cc: Joerg Roedel 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: x...@kernel.org
Link: 
http://lkml.kernel.org/r/1526986485-6562-17-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/symbol-elf.c | 42 ++
 1 file changed, 42 insertions(+)

diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 37d9324c277c..584966913aeb 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -1392,6 +1392,11 @@ struct phdr_data {
struct list_head node;
 };
 
+struct sym_data {
+   u64 addr;
+   struct list_head node;
+};
+
 struct kcore_copy_info {
u64 stext;
u64 etext;
@@ -1401,6 +1406,7 @@ struct kcore_copy_info {
u64 last_module_symbol;
size_t phnum;
struct list_head phdrs;
+   struct list_head syms;
 };
 
 #define kcore_copy__for_each_phdr(k, p) \
@@ -1441,6 +1447,29 @@ static void kcore_copy__free_phdrs(struct 
kcore_copy_info *kci)
}
 }
 
+static struct sym_data *kcore_copy__new_sym(struct kcore_copy_info *kci,
+   u64 addr)
+{
+   struct sym_data *s = zalloc(sizeof(*s));
+
+   if (s) {
+   s->addr = addr;
+   list_add_tail(>node, >syms);
+   }
+
+   return s;
+}
+
+static void kcore_copy__free_syms(struct kcore_copy_info *kci)
+{
+   struct sym_data *s, *tmp;
+
+   list_for_each_entry_safe(s, tmp, >syms, node) {
+   list_del(>node);
+   free(s);
+   }
+}
+
 static int kcore_copy__process_kallsyms(void *arg, const char *name, char type,
u64 start)
 {
@@ -1471,6 +1500,9 @@ static int kcore_copy__process_kallsyms(void *arg, const 
char *name, char type,
return 0;
}
 
+   if (is_entry_trampoline(name) && !kcore_copy__new_sym(kci, start))
+   return -1;
+
return 0;
 }
 
@@ -1538,6 +1570,7 @@ static int kcore_copy__read_map(u64 start, u64 len, u64 
pgoff, void *data)
 {
struct kcore_copy_info *kci = data;
u64 end = start + len;
+   struct sym_data *sdat;
 
if (kcore_copy__map(kci, start, end, pgoff, kci->stext, kci->etext))
return -1;
@@ -1546,6 +1579,13 @@ static int kcore_copy__read_map(u64 start, u64 len, u64 
pgoff, void *data)
kci->last_module_symbol))
return -1;
 
+   list_for_each_entry(sdat, >syms, node) {
+   u64 s = round_down(sdat->addr, page_size);
+
+   if (kcore_copy__map(kci, start, end, pgoff, s, s + len))
+   return -1;
+   }
+
return 0;
 }
 
@@ -1740,6 +1780,7 @@ int kcore_copy(const char *from_dir, const char *to_dir)
struct phdr_data *p;
 
INIT_LIST_HEAD();
+   INIT_LIST_HEAD();
 
if (kcore_copy__copy_file(from_dir, to_dir, "kallsyms"))
return -1;
@@ -1806,6 +1847,7 @@ out_unlink_kallsyms:
kcore_copy__unlink(to_dir, "kallsyms");
 
kcore_copy__free_phdrs();
+   kcore_copy__free_syms();
 
return err;
 }

[tip:perf/core] perf kcore_copy: Layout sections

[tip-bot for Adrian Hunter]

Commit-ID:  15acef6c3727cfe0bc9d1f6b273cca46689e8cd8
Gitweb: https://git.kernel.org/tip/15acef6c3727cfe0bc9d1f6b273cca46689e8cd8
Author: Adrian Hunter 
AuthorDate: Tue, 22 May 2018 13:54:41 +0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 23 May 2018 10:26:42 -0300

perf kcore_copy: Layout sections

In preparation to add more program headers, layout the relative offset
of each section.

Signed-off-by: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Andy Lutomirski 
Cc: Dave Hansen 
Cc: H. Peter Anvin 
Cc: Jiri Olsa 
Cc: Joerg Roedel 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: x...@kernel.org
Link: 
http://lkml.kernel.org/r/1526986485-6562-14-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/symbol-elf.c | 25 ++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 4aec12102e19..3e76a0efd15c 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -1386,6 +1386,7 @@ static off_t kcore__write(struct kcore *kcore)
 
 struct phdr_data {
off_t offset;
+   off_t rel;
u64 addr;
u64 len;
struct list_head node;
@@ -1404,6 +1405,9 @@ struct kcore_copy_info {
struct list_head phdrs;
 };
 
+#define kcore_copy__for_each_phdr(k, p) \
+   list_for_each_entry((p), &(k)->phdrs, node)
+
 static int kcore_copy__process_kallsyms(void *arg, const char *name, char type,
u64 start)
 {
@@ -1518,11 +1522,21 @@ static int kcore_copy__read_maps(struct kcore_copy_info 
*kci, Elf *elf)
if (kci->modules_map.len)
list_add_tail(>modules_map.node, >phdrs);
 
-   kci->phnum = !!kci->kernel_map.len + !!kci->modules_map.len;
-
return 0;
 }
 
+static void kcore_copy__layout(struct kcore_copy_info *kci)
+{
+   struct phdr_data *p;
+   off_t rel = 0;
+
+   kcore_copy__for_each_phdr(kci, p) {
+   p->rel = rel;
+   rel += p->len;
+   kci->phnum += 1;
+   }
+}
+
 static int kcore_copy__calc_maps(struct kcore_copy_info *kci, const char *dir,
 Elf *elf)
 {
@@ -1558,7 +1572,12 @@ static int kcore_copy__calc_maps(struct kcore_copy_info 
*kci, const char *dir,
if (kci->first_module && !kci->last_module_symbol)
return -1;
 
-   return kcore_copy__read_maps(kci, elf);
+   if (kcore_copy__read_maps(kci, elf))
+   return -1;
+
+   kcore_copy__layout(kci);
+
+   return 0;
 }
 
 static int kcore_copy__copy_file(const char *from_dir, const char *to_dir,

[tip:perf/core] perf kcore_copy: Layout sections

[tip-bot for Adrian Hunter]

Commit-ID:  15acef6c3727cfe0bc9d1f6b273cca46689e8cd8
Gitweb: https://git.kernel.org/tip/15acef6c3727cfe0bc9d1f6b273cca46689e8cd8
Author: Adrian Hunter 
AuthorDate: Tue, 22 May 2018 13:54:41 +0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 23 May 2018 10:26:42 -0300

perf kcore_copy: Layout sections

In preparation to add more program headers, layout the relative offset
of each section.

Signed-off-by: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Andy Lutomirski 
Cc: Dave Hansen 
Cc: H. Peter Anvin 
Cc: Jiri Olsa 
Cc: Joerg Roedel 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: x...@kernel.org
Link: 
http://lkml.kernel.org/r/1526986485-6562-14-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/symbol-elf.c | 25 ++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 4aec12102e19..3e76a0efd15c 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -1386,6 +1386,7 @@ static off_t kcore__write(struct kcore *kcore)
 
 struct phdr_data {
off_t offset;
+   off_t rel;
u64 addr;
u64 len;
struct list_head node;
@@ -1404,6 +1405,9 @@ struct kcore_copy_info {
struct list_head phdrs;
 };
 
+#define kcore_copy__for_each_phdr(k, p) \
+   list_for_each_entry((p), &(k)->phdrs, node)
+
 static int kcore_copy__process_kallsyms(void *arg, const char *name, char type,
u64 start)
 {
@@ -1518,11 +1522,21 @@ static int kcore_copy__read_maps(struct kcore_copy_info 
*kci, Elf *elf)
if (kci->modules_map.len)
list_add_tail(>modules_map.node, >phdrs);
 
-   kci->phnum = !!kci->kernel_map.len + !!kci->modules_map.len;
-
return 0;
 }
 
+static void kcore_copy__layout(struct kcore_copy_info *kci)
+{
+   struct phdr_data *p;
+   off_t rel = 0;
+
+   kcore_copy__for_each_phdr(kci, p) {
+   p->rel = rel;
+   rel += p->len;
+   kci->phnum += 1;
+   }
+}
+
 static int kcore_copy__calc_maps(struct kcore_copy_info *kci, const char *dir,
 Elf *elf)
 {
@@ -1558,7 +1572,12 @@ static int kcore_copy__calc_maps(struct kcore_copy_info 
*kci, const char *dir,
if (kci->first_module && !kci->last_module_symbol)
return -1;
 
-   return kcore_copy__read_maps(kci, elf);
+   if (kcore_copy__read_maps(kci, elf))
+   return -1;
+
+   kcore_copy__layout(kci);
+
+   return 0;
 }
 
 static int kcore_copy__copy_file(const char *from_dir, const char *to_dir,

[tip:perf/core] perf kcore_copy: Get rid of kernel_map

[tip-bot for Adrian Hunter]

Commit-ID:  b4503cdb67098b2f08320c2c83df758ea72a4431
Gitweb: https://git.kernel.org/tip/b4503cdb67098b2f08320c2c83df758ea72a4431
Author: Adrian Hunter 
AuthorDate: Tue, 22 May 2018 13:54:43 +0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 23 May 2018 10:26:43 -0300

perf kcore_copy: Get rid of kernel_map

In preparation to add more program headers, get rid of kernel_map and
modules_map by moving ->kernel_map and ->modules_map to newly allocated
entries in the ->phdrs list.

Signed-off-by: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Andy Lutomirski 
Cc: Dave Hansen 
Cc: H. Peter Anvin 
Cc: Jiri Olsa 
Cc: Joerg Roedel 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: x...@kernel.org
Link: 
http://lkml.kernel.org/r/1526986485-6562-16-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/symbol-elf.c | 70 
 1 file changed, 52 insertions(+), 18 deletions(-)

diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 91b8cfb045ec..37d9324c277c 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -1400,14 +1400,47 @@ struct kcore_copy_info {
u64 first_module;
u64 last_module_symbol;
size_t phnum;
-   struct phdr_data kernel_map;
-   struct phdr_data modules_map;
struct list_head phdrs;
 };
 
 #define kcore_copy__for_each_phdr(k, p) \
list_for_each_entry((p), &(k)->phdrs, node)
 
+static struct phdr_data *phdr_data__new(u64 addr, u64 len, off_t offset)
+{
+   struct phdr_data *p = zalloc(sizeof(*p));
+
+   if (p) {
+   p->addr   = addr;
+   p->len= len;
+   p->offset = offset;
+   }
+
+   return p;
+}
+
+static struct phdr_data *kcore_copy_info__addnew(struct kcore_copy_info *kci,
+u64 addr, u64 len,
+off_t offset)
+{
+   struct phdr_data *p = phdr_data__new(addr, len, offset);
+
+   if (p)
+   list_add_tail(>node, >phdrs);
+
+   return p;
+}
+
+static void kcore_copy__free_phdrs(struct kcore_copy_info *kci)
+{
+   struct phdr_data *p, *tmp;
+
+   list_for_each_entry_safe(p, tmp, >phdrs, node) {
+   list_del(>node);
+   free(p);
+   }
+}
+
 static int kcore_copy__process_kallsyms(void *arg, const char *name, char type,
u64 start)
 {
@@ -1487,15 +1520,18 @@ static int kcore_copy__parse_modules(struct 
kcore_copy_info *kci,
return 0;
 }
 
-static void kcore_copy__map(struct phdr_data *p, u64 start, u64 end, u64 pgoff,
-   u64 s, u64 e)
+static int kcore_copy__map(struct kcore_copy_info *kci, u64 start, u64 end,
+  u64 pgoff, u64 s, u64 e)
 {
-   if (p->addr || s < start || s >= end)
-   return;
+   u64 len, offset;
+
+   if (s < start || s >= end)
+   return 0;
 
-   p->addr = s;
-   p->offset = (s - start) + pgoff;
-   p->len = e < end ? e - s : end - s;
+   offset = (s - start) + pgoff;
+   len = e < end ? e - s : end - s;
+
+   return kcore_copy_info__addnew(kci, s, len, offset) ? 0 : -1;
 }
 
 static int kcore_copy__read_map(u64 start, u64 len, u64 pgoff, void *data)
@@ -1503,11 +1539,12 @@ static int kcore_copy__read_map(u64 start, u64 len, u64 
pgoff, void *data)
struct kcore_copy_info *kci = data;
u64 end = start + len;
 
-   kcore_copy__map(>kernel_map, start, end, pgoff, kci->stext,
-   kci->etext);
+   if (kcore_copy__map(kci, start, end, pgoff, kci->stext, kci->etext))
+   return -1;
 
-   kcore_copy__map(>modules_map, start, end, pgoff, kci->first_module,
-   kci->last_module_symbol);
+   if (kcore_copy__map(kci, start, end, pgoff, kci->first_module,
+   kci->last_module_symbol))
+   return -1;
 
return 0;
 }
@@ -1517,11 +1554,6 @@ static int kcore_copy__read_maps(struct kcore_copy_info 
*kci, Elf *elf)
if (elf_read_maps(elf, true, kcore_copy__read_map, kci) < 0)
return -1;
 
-   if (kci->kernel_map.len)
-   list_add_tail(>kernel_map.node, >phdrs);
-   if (kci->modules_map.len)
-   list_add_tail(>modules_map.node, >phdrs);
-
return 0;
 }
 
@@ -1773,6 +1805,8 @@ out_unlink_kallsyms:
if (err)
kcore_copy__unlink(to_dir, "kallsyms");
 
+   kcore_copy__free_phdrs();
+
return err;
 }
 

[tip:perf/core] perf kcore_copy: Get rid of kernel_map

[tip-bot for Adrian Hunter]

Commit-ID:  b4503cdb67098b2f08320c2c83df758ea72a4431
Gitweb: https://git.kernel.org/tip/b4503cdb67098b2f08320c2c83df758ea72a4431
Author: Adrian Hunter 
AuthorDate: Tue, 22 May 2018 13:54:43 +0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 23 May 2018 10:26:43 -0300

perf kcore_copy: Get rid of kernel_map

In preparation to add more program headers, get rid of kernel_map and
modules_map by moving ->kernel_map and ->modules_map to newly allocated
entries in the ->phdrs list.

Signed-off-by: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Andy Lutomirski 
Cc: Dave Hansen 
Cc: H. Peter Anvin 
Cc: Jiri Olsa 
Cc: Joerg Roedel 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: x...@kernel.org
Link: 
http://lkml.kernel.org/r/1526986485-6562-16-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/symbol-elf.c | 70 
 1 file changed, 52 insertions(+), 18 deletions(-)

diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 91b8cfb045ec..37d9324c277c 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -1400,14 +1400,47 @@ struct kcore_copy_info {
u64 first_module;
u64 last_module_symbol;
size_t phnum;
-   struct phdr_data kernel_map;
-   struct phdr_data modules_map;
struct list_head phdrs;
 };
 
 #define kcore_copy__for_each_phdr(k, p) \
list_for_each_entry((p), &(k)->phdrs, node)
 
+static struct phdr_data *phdr_data__new(u64 addr, u64 len, off_t offset)
+{
+   struct phdr_data *p = zalloc(sizeof(*p));
+
+   if (p) {
+   p->addr   = addr;
+   p->len= len;
+   p->offset = offset;
+   }
+
+   return p;
+}
+
+static struct phdr_data *kcore_copy_info__addnew(struct kcore_copy_info *kci,
+u64 addr, u64 len,
+off_t offset)
+{
+   struct phdr_data *p = phdr_data__new(addr, len, offset);
+
+   if (p)
+   list_add_tail(>node, >phdrs);
+
+   return p;
+}
+
+static void kcore_copy__free_phdrs(struct kcore_copy_info *kci)
+{
+   struct phdr_data *p, *tmp;
+
+   list_for_each_entry_safe(p, tmp, >phdrs, node) {
+   list_del(>node);
+   free(p);
+   }
+}
+
 static int kcore_copy__process_kallsyms(void *arg, const char *name, char type,
u64 start)
 {
@@ -1487,15 +1520,18 @@ static int kcore_copy__parse_modules(struct 
kcore_copy_info *kci,
return 0;
 }
 
-static void kcore_copy__map(struct phdr_data *p, u64 start, u64 end, u64 pgoff,
-   u64 s, u64 e)
+static int kcore_copy__map(struct kcore_copy_info *kci, u64 start, u64 end,
+  u64 pgoff, u64 s, u64 e)
 {
-   if (p->addr || s < start || s >= end)
-   return;
+   u64 len, offset;
+
+   if (s < start || s >= end)
+   return 0;
 
-   p->addr = s;
-   p->offset = (s - start) + pgoff;
-   p->len = e < end ? e - s : end - s;
+   offset = (s - start) + pgoff;
+   len = e < end ? e - s : end - s;
+
+   return kcore_copy_info__addnew(kci, s, len, offset) ? 0 : -1;
 }
 
 static int kcore_copy__read_map(u64 start, u64 len, u64 pgoff, void *data)
@@ -1503,11 +1539,12 @@ static int kcore_copy__read_map(u64 start, u64 len, u64 
pgoff, void *data)
struct kcore_copy_info *kci = data;
u64 end = start + len;
 
-   kcore_copy__map(>kernel_map, start, end, pgoff, kci->stext,
-   kci->etext);
+   if (kcore_copy__map(kci, start, end, pgoff, kci->stext, kci->etext))
+   return -1;
 
-   kcore_copy__map(>modules_map, start, end, pgoff, kci->first_module,
-   kci->last_module_symbol);
+   if (kcore_copy__map(kci, start, end, pgoff, kci->first_module,
+   kci->last_module_symbol))
+   return -1;
 
return 0;
 }
@@ -1517,11 +1554,6 @@ static int kcore_copy__read_maps(struct kcore_copy_info 
*kci, Elf *elf)
if (elf_read_maps(elf, true, kcore_copy__read_map, kci) < 0)
return -1;
 
-   if (kci->kernel_map.len)
-   list_add_tail(>kernel_map.node, >phdrs);
-   if (kci->modules_map.len)
-   list_add_tail(>modules_map.node, >phdrs);
-
return 0;
 }
 
@@ -1773,6 +1805,8 @@ out_unlink_kallsyms:
if (err)
kcore_copy__unlink(to_dir, "kallsyms");
 
+   kcore_copy__free_phdrs();
+
return err;
 }
 

[tip:perf/core] perf kcore_copy: Iterate phdrs

[tip-bot for Adrian Hunter]

Commit-ID:  d2c959803c8843f64e419d833dc3722154c82492
Gitweb: https://git.kernel.org/tip/d2c959803c8843f64e419d833dc3722154c82492
Author: Adrian Hunter 
AuthorDate: Tue, 22 May 2018 13:54:42 +0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 23 May 2018 10:26:42 -0300

perf kcore_copy: Iterate phdrs

In preparation to add more program headers, iterate phdrs instead of
assuming there is only one for the kernel text and one for the modules.

Signed-off-by: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Andy Lutomirski 
Cc: Dave Hansen 
Cc: H. Peter Anvin 
Cc: Jiri Olsa 
Cc: Joerg Roedel 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: x...@kernel.org
Link: 
http://lkml.kernel.org/r/1526986485-6562-15-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/symbol-elf.c | 25 ++---
 1 file changed, 10 insertions(+), 15 deletions(-)

diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 3e76a0efd15c..91b8cfb045ec 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -1701,10 +1701,11 @@ int kcore_copy(const char *from_dir, const char *to_dir)
struct kcore kcore;
struct kcore extract;
int idx = 0, err = -1;
-   off_t offset, sz, modules_offset = 0;
+   off_t offset, sz;
struct kcore_copy_info kci = { .stext = 0, };
char kcore_filename[PATH_MAX];
char extract_filename[PATH_MAX];
+   struct phdr_data *p;
 
INIT_LIST_HEAD();
 
@@ -1733,14 +1734,10 @@ int kcore_copy(const char *from_dir, const char *to_dir)
 gelf_fsize(extract.elf, ELF_T_PHDR, kci.phnum, EV_CURRENT);
offset = round_up(offset, page_size);
 
-   if (kcore__add_phdr(, idx++, offset, kci.kernel_map.addr,
-   kci.kernel_map.len))
-   goto out_extract_close;
+   kcore_copy__for_each_phdr(, p) {
+   off_t offs = p->rel + offset;
 
-   if (kci.modules_map.addr) {
-   modules_offset = offset + kci.kernel_map.len;
-   if (kcore__add_phdr(, idx, modules_offset,
-   kci.modules_map.addr, kci.modules_map.len))
+   if (kcore__add_phdr(, idx++, offs, p->addr, p->len))
goto out_extract_close;
}
 
@@ -1748,14 +1745,12 @@ int kcore_copy(const char *from_dir, const char *to_dir)
if (sz < 0 || sz > offset)
goto out_extract_close;
 
-   if (copy_bytes(kcore.fd, kci.kernel_map.offset, extract.fd, offset,
-  kci.kernel_map.len))
-   goto out_extract_close;
+   kcore_copy__for_each_phdr(, p) {
+   off_t offs = p->rel + offset;
 
-   if (modules_offset && copy_bytes(kcore.fd, kci.modules_map.offset,
-extract.fd, modules_offset,
-kci.modules_map.len))
-   goto out_extract_close;
+   if (copy_bytes(kcore.fd, p->offset, extract.fd, offs, p->len))
+   goto out_extract_close;
+   }
 
if (kcore_copy__compare_file(from_dir, to_dir, "modules"))
goto out_extract_close;

[tip:perf/core] perf kcore_copy: Iterate phdrs

[tip-bot for Adrian Hunter]

Commit-ID:  d2c959803c8843f64e419d833dc3722154c82492
Gitweb: https://git.kernel.org/tip/d2c959803c8843f64e419d833dc3722154c82492
Author: Adrian Hunter 
AuthorDate: Tue, 22 May 2018 13:54:42 +0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 23 May 2018 10:26:42 -0300

perf kcore_copy: Iterate phdrs

In preparation to add more program headers, iterate phdrs instead of
assuming there is only one for the kernel text and one for the modules.

Signed-off-by: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Andy Lutomirski 
Cc: Dave Hansen 
Cc: H. Peter Anvin 
Cc: Jiri Olsa 
Cc: Joerg Roedel 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: x...@kernel.org
Link: 
http://lkml.kernel.org/r/1526986485-6562-15-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/symbol-elf.c | 25 ++---
 1 file changed, 10 insertions(+), 15 deletions(-)

diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 3e76a0efd15c..91b8cfb045ec 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -1701,10 +1701,11 @@ int kcore_copy(const char *from_dir, const char *to_dir)
struct kcore kcore;
struct kcore extract;
int idx = 0, err = -1;
-   off_t offset, sz, modules_offset = 0;
+   off_t offset, sz;
struct kcore_copy_info kci = { .stext = 0, };
char kcore_filename[PATH_MAX];
char extract_filename[PATH_MAX];
+   struct phdr_data *p;
 
INIT_LIST_HEAD();
 
@@ -1733,14 +1734,10 @@ int kcore_copy(const char *from_dir, const char *to_dir)
 gelf_fsize(extract.elf, ELF_T_PHDR, kci.phnum, EV_CURRENT);
offset = round_up(offset, page_size);
 
-   if (kcore__add_phdr(, idx++, offset, kci.kernel_map.addr,
-   kci.kernel_map.len))
-   goto out_extract_close;
+   kcore_copy__for_each_phdr(, p) {
+   off_t offs = p->rel + offset;
 
-   if (kci.modules_map.addr) {
-   modules_offset = offset + kci.kernel_map.len;
-   if (kcore__add_phdr(, idx, modules_offset,
-   kci.modules_map.addr, kci.modules_map.len))
+   if (kcore__add_phdr(, idx++, offs, p->addr, p->len))
goto out_extract_close;
}
 
@@ -1748,14 +1745,12 @@ int kcore_copy(const char *from_dir, const char *to_dir)
if (sz < 0 || sz > offset)
goto out_extract_close;
 
-   if (copy_bytes(kcore.fd, kci.kernel_map.offset, extract.fd, offset,
-  kci.kernel_map.len))
-   goto out_extract_close;
+   kcore_copy__for_each_phdr(, p) {
+   off_t offs = p->rel + offset;
 
-   if (modules_offset && copy_bytes(kcore.fd, kci.modules_map.offset,
-extract.fd, modules_offset,
-kci.modules_map.len))
-   goto out_extract_close;
+   if (copy_bytes(kcore.fd, p->offset, extract.fd, offs, p->len))
+   goto out_extract_close;
+   }
 
if (kcore_copy__compare_file(from_dir, to_dir, "modules"))
goto out_extract_close;

Re: [PATCH v2 1/2] dt-bindings: cpufreq: Introduce QCOM CPUFREQ FW bindings

[Viresh Kumar]

On 24-05-18, 10:48, Taniya Das wrote:
> Hello Rob, Viresh,
> 
> Thank you for the comments. If I understand correctly, the device tree nodes
> should look something like the below.
> 
> Though I am not sure if any vendor name could be associated in the cpu
> nodes.

Well Rob said Yes to that I think.

> Please suggest if my understanding is wrong.
> 
> cpu@0 {
>   qcom,freq-domain = <_domain_table0>;
>   …
> };
> 
> same follows for cpu 1/2/3
> 
> cpu@400 {
>   qcom,freq-domain = <_domain_table1>;
>   …
> };
> same follows for cpu 5/6/7
> 
> freq_domain_table0 : freq_table {
>   reg = < >, < >, < > ;
>   reg-names = "perf_base", "lut_base", "en_base";
> };
> 
> freq_domain_table1 : freq_table {
>   reg = < >, < >, < > ;
>   reg-names = "perf_base", "lut_base", "en_base";
> };

Mostly yes.

-- 
viresh

Re: [PATCH v2 1/2] dt-bindings: cpufreq: Introduce QCOM CPUFREQ FW bindings

[Viresh Kumar]

On 24-05-18, 10:48, Taniya Das wrote:
> Hello Rob, Viresh,
> 
> Thank you for the comments. If I understand correctly, the device tree nodes
> should look something like the below.
> 
> Though I am not sure if any vendor name could be associated in the cpu
> nodes.

Well Rob said Yes to that I think.

> Please suggest if my understanding is wrong.
> 
> cpu@0 {
>   qcom,freq-domain = <_domain_table0>;
>   …
> };
> 
> same follows for cpu 1/2/3
> 
> cpu@400 {
>   qcom,freq-domain = <_domain_table1>;
>   …
> };
> same follows for cpu 5/6/7
> 
> freq_domain_table0 : freq_table {
>   reg = < >, < >, < > ;
>   reg-names = "perf_base", "lut_base", "en_base";
> };
> 
> freq_domain_table1 : freq_table {
>   reg = < >, < >, < > ;
>   reg-names = "perf_base", "lut_base", "en_base";
> };

Mostly yes.

-- 
viresh

[tip:perf/core] perf kcore_copy: Calculate offset from phnum

[tip-bot for Adrian Hunter]

Commit-ID:  c9dd1d894958b81a329ec01e7dd03b92eca52789
Gitweb: https://git.kernel.org/tip/c9dd1d894958b81a329ec01e7dd03b92eca52789
Author: Adrian Hunter 
AuthorDate: Tue, 22 May 2018 13:54:40 +0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 23 May 2018 10:26:41 -0300

perf kcore_copy: Calculate offset from phnum

In preparation to add more program headers, calculate offset from the
number of phdrs.

Signed-off-by: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Andy Lutomirski 
Cc: Dave Hansen 
Cc: H. Peter Anvin 
Cc: Jiri Olsa 
Cc: Joerg Roedel 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: x...@kernel.org
Link: 
http://lkml.kernel.org/r/1526986485-6562-13-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/symbol-elf.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 4e7b71e8ac0e..4aec12102e19 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -1682,7 +1682,7 @@ int kcore_copy(const char *from_dir, const char *to_dir)
struct kcore kcore;
struct kcore extract;
int idx = 0, err = -1;
-   off_t offset = page_size, sz, modules_offset = 0;
+   off_t offset, sz, modules_offset = 0;
struct kcore_copy_info kci = { .stext = 0, };
char kcore_filename[PATH_MAX];
char extract_filename[PATH_MAX];
@@ -1710,6 +1710,10 @@ int kcore_copy(const char *from_dir, const char *to_dir)
if (kcore__copy_hdr(, , kci.phnum))
goto out_extract_close;
 
+   offset = gelf_fsize(extract.elf, ELF_T_EHDR, 1, EV_CURRENT) +
+gelf_fsize(extract.elf, ELF_T_PHDR, kci.phnum, EV_CURRENT);
+   offset = round_up(offset, page_size);
+
if (kcore__add_phdr(, idx++, offset, kci.kernel_map.addr,
kci.kernel_map.len))
goto out_extract_close;

[tip:perf/core] perf kcore_copy: Calculate offset from phnum

[tip-bot for Adrian Hunter]

Commit-ID:  c9dd1d894958b81a329ec01e7dd03b92eca52789
Gitweb: https://git.kernel.org/tip/c9dd1d894958b81a329ec01e7dd03b92eca52789
Author: Adrian Hunter 
AuthorDate: Tue, 22 May 2018 13:54:40 +0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 23 May 2018 10:26:41 -0300

perf kcore_copy: Calculate offset from phnum

In preparation to add more program headers, calculate offset from the
number of phdrs.

Signed-off-by: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Andy Lutomirski 
Cc: Dave Hansen 
Cc: H. Peter Anvin 
Cc: Jiri Olsa 
Cc: Joerg Roedel 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: x...@kernel.org
Link: 
http://lkml.kernel.org/r/1526986485-6562-13-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/symbol-elf.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 4e7b71e8ac0e..4aec12102e19 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -1682,7 +1682,7 @@ int kcore_copy(const char *from_dir, const char *to_dir)
struct kcore kcore;
struct kcore extract;
int idx = 0, err = -1;
-   off_t offset = page_size, sz, modules_offset = 0;
+   off_t offset, sz, modules_offset = 0;
struct kcore_copy_info kci = { .stext = 0, };
char kcore_filename[PATH_MAX];
char extract_filename[PATH_MAX];
@@ -1710,6 +1710,10 @@ int kcore_copy(const char *from_dir, const char *to_dir)
if (kcore__copy_hdr(, , kci.phnum))
goto out_extract_close;
 
+   offset = gelf_fsize(extract.elf, ELF_T_EHDR, 1, EV_CURRENT) +
+gelf_fsize(extract.elf, ELF_T_PHDR, kci.phnum, EV_CURRENT);
+   offset = round_up(offset, page_size);
+
if (kcore__add_phdr(, idx++, offset, kci.kernel_map.addr,
kci.kernel_map.len))
goto out_extract_close;

[tip:perf/core] perf kcore_copy: Keep a count of phdrs

[tip-bot for Adrian Hunter]

Commit-ID:  6e97957d3d30552c415292bb08a0e5f3c459c027
Gitweb: https://git.kernel.org/tip/6e97957d3d30552c415292bb08a0e5f3c459c027
Author: Adrian Hunter 
AuthorDate: Tue, 22 May 2018 13:54:39 +0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 23 May 2018 10:26:41 -0300

perf kcore_copy: Keep a count of phdrs

In preparation to add more program headers, keep a count of phdrs.

Signed-off-by: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Andy Lutomirski 
Cc: Dave Hansen 
Cc: H. Peter Anvin 
Cc: Jiri Olsa 
Cc: Joerg Roedel 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: x...@kernel.org
Link: 
http://lkml.kernel.org/r/1526986485-6562-12-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/symbol-elf.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index b13873a6f368..4e7b71e8ac0e 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -1398,6 +1398,7 @@ struct kcore_copy_info {
u64 last_symbol;
u64 first_module;
u64 last_module_symbol;
+   size_t phnum;
struct phdr_data kernel_map;
struct phdr_data modules_map;
struct list_head phdrs;
@@ -1517,6 +1518,8 @@ static int kcore_copy__read_maps(struct kcore_copy_info 
*kci, Elf *elf)
if (kci->modules_map.len)
list_add_tail(>modules_map.node, >phdrs);
 
+   kci->phnum = !!kci->kernel_map.len + !!kci->modules_map.len;
+
return 0;
 }
 
@@ -1678,7 +1681,6 @@ int kcore_copy(const char *from_dir, const char *to_dir)
 {
struct kcore kcore;
struct kcore extract;
-   size_t count = 2;
int idx = 0, err = -1;
off_t offset = page_size, sz, modules_offset = 0;
struct kcore_copy_info kci = { .stext = 0, };
@@ -1705,10 +1707,7 @@ int kcore_copy(const char *from_dir, const char *to_dir)
if (kcore__init(, extract_filename, kcore.elfclass, false))
goto out_kcore_close;
 
-   if (!kci.modules_map.addr)
-   count -= 1;
-
-   if (kcore__copy_hdr(, , count))
+   if (kcore__copy_hdr(, , kci.phnum))
goto out_extract_close;
 
if (kcore__add_phdr(, idx++, offset, kci.kernel_map.addr,

[tip:perf/core] perf kcore_copy: Keep a count of phdrs

[tip-bot for Adrian Hunter]

Commit-ID:  6e97957d3d30552c415292bb08a0e5f3c459c027
Gitweb: https://git.kernel.org/tip/6e97957d3d30552c415292bb08a0e5f3c459c027
Author: Adrian Hunter 
AuthorDate: Tue, 22 May 2018 13:54:39 +0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 23 May 2018 10:26:41 -0300

perf kcore_copy: Keep a count of phdrs

In preparation to add more program headers, keep a count of phdrs.

Signed-off-by: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Andy Lutomirski 
Cc: Dave Hansen 
Cc: H. Peter Anvin 
Cc: Jiri Olsa 
Cc: Joerg Roedel 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: x...@kernel.org
Link: 
http://lkml.kernel.org/r/1526986485-6562-12-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/symbol-elf.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index b13873a6f368..4e7b71e8ac0e 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -1398,6 +1398,7 @@ struct kcore_copy_info {
u64 last_symbol;
u64 first_module;
u64 last_module_symbol;
+   size_t phnum;
struct phdr_data kernel_map;
struct phdr_data modules_map;
struct list_head phdrs;
@@ -1517,6 +1518,8 @@ static int kcore_copy__read_maps(struct kcore_copy_info 
*kci, Elf *elf)
if (kci->modules_map.len)
list_add_tail(>modules_map.node, >phdrs);
 
+   kci->phnum = !!kci->kernel_map.len + !!kci->modules_map.len;
+
return 0;
 }
 
@@ -1678,7 +1681,6 @@ int kcore_copy(const char *from_dir, const char *to_dir)
 {
struct kcore kcore;
struct kcore extract;
-   size_t count = 2;
int idx = 0, err = -1;
off_t offset = page_size, sz, modules_offset = 0;
struct kcore_copy_info kci = { .stext = 0, };
@@ -1705,10 +1707,7 @@ int kcore_copy(const char *from_dir, const char *to_dir)
if (kcore__init(, extract_filename, kcore.elfclass, false))
goto out_kcore_close;
 
-   if (!kci.modules_map.addr)
-   count -= 1;
-
-   if (kcore__copy_hdr(, , count))
+   if (kcore__copy_hdr(, , kci.phnum))
goto out_extract_close;
 
if (kcore__add_phdr(, idx++, offset, kci.kernel_map.addr,

[tip:perf/core] perf kcore_copy: Keep phdr data in a list

[tip-bot for Adrian Hunter]

Commit-ID:  f6838209484d5cfb368ca5c61d150cc4054eef59
Gitweb: https://git.kernel.org/tip/f6838209484d5cfb368ca5c61d150cc4054eef59
Author: Adrian Hunter 
AuthorDate: Tue, 22 May 2018 13:54:38 +0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 23 May 2018 10:26:40 -0300

perf kcore_copy: Keep phdr data in a list

Currently, kcore_copy makes 2 program headers, one for the kernel text
(namely kernel_map) and one for the modules (namely modules_map). Now
more program headers are needed, but treating each program header as a
special case results in much more code.

Instead, in preparation to add more program headers, change to keep
program header data (phdr_data) in a list.

Signed-off-by: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Andy Lutomirski 
Cc: Dave Hansen 
Cc: H. Peter Anvin 
Cc: Jiri Olsa 
Cc: Joerg Roedel 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: x...@kernel.org
Link: 
http://lkml.kernel.org/r/1526986485-6562-11-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/symbol-elf.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 48943b834f11..b13873a6f368 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -1388,6 +1388,7 @@ struct phdr_data {
off_t offset;
u64 addr;
u64 len;
+   struct list_head node;
 };
 
 struct kcore_copy_info {
@@ -1399,6 +1400,7 @@ struct kcore_copy_info {
u64 last_module_symbol;
struct phdr_data kernel_map;
struct phdr_data modules_map;
+   struct list_head phdrs;
 };
 
 static int kcore_copy__process_kallsyms(void *arg, const char *name, char type,
@@ -1510,6 +1512,11 @@ static int kcore_copy__read_maps(struct kcore_copy_info 
*kci, Elf *elf)
if (elf_read_maps(elf, true, kcore_copy__read_map, kci) < 0)
return -1;
 
+   if (kci->kernel_map.len)
+   list_add_tail(>kernel_map.node, >phdrs);
+   if (kci->modules_map.len)
+   list_add_tail(>modules_map.node, >phdrs);
+
return 0;
 }
 
@@ -1678,6 +1685,8 @@ int kcore_copy(const char *from_dir, const char *to_dir)
char kcore_filename[PATH_MAX];
char extract_filename[PATH_MAX];
 
+   INIT_LIST_HEAD();
+
if (kcore_copy__copy_file(from_dir, to_dir, "kallsyms"))
return -1;
 

[tip:perf/core] perf kcore_copy: Keep phdr data in a list

[tip-bot for Adrian Hunter]

Commit-ID:  f6838209484d5cfb368ca5c61d150cc4054eef59
Gitweb: https://git.kernel.org/tip/f6838209484d5cfb368ca5c61d150cc4054eef59
Author: Adrian Hunter 
AuthorDate: Tue, 22 May 2018 13:54:38 +0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 23 May 2018 10:26:40 -0300

perf kcore_copy: Keep phdr data in a list

Currently, kcore_copy makes 2 program headers, one for the kernel text
(namely kernel_map) and one for the modules (namely modules_map). Now
more program headers are needed, but treating each program header as a
special case results in much more code.

Instead, in preparation to add more program headers, change to keep
program header data (phdr_data) in a list.

Signed-off-by: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Andy Lutomirski 
Cc: Dave Hansen 
Cc: H. Peter Anvin 
Cc: Jiri Olsa 
Cc: Joerg Roedel 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: x...@kernel.org
Link: 
http://lkml.kernel.org/r/1526986485-6562-11-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/symbol-elf.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 48943b834f11..b13873a6f368 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -1388,6 +1388,7 @@ struct phdr_data {
off_t offset;
u64 addr;
u64 len;
+   struct list_head node;
 };
 
 struct kcore_copy_info {
@@ -1399,6 +1400,7 @@ struct kcore_copy_info {
u64 last_module_symbol;
struct phdr_data kernel_map;
struct phdr_data modules_map;
+   struct list_head phdrs;
 };
 
 static int kcore_copy__process_kallsyms(void *arg, const char *name, char type,
@@ -1510,6 +1512,11 @@ static int kcore_copy__read_maps(struct kcore_copy_info 
*kci, Elf *elf)
if (elf_read_maps(elf, true, kcore_copy__read_map, kci) < 0)
return -1;
 
+   if (kci->kernel_map.len)
+   list_add_tail(>kernel_map.node, >phdrs);
+   if (kci->modules_map.len)
+   list_add_tail(>modules_map.node, >phdrs);
+
return 0;
 }
 
@@ -1678,6 +1685,8 @@ int kcore_copy(const char *from_dir, const char *to_dir)
char kcore_filename[PATH_MAX];
char extract_filename[PATH_MAX];
 
+   INIT_LIST_HEAD();
+
if (kcore_copy__copy_file(from_dir, to_dir, "kallsyms"))
return -1;
 

[tip:perf/core] perf machine: Allow for extra kernel maps

[tip-bot for Adrian Hunter]

Commit-ID:  5759a6820aadd38b2c8c10e93919eae8e31a9f9a
Gitweb: https://git.kernel.org/tip/5759a6820aadd38b2c8c10e93919eae8e31a9f9a
Author: Adrian Hunter 
AuthorDate: Tue, 22 May 2018 13:54:35 +0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 22 May 2018 10:59:22 -0300

perf machine: Allow for extra kernel maps

Identify extra kernel maps by name so that they can be distinguished
from the kernel map and module maps.

Signed-off-by: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Andy Lutomirski 
Cc: Dave Hansen 
Cc: H. Peter Anvin 
Cc: Jiri Olsa 
Cc: Joerg Roedel 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: x...@kernel.org
Link: 
http://lkml.kernel.org/r/1526986485-6562-8-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/event.c   |  2 +-
 tools/perf/util/machine.c |  8 ++--
 tools/perf/util/map.c | 22 ++
 tools/perf/util/map.h |  7 ++-
 tools/perf/util/symbol.c  |  7 +++
 5 files changed, 34 insertions(+), 12 deletions(-)

diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index 244135b5ea43..aafa9878465f 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -487,7 +487,7 @@ int perf_event__synthesize_modules(struct perf_tool *tool,
for (pos = maps__first(maps); pos; pos = map__next(pos)) {
size_t size;
 
-   if (__map__is_kernel(pos))
+   if (!__map__is_kmodule(pos))
continue;
 
size = PERF_ALIGN(pos->dso->long_name_len + 1, sizeof(u64));
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index db695603873b..355d23bcd443 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -856,6 +856,7 @@ struct extra_kernel_map {
u64 start;
u64 end;
u64 pgoff;
+   char name[KMAP_NAME_LEN];
 };
 
 static int machine__create_extra_kernel_map(struct machine *machine,
@@ -875,11 +876,12 @@ static int machine__create_extra_kernel_map(struct 
machine *machine,
kmap = map__kmap(map);
 
kmap->kmaps = >kmaps;
+   strlcpy(kmap->name, xm->name, KMAP_NAME_LEN);
 
map_groups__insert(>kmaps, map);
 
-   pr_debug2("Added extra kernel map %" PRIx64 "-%" PRIx64 "\n",
- map->start, map->end);
+   pr_debug2("Added extra kernel map %s %" PRIx64 "-%" PRIx64 "\n",
+ kmap->name, map->start, map->end);
 
map__put(map);
 
@@ -940,6 +942,8 @@ int machine__map_x86_64_entry_trampolines(struct machine 
*machine,
.pgoff = pgoff,
};
 
+   strlcpy(xm.name, ENTRY_TRAMPOLINE_NAME, KMAP_NAME_LEN);
+
if (machine__create_extra_kernel_map(machine, kernel, ) < 0)
return -1;
}
diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index c8fe836e4c3c..6ae97eda370b 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -252,6 +252,13 @@ bool __map__is_kernel(const struct map *map)
return machine__kernel_map(map->groups->machine) == map;
 }
 
+bool __map__is_extra_kernel_map(const struct map *map)
+{
+   struct kmap *kmap = __map__kmap((struct map *)map);
+
+   return kmap && kmap->name[0];
+}
+
 bool map__has_symbols(const struct map *map)
 {
return dso__has_symbols(map->dso);
@@ -846,15 +853,22 @@ struct map *map__next(struct map *map)
return NULL;
 }
 
-struct kmap *map__kmap(struct map *map)
+struct kmap *__map__kmap(struct map *map)
 {
-   if (!map->dso || !map->dso->kernel) {
-   pr_err("Internal error: map__kmap with a non-kernel map\n");
+   if (!map->dso || !map->dso->kernel)
return NULL;
-   }
return (struct kmap *)(map + 1);
 }
 
+struct kmap *map__kmap(struct map *map)
+{
+   struct kmap *kmap = __map__kmap(map);
+
+   if (!kmap)
+   pr_err("Internal error: map__kmap with a non-kernel map\n");
+   return kmap;
+}
+
 struct map_groups *map__kmaps(struct map *map)
 {
struct kmap *kmap = map__kmap(map);
diff --git a/tools/perf/util/map.h b/tools/perf/util/map.h
index fafcc375ed37..97e2a063bd65 100644
--- a/tools/perf/util/map.h
+++ b/tools/perf/util/map.h
@@ -47,9 +47,12 @@ struct map {
refcount_t  refcnt;
 };
 
+#define KMAP_NAME_LEN 256
+
 struct kmap {
struct ref_reloc_sym*ref_reloc_sym;
struct map_groups   *kmaps;
+   charname[KMAP_NAME_LEN];
 };
 
 struct maps {
@@ -76,6 +79,7 @@ static inline struct map_groups *map_groups__get(struct 
map_groups *mg)
 
 void map_groups__put(struct map_groups *mg);
 
+struct kmap 

[tip:perf/core] perf annotate: Show group event string for stdio

[tip-bot for Jin Yao]

Commit-ID:  787e4da9f95fd44376b3af6fa163ac0b3a48a1fc
Gitweb: https://git.kernel.org/tip/787e4da9f95fd44376b3af6fa163ac0b3a48a1fc
Author: Jin Yao 
AuthorDate: Tue, 22 May 2018 19:38:35 +0800
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 23 May 2018 10:26:40 -0300

perf annotate: Show group event string for stdio

When we enable the group, for tui/stdio2, the output first line includes
the group event string. While for stdio, it will show only one event.

For example,

perf record -e cycles,branches ./div
perf annotate --group --stdio

Percent |  Source code & Disassembly of div for cycles (44407 samples)
..

The first line doesn't include the event 'branches'.

With this patch, it will show the correct group even string.

perf annotate --group --stdio

Percent |  Source code & Disassembly of div for cycles, branches (44407 
samples)
..

Signed-off-by: Jin Yao 
Suggested-by: Arnaldo Carvalho de Melo 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Jiri Olsa 
Cc: Kan Liang 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1526989115-14435-1-git-send-email-yao@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/annotate.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 6612c7f90af4..71897689dacf 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -1965,6 +1965,7 @@ int symbol__annotate_printf(struct symbol *sym, struct 
map *map,
u64 len;
int width = symbol_conf.show_total_period ? 12 : 8;
int graph_dotted_len;
+   char buf[512];
 
filename = strdup(dso->long_name);
if (!filename)
@@ -1977,8 +1978,11 @@ int symbol__annotate_printf(struct symbol *sym, struct 
map *map,
 
len = symbol__size(sym);
 
-   if (perf_evsel__is_group_event(evsel))
+   if (perf_evsel__is_group_event(evsel)) {
width *= evsel->nr_members;
+   perf_evsel__group_desc(evsel, buf, sizeof(buf));
+   evsel_name = buf;
+   }
 
graph_dotted_len = printf(" %-*.*s| Source code & Disassembly of %s 
for %s (%" PRIu64 " samples)\n",
  width, width, symbol_conf.show_total_period ? 
"Period" :

[tip:perf/core] perf machine: Allow for extra kernel maps

[tip-bot for Adrian Hunter]

Commit-ID:  5759a6820aadd38b2c8c10e93919eae8e31a9f9a
Gitweb: https://git.kernel.org/tip/5759a6820aadd38b2c8c10e93919eae8e31a9f9a
Author: Adrian Hunter 
AuthorDate: Tue, 22 May 2018 13:54:35 +0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 22 May 2018 10:59:22 -0300

perf machine: Allow for extra kernel maps

Identify extra kernel maps by name so that they can be distinguished
from the kernel map and module maps.

Signed-off-by: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Andy Lutomirski 
Cc: Dave Hansen 
Cc: H. Peter Anvin 
Cc: Jiri Olsa 
Cc: Joerg Roedel 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: x...@kernel.org
Link: 
http://lkml.kernel.org/r/1526986485-6562-8-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/event.c   |  2 +-
 tools/perf/util/machine.c |  8 ++--
 tools/perf/util/map.c | 22 ++
 tools/perf/util/map.h |  7 ++-
 tools/perf/util/symbol.c  |  7 +++
 5 files changed, 34 insertions(+), 12 deletions(-)

diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index 244135b5ea43..aafa9878465f 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -487,7 +487,7 @@ int perf_event__synthesize_modules(struct perf_tool *tool,
for (pos = maps__first(maps); pos; pos = map__next(pos)) {
size_t size;
 
-   if (__map__is_kernel(pos))
+   if (!__map__is_kmodule(pos))
continue;
 
size = PERF_ALIGN(pos->dso->long_name_len + 1, sizeof(u64));
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index db695603873b..355d23bcd443 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -856,6 +856,7 @@ struct extra_kernel_map {
u64 start;
u64 end;
u64 pgoff;
+   char name[KMAP_NAME_LEN];
 };
 
 static int machine__create_extra_kernel_map(struct machine *machine,
@@ -875,11 +876,12 @@ static int machine__create_extra_kernel_map(struct 
machine *machine,
kmap = map__kmap(map);
 
kmap->kmaps = >kmaps;
+   strlcpy(kmap->name, xm->name, KMAP_NAME_LEN);
 
map_groups__insert(>kmaps, map);
 
-   pr_debug2("Added extra kernel map %" PRIx64 "-%" PRIx64 "\n",
- map->start, map->end);
+   pr_debug2("Added extra kernel map %s %" PRIx64 "-%" PRIx64 "\n",
+ kmap->name, map->start, map->end);
 
map__put(map);
 
@@ -940,6 +942,8 @@ int machine__map_x86_64_entry_trampolines(struct machine 
*machine,
.pgoff = pgoff,
};
 
+   strlcpy(xm.name, ENTRY_TRAMPOLINE_NAME, KMAP_NAME_LEN);
+
if (machine__create_extra_kernel_map(machine, kernel, ) < 0)
return -1;
}
diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index c8fe836e4c3c..6ae97eda370b 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -252,6 +252,13 @@ bool __map__is_kernel(const struct map *map)
return machine__kernel_map(map->groups->machine) == map;
 }
 
+bool __map__is_extra_kernel_map(const struct map *map)
+{
+   struct kmap *kmap = __map__kmap((struct map *)map);
+
+   return kmap && kmap->name[0];
+}
+
 bool map__has_symbols(const struct map *map)
 {
return dso__has_symbols(map->dso);
@@ -846,15 +853,22 @@ struct map *map__next(struct map *map)
return NULL;
 }
 
-struct kmap *map__kmap(struct map *map)
+struct kmap *__map__kmap(struct map *map)
 {
-   if (!map->dso || !map->dso->kernel) {
-   pr_err("Internal error: map__kmap with a non-kernel map\n");
+   if (!map->dso || !map->dso->kernel)
return NULL;
-   }
return (struct kmap *)(map + 1);
 }
 
+struct kmap *map__kmap(struct map *map)
+{
+   struct kmap *kmap = __map__kmap(map);
+
+   if (!kmap)
+   pr_err("Internal error: map__kmap with a non-kernel map\n");
+   return kmap;
+}
+
 struct map_groups *map__kmaps(struct map *map)
 {
struct kmap *kmap = map__kmap(map);
diff --git a/tools/perf/util/map.h b/tools/perf/util/map.h
index fafcc375ed37..97e2a063bd65 100644
--- a/tools/perf/util/map.h
+++ b/tools/perf/util/map.h
@@ -47,9 +47,12 @@ struct map {
refcount_t  refcnt;
 };
 
+#define KMAP_NAME_LEN 256
+
 struct kmap {
struct ref_reloc_sym*ref_reloc_sym;
struct map_groups   *kmaps;
+   charname[KMAP_NAME_LEN];
 };
 
 struct maps {
@@ -76,6 +79,7 @@ static inline struct map_groups *map_groups__get(struct 
map_groups *mg)
 
 void map_groups__put(struct map_groups *mg);
 
+struct kmap *__map__kmap(struct map *map);
 struct kmap *map__kmap(struct map *map);
 struct map_groups *map__kmaps(struct map *map);
 
@@ -232,10 +236,11 @@ int map_groups__fixup_overlappings(struct map_groups *mg, 
struct map *map,
 struct map *map_groups__find_by_name(struct map_groups 

[tip:perf/core] perf annotate: Show group event string for stdio

[tip-bot for Jin Yao]

Commit-ID:  787e4da9f95fd44376b3af6fa163ac0b3a48a1fc
Gitweb: https://git.kernel.org/tip/787e4da9f95fd44376b3af6fa163ac0b3a48a1fc
Author: Jin Yao 
AuthorDate: Tue, 22 May 2018 19:38:35 +0800
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 23 May 2018 10:26:40 -0300

perf annotate: Show group event string for stdio

When we enable the group, for tui/stdio2, the output first line includes
the group event string. While for stdio, it will show only one event.

For example,

perf record -e cycles,branches ./div
perf annotate --group --stdio

Percent |  Source code & Disassembly of div for cycles (44407 samples)
..

The first line doesn't include the event 'branches'.

With this patch, it will show the correct group even string.

perf annotate --group --stdio

Percent |  Source code & Disassembly of div for cycles, branches (44407 
samples)
..

Signed-off-by: Jin Yao 
Suggested-by: Arnaldo Carvalho de Melo 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Jiri Olsa 
Cc: Kan Liang 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1526989115-14435-1-git-send-email-yao@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/annotate.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 6612c7f90af4..71897689dacf 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -1965,6 +1965,7 @@ int symbol__annotate_printf(struct symbol *sym, struct 
map *map,
u64 len;
int width = symbol_conf.show_total_period ? 12 : 8;
int graph_dotted_len;
+   char buf[512];
 
filename = strdup(dso->long_name);
if (!filename)
@@ -1977,8 +1978,11 @@ int symbol__annotate_printf(struct symbol *sym, struct 
map *map,
 
len = symbol__size(sym);
 
-   if (perf_evsel__is_group_event(evsel))
+   if (perf_evsel__is_group_event(evsel)) {
width *= evsel->nr_members;
+   perf_evsel__group_desc(evsel, buf, sizeof(buf));
+   evsel_name = buf;
+   }
 
graph_dotted_len = printf(" %-*.*s| Source code & Disassembly of %s 
for %s (%" PRIu64 " samples)\n",
  width, width, symbol_conf.show_total_period ? 
"Period" :

[tip:perf/core] perf machine: Create maps for x86 PTI entry trampolines

[tip-bot for Adrian Hunter]

Commit-ID:  1c5aae7710bb9ecf82a5cc88e35a028a8b385763
Gitweb: https://git.kernel.org/tip/1c5aae7710bb9ecf82a5cc88e35a028a8b385763
Author: Adrian Hunter 
AuthorDate: Tue, 22 May 2018 13:54:36 +0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 23 May 2018 10:24:08 -0300

perf machine: Create maps for x86 PTI entry trampolines

Create maps for x86 PTI entry trampolines, based on symbols found in
kallsyms. It is also necessary to keep track of whether the trampolines
have been mapped particularly when the kernel dso is kcore.

Signed-off-by: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Andy Lutomirski 
Cc: Dave Hansen 
Cc: H. Peter Anvin 
Cc: Jiri Olsa 
Cc: Joerg Roedel 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: x...@kernel.org
Link: 
http://lkml.kernel.org/r/1526986485-6562-9-git-send-email-adrian.hun...@intel.com
[ Fix extra_kernel_map_info.cnt designed struct initializer on gcc 4.4.7 
(centos:6, etc) ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/arch/x86/util/Build |   1 +
 tools/perf/arch/x86/util/machine.c | 103 +
 tools/perf/util/machine.c  |  66 +---
 tools/perf/util/machine.h  |  19 +++
 tools/perf/util/symbol.c   |  17 ++
 5 files changed, 187 insertions(+), 19 deletions(-)

diff --git a/tools/perf/arch/x86/util/Build b/tools/perf/arch/x86/util/Build
index f95e6f46ef0d..aa1ce5f6cc00 100644
--- a/tools/perf/arch/x86/util/Build
+++ b/tools/perf/arch/x86/util/Build
@@ -4,6 +4,7 @@ libperf-y += pmu.o
 libperf-y += kvm-stat.o
 libperf-y += perf_regs.o
 libperf-y += group.o
+libperf-y += machine.o
 
 libperf-$(CONFIG_DWARF) += dwarf-regs.o
 libperf-$(CONFIG_BPF_PROLOGUE) += dwarf-regs.o
diff --git a/tools/perf/arch/x86/util/machine.c 
b/tools/perf/arch/x86/util/machine.c
new file mode 100644
index ..4520ac53caa9
--- /dev/null
+++ b/tools/perf/arch/x86/util/machine.c
@@ -0,0 +1,103 @@
+// SPDX-License-Identifier: GPL-2.0
+#include 
+#include 
+#include 
+
+#include "../../util/machine.h"
+#include "../../util/map.h"
+#include "../../util/symbol.h"
+#include "../../util/sane_ctype.h"
+
+#include 
+
+#if defined(__x86_64__)
+
+struct extra_kernel_map_info {
+   int cnt;
+   int max_cnt;
+   struct extra_kernel_map *maps;
+   bool get_entry_trampolines;
+   u64 entry_trampoline;
+};
+
+static int add_extra_kernel_map(struct extra_kernel_map_info *mi, u64 start,
+   u64 end, u64 pgoff, const char *name)
+{
+   if (mi->cnt >= mi->max_cnt) {
+   void *buf;
+   size_t sz;
+
+   mi->max_cnt = mi->max_cnt ? mi->max_cnt * 2 : 32;
+   sz = sizeof(struct extra_kernel_map) * mi->max_cnt;
+   buf = realloc(mi->maps, sz);
+   if (!buf)
+   return -1;
+   mi->maps = buf;
+   }
+
+   mi->maps[mi->cnt].start = start;
+   mi->maps[mi->cnt].end   = end;
+   mi->maps[mi->cnt].pgoff = pgoff;
+   strlcpy(mi->maps[mi->cnt].name, name, KMAP_NAME_LEN);
+
+   mi->cnt += 1;
+
+   return 0;
+}
+
+static int find_extra_kernel_maps(void *arg, const char *name, char type,
+ u64 start)
+{
+   struct extra_kernel_map_info *mi = arg;
+
+   if (!mi->entry_trampoline && kallsyms2elf_binding(type) == STB_GLOBAL &&
+   !strcmp(name, "_entry_trampoline")) {
+   mi->entry_trampoline = start;
+   return 0;
+   }
+
+   if (is_entry_trampoline(name)) {
+   u64 end = start + page_size;
+
+   return add_extra_kernel_map(mi, start, end, 0, name);
+   }
+
+   return 0;
+}
+
+int machine__create_extra_kernel_maps(struct machine *machine,
+ struct dso *kernel)
+{
+   struct extra_kernel_map_info mi = { .cnt = 0, };
+   char filename[PATH_MAX];
+   int ret;
+   int i;
+
+   machine__get_kallsyms_filename(machine, filename, PATH_MAX);
+
+   if (symbol__restricted_filename(filename, "/proc/kallsyms"))
+   return 0;
+
+   ret = kallsyms__parse(filename, , find_extra_kernel_maps);
+   if (ret)
+   goto out_free;
+
+   if (!mi.entry_trampoline)
+   goto out_free;
+
+   for (i = 0; i < mi.cnt; i++) {
+   struct extra_kernel_map *xm = [i];
+
+   xm->pgoff = mi.entry_trampoline;
+   ret = machine__create_extra_kernel_map(machine, kernel, xm);
+   if (ret)
+   goto out_free;
+   }
+
+   machine->trampolines_mapped = mi.cnt;
+out_free:
+   free(mi.maps);
+   

[tip:perf/core] perf machine: Create maps for x86 PTI entry trampolines

[tip-bot for Adrian Hunter]

Commit-ID:  1c5aae7710bb9ecf82a5cc88e35a028a8b385763
Gitweb: https://git.kernel.org/tip/1c5aae7710bb9ecf82a5cc88e35a028a8b385763
Author: Adrian Hunter 
AuthorDate: Tue, 22 May 2018 13:54:36 +0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 23 May 2018 10:24:08 -0300

perf machine: Create maps for x86 PTI entry trampolines

Create maps for x86 PTI entry trampolines, based on symbols found in
kallsyms. It is also necessary to keep track of whether the trampolines
have been mapped particularly when the kernel dso is kcore.

Signed-off-by: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Andy Lutomirski 
Cc: Dave Hansen 
Cc: H. Peter Anvin 
Cc: Jiri Olsa 
Cc: Joerg Roedel 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: x...@kernel.org
Link: 
http://lkml.kernel.org/r/1526986485-6562-9-git-send-email-adrian.hun...@intel.com
[ Fix extra_kernel_map_info.cnt designed struct initializer on gcc 4.4.7 
(centos:6, etc) ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/arch/x86/util/Build |   1 +
 tools/perf/arch/x86/util/machine.c | 103 +
 tools/perf/util/machine.c  |  66 +---
 tools/perf/util/machine.h  |  19 +++
 tools/perf/util/symbol.c   |  17 ++
 5 files changed, 187 insertions(+), 19 deletions(-)

diff --git a/tools/perf/arch/x86/util/Build b/tools/perf/arch/x86/util/Build
index f95e6f46ef0d..aa1ce5f6cc00 100644
--- a/tools/perf/arch/x86/util/Build
+++ b/tools/perf/arch/x86/util/Build
@@ -4,6 +4,7 @@ libperf-y += pmu.o
 libperf-y += kvm-stat.o
 libperf-y += perf_regs.o
 libperf-y += group.o
+libperf-y += machine.o
 
 libperf-$(CONFIG_DWARF) += dwarf-regs.o
 libperf-$(CONFIG_BPF_PROLOGUE) += dwarf-regs.o
diff --git a/tools/perf/arch/x86/util/machine.c 
b/tools/perf/arch/x86/util/machine.c
new file mode 100644
index ..4520ac53caa9
--- /dev/null
+++ b/tools/perf/arch/x86/util/machine.c
@@ -0,0 +1,103 @@
+// SPDX-License-Identifier: GPL-2.0
+#include 
+#include 
+#include 
+
+#include "../../util/machine.h"
+#include "../../util/map.h"
+#include "../../util/symbol.h"
+#include "../../util/sane_ctype.h"
+
+#include 
+
+#if defined(__x86_64__)
+
+struct extra_kernel_map_info {
+   int cnt;
+   int max_cnt;
+   struct extra_kernel_map *maps;
+   bool get_entry_trampolines;
+   u64 entry_trampoline;
+};
+
+static int add_extra_kernel_map(struct extra_kernel_map_info *mi, u64 start,
+   u64 end, u64 pgoff, const char *name)
+{
+   if (mi->cnt >= mi->max_cnt) {
+   void *buf;
+   size_t sz;
+
+   mi->max_cnt = mi->max_cnt ? mi->max_cnt * 2 : 32;
+   sz = sizeof(struct extra_kernel_map) * mi->max_cnt;
+   buf = realloc(mi->maps, sz);
+   if (!buf)
+   return -1;
+   mi->maps = buf;
+   }
+
+   mi->maps[mi->cnt].start = start;
+   mi->maps[mi->cnt].end   = end;
+   mi->maps[mi->cnt].pgoff = pgoff;
+   strlcpy(mi->maps[mi->cnt].name, name, KMAP_NAME_LEN);
+
+   mi->cnt += 1;
+
+   return 0;
+}
+
+static int find_extra_kernel_maps(void *arg, const char *name, char type,
+ u64 start)
+{
+   struct extra_kernel_map_info *mi = arg;
+
+   if (!mi->entry_trampoline && kallsyms2elf_binding(type) == STB_GLOBAL &&
+   !strcmp(name, "_entry_trampoline")) {
+   mi->entry_trampoline = start;
+   return 0;
+   }
+
+   if (is_entry_trampoline(name)) {
+   u64 end = start + page_size;
+
+   return add_extra_kernel_map(mi, start, end, 0, name);
+   }
+
+   return 0;
+}
+
+int machine__create_extra_kernel_maps(struct machine *machine,
+ struct dso *kernel)
+{
+   struct extra_kernel_map_info mi = { .cnt = 0, };
+   char filename[PATH_MAX];
+   int ret;
+   int i;
+
+   machine__get_kallsyms_filename(machine, filename, PATH_MAX);
+
+   if (symbol__restricted_filename(filename, "/proc/kallsyms"))
+   return 0;
+
+   ret = kallsyms__parse(filename, , find_extra_kernel_maps);
+   if (ret)
+   goto out_free;
+
+   if (!mi.entry_trampoline)
+   goto out_free;
+
+   for (i = 0; i < mi.cnt; i++) {
+   struct extra_kernel_map *xm = [i];
+
+   xm->pgoff = mi.entry_trampoline;
+   ret = machine__create_extra_kernel_map(machine, kernel, xm);
+   if (ret)
+   goto out_free;
+   }
+
+   machine->trampolines_mapped = mi.cnt;
+out_free:
+   free(mi.maps);
+   return ret;
+}
+
+#endif
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index 355d23bcd443..dd7ab0731167 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -807,8 +807,8 @@ struct process_args {
u64 start;
 };
 
-static void 

[tip:perf/core] perf machine: Synthesize and process mmap events for x86 PTI entry trampolines

[tip-bot for Adrian Hunter]

Commit-ID:  a8ce99b0ee9ad32debad0a9f28d21451ba237cc1
Gitweb: https://git.kernel.org/tip/a8ce99b0ee9ad32debad0a9f28d21451ba237cc1
Author: Adrian Hunter 
AuthorDate: Tue, 22 May 2018 13:54:37 +0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 23 May 2018 10:26:39 -0300

perf machine: Synthesize and process mmap events for x86 PTI entry trampolines

Like the kernel text, the location of x86 PTI entry trampolines must be
recorded in the perf.data file. Like the kernel, synthesize a mmap event
for that, and add processing for it.

Signed-off-by: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Andy Lutomirski 
Cc: Dave Hansen 
Cc: H. Peter Anvin 
Cc: Jiri Olsa 
Cc: Joerg Roedel 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: x...@kernel.org
Link: 
http://lkml.kernel.org/r/1526986485-6562-10-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/arch/x86/util/Build   |  1 +
 tools/perf/arch/x86/util/event.c | 76 
 tools/perf/util/event.c  | 34 ++
 tools/perf/util/event.h  |  8 +
 tools/perf/util/machine.c| 28 +++
 5 files changed, 140 insertions(+), 7 deletions(-)

diff --git a/tools/perf/arch/x86/util/Build b/tools/perf/arch/x86/util/Build
index aa1ce5f6cc00..844b8f335532 100644
--- a/tools/perf/arch/x86/util/Build
+++ b/tools/perf/arch/x86/util/Build
@@ -5,6 +5,7 @@ libperf-y += kvm-stat.o
 libperf-y += perf_regs.o
 libperf-y += group.o
 libperf-y += machine.o
+libperf-y += event.o
 
 libperf-$(CONFIG_DWARF) += dwarf-regs.o
 libperf-$(CONFIG_BPF_PROLOGUE) += dwarf-regs.o
diff --git a/tools/perf/arch/x86/util/event.c b/tools/perf/arch/x86/util/event.c
new file mode 100644
index ..675a0213044d
--- /dev/null
+++ b/tools/perf/arch/x86/util/event.c
@@ -0,0 +1,76 @@
+// SPDX-License-Identifier: GPL-2.0
+#include 
+#include 
+
+#include "../../util/machine.h"
+#include "../../util/tool.h"
+#include "../../util/map.h"
+#include "../../util/util.h"
+#include "../../util/debug.h"
+
+#if defined(__x86_64__)
+
+int perf_event__synthesize_extra_kmaps(struct perf_tool *tool,
+  perf_event__handler_t process,
+  struct machine *machine)
+{
+   int rc = 0;
+   struct map *pos;
+   struct map_groups *kmaps = >kmaps;
+   struct maps *maps = >maps;
+   union perf_event *event = zalloc(sizeof(event->mmap) +
+machine->id_hdr_size);
+
+   if (!event) {
+   pr_debug("Not enough memory synthesizing mmap event "
+"for extra kernel maps\n");
+   return -1;
+   }
+
+   for (pos = maps__first(maps); pos; pos = map__next(pos)) {
+   struct kmap *kmap;
+   size_t size;
+
+   if (!__map__is_extra_kernel_map(pos))
+   continue;
+
+   kmap = map__kmap(pos);
+
+   size = sizeof(event->mmap) - sizeof(event->mmap.filename) +
+  PERF_ALIGN(strlen(kmap->name) + 1, sizeof(u64)) +
+  machine->id_hdr_size;
+
+   memset(event, 0, size);
+
+   event->mmap.header.type = PERF_RECORD_MMAP;
+
+   /*
+* kernel uses 0 for user space maps, see kernel/perf_event.c
+* __perf_event_mmap
+*/
+   if (machine__is_host(machine))
+   event->header.misc = PERF_RECORD_MISC_KERNEL;
+   else
+   event->header.misc = PERF_RECORD_MISC_GUEST_KERNEL;
+
+   event->mmap.header.size = size;
+
+   event->mmap.start = pos->start;
+   event->mmap.len   = pos->end - pos->start;
+   event->mmap.pgoff = pos->pgoff;
+   event->mmap.pid   = machine->pid;
+
+   strlcpy(event->mmap.filename, kmap->name, PATH_MAX);
+
+   if (perf_tool__process_synth_event(tool, event, machine,
+  process) != 0) {
+   rc = -1;
+   break;
+   }
+   }
+
+   free(event);
+   return rc;
+}
+
+#endif
diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index aafa9878465f..0c8ecf0c78a4 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -88,10 +88,10 @@ static const char *perf_ns__name(unsigned int id)
return perf_ns__names[id];
 }
 
-static int perf_tool__process_synth_event(struct perf_tool *tool,
- union perf_event *event,
-

[tip:perf/core] perf machine: Synthesize and process mmap events for x86 PTI entry trampolines

[tip-bot for Adrian Hunter]

Commit-ID:  a8ce99b0ee9ad32debad0a9f28d21451ba237cc1
Gitweb: https://git.kernel.org/tip/a8ce99b0ee9ad32debad0a9f28d21451ba237cc1
Author: Adrian Hunter 
AuthorDate: Tue, 22 May 2018 13:54:37 +0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 23 May 2018 10:26:39 -0300

perf machine: Synthesize and process mmap events for x86 PTI entry trampolines

Like the kernel text, the location of x86 PTI entry trampolines must be
recorded in the perf.data file. Like the kernel, synthesize a mmap event
for that, and add processing for it.

Signed-off-by: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Andy Lutomirski 
Cc: Dave Hansen 
Cc: H. Peter Anvin 
Cc: Jiri Olsa 
Cc: Joerg Roedel 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: x...@kernel.org
Link: 
http://lkml.kernel.org/r/1526986485-6562-10-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/arch/x86/util/Build   |  1 +
 tools/perf/arch/x86/util/event.c | 76 
 tools/perf/util/event.c  | 34 ++
 tools/perf/util/event.h  |  8 +
 tools/perf/util/machine.c| 28 +++
 5 files changed, 140 insertions(+), 7 deletions(-)

diff --git a/tools/perf/arch/x86/util/Build b/tools/perf/arch/x86/util/Build
index aa1ce5f6cc00..844b8f335532 100644
--- a/tools/perf/arch/x86/util/Build
+++ b/tools/perf/arch/x86/util/Build
@@ -5,6 +5,7 @@ libperf-y += kvm-stat.o
 libperf-y += perf_regs.o
 libperf-y += group.o
 libperf-y += machine.o
+libperf-y += event.o
 
 libperf-$(CONFIG_DWARF) += dwarf-regs.o
 libperf-$(CONFIG_BPF_PROLOGUE) += dwarf-regs.o
diff --git a/tools/perf/arch/x86/util/event.c b/tools/perf/arch/x86/util/event.c
new file mode 100644
index ..675a0213044d
--- /dev/null
+++ b/tools/perf/arch/x86/util/event.c
@@ -0,0 +1,76 @@
+// SPDX-License-Identifier: GPL-2.0
+#include 
+#include 
+
+#include "../../util/machine.h"
+#include "../../util/tool.h"
+#include "../../util/map.h"
+#include "../../util/util.h"
+#include "../../util/debug.h"
+
+#if defined(__x86_64__)
+
+int perf_event__synthesize_extra_kmaps(struct perf_tool *tool,
+  perf_event__handler_t process,
+  struct machine *machine)
+{
+   int rc = 0;
+   struct map *pos;
+   struct map_groups *kmaps = >kmaps;
+   struct maps *maps = >maps;
+   union perf_event *event = zalloc(sizeof(event->mmap) +
+machine->id_hdr_size);
+
+   if (!event) {
+   pr_debug("Not enough memory synthesizing mmap event "
+"for extra kernel maps\n");
+   return -1;
+   }
+
+   for (pos = maps__first(maps); pos; pos = map__next(pos)) {
+   struct kmap *kmap;
+   size_t size;
+
+   if (!__map__is_extra_kernel_map(pos))
+   continue;
+
+   kmap = map__kmap(pos);
+
+   size = sizeof(event->mmap) - sizeof(event->mmap.filename) +
+  PERF_ALIGN(strlen(kmap->name) + 1, sizeof(u64)) +
+  machine->id_hdr_size;
+
+   memset(event, 0, size);
+
+   event->mmap.header.type = PERF_RECORD_MMAP;
+
+   /*
+* kernel uses 0 for user space maps, see kernel/perf_event.c
+* __perf_event_mmap
+*/
+   if (machine__is_host(machine))
+   event->header.misc = PERF_RECORD_MISC_KERNEL;
+   else
+   event->header.misc = PERF_RECORD_MISC_GUEST_KERNEL;
+
+   event->mmap.header.size = size;
+
+   event->mmap.start = pos->start;
+   event->mmap.len   = pos->end - pos->start;
+   event->mmap.pgoff = pos->pgoff;
+   event->mmap.pid   = machine->pid;
+
+   strlcpy(event->mmap.filename, kmap->name, PATH_MAX);
+
+   if (perf_tool__process_synth_event(tool, event, machine,
+  process) != 0) {
+   rc = -1;
+   break;
+   }
+   }
+
+   free(event);
+   return rc;
+}
+
+#endif
diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index aafa9878465f..0c8ecf0c78a4 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -88,10 +88,10 @@ static const char *perf_ns__name(unsigned int id)
return perf_ns__names[id];
 }
 
-static int perf_tool__process_synth_event(struct perf_tool *tool,
- union perf_event *event,
- struct machine *machine,
- perf_event__handler_t process)
+int perf_tool__process_synth_event(struct perf_tool *tool,
+  union perf_event *event,
+  struct 

[tip:perf/core] perf machine: Fix map_groups__split_kallsyms() for entry trampoline symbols

[tip-bot for Adrian Hunter]

Commit-ID:  4d004365e25251002935fc3843d80934248ad3ed
Gitweb: https://git.kernel.org/tip/4d004365e25251002935fc3843d80934248ad3ed
Author: Adrian Hunter 
AuthorDate: Tue, 22 May 2018 13:54:34 +0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 22 May 2018 10:55:59 -0300

perf machine: Fix map_groups__split_kallsyms() for entry trampoline symbols

When kernel symbols are derived from /proc/kallsyms only (not using
vmlinux or /proc/kcore) map_groups__split_kallsyms() is used. However
that function makes assumptions that are not true with entry trampoline
symbols. For now, remove the entry trampoline symbols at that point, as
they are no longer needed at that point.

Signed-off-by: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Andy Lutomirski 
Cc: Dave Hansen 
Cc: H. Peter Anvin 
Cc: Jiri Olsa 
Cc: Joerg Roedel 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: x...@kernel.org
Link: 
http://lkml.kernel.org/r/1526986485-6562-7-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/map.h|  8 
 tools/perf/util/symbol.c | 13 +
 2 files changed, 21 insertions(+)

diff --git a/tools/perf/util/map.h b/tools/perf/util/map.h
index f1afe1ab6ff7..fafcc375ed37 100644
--- a/tools/perf/util/map.h
+++ b/tools/perf/util/map.h
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "rwsem.h"
@@ -239,4 +240,11 @@ static inline bool __map__is_kmodule(const struct map *map)
 
 bool map__has_symbols(const struct map *map);
 
+#define ENTRY_TRAMPOLINE_NAME "__entry_SYSCALL_64_trampoline"
+
+static inline bool is_entry_trampoline(const char *name)
+{
+   return !strcmp(name, ENTRY_TRAMPOLINE_NAME);
+}
+
 #endif /* __PERF_MAP_H */
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 701144094183..929058da6727 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -737,12 +737,15 @@ static int map_groups__split_kallsyms(struct map_groups 
*kmaps, struct dso *dso,
struct rb_root *root = >symbols;
struct rb_node *next = rb_first(root);
int kernel_range = 0;
+   bool x86_64;
 
if (!kmaps)
return -1;
 
machine = kmaps->machine;
 
+   x86_64 = machine__is(machine, "x86_64");
+
while (next) {
char *module;
 
@@ -790,6 +793,16 @@ static int map_groups__split_kallsyms(struct map_groups 
*kmaps, struct dso *dso,
 */
pos->start = curr_map->map_ip(curr_map, pos->start);
pos->end   = curr_map->map_ip(curr_map, pos->end);
+   } else if (x86_64 && is_entry_trampoline(pos->name)) {
+   /*
+* These symbols are not needed anymore since the
+* trampoline maps refer to the text section and it's
+* symbols instead. Avoid having to deal with
+* relocations, and the assumption that the first symbol
+* is the start of kernel text, by simply removing the
+* symbols at this point.
+*/
+   goto discard_symbol;
} else if (curr_map != initial_map) {
char dso_name[PATH_MAX];
struct dso *ndso;

[tip:perf/core] perf machine: Fix map_groups__split_kallsyms() for entry trampoline symbols

[tip-bot for Adrian Hunter]

Commit-ID:  4d004365e25251002935fc3843d80934248ad3ed
Gitweb: https://git.kernel.org/tip/4d004365e25251002935fc3843d80934248ad3ed
Author: Adrian Hunter 
AuthorDate: Tue, 22 May 2018 13:54:34 +0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 22 May 2018 10:55:59 -0300

perf machine: Fix map_groups__split_kallsyms() for entry trampoline symbols

When kernel symbols are derived from /proc/kallsyms only (not using
vmlinux or /proc/kcore) map_groups__split_kallsyms() is used. However
that function makes assumptions that are not true with entry trampoline
symbols. For now, remove the entry trampoline symbols at that point, as
they are no longer needed at that point.

Signed-off-by: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Andy Lutomirski 
Cc: Dave Hansen 
Cc: H. Peter Anvin 
Cc: Jiri Olsa 
Cc: Joerg Roedel 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: x...@kernel.org
Link: 
http://lkml.kernel.org/r/1526986485-6562-7-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/map.h|  8 
 tools/perf/util/symbol.c | 13 +
 2 files changed, 21 insertions(+)

diff --git a/tools/perf/util/map.h b/tools/perf/util/map.h
index f1afe1ab6ff7..fafcc375ed37 100644
--- a/tools/perf/util/map.h
+++ b/tools/perf/util/map.h
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "rwsem.h"
@@ -239,4 +240,11 @@ static inline bool __map__is_kmodule(const struct map *map)
 
 bool map__has_symbols(const struct map *map);
 
+#define ENTRY_TRAMPOLINE_NAME "__entry_SYSCALL_64_trampoline"
+
+static inline bool is_entry_trampoline(const char *name)
+{
+   return !strcmp(name, ENTRY_TRAMPOLINE_NAME);
+}
+
 #endif /* __PERF_MAP_H */
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 701144094183..929058da6727 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -737,12 +737,15 @@ static int map_groups__split_kallsyms(struct map_groups 
*kmaps, struct dso *dso,
struct rb_root *root = >symbols;
struct rb_node *next = rb_first(root);
int kernel_range = 0;
+   bool x86_64;
 
if (!kmaps)
return -1;
 
machine = kmaps->machine;
 
+   x86_64 = machine__is(machine, "x86_64");
+
while (next) {
char *module;
 
@@ -790,6 +793,16 @@ static int map_groups__split_kallsyms(struct map_groups 
*kmaps, struct dso *dso,
 */
pos->start = curr_map->map_ip(curr_map, pos->start);
pos->end   = curr_map->map_ip(curr_map, pos->end);
+   } else if (x86_64 && is_entry_trampoline(pos->name)) {
+   /*
+* These symbols are not needed anymore since the
+* trampoline maps refer to the text section and it's
+* symbols instead. Avoid having to deal with
+* relocations, and the assumption that the first symbol
+* is the start of kernel text, by simply removing the
+* symbols at this point.
+*/
+   goto discard_symbol;
} else if (curr_map != initial_map) {
char dso_name[PATH_MAX];
struct dso *ndso;

[tip:perf/core] perf annotate: Support '--group' option

[tip-bot for Jin Yao]

Commit-ID:  7ebaf4890f63eb90856b76864a0847413cdf6c86
Gitweb: https://git.kernel.org/tip/7ebaf4890f63eb90856b76864a0847413cdf6c86
Author: Jin Yao 
AuthorDate: Mon, 21 May 2018 22:57:46 +0800
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 21 May 2018 14:41:25 -0300

perf annotate: Support '--group' option

With the '--group' option, even for non-explicit group, 'perf annotate'
will enable the group output.

For example,

  $ perf record -e cycles,branches ./div
  $ perf annotate main --stdio --group

 :Disassembly of section .text:
 :
 :004004b0 :
 :main():
 :
 :return i;
 :}
 :
 :int main(void)
 :{
0.000.00 :   4004b0:   push   %rbx
 :int i;
 :int flag;
 :volatile double x = 1212121212, y = 
121212;
 :
 :s_randseed = time(0);
0.000.00 :   4004b1:   xor%edi,%edi
 :srand(s_randseed);
0.000.00 :   4004b3:   mov$0x77359400,%ebx
 :
 :return i;
 :}
 :

But if without --group, there is only one event reported.

  $ perf annotate main --stdio

 :Disassembly of section .text:
 :
 :004004b0 :
 :main():
 :
 :return i;
 :}
 :
 :int main(void)
 :{
0.00 :   4004b0:   push   %rbx
 :int i;
 :int flag;
 :volatile double x = 1212121212, y = 121212;
 :
 :s_randseed = time(0);
0.00 :   4004b1:   xor%edi,%edi
 :srand(s_randseed);
0.00 :   4004b3:   mov$0x77359400,%ebx
 :
 :return i;
 :}

Signed-off-by: Jin Yao 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Jiri Olsa 
Cc: Kan Liang 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1526914666-31839-4-git-send-email-yao@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-annotate.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index 6e5d9f718154..da5704240239 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -45,6 +45,7 @@ struct perf_annotate {
bool   print_line;
bool   skip_missing;
bool   has_br_stack;
+   bool   group_set;
const char *sym_hist_filter;
const char *cpu_list;
DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
@@ -508,6 +509,9 @@ int cmd_annotate(int argc, const char **argv)
"Don't shorten the displayed pathnames"),
OPT_BOOLEAN(0, "skip-missing", _missing,
"Skip symbols that cannot be annotated"),
+   OPT_BOOLEAN_SET(0, "group", _conf.event_group,
+   _set,
+   "Show event group information together"),
OPT_STRING('C', "cpu", _list, "cpu", "list of cpus to 
profile"),
OPT_CALLBACK(0, "symfs", NULL, "directory",
 "Look for files with symbols relative to this directory",
@@ -570,6 +574,9 @@ int cmd_annotate(int argc, const char **argv)
annotate.has_br_stack = perf_header__has_feat(>header,
  HEADER_BRANCH_STACK);
 
+   if (annotate.group_set)
+   perf_evlist__force_leader(annotate.session->evlist);
+
ret = symbol__annotation_init();
if (ret < 0)
goto out_delete;

[tip:perf/core] perf annotate: Support '--group' option

[tip-bot for Jin Yao]

Commit-ID:  7ebaf4890f63eb90856b76864a0847413cdf6c86
Gitweb: https://git.kernel.org/tip/7ebaf4890f63eb90856b76864a0847413cdf6c86
Author: Jin Yao 
AuthorDate: Mon, 21 May 2018 22:57:46 +0800
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 21 May 2018 14:41:25 -0300

perf annotate: Support '--group' option

With the '--group' option, even for non-explicit group, 'perf annotate'
will enable the group output.

For example,

  $ perf record -e cycles,branches ./div
  $ perf annotate main --stdio --group

 :Disassembly of section .text:
 :
 :004004b0 :
 :main():
 :
 :return i;
 :}
 :
 :int main(void)
 :{
0.000.00 :   4004b0:   push   %rbx
 :int i;
 :int flag;
 :volatile double x = 1212121212, y = 
121212;
 :
 :s_randseed = time(0);
0.000.00 :   4004b1:   xor%edi,%edi
 :srand(s_randseed);
0.000.00 :   4004b3:   mov$0x77359400,%ebx
 :
 :return i;
 :}
 :

But if without --group, there is only one event reported.

  $ perf annotate main --stdio

 :Disassembly of section .text:
 :
 :004004b0 :
 :main():
 :
 :return i;
 :}
 :
 :int main(void)
 :{
0.00 :   4004b0:   push   %rbx
 :int i;
 :int flag;
 :volatile double x = 1212121212, y = 121212;
 :
 :s_randseed = time(0);
0.00 :   4004b1:   xor%edi,%edi
 :srand(s_randseed);
0.00 :   4004b3:   mov$0x77359400,%ebx
 :
 :return i;
 :}

Signed-off-by: Jin Yao 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Jiri Olsa 
Cc: Kan Liang 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1526914666-31839-4-git-send-email-yao@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-annotate.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index 6e5d9f718154..da5704240239 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -45,6 +45,7 @@ struct perf_annotate {
bool   print_line;
bool   skip_missing;
bool   has_br_stack;
+   bool   group_set;
const char *sym_hist_filter;
const char *cpu_list;
DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
@@ -508,6 +509,9 @@ int cmd_annotate(int argc, const char **argv)
"Don't shorten the displayed pathnames"),
OPT_BOOLEAN(0, "skip-missing", _missing,
"Skip symbols that cannot be annotated"),
+   OPT_BOOLEAN_SET(0, "group", _conf.event_group,
+   _set,
+   "Show event group information together"),
OPT_STRING('C', "cpu", _list, "cpu", "list of cpus to 
profile"),
OPT_CALLBACK(0, "symfs", NULL, "directory",
 "Look for files with symbols relative to this directory",
@@ -570,6 +574,9 @@ int cmd_annotate(int argc, const char **argv)
annotate.has_br_stack = perf_header__has_feat(>header,
  HEADER_BRANCH_STACK);
 
+   if (annotate.group_set)
+   perf_evlist__force_leader(annotate.session->evlist);
+
ret = symbol__annotation_init();
if (ret < 0)
goto out_delete;

[tip:perf/core] perf machine: Add nr_cpus_avail()

[tip-bot for Adrian Hunter]

Commit-ID:  9cecca325ea879c84fcd31a5e609a514c1a1dbd1
Gitweb: https://git.kernel.org/tip/9cecca325ea879c84fcd31a5e609a514c1a1dbd1
Author: Adrian Hunter 
AuthorDate: Tue, 22 May 2018 13:54:32 +0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 22 May 2018 10:52:49 -0300

perf machine: Add nr_cpus_avail()

Add a function to return the number of the machine's available CPUs.

Signed-off-by: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Andy Lutomirski 
Cc: Dave Hansen 
Cc: H. Peter Anvin 
Cc: Jiri Olsa 
Cc: Joerg Roedel 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: x...@kernel.org
Link: 
http://lkml.kernel.org/r/1526986485-6562-5-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/env.c | 13 +
 tools/perf/util/env.h |  1 +
 tools/perf/util/machine.c |  5 +
 tools/perf/util/machine.h |  1 +
 4 files changed, 20 insertions(+)

diff --git a/tools/perf/util/env.c b/tools/perf/util/env.c
index 319fb0a0d05e..59f38c7693f8 100644
--- a/tools/perf/util/env.c
+++ b/tools/perf/util/env.c
@@ -106,11 +106,24 @@ static int perf_env__read_arch(struct perf_env *env)
return env->arch ? 0 : -ENOMEM;
 }
 
+static int perf_env__read_nr_cpus_avail(struct perf_env *env)
+{
+   if (env->nr_cpus_avail == 0)
+   env->nr_cpus_avail = cpu__max_present_cpu();
+
+   return env->nr_cpus_avail ? 0 : -ENOENT;
+}
+
 const char *perf_env__raw_arch(struct perf_env *env)
 {
return env && !perf_env__read_arch(env) ? env->arch : "unknown";
 }
 
+int perf_env__nr_cpus_avail(struct perf_env *env)
+{
+   return env && !perf_env__read_nr_cpus_avail(env) ? env->nr_cpus_avail : 
0;
+}
+
 void cpu_cache_level__free(struct cpu_cache_level *cache)
 {
free(cache->type);
diff --git a/tools/perf/util/env.h b/tools/perf/util/env.h
index 62e193948608..1f3ccc368530 100644
--- a/tools/perf/util/env.h
+++ b/tools/perf/util/env.h
@@ -77,5 +77,6 @@ void cpu_cache_level__free(struct cpu_cache_level *cache);
 
 const char *perf_env__arch(struct perf_env *env);
 const char *perf_env__raw_arch(struct perf_env *env);
+int perf_env__nr_cpus_avail(struct perf_env *env);
 
 #endif /* __PERF_ENV_H */
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index e011a7160380..f62ecd9c36e8 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -2305,6 +2305,11 @@ bool machine__is(struct machine *machine, const char 
*arch)
return machine && !strcmp(perf_env__raw_arch(machine->env), arch);
 }
 
+int machine__nr_cpus_avail(struct machine *machine)
+{
+   return machine ? perf_env__nr_cpus_avail(machine->env) : 0;
+}
+
 int machine__get_kernel_start(struct machine *machine)
 {
struct map *map = machine__kernel_map(machine);
diff --git a/tools/perf/util/machine.h b/tools/perf/util/machine.h
index b31d33b5aa2a..2d2b092ba753 100644
--- a/tools/perf/util/machine.h
+++ b/tools/perf/util/machine.h
@@ -189,6 +189,7 @@ static inline bool machine__is_host(struct machine *machine)
 }
 
 bool machine__is(struct machine *machine, const char *arch);
+int machine__nr_cpus_avail(struct machine *machine);
 
 struct thread *__machine__findnew_thread(struct machine *machine, pid_t pid, 
pid_t tid);
 struct thread *machine__findnew_thread(struct machine *machine, pid_t pid, 
pid_t tid);

[tip:perf/core] perf machine: Add nr_cpus_avail()

[tip-bot for Adrian Hunter]

Commit-ID:  9cecca325ea879c84fcd31a5e609a514c1a1dbd1
Gitweb: https://git.kernel.org/tip/9cecca325ea879c84fcd31a5e609a514c1a1dbd1
Author: Adrian Hunter 
AuthorDate: Tue, 22 May 2018 13:54:32 +0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 22 May 2018 10:52:49 -0300

perf machine: Add nr_cpus_avail()

Add a function to return the number of the machine's available CPUs.

Signed-off-by: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Andy Lutomirski 
Cc: Dave Hansen 
Cc: H. Peter Anvin 
Cc: Jiri Olsa 
Cc: Joerg Roedel 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: x...@kernel.org
Link: 
http://lkml.kernel.org/r/1526986485-6562-5-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/env.c | 13 +
 tools/perf/util/env.h |  1 +
 tools/perf/util/machine.c |  5 +
 tools/perf/util/machine.h |  1 +
 4 files changed, 20 insertions(+)

diff --git a/tools/perf/util/env.c b/tools/perf/util/env.c
index 319fb0a0d05e..59f38c7693f8 100644
--- a/tools/perf/util/env.c
+++ b/tools/perf/util/env.c
@@ -106,11 +106,24 @@ static int perf_env__read_arch(struct perf_env *env)
return env->arch ? 0 : -ENOMEM;
 }
 
+static int perf_env__read_nr_cpus_avail(struct perf_env *env)
+{
+   if (env->nr_cpus_avail == 0)
+   env->nr_cpus_avail = cpu__max_present_cpu();
+
+   return env->nr_cpus_avail ? 0 : -ENOENT;
+}
+
 const char *perf_env__raw_arch(struct perf_env *env)
 {
return env && !perf_env__read_arch(env) ? env->arch : "unknown";
 }
 
+int perf_env__nr_cpus_avail(struct perf_env *env)
+{
+   return env && !perf_env__read_nr_cpus_avail(env) ? env->nr_cpus_avail : 
0;
+}
+
 void cpu_cache_level__free(struct cpu_cache_level *cache)
 {
free(cache->type);
diff --git a/tools/perf/util/env.h b/tools/perf/util/env.h
index 62e193948608..1f3ccc368530 100644
--- a/tools/perf/util/env.h
+++ b/tools/perf/util/env.h
@@ -77,5 +77,6 @@ void cpu_cache_level__free(struct cpu_cache_level *cache);
 
 const char *perf_env__arch(struct perf_env *env);
 const char *perf_env__raw_arch(struct perf_env *env);
+int perf_env__nr_cpus_avail(struct perf_env *env);
 
 #endif /* __PERF_ENV_H */
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index e011a7160380..f62ecd9c36e8 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -2305,6 +2305,11 @@ bool machine__is(struct machine *machine, const char 
*arch)
return machine && !strcmp(perf_env__raw_arch(machine->env), arch);
 }
 
+int machine__nr_cpus_avail(struct machine *machine)
+{
+   return machine ? perf_env__nr_cpus_avail(machine->env) : 0;
+}
+
 int machine__get_kernel_start(struct machine *machine)
 {
struct map *map = machine__kernel_map(machine);
diff --git a/tools/perf/util/machine.h b/tools/perf/util/machine.h
index b31d33b5aa2a..2d2b092ba753 100644
--- a/tools/perf/util/machine.h
+++ b/tools/perf/util/machine.h
@@ -189,6 +189,7 @@ static inline bool machine__is_host(struct machine *machine)
 }
 
 bool machine__is(struct machine *machine, const char *arch);
+int machine__nr_cpus_avail(struct machine *machine);
 
 struct thread *__machine__findnew_thread(struct machine *machine, pid_t pid, 
pid_t tid);
 struct thread *machine__findnew_thread(struct machine *machine, pid_t pid, 
pid_t tid);

[tip:perf/core] perf machine: Workaround missing maps for x86 PTI entry trampolines

[tip-bot for Adrian Hunter]

Commit-ID:  4d99e4136580d178e3523281a820be17bf814bf8
Gitweb: https://git.kernel.org/tip/4d99e4136580d178e3523281a820be17bf814bf8
Author: Adrian Hunter 
AuthorDate: Tue, 22 May 2018 13:54:33 +0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 22 May 2018 10:54:22 -0300

perf machine: Workaround missing maps for x86 PTI entry trampolines

On x86_64 the PTI entry trampolines are not in the kernel map created by
perf tools. That results in the addresses having no symbols and prevents
annotation.  It also causes Intel PT to have decoding errors at the
trampoline addresses.

Workaround that by creating maps for the trampolines.

At present the kernel does not export information revealing where the
trampolines are.  Until that happens, the addresses are hardcoded.

Signed-off-by: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Andy Lutomirski 
Cc: Dave Hansen 
Cc: H. Peter Anvin 
Cc: Jiri Olsa 
Cc: Joerg Roedel 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: x...@kernel.org
Link: 
http://lkml.kernel.org/r/1526986485-6562-6-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/machine.c | 96 +++
 tools/perf/util/machine.h |  3 ++
 tools/perf/util/symbol.c  | 12 +++---
 3 files changed, 106 insertions(+), 5 deletions(-)

diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index f62ecd9c36e8..db695603873b 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -851,6 +851,102 @@ static int machine__get_running_kernel_start(struct 
machine *machine,
return 0;
 }
 
+/* Kernel-space maps for symbols that are outside the main kernel map and 
module maps */
+struct extra_kernel_map {
+   u64 start;
+   u64 end;
+   u64 pgoff;
+};
+
+static int machine__create_extra_kernel_map(struct machine *machine,
+   struct dso *kernel,
+   struct extra_kernel_map *xm)
+{
+   struct kmap *kmap;
+   struct map *map;
+
+   map = map__new2(xm->start, kernel);
+   if (!map)
+   return -1;
+
+   map->end   = xm->end;
+   map->pgoff = xm->pgoff;
+
+   kmap = map__kmap(map);
+
+   kmap->kmaps = >kmaps;
+
+   map_groups__insert(>kmaps, map);
+
+   pr_debug2("Added extra kernel map %" PRIx64 "-%" PRIx64 "\n",
+ map->start, map->end);
+
+   map__put(map);
+
+   return 0;
+}
+
+static u64 find_entry_trampoline(struct dso *dso)
+{
+   /* Duplicates are removed so lookup all aliases */
+   const char *syms[] = {
+   "_entry_trampoline",
+   "__entry_trampoline_start",
+   "entry_SYSCALL_64_trampoline",
+   };
+   struct symbol *sym = dso__first_symbol(dso);
+   unsigned int i;
+
+   for (; sym; sym = dso__next_symbol(sym)) {
+   if (sym->binding != STB_GLOBAL)
+   continue;
+   for (i = 0; i < ARRAY_SIZE(syms); i++) {
+   if (!strcmp(sym->name, syms[i]))
+   return sym->start;
+   }
+   }
+
+   return 0;
+}
+
+/*
+ * These values can be used for kernels that do not have symbols for the entry
+ * trampolines in kallsyms.
+ */
+#define X86_64_CPU_ENTRY_AREA_PER_CPU  0xfe00ULL
+#define X86_64_CPU_ENTRY_AREA_SIZE 0x2c000
+#define X86_64_ENTRY_TRAMPOLINE0x6000
+
+/* Map x86_64 PTI entry trampolines */
+int machine__map_x86_64_entry_trampolines(struct machine *machine,
+ struct dso *kernel)
+{
+   u64 pgoff = find_entry_trampoline(kernel);
+   int nr_cpus_avail, cpu;
+
+   if (!pgoff)
+   return 0;
+
+   nr_cpus_avail = machine__nr_cpus_avail(machine);
+
+   /* Add a 1 page map for each CPU's entry trampoline */
+   for (cpu = 0; cpu < nr_cpus_avail; cpu++) {
+   u64 va = X86_64_CPU_ENTRY_AREA_PER_CPU +
+cpu * X86_64_CPU_ENTRY_AREA_SIZE +
+X86_64_ENTRY_TRAMPOLINE;
+   struct extra_kernel_map xm = {
+   .start = va,
+   .end   = va + page_size,
+   .pgoff = pgoff,
+   };
+
+   if (machine__create_extra_kernel_map(machine, kernel, ) < 0)
+   return -1;
+   }
+
+   return 0;
+}
+
 static int
 __machine__create_kernel_maps(struct machine *machine, struct dso *kernel)
 {
diff --git a/tools/perf/util/machine.h b/tools/perf/util/machine.h
index 2d2b092ba753..b6a1c3eb3d65 100644
--- 

[tip:perf/core] perf machine: Workaround missing maps for x86 PTI entry trampolines

[tip-bot for Adrian Hunter]

Commit-ID:  4d99e4136580d178e3523281a820be17bf814bf8
Gitweb: https://git.kernel.org/tip/4d99e4136580d178e3523281a820be17bf814bf8
Author: Adrian Hunter 
AuthorDate: Tue, 22 May 2018 13:54:33 +0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 22 May 2018 10:54:22 -0300

perf machine: Workaround missing maps for x86 PTI entry trampolines

On x86_64 the PTI entry trampolines are not in the kernel map created by
perf tools. That results in the addresses having no symbols and prevents
annotation.  It also causes Intel PT to have decoding errors at the
trampoline addresses.

Workaround that by creating maps for the trampolines.

At present the kernel does not export information revealing where the
trampolines are.  Until that happens, the addresses are hardcoded.

Signed-off-by: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Andy Lutomirski 
Cc: Dave Hansen 
Cc: H. Peter Anvin 
Cc: Jiri Olsa 
Cc: Joerg Roedel 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: x...@kernel.org
Link: 
http://lkml.kernel.org/r/1526986485-6562-6-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/machine.c | 96 +++
 tools/perf/util/machine.h |  3 ++
 tools/perf/util/symbol.c  | 12 +++---
 3 files changed, 106 insertions(+), 5 deletions(-)

diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index f62ecd9c36e8..db695603873b 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -851,6 +851,102 @@ static int machine__get_running_kernel_start(struct 
machine *machine,
return 0;
 }
 
+/* Kernel-space maps for symbols that are outside the main kernel map and 
module maps */
+struct extra_kernel_map {
+   u64 start;
+   u64 end;
+   u64 pgoff;
+};
+
+static int machine__create_extra_kernel_map(struct machine *machine,
+   struct dso *kernel,
+   struct extra_kernel_map *xm)
+{
+   struct kmap *kmap;
+   struct map *map;
+
+   map = map__new2(xm->start, kernel);
+   if (!map)
+   return -1;
+
+   map->end   = xm->end;
+   map->pgoff = xm->pgoff;
+
+   kmap = map__kmap(map);
+
+   kmap->kmaps = >kmaps;
+
+   map_groups__insert(>kmaps, map);
+
+   pr_debug2("Added extra kernel map %" PRIx64 "-%" PRIx64 "\n",
+ map->start, map->end);
+
+   map__put(map);
+
+   return 0;
+}
+
+static u64 find_entry_trampoline(struct dso *dso)
+{
+   /* Duplicates are removed so lookup all aliases */
+   const char *syms[] = {
+   "_entry_trampoline",
+   "__entry_trampoline_start",
+   "entry_SYSCALL_64_trampoline",
+   };
+   struct symbol *sym = dso__first_symbol(dso);
+   unsigned int i;
+
+   for (; sym; sym = dso__next_symbol(sym)) {
+   if (sym->binding != STB_GLOBAL)
+   continue;
+   for (i = 0; i < ARRAY_SIZE(syms); i++) {
+   if (!strcmp(sym->name, syms[i]))
+   return sym->start;
+   }
+   }
+
+   return 0;
+}
+
+/*
+ * These values can be used for kernels that do not have symbols for the entry
+ * trampolines in kallsyms.
+ */
+#define X86_64_CPU_ENTRY_AREA_PER_CPU  0xfe00ULL
+#define X86_64_CPU_ENTRY_AREA_SIZE 0x2c000
+#define X86_64_ENTRY_TRAMPOLINE0x6000
+
+/* Map x86_64 PTI entry trampolines */
+int machine__map_x86_64_entry_trampolines(struct machine *machine,
+ struct dso *kernel)
+{
+   u64 pgoff = find_entry_trampoline(kernel);
+   int nr_cpus_avail, cpu;
+
+   if (!pgoff)
+   return 0;
+
+   nr_cpus_avail = machine__nr_cpus_avail(machine);
+
+   /* Add a 1 page map for each CPU's entry trampoline */
+   for (cpu = 0; cpu < nr_cpus_avail; cpu++) {
+   u64 va = X86_64_CPU_ENTRY_AREA_PER_CPU +
+cpu * X86_64_CPU_ENTRY_AREA_SIZE +
+X86_64_ENTRY_TRAMPOLINE;
+   struct extra_kernel_map xm = {
+   .start = va,
+   .end   = va + page_size,
+   .pgoff = pgoff,
+   };
+
+   if (machine__create_extra_kernel_map(machine, kernel, ) < 0)
+   return -1;
+   }
+
+   return 0;
+}
+
 static int
 __machine__create_kernel_maps(struct machine *machine, struct dso *kernel)
 {
diff --git a/tools/perf/util/machine.h b/tools/perf/util/machine.h
index 2d2b092ba753..b6a1c3eb3d65 100644
--- a/tools/perf/util/machine.h
+++ b/tools/perf/util/machine.h
@@ -268,4 +268,7 @@ int machine__set_current_tid(struct machine *machine, int 
cpu, pid_t pid,
  */
 char *machine__resolve_kernel_addr(void *vmachine, unsigned long long *addrp, 
char **modp);
 
+int machine__map_x86_64_entry_trampolines(struct 

[tip:perf/core] perf report: Use perf_evlist__force_leader to support '--group'

[tip-bot for Jin Yao]

Commit-ID:  a26bb0ba706aef4f42cc9377c0d4e849378574a4
Gitweb: https://git.kernel.org/tip/a26bb0ba706aef4f42cc9377c0d4e849378574a4
Author: Jin Yao 
AuthorDate: Mon, 21 May 2018 22:57:45 +0800
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 21 May 2018 14:41:01 -0300

perf report: Use perf_evlist__force_leader to support '--group'

Since we created a new function perf_evlist__force_leader(), remove the
old code and use that new evlist method.

Signed-off-by: Jin Yao 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Jiri Olsa 
Cc: Kan Liang 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1526914666-31839-3-git-send-email-yao@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-report.c | 13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 4c931afb2e80..ad978e3ee2b8 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -194,20 +194,11 @@ out:
return err;
 }
 
-/*
- * Events in data file are not collect in groups, but we still want
- * the group display. Set the artificial group and set the leader's
- * forced_leader flag to notify the display code.
- */
 static void setup_forced_leader(struct report *report,
struct perf_evlist *evlist)
 {
-   if (report->group_set && !evlist->nr_groups) {
-   struct perf_evsel *leader = perf_evlist__first(evlist);
-
-   perf_evlist__set_leader(evlist);
-   leader->forced_leader = true;
-   }
+   if (report->group_set)
+   perf_evlist__force_leader(evlist);
 }
 
 static int process_feature_event(struct perf_tool *tool,

[tip:perf/core] perf report: Use perf_evlist__force_leader to support '--group'

[tip-bot for Jin Yao]

Commit-ID:  a26bb0ba706aef4f42cc9377c0d4e849378574a4
Gitweb: https://git.kernel.org/tip/a26bb0ba706aef4f42cc9377c0d4e849378574a4
Author: Jin Yao 
AuthorDate: Mon, 21 May 2018 22:57:45 +0800
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 21 May 2018 14:41:01 -0300

perf report: Use perf_evlist__force_leader to support '--group'

Since we created a new function perf_evlist__force_leader(), remove the
old code and use that new evlist method.

Signed-off-by: Jin Yao 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Jiri Olsa 
Cc: Kan Liang 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1526914666-31839-3-git-send-email-yao@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-report.c | 13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 4c931afb2e80..ad978e3ee2b8 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -194,20 +194,11 @@ out:
return err;
 }
 
-/*
- * Events in data file are not collect in groups, but we still want
- * the group display. Set the artificial group and set the leader's
- * forced_leader flag to notify the display code.
- */
 static void setup_forced_leader(struct report *report,
struct perf_evlist *evlist)
 {
-   if (report->group_set && !evlist->nr_groups) {
-   struct perf_evsel *leader = perf_evlist__first(evlist);
-
-   perf_evlist__set_leader(evlist);
-   leader->forced_leader = true;
-   }
+   if (report->group_set)
+   perf_evlist__force_leader(evlist);
 }
 
 static int process_feature_event(struct perf_tool *tool,

Re: [PATCH v1 2/2] cpufreq: tegra20: Use PLL_C as intermediate clock source

[Dmitry Osipenko]

On 24.05.2018 07:30, Viresh Kumar wrote:
> On 23-05-18, 19:00, Dmitry Osipenko wrote:
>> PLL_C is running at 600MHz which is significantly higher than the 216MHz
>> of the PLL_P and it is known that PLL_C is always-ON because AHB BUS is
>> running on that PLL. Let's use PLL_C as intermediate clock source, making
>> CPU snappier a tad during of the frequency transition.
>>
>> Signed-off-by: Dmitry Osipenko 
>> ---
>>  drivers/cpufreq/tegra20-cpufreq.c | 25 +
>>  1 file changed, 21 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/cpufreq/tegra20-cpufreq.c 
>> b/drivers/cpufreq/tegra20-cpufreq.c
>> index 3ad6bded6efc..4bf5ba7da40b 100644
>> --- a/drivers/cpufreq/tegra20-cpufreq.c
>> +++ b/drivers/cpufreq/tegra20-cpufreq.c
>> @@ -25,12 +25,13 @@
>>  #include 
>>  
>>  #define PLL_P_FREQ  216000
>> +#define PLL_C_FREQ  60
>>  
>>  static struct cpufreq_frequency_table freq_table[] = {
>>  { .frequency = 216000 },
>>  { .frequency = 312000 },
>>  { .frequency = 456000 },
>> -{ .frequency = 608000 },
>> +{ .frequency = 60 },
>>  { .frequency = 76 },
>>  { .frequency = 816000 },
>>  { .frequency = 912000 },
>> @@ -44,6 +45,7 @@ struct tegra20_cpufreq {
>>  struct clk *cpu_clk;
>>  struct clk *pll_x_clk;
>>  struct clk *pll_p_clk;
>> +struct clk *pll_c_clk;
>>  bool pll_x_prepared;
>>  };
>>  
>> @@ -58,7 +60,10 @@ static unsigned int tegra_get_intermediate(struct 
>> cpufreq_policy *policy,
>>  if (index == 0 || policy->cur == PLL_P_FREQ)
>>  return 0;
>>  
>> -return PLL_P_FREQ;
>> +if (index == 3 || policy->cur == PLL_C_FREQ)
>> +return 0;
> 
> So we can choose between two different intermediate frequencies ? And
> I didn't like the way magic number 3 is used here. Its prone to errors
> and we better use a macro or something else here.
> 
> Like instead of doing index == 3, what about freq_table[index].freq ==
> PLL_C_FREQ ? Same for the previous patch as well.

The frequency is determined by the parent clock of CCLK (CPU clock), we can
choose between different parents for the CCLK. PLL_C as PLL_P and PLL_X are
among the available parents for the CCLK to choose from and there some others.

I don't mind to use freq_table[index].freq, though I'd like to keep compiled
assembly minimal where possible. Hence the freq_table should be made constant to
tell compiler that it doesn't need to emit data fetches for the table values and
could embed the constants into the code where appropriate.

Could we constify the "struct cpufreq_frequency_table" within the cpufreq core?
Seems nothing prevents this (I already tried to constify - there are no
obstacles), unless some cpufreq driver would try to modify
policy->freq_table->... within the cpufreq callback implementation.

Re: [PATCH v1 2/2] cpufreq: tegra20: Use PLL_C as intermediate clock source

[Dmitry Osipenko]

On 24.05.2018 07:30, Viresh Kumar wrote:
> On 23-05-18, 19:00, Dmitry Osipenko wrote:
>> PLL_C is running at 600MHz which is significantly higher than the 216MHz
>> of the PLL_P and it is known that PLL_C is always-ON because AHB BUS is
>> running on that PLL. Let's use PLL_C as intermediate clock source, making
>> CPU snappier a tad during of the frequency transition.
>>
>> Signed-off-by: Dmitry Osipenko 
>> ---
>>  drivers/cpufreq/tegra20-cpufreq.c | 25 +
>>  1 file changed, 21 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/cpufreq/tegra20-cpufreq.c 
>> b/drivers/cpufreq/tegra20-cpufreq.c
>> index 3ad6bded6efc..4bf5ba7da40b 100644
>> --- a/drivers/cpufreq/tegra20-cpufreq.c
>> +++ b/drivers/cpufreq/tegra20-cpufreq.c
>> @@ -25,12 +25,13 @@
>>  #include 
>>  
>>  #define PLL_P_FREQ  216000
>> +#define PLL_C_FREQ  60
>>  
>>  static struct cpufreq_frequency_table freq_table[] = {
>>  { .frequency = 216000 },
>>  { .frequency = 312000 },
>>  { .frequency = 456000 },
>> -{ .frequency = 608000 },
>> +{ .frequency = 60 },
>>  { .frequency = 76 },
>>  { .frequency = 816000 },
>>  { .frequency = 912000 },
>> @@ -44,6 +45,7 @@ struct tegra20_cpufreq {
>>  struct clk *cpu_clk;
>>  struct clk *pll_x_clk;
>>  struct clk *pll_p_clk;
>> +struct clk *pll_c_clk;
>>  bool pll_x_prepared;
>>  };
>>  
>> @@ -58,7 +60,10 @@ static unsigned int tegra_get_intermediate(struct 
>> cpufreq_policy *policy,
>>  if (index == 0 || policy->cur == PLL_P_FREQ)
>>  return 0;
>>  
>> -return PLL_P_FREQ;
>> +if (index == 3 || policy->cur == PLL_C_FREQ)
>> +return 0;
> 
> So we can choose between two different intermediate frequencies ? And
> I didn't like the way magic number 3 is used here. Its prone to errors
> and we better use a macro or something else here.
> 
> Like instead of doing index == 3, what about freq_table[index].freq ==
> PLL_C_FREQ ? Same for the previous patch as well.

The frequency is determined by the parent clock of CCLK (CPU clock), we can
choose between different parents for the CCLK. PLL_C as PLL_P and PLL_X are
among the available parents for the CCLK to choose from and there some others.

I don't mind to use freq_table[index].freq, though I'd like to keep compiled
assembly minimal where possible. Hence the freq_table should be made constant to
tell compiler that it doesn't need to emit data fetches for the table values and
could embed the constants into the code where appropriate.

Could we constify the "struct cpufreq_frequency_table" within the cpufreq core?
Seems nothing prevents this (I already tried to constify - there are no
obstacles), unless some cpufreq driver would try to modify
policy->freq_table->... within the cpufreq callback implementation.

[tip:perf/core] perf evlist: Introduce force_leader() method

[tip-bot for Jin Yao]

Commit-ID:  e2bdbe80a0b7dea9ba73582701b8a67c01e1da4f
Gitweb: https://git.kernel.org/tip/e2bdbe80a0b7dea9ba73582701b8a67c01e1da4f
Author: Jin Yao 
AuthorDate: Mon, 21 May 2018 22:57:44 +0800
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 21 May 2018 14:40:54 -0300

perf evlist: Introduce force_leader() method

For non-explicit group (e.g. those created with -e '{eventA,eventB}'),
'perf report' supports a option '--group' which can enable group output.

We also need to support 'perf annotate' with the same '--group'.

Create a new function perf_evlist__force_leader() which contains common
code to force setting the group leader.

Signed-off-by: Jin Yao 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Jiri Olsa 
Cc: Kan Liang 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1526914666-31839-2-git-send-email-yao@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/evlist.c | 15 +++
 tools/perf/util/evlist.h |  3 +++
 2 files changed, 18 insertions(+)

diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index a59281d64368..e7a4b31a84fb 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1795,3 +1795,18 @@ bool perf_evlist__exclude_kernel(struct perf_evlist 
*evlist)
 
return true;
 }
+
+/*
+ * Events in data file are not collect in groups, but we still want
+ * the group display. Set the artificial group and set the leader's
+ * forced_leader flag to notify the display code.
+ */
+void perf_evlist__force_leader(struct perf_evlist *evlist)
+{
+   if (!evlist->nr_groups) {
+   struct perf_evsel *leader = perf_evlist__first(evlist);
+
+   perf_evlist__set_leader(evlist);
+   leader->forced_leader = true;
+   }
+}
diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
index 6c41b2f78713..dc66436add98 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -309,4 +309,7 @@ struct perf_evsel *perf_evlist__event2evsel(struct 
perf_evlist *evlist,
union perf_event *event);
 
 bool perf_evlist__exclude_kernel(struct perf_evlist *evlist);
+
+void perf_evlist__force_leader(struct perf_evlist *evlist);
+
 #endif /* __PERF_EVLIST_H */

[tip:perf/core] perf evlist: Introduce force_leader() method

[tip-bot for Jin Yao]

Commit-ID:  e2bdbe80a0b7dea9ba73582701b8a67c01e1da4f
Gitweb: https://git.kernel.org/tip/e2bdbe80a0b7dea9ba73582701b8a67c01e1da4f
Author: Jin Yao 
AuthorDate: Mon, 21 May 2018 22:57:44 +0800
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 21 May 2018 14:40:54 -0300

perf evlist: Introduce force_leader() method

For non-explicit group (e.g. those created with -e '{eventA,eventB}'),
'perf report' supports a option '--group' which can enable group output.

We also need to support 'perf annotate' with the same '--group'.

Create a new function perf_evlist__force_leader() which contains common
code to force setting the group leader.

Signed-off-by: Jin Yao 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Jiri Olsa 
Cc: Kan Liang 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1526914666-31839-2-git-send-email-yao@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/evlist.c | 15 +++
 tools/perf/util/evlist.h |  3 +++
 2 files changed, 18 insertions(+)

diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index a59281d64368..e7a4b31a84fb 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1795,3 +1795,18 @@ bool perf_evlist__exclude_kernel(struct perf_evlist 
*evlist)
 
return true;
 }
+
+/*
+ * Events in data file are not collect in groups, but we still want
+ * the group display. Set the artificial group and set the leader's
+ * forced_leader flag to notify the display code.
+ */
+void perf_evlist__force_leader(struct perf_evlist *evlist)
+{
+   if (!evlist->nr_groups) {
+   struct perf_evsel *leader = perf_evlist__first(evlist);
+
+   perf_evlist__set_leader(evlist);
+   leader->forced_leader = true;
+   }
+}
diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
index 6c41b2f78713..dc66436add98 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -309,4 +309,7 @@ struct perf_evsel *perf_evlist__event2evsel(struct 
perf_evlist *evlist,
union perf_event *event);
 
 bool perf_evlist__exclude_kernel(struct perf_evlist *evlist);
+
+void perf_evlist__force_leader(struct perf_evlist *evlist);
+
 #endif /* __PERF_EVLIST_H */

Re: [GIT PULL 00/18] perf/core improvements

[Ingo Molnar]

* Arnaldo Carvalho de Melo <a...@kernel.org> wrote:

> Hi Ingo,
> 
>   Please consider pulling,
> 
> - Arnaldo
> 
> Test results at the end of this message, as usual.
> 
> The following changes since commit 2996123e7e589d78e73cfeb7e7f14d49127eb1b0:
> 
>   Merge tag 'perf-core-for-mingo-4.18-20180519' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core 
> (2018-05-19 13:32:53 +0200)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git 
> tags/perf-core-for-mingo-4.18-20180523
> 
> for you to fetch changes up to 22916fdb9c50e8fb303bdcedca88fd8798a85844:
> 
>   perf kcore_copy: Amend the offset of sections that remap kernel text 
> (2018-05-23 10:26:44 -0300)
> 
> 
> perf/core improvements:
> 
> . Create extra kernel maps to help in decoding samples in x86 PTI entry
>   trampolines (Adrian Hunter)
> 
> . Copy x86 PTI entry trampoline sections in the kcore copy used for
>   annotation and intel_pt CPU traces decoding (Adrian Hunter)
> 
> - Support 'perf annotate --group' for non-explicit recorded event
>   "groups", showing multiple columns, one for each event, just like
>   when dealing with explicit event groups (those enclosed with {}) (Jin Yao)
> 
> Signed-off-by: Arnaldo Carvalho de Melo <a...@redhat.com>
> 
> 
> Adrian Hunter (14):
>   perf machine: Add nr_cpus_avail()
>   perf machine: Workaround missing maps for x86 PTI entry trampolines
>   perf machine: Fix map_groups__split_kallsyms() for entry trampoline 
> symbols
>   perf machine: Allow for extra kernel maps
>   perf machine: Create maps for x86 PTI entry trampolines
>   perf machine: Synthesize and process mmap events for x86 PTI entry 
> trampolines
>   perf kcore_copy: Keep phdr data in a list
>   perf kcore_copy: Keep a count of phdrs
>   perf kcore_copy: Calculate offset from phnum
>   perf kcore_copy: Layout sections
>   perf kcore_copy: Iterate phdrs
>   perf kcore_copy: Get rid of kernel_map
>   perf kcore_copy: Copy x86 PTI entry trampoline sections
>   perf kcore_copy: Amend the offset of sections that remap kernel text
> 
> Jin Yao (4):
>   perf evlist: Introduce force_leader() method
>   perf report: Use perf_evlist__force_leader to support '--group'
>   perf annotate: Support '--group' option
>   perf annotate: Show group event string for stdio
> 
>  tools/perf/arch/x86/util/Build |   2 +
>  tools/perf/arch/x86/util/event.c   |  76 +
>  tools/perf/arch/x86/util/machine.c | 103 +
>  tools/perf/builtin-annotate.c  |   7 ++
>  tools/perf/builtin-report.c|  13 +--
>  tools/perf/util/annotate.c |   6 +-
>  tools/perf/util/env.c  |  13 +++
>  tools/perf/util/env.h  |   1 +
>  tools/perf/util/event.c|  36 --
>  tools/perf/util/event.h|   8 ++
>  tools/perf/util/evlist.c   |  15 +++
>  tools/perf/util/evlist.h   |   3 +
>  tools/perf/util/machine.c  | 175 +++--
>  tools/perf/util/machine.h  |  23 
>  tools/perf/util/map.c  |  22 +++-
>  tools/perf/util/map.h  |  15 ++-
>  tools/perf/util/symbol-elf.c   | 219 
> +++--
>  tools/perf/util/symbol.c   |  49 +++--
>  18 files changed, 711 insertions(+), 75 deletions(-)
>  create mode 100644 tools/perf/arch/x86/util/event.c
>  create mode 100644 tools/perf/arch/x86/util/machine.c

Pulled, thanks a lot Arnaldo!

Ingo

Re: [GIT PULL 00/18] perf/core improvements

[Ingo Molnar]

* Arnaldo Carvalho de Melo  wrote:

> Hi Ingo,
> 
>   Please consider pulling,
> 
> - Arnaldo
> 
> Test results at the end of this message, as usual.
> 
> The following changes since commit 2996123e7e589d78e73cfeb7e7f14d49127eb1b0:
> 
>   Merge tag 'perf-core-for-mingo-4.18-20180519' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core 
> (2018-05-19 13:32:53 +0200)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git 
> tags/perf-core-for-mingo-4.18-20180523
> 
> for you to fetch changes up to 22916fdb9c50e8fb303bdcedca88fd8798a85844:
> 
>   perf kcore_copy: Amend the offset of sections that remap kernel text 
> (2018-05-23 10:26:44 -0300)
> 
> 
> perf/core improvements:
> 
> . Create extra kernel maps to help in decoding samples in x86 PTI entry
>   trampolines (Adrian Hunter)
> 
> . Copy x86 PTI entry trampoline sections in the kcore copy used for
>   annotation and intel_pt CPU traces decoding (Adrian Hunter)
> 
> - Support 'perf annotate --group' for non-explicit recorded event
>   "groups", showing multiple columns, one for each event, just like
>   when dealing with explicit event groups (those enclosed with {}) (Jin Yao)
> 
> Signed-off-by: Arnaldo Carvalho de Melo 
> 
> 
> Adrian Hunter (14):
>   perf machine: Add nr_cpus_avail()
>   perf machine: Workaround missing maps for x86 PTI entry trampolines
>   perf machine: Fix map_groups__split_kallsyms() for entry trampoline 
> symbols
>   perf machine: Allow for extra kernel maps
>   perf machine: Create maps for x86 PTI entry trampolines
>   perf machine: Synthesize and process mmap events for x86 PTI entry 
> trampolines
>   perf kcore_copy: Keep phdr data in a list
>   perf kcore_copy: Keep a count of phdrs
>   perf kcore_copy: Calculate offset from phnum
>   perf kcore_copy: Layout sections
>   perf kcore_copy: Iterate phdrs
>   perf kcore_copy: Get rid of kernel_map
>   perf kcore_copy: Copy x86 PTI entry trampoline sections
>   perf kcore_copy: Amend the offset of sections that remap kernel text
> 
> Jin Yao (4):
>   perf evlist: Introduce force_leader() method
>   perf report: Use perf_evlist__force_leader to support '--group'
>   perf annotate: Support '--group' option
>   perf annotate: Show group event string for stdio
> 
>  tools/perf/arch/x86/util/Build |   2 +
>  tools/perf/arch/x86/util/event.c   |  76 +
>  tools/perf/arch/x86/util/machine.c | 103 +
>  tools/perf/builtin-annotate.c  |   7 ++
>  tools/perf/builtin-report.c|  13 +--
>  tools/perf/util/annotate.c |   6 +-
>  tools/perf/util/env.c  |  13 +++
>  tools/perf/util/env.h  |   1 +
>  tools/perf/util/event.c|  36 --
>  tools/perf/util/event.h|   8 ++
>  tools/perf/util/evlist.c   |  15 +++
>  tools/perf/util/evlist.h   |   3 +
>  tools/perf/util/machine.c  | 175 +++--
>  tools/perf/util/machine.h  |  23 
>  tools/perf/util/map.c  |  22 +++-
>  tools/perf/util/map.h  |  15 ++-
>  tools/perf/util/symbol-elf.c   | 219 
> +++--
>  tools/perf/util/symbol.c   |  49 +++--
>  18 files changed, 711 insertions(+), 75 deletions(-)
>  create mode 100644 tools/perf/arch/x86/util/event.c
>  create mode 100644 tools/perf/arch/x86/util/machine.c

Pulled, thanks a lot Arnaldo!

Ingo

Re: B53 DSA switch problem on Banana Pi-R1 on Fedora 26

[Gerhard Wiesinger]

After some analysis with Florian (thnx) we found out that the current 
implementation is broken:


https://patchwork.ozlabs.org/patch/836538/
https://github.com/torvalds/linux/commit/c499696e7901bda18385ac723b7bd27c3a4af624#diff-a2b6f8d89e18de600e873ac3ac43fa1d

Florians comment:

c499696e7901bda18385ac723b7bd27c3a4af624 ("net: dsa: b53: Stop using
dev->cpu_port incorrectly") since it would result in no longer setting
the CPU port as tagged for a specific VLAN. Easiest way for you right
now is to just revert it, but this needs some more thoughts for a proper
upstream change. I will think about it some more.

Ciao,
Gerhard

Re: B53 DSA switch problem on Banana Pi-R1 on Fedora 26

[Gerhard Wiesinger]

After some analysis with Florian (thnx) we found out that the current 
implementation is broken:


https://patchwork.ozlabs.org/patch/836538/
https://github.com/torvalds/linux/commit/c499696e7901bda18385ac723b7bd27c3a4af624#diff-a2b6f8d89e18de600e873ac3ac43fa1d

Florians comment:

c499696e7901bda18385ac723b7bd27c3a4af624 ("net: dsa: b53: Stop using
dev->cpu_port incorrectly") since it would result in no longer setting
the CPU port as tagged for a specific VLAN. Easiest way for you right
now is to just revert it, but this needs some more thoughts for a proper
upstream change. I will think about it some more.

Ciao,
Gerhard

[PATCH] clk: mvebu: use correct bit for 98DX3236 NAND

[Chris Packham]

The correct fieldbit value for the NAND PLL reload trigger is 27.

Fixes: commit e120c17a70e5 ("clk: mvebu: support for 98DX3236 SoC")
Signed-off-by: Chris Packham 
---
I can't remember where the value of 26 came from. Looking at the lsp source I
have from Marvell it's always been 27, so I suspect I just messed up when
porting. The only documentation I have is that register field is bits 21:27
without adding any detail as to which clock trees correspond to the individual
bits so I'm not sure which clock tree was being triggered.

 drivers/clk/mvebu/clk-corediv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/mvebu/clk-corediv.c b/drivers/clk/mvebu/clk-corediv.c
index 8491979f4096..68f05c53d40e 100644
--- a/drivers/clk/mvebu/clk-corediv.c
+++ b/drivers/clk/mvebu/clk-corediv.c
@@ -72,7 +72,7 @@ static const struct clk_corediv_desc mvebu_corediv_desc[] = {
 };
 
 static const struct clk_corediv_desc mv98dx3236_corediv_desc[] = {
-   { .mask = 0x0f, .offset = 6, .fieldbit = 26 }, /* NAND clock */
+   { .mask = 0x0f, .offset = 6, .fieldbit = 27 }, /* NAND clock */
 };
 
 #define to_corediv_clk(p) container_of(p, struct clk_corediv, hw)
-- 
2.17.0

[PATCH] clk: mvebu: use correct bit for 98DX3236 NAND

[Chris Packham]

The correct fieldbit value for the NAND PLL reload trigger is 27.

Fixes: commit e120c17a70e5 ("clk: mvebu: support for 98DX3236 SoC")
Signed-off-by: Chris Packham 
---
I can't remember where the value of 26 came from. Looking at the lsp source I
have from Marvell it's always been 27, so I suspect I just messed up when
porting. The only documentation I have is that register field is bits 21:27
without adding any detail as to which clock trees correspond to the individual
bits so I'm not sure which clock tree was being triggered.

 drivers/clk/mvebu/clk-corediv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/mvebu/clk-corediv.c b/drivers/clk/mvebu/clk-corediv.c
index 8491979f4096..68f05c53d40e 100644
--- a/drivers/clk/mvebu/clk-corediv.c
+++ b/drivers/clk/mvebu/clk-corediv.c
@@ -72,7 +72,7 @@ static const struct clk_corediv_desc mvebu_corediv_desc[] = {
 };
 
 static const struct clk_corediv_desc mv98dx3236_corediv_desc[] = {
-   { .mask = 0x0f, .offset = 6, .fieldbit = 26 }, /* NAND clock */
+   { .mask = 0x0f, .offset = 6, .fieldbit = 27 }, /* NAND clock */
 };
 
 #define to_corediv_clk(p) container_of(p, struct clk_corediv, hw)
-- 
2.17.0

Re: [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

[Matthew Wilcox]

On Tue, May 22, 2018 at 08:37:28PM +0200, Michal Hocko wrote:
> So why is this any better than the current code. Sure I am not a great
> fan of GFP_ZONE_TABLE because of how it is incomprehensible but this
> doesn't look too much better, yet we are losing a check for incompatible
> gfp flags. The diffstat looks really sound but then you just look and
> see that the large part is the comment that at least explained the gfp
> zone modifiers somehow and the debugging code. So what is the selling
> point?

I have a plan, but it's not exactly fully-formed yet.

One of the big problems we have today is that we have a lot of users
who have constraints on the physical memory they want to allocate,
but we have very limited abilities to provide them with what they're
asking for.  The various different ZONEs have different meanings on
different architectures and are generally a mess.

If we had eight ZONEs, we could offer:

ZONE_16M// 24 bit
ZONE_256M   // 28 bit
ZONE_LOWMEM // CONFIG_32BIT only
ZONE_4G // 32 bit
ZONE_64G// 36 bit
ZONE_1T // 40 bit
ZONE_ALL// everything larger
ZONE_MOVABLE// movable allocations; no physical address guarantees

#ifdef CONFIG_64BIT
#define ZONE_NORMAL ZONE_ALL
#else
#define ZONE_NORMAL ZONE_LOWMEM
#endif

This would cover most driver DMA mask allocations; we could tweak the
offered zones based on analysis of what people need.

#define GFP_HIGHUSER(GFP_USER | ZONE_ALL)
#define GFP_HIGHUSER_MOVABLE(GFP_USER | ZONE_MOVABLE)

One other thing I want to see is that fallback from zones happens from
highest to lowest normally (ie if you fail to allocate in 1T, then you
try to allocate from 64G), but movable allocations hapen from lowest
to highest.  So ZONE_16M ends up full of page cache pages which are
readily evictable for the rare occasions when we need to allocate memory
below 16MB.

I'm sure there are lots of good reasons why this won't work, which is
why I've been hesitant to propose it before now.

Re: [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

[Matthew Wilcox]

On Tue, May 22, 2018 at 08:37:28PM +0200, Michal Hocko wrote:
> So why is this any better than the current code. Sure I am not a great
> fan of GFP_ZONE_TABLE because of how it is incomprehensible but this
> doesn't look too much better, yet we are losing a check for incompatible
> gfp flags. The diffstat looks really sound but then you just look and
> see that the large part is the comment that at least explained the gfp
> zone modifiers somehow and the debugging code. So what is the selling
> point?

I have a plan, but it's not exactly fully-formed yet.

One of the big problems we have today is that we have a lot of users
who have constraints on the physical memory they want to allocate,
but we have very limited abilities to provide them with what they're
asking for.  The various different ZONEs have different meanings on
different architectures and are generally a mess.

If we had eight ZONEs, we could offer:

ZONE_16M// 24 bit
ZONE_256M   // 28 bit
ZONE_LOWMEM // CONFIG_32BIT only
ZONE_4G // 32 bit
ZONE_64G// 36 bit
ZONE_1T // 40 bit
ZONE_ALL// everything larger
ZONE_MOVABLE// movable allocations; no physical address guarantees

#ifdef CONFIG_64BIT
#define ZONE_NORMAL ZONE_ALL
#else
#define ZONE_NORMAL ZONE_LOWMEM
#endif

This would cover most driver DMA mask allocations; we could tweak the
offered zones based on analysis of what people need.

#define GFP_HIGHUSER(GFP_USER | ZONE_ALL)
#define GFP_HIGHUSER_MOVABLE(GFP_USER | ZONE_MOVABLE)

One other thing I want to see is that fallback from zones happens from
highest to lowest normally (ie if you fail to allocate in 1T, then you
try to allocate from 64G), but movable allocations hapen from lowest
to highest.  So ZONE_16M ends up full of page cache pages which are
readily evictable for the rare occasions when we need to allocate memory
below 16MB.

I'm sure there are lots of good reasons why this won't work, which is
why I've been hesitant to propose it before now.

Re: [PATCH] remoteproc: Add APSS based Qualcomm ADSP PIL driver for SDM845

[Rohit Kumar]

Thanks Bjorn for reviewing.


On 5/23/2018 11:56 AM, Bjorn Andersson wrote:

On Sun 13 May 00:01 PDT 2018, Rohit kumar wrote:


--- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
@@ -10,6 +10,7 @@ on the Qualcomm ADSP Hexagon core.
"qcom,msm8974-adsp-pil"
"qcom,msm8996-adsp-pil"
"qcom,msm8996-slpi-pil"
+   "qcom,sdm845-apss-adsp-pil"

Afaict there's nothing in this binding that ties this to the apss, so I
don't think we should base the compatible on this. The differentiation
is PAS vs non-PAS; so let's start naming the PAS variants
"qcom,platform-subsystem-pas" and the non-PAS
"qcom,platform-subsystem-pil" instead.

I.e. please make this "qcom,sdm845-adsp-pil".

More importantly, any resources such as clocks or reset lines should
come from DT and as such you need to extend the binding quite a bit -
which I suggest you do by introducing a new binding document.
Sure. Will create new dt-binding document with clocks and reset driver 
info added for sdm845 PIL.


  
  - interrupts-extended:

Usage: required
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 02627ed..759831b 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -14,7 +14,8 @@ obj-$(CONFIG_OMAP_REMOTEPROC) += omap_remoteproc.o
  obj-$(CONFIG_WKUP_M3_RPROC)   += wkup_m3_rproc.o
  obj-$(CONFIG_DA8XX_REMOTEPROC)+= da8xx_remoteproc.o
  obj-$(CONFIG_KEYSTONE_REMOTEPROC) += keystone_remoteproc.o
-obj-$(CONFIG_QCOM_ADSP_PIL)+= qcom_adsp_pil.o
+obj-$(CONFIG_QCOM_ADSP_PIL)+= qcom_adsp.o
+qcom_adsp-objs += qcom_adsp_pil.o 
qcom_adsp_pil_sdm845.o
  obj-$(CONFIG_QCOM_RPROC_COMMON)   += qcom_common.o
  obj-$(CONFIG_QCOM_Q6V5_PIL)   += qcom_q6v5_pil.o
  obj-$(CONFIG_QCOM_SYSMON) += qcom_sysmon.o
diff --git a/drivers/remoteproc/qcom_adsp_pil.c 
b/drivers/remoteproc/qcom_adsp_pil.c

I get the feeling that the main reason for modifying this file is its
name, not that it reduces the complexity of the final solution. I
definitely think it's cleaner to have some structural duplication and
keep this driver handling the various PAS based remoteprocs.
The main intention was to re-use exisiting APIs in PAS based PIL driver 
as the major change was
w.r.t. start and stop of ADSP firmware. Load(), interrupt handling and 
few other APIs will be same

as done in exisiting PAS based PIL driver.

Please see the RFC series I posted reducing the duplication between the
various "Q6V5 drivers".
I went through the RFC. Our code will fit into the design. However, we 
will still have some amount of code
duplication between PAS and Non-PAS ADSP PIL driver. Will this be fine? 
Please suggest.
Will wait for your response whether to write complete new driver or 
reuse exisitng one.



[..]

diff --git a/drivers/remoteproc/qcom_adsp_pil.h 
b/drivers/remoteproc/qcom_adsp_pil.h

[..]

+static inline void update_bits(void *reg, u32 mask_val, u32 set_val, u32 shift)
+{
+   u32 reg_val = 0;
+
+   reg_val = ((readl(reg)) & ~mask_val) | ((set_val << shift) & mask_val);
+   writel(reg_val, reg);
+}
+
+static inline unsigned int read_bit(void *reg, u32 mask, int shift)
+{
+   return ((readl(reg) & mask) >> shift);
+}

I don't like these helper functions, their prototype is nonstandard and
makes it really hard to read all the calling code.

I would prefer if you just inline the operations directly, to make it
clearer what's going on in each case - if not then at least follow the
prototype of e.g. regmap_udpate_bits(), which people might be used to.
Sure. Will update these APIs to follow standard format used in regmap 
and other drivers.

+
+#endif
diff --git a/drivers/remoteproc/qcom_adsp_pil_sdm845.c 
b/drivers/remoteproc/qcom_adsp_pil_sdm845.c
new file mode 100644
index 000..7518385
--- /dev/null
+++ b/drivers/remoteproc/qcom_adsp_pil_sdm845.c
@@ -0,0 +1,304 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Qualcomm APSS Based ADSP bootup/shutdown ops for SDM845.
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+#include 
+
+#include "qcom_adsp_pil.h"
+
+/* set values */
+#define CLK_ENABLE 0x1
+#define CLK_DISABLE0x0

Just write 0 and 1 in the code, it saves future readers the trouble of
having to remember if these are special in any way.

OK.

+/* time out value */
+#define ACK_TIMEOUT20

This is currently given in the rather awkward unit of 5uS. As it's input
to what should have been a call to readl_poll_timeout() please express
it in micro seconds.

sure. will do that in next patch

+/* mask values */
+#define CLK_MASK   GENMASK(4, 0)
+#define EVB_MASK   GENMASK(27, 4)

Re: [PATCH v2 1/2] dt-bindings: cpufreq: Introduce QCOM CPUFREQ FW bindings

[Taniya Das]

Hello Rob, Viresh,

Thank you for the comments. If I understand correctly, the device tree 
nodes should look something like the below.


Though I am not sure if any vendor name could be associated in the cpu 
nodes.


Please suggest if my understanding is wrong.

cpu@0 {
qcom,freq-domain = <_domain_table0>;
…
};

same follows for cpu 1/2/3

cpu@400 {
qcom,freq-domain = <_domain_table1>;
…
};
same follows for cpu 5/6/7

freq_domain_table0 : freq_table {
reg = < >, < >, < > ;
reg-names = "perf_base", "lut_base", "en_base";
};

freq_domain_table1 : freq_table {
reg = < >, < >, < > ;
reg-names = "perf_base", "lut_base", "en_base";
};



On 5/23/2018 7:48 PM, Rob Herring wrote:

On Wed, May 23, 2018 at 12:48 AM, Viresh Kumar  wrote:

On 22-05-18, 14:31, Rob Herring wrote:

On Sat, May 19, 2018 at 11:04:50PM +0530, Taniya Das wrote:

+   freq-domain-0 {
+   compatible = "cpufreq";
+   reg = <0x17d43920 0x4>,
+<0x17d43110 0x500>,
+<0x17d41000 0x4>;
+   reg-names = "perf_base", "lut_base", "en_base";
+   qcom,cpulist = <   >;


I was thinking, can't we add platform specific properties in the CPU
nodes ? If yes, then we can point the phandle of fw node from the CPUs
and this awkward list can go away.


Yes, that's fine. That would be more like OPP binding in that the CPU
points to the OPP table rather than the OPP pointing to the CPUs.

With that, you can get rid of the child nodes completely. Just make
the parent reg property N sets of 3 addresses for N domains.

Rob



--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.

--

Re: [PATCH] remoteproc: Add APSS based Qualcomm ADSP PIL driver for SDM845

[Rohit Kumar]

Thanks Bjorn for reviewing.


On 5/23/2018 11:56 AM, Bjorn Andersson wrote:

On Sun 13 May 00:01 PDT 2018, Rohit kumar wrote:


--- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
@@ -10,6 +10,7 @@ on the Qualcomm ADSP Hexagon core.
"qcom,msm8974-adsp-pil"
"qcom,msm8996-adsp-pil"
"qcom,msm8996-slpi-pil"
+   "qcom,sdm845-apss-adsp-pil"

Afaict there's nothing in this binding that ties this to the apss, so I
don't think we should base the compatible on this. The differentiation
is PAS vs non-PAS; so let's start naming the PAS variants
"qcom,platform-subsystem-pas" and the non-PAS
"qcom,platform-subsystem-pil" instead.

I.e. please make this "qcom,sdm845-adsp-pil".

More importantly, any resources such as clocks or reset lines should
come from DT and as such you need to extend the binding quite a bit -
which I suggest you do by introducing a new binding document.
Sure. Will create new dt-binding document with clocks and reset driver 
info added for sdm845 PIL.


  
  - interrupts-extended:

Usage: required
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 02627ed..759831b 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -14,7 +14,8 @@ obj-$(CONFIG_OMAP_REMOTEPROC) += omap_remoteproc.o
  obj-$(CONFIG_WKUP_M3_RPROC)   += wkup_m3_rproc.o
  obj-$(CONFIG_DA8XX_REMOTEPROC)+= da8xx_remoteproc.o
  obj-$(CONFIG_KEYSTONE_REMOTEPROC) += keystone_remoteproc.o
-obj-$(CONFIG_QCOM_ADSP_PIL)+= qcom_adsp_pil.o
+obj-$(CONFIG_QCOM_ADSP_PIL)+= qcom_adsp.o
+qcom_adsp-objs += qcom_adsp_pil.o 
qcom_adsp_pil_sdm845.o
  obj-$(CONFIG_QCOM_RPROC_COMMON)   += qcom_common.o
  obj-$(CONFIG_QCOM_Q6V5_PIL)   += qcom_q6v5_pil.o
  obj-$(CONFIG_QCOM_SYSMON) += qcom_sysmon.o
diff --git a/drivers/remoteproc/qcom_adsp_pil.c 
b/drivers/remoteproc/qcom_adsp_pil.c

I get the feeling that the main reason for modifying this file is its
name, not that it reduces the complexity of the final solution. I
definitely think it's cleaner to have some structural duplication and
keep this driver handling the various PAS based remoteprocs.
The main intention was to re-use exisiting APIs in PAS based PIL driver 
as the major change was
w.r.t. start and stop of ADSP firmware. Load(), interrupt handling and 
few other APIs will be same

as done in exisiting PAS based PIL driver.

Please see the RFC series I posted reducing the duplication between the
various "Q6V5 drivers".
I went through the RFC. Our code will fit into the design. However, we 
will still have some amount of code
duplication between PAS and Non-PAS ADSP PIL driver. Will this be fine? 
Please suggest.
Will wait for your response whether to write complete new driver or 
reuse exisitng one.



[..]

diff --git a/drivers/remoteproc/qcom_adsp_pil.h 
b/drivers/remoteproc/qcom_adsp_pil.h

[..]

+static inline void update_bits(void *reg, u32 mask_val, u32 set_val, u32 shift)
+{
+   u32 reg_val = 0;
+
+   reg_val = ((readl(reg)) & ~mask_val) | ((set_val << shift) & mask_val);
+   writel(reg_val, reg);
+}
+
+static inline unsigned int read_bit(void *reg, u32 mask, int shift)
+{
+   return ((readl(reg) & mask) >> shift);
+}

I don't like these helper functions, their prototype is nonstandard and
makes it really hard to read all the calling code.

I would prefer if you just inline the operations directly, to make it
clearer what's going on in each case - if not then at least follow the
prototype of e.g. regmap_udpate_bits(), which people might be used to.
Sure. Will update these APIs to follow standard format used in regmap 
and other drivers.

+
+#endif
diff --git a/drivers/remoteproc/qcom_adsp_pil_sdm845.c 
b/drivers/remoteproc/qcom_adsp_pil_sdm845.c
new file mode 100644
index 000..7518385
--- /dev/null
+++ b/drivers/remoteproc/qcom_adsp_pil_sdm845.c
@@ -0,0 +1,304 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Qualcomm APSS Based ADSP bootup/shutdown ops for SDM845.
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+#include 
+
+#include "qcom_adsp_pil.h"
+
+/* set values */
+#define CLK_ENABLE 0x1
+#define CLK_DISABLE0x0

Just write 0 and 1 in the code, it saves future readers the trouble of
having to remember if these are special in any way.

OK.

+/* time out value */
+#define ACK_TIMEOUT20

This is currently given in the rather awkward unit of 5uS. As it's input
to what should have been a call to readl_poll_timeout() please express
it in micro seconds.

sure. will do that in next patch

+/* mask values */
+#define CLK_MASK   GENMASK(4, 0)
+#define EVB_MASK   GENMASK(27, 4)

Re: [PATCH v2 1/2] dt-bindings: cpufreq: Introduce QCOM CPUFREQ FW bindings

[Taniya Das]

Hello Rob, Viresh,

Thank you for the comments. If I understand correctly, the device tree 
nodes should look something like the below.


Though I am not sure if any vendor name could be associated in the cpu 
nodes.


Please suggest if my understanding is wrong.

cpu@0 {
qcom,freq-domain = <_domain_table0>;
…
};

same follows for cpu 1/2/3

cpu@400 {
qcom,freq-domain = <_domain_table1>;
…
};
same follows for cpu 5/6/7

freq_domain_table0 : freq_table {
reg = < >, < >, < > ;
reg-names = "perf_base", "lut_base", "en_base";
};

freq_domain_table1 : freq_table {
reg = < >, < >, < > ;
reg-names = "perf_base", "lut_base", "en_base";
};



On 5/23/2018 7:48 PM, Rob Herring wrote:

On Wed, May 23, 2018 at 12:48 AM, Viresh Kumar  wrote:

On 22-05-18, 14:31, Rob Herring wrote:

On Sat, May 19, 2018 at 11:04:50PM +0530, Taniya Das wrote:

+   freq-domain-0 {
+   compatible = "cpufreq";
+   reg = <0x17d43920 0x4>,
+<0x17d43110 0x500>,
+<0x17d41000 0x4>;
+   reg-names = "perf_base", "lut_base", "en_base";
+   qcom,cpulist = <   >;


I was thinking, can't we add platform specific properties in the CPU
nodes ? If yes, then we can point the phandle of fw node from the CPUs
and this awkward list can go away.


Yes, that's fine. That would be more like OPP binding in that the CPU
points to the OPP table rather than the OPP pointing to the CPUs.

With that, you can get rid of the child nodes completely. Just make
the parent reg property N sets of 3 addresses for N domains.

Rob



--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.

--

Re: [PATCH v4 03/31] kconfig: reference environment variables directly and remove 'option env='

[Masahiro Yamada]

2018-05-21 20:06 GMT+09:00 Ulf Magnusson :

>>
>> static char *__expand_string(const char **str, bool (*is_end)(const char *))
>> {
>> const char *in, *prev_in, *p;
>> char *new, *out;
>> size_t outlen;
>>
>> out = xmalloc(1);
>> *out = 0;
>>
>> p = in = *str;
>>
>> while (1) {
>> if (*p == '$') {
>> prev_in = in;
>> in = p + 1;
>> new = expand_dollar();
>> outlen = strlen(out) + (p - prev_in) + strlen(new) + 
>> 1;
>> out = xrealloc(out, outlen);
>> strncat(out, prev_in, p - prev_in);
>> strcat(out, new);
>> free(new);
>> p = in;
>> continue;
>> }
>>
>> if (is_end(p))
>> break;
>>
>> p++;
>> }
>>
>> outlen = strlen(out) + (p - in) + 1;
>> out = xrealloc(out, outlen);
>> strncat(out, in, p - in);
>>
>> *str = p;
>>
>> return out;
>> }
>>
>> static bool is_end_of_str(const char *s)
>> {
>> return !*s;
>> }
>>
>> char *expand_string(const char *in)
>> {
>> return __expand_string(, is_end_of_str);
>> }
>>
>> static bool is_end_of_token(const char *s)
>> {
>> return !(isalnum(*s) || *s == '_' || *s == '-' || *s == '.' ||
>> *s == '/');
>> }
>>
>> char *expand_one_token(const char **str)
>> {
>> return __expand_string(str, is_end_of_token);
>> }
>
> Yep, something like that would be nicer I think.
>
> This variant might work too (untested):
>
>   dollar_i = p;
>   p++;
>   expansion = expand_dollar();
>
>   out = xrealloc(out, strlen(out) + (dollar_i - in)
>   + strlen(expansion) + 1);
>   strncat(out, in, dollar_i - in);
>   strcat(out, expansion);
>   free(expansion);
>
>   in = p;
>
>   continue;
>
> The p++ would disappear if expand_dollar() took a pointer to the '$'.
>


I took the variable name "expansion" because
it is more descriptive than "new".


I rewrote like follows:


static char *__expand_string(const char **str, bool (*is_end)(const char *))
{
const char *in, *p;
char *expansion, *out;
size_t in_len, out_len;

out = xmalloc(1);
*out = 0;
out_len = 1;

p = in = *str;

while (1) {
if (*p == '$') {
in_len = p - in;
p++;
expansion = expand_dollar();
out_len += in_len + strlen(expansion);
out = xrealloc(out, out_len);
strncat(out, in, in_len);
strcat(out, expansion);
free(expansion);
in = p;
continue;
}

if (is_end(p))
break;

p++;
}

in_len = p - in;
out_len += in_len;
out = xrealloc(out, out_len);
strncat(out, in, in_len);

/* Advance 'str' to the end character */
*str = p;

return out;
}



I used "out_len" to remember the length of "out"
instead of calculating strlen(out) every time.

I do not need dollar_p.




-- 
Best Regards
Masahiro Yamada

Re: [PATCH v4 03/31] kconfig: reference environment variables directly and remove 'option env='

[Masahiro Yamada]

2018-05-21 20:06 GMT+09:00 Ulf Magnusson :

>>
>> static char *__expand_string(const char **str, bool (*is_end)(const char *))
>> {
>> const char *in, *prev_in, *p;
>> char *new, *out;
>> size_t outlen;
>>
>> out = xmalloc(1);
>> *out = 0;
>>
>> p = in = *str;
>>
>> while (1) {
>> if (*p == '$') {
>> prev_in = in;
>> in = p + 1;
>> new = expand_dollar();
>> outlen = strlen(out) + (p - prev_in) + strlen(new) + 
>> 1;
>> out = xrealloc(out, outlen);
>> strncat(out, prev_in, p - prev_in);
>> strcat(out, new);
>> free(new);
>> p = in;
>> continue;
>> }
>>
>> if (is_end(p))
>> break;
>>
>> p++;
>> }
>>
>> outlen = strlen(out) + (p - in) + 1;
>> out = xrealloc(out, outlen);
>> strncat(out, in, p - in);
>>
>> *str = p;
>>
>> return out;
>> }
>>
>> static bool is_end_of_str(const char *s)
>> {
>> return !*s;
>> }
>>
>> char *expand_string(const char *in)
>> {
>> return __expand_string(, is_end_of_str);
>> }
>>
>> static bool is_end_of_token(const char *s)
>> {
>> return !(isalnum(*s) || *s == '_' || *s == '-' || *s == '.' ||
>> *s == '/');
>> }
>>
>> char *expand_one_token(const char **str)
>> {
>> return __expand_string(str, is_end_of_token);
>> }
>
> Yep, something like that would be nicer I think.
>
> This variant might work too (untested):
>
>   dollar_i = p;
>   p++;
>   expansion = expand_dollar();
>
>   out = xrealloc(out, strlen(out) + (dollar_i - in)
>   + strlen(expansion) + 1);
>   strncat(out, in, dollar_i - in);
>   strcat(out, expansion);
>   free(expansion);
>
>   in = p;
>
>   continue;
>
> The p++ would disappear if expand_dollar() took a pointer to the '$'.
>


I took the variable name "expansion" because
it is more descriptive than "new".


I rewrote like follows:


static char *__expand_string(const char **str, bool (*is_end)(const char *))
{
const char *in, *p;
char *expansion, *out;
size_t in_len, out_len;

out = xmalloc(1);
*out = 0;
out_len = 1;

p = in = *str;

while (1) {
if (*p == '$') {
in_len = p - in;
p++;
expansion = expand_dollar();
out_len += in_len + strlen(expansion);
out = xrealloc(out, out_len);
strncat(out, in, in_len);
strcat(out, expansion);
free(expansion);
in = p;
continue;
}

if (is_end(p))
break;

p++;
}

in_len = p - in;
out_len += in_len;
out = xrealloc(out, out_len);
strncat(out, in, in_len);

/* Advance 'str' to the end character */
*str = p;

return out;
}



I used "out_len" to remember the length of "out"
instead of calculating strlen(out) every time.

I do not need dollar_p.




-- 
Best Regards
Masahiro Yamada

Re: [PATCH 3/3] sched/fair: add tracepoints for cfs throttle

[Cong Wang]

On Wed, May 23, 2018 at 2:09 AM, Peter Zijlstra  wrote:
> On Mon, May 21, 2018 at 11:35:38PM -0700, Ivan Babrou wrote:
>> > +   TP_printk("path=%s cpu=%d runtime_remaining=%lld",
>> > __get_str(cfs_path),
>> > + __entry->cpu, __entry->runtime_remaining)
>> >
>>
>> Can you add "[ns]" as the unit to runtime_remaining? We have it in
>> "sched:sched_stat_runtime".
>
> Yeah, don't worry. I hate tracepoints, I regret the existing ones, no
> new ones will happen.

No matter you hate them or not, they are useful:

https://github.com/iovisor/bcc/blob/master/tools/runqlat.py

Unlike in sched, tracepoints are welcome in networking:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/include/trace/events/tcp.h

I don't want to change your mind, just want to show the facts.

Re: [PATCH 3/3] sched/fair: add tracepoints for cfs throttle

[Cong Wang]

On Wed, May 23, 2018 at 2:09 AM, Peter Zijlstra  wrote:
> On Mon, May 21, 2018 at 11:35:38PM -0700, Ivan Babrou wrote:
>> > +   TP_printk("path=%s cpu=%d runtime_remaining=%lld",
>> > __get_str(cfs_path),
>> > + __entry->cpu, __entry->runtime_remaining)
>> >
>>
>> Can you add "[ns]" as the unit to runtime_remaining? We have it in
>> "sched:sched_stat_runtime".
>
> Yeah, don't worry. I hate tracepoints, I regret the existing ones, no
> new ones will happen.

No matter you hate them or not, they are useful:

https://github.com/iovisor/bcc/blob/master/tools/runqlat.py

Unlike in sched, tracepoints are welcome in networking:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/include/trace/events/tcp.h

I don't want to change your mind, just want to show the facts.

Re: [PATCH v2 0/7] mm: pages for hugetlb's overcommit may be able to charge to memcg

[TSUKADA Koutaro]

On 2018/05/23 3:54, Michal Hocko wrote:
> On Tue 22-05-18 22:04:23, TSUKADA Koutaro wrote:
>> On 2018/05/22 3:07, Mike Kravetz wrote:
>>> On 05/17/2018 09:27 PM, TSUKADA Koutaro wrote:
 Thanks to Mike Kravetz for comment on the previous version patch.

 The purpose of this patch-set is to make it possible to control whether or
 not to charge surplus hugetlb pages obtained by overcommitting to memory
 cgroup. In the future, I am trying to accomplish limiting the memory usage
 of applications that use both normal pages and hugetlb pages by the memory
 cgroup(not use the hugetlb cgroup).

 Applications that use shared libraries like libhugetlbfs.so use both normal
 pages and hugetlb pages, but we do not know how much to use each. Please
 suppose you want to manage the memory usage of such applications by cgroup
 How do you set the memory cgroup and hugetlb cgroup limit when you want to
 limit memory usage to 10GB?

 If you set a limit of 10GB for each, the user can use a total of 20GB of
 memory and can not limit it well. Since it is difficult to estimate the
 ratio used by user of normal pages and hugetlb pages, setting limits of 2GB
 to memory cgroup and 8GB to hugetlb cgroup is not very good idea. In such a
 case, I thought that by using my patch-set, we could manage resources just
 by setting 10GB as the limit of memory cgoup(there is no limit to hugetlb
 cgroup).

 In this patch-set, introduce the charge_surplus_huge_pages(boolean) to
 struct hstate. If it is true, it charges to the memory cgroup to which the
 task that obtained surplus hugepages belongs. If it is false, do nothing as
 before, and the default value is false. The charge_surplus_huge_pages can
 be controlled procfs or sysfs interfaces.

 Since THP is very effective in environments with kernel page size of 4KB,
 such as x86, there is no reason to positively use HugeTLBfs, so I think
 that there is no situation to enable charge_surplus_huge_pages. However, in
 some distributions such as arm64, the page size of the kernel is 64KB, and
 the size of THP is too huge as 512MB, making it difficult to use. HugeTLBfs
 may support multiple huge page sizes, and in such a special environment
 there is a desire to use HugeTLBfs.
>>>
>>> One of the basic questions/concerns I have is accounting for surplus huge
>>> pages in the default memory resource controller.  The existing huegtlb
>>> resource controller already takes hugetlbfs huge pages into account,
>>> including surplus pages.  This series would allow surplus pages to be
>>> accounted for in the default  memory controller, or the hugetlb controller
>>> or both.
>>>
>>> I understand that current mechanisms do not meet the needs of the above
>>> use case.  The question is whether this is an appropriate way to approach
>>> the issue.
> 
> I do share your view Mike!
> 
>>> My cgroup experience and knowledge is extremely limited, but
>>> it does not appear that any other resource can be controlled by multiple
>>> controllers.  Therefore, I am concerned that this may be going against
>>> basic cgroup design philosophy.
>>
>> Thank you for your feedback.
>> That makes sense, surplus hugepages are charged to both memcg and hugetlb
>> cgroup, which may be contrary to cgroup design philosophy.
>>
>> Based on the above advice, I have considered the following improvements,
>> what do you think about?
>>
>> The 'charge_surplus_hugepages' of v2 patch-set was an option to switch
>> "whether to charge memcg in addition to hugetlb cgroup", but it will be
>> abolished. Instead, change to "switch only to memcg instead of hugetlb
>> cgroup" option. This is called 'surplus_charge_to_memcg'.
> 
> This all looks so hackish and ad-hoc that I would be tempted to give it
> an outright nack, but let's here more about why do we need this fiddling
> at all. I've asked in other email so I guess I will get an answer there
> but let me just emphasize again that I absolutely detest a possibility
> to put hugetlb pages into the memcg mix. They just do not belong there.
> Try to look at previous discussions why it has been decided to have a
> separate hugetlb pages at all.
> 
> I am also quite confused why you keep distinguishing surplus hugetlb
> pages from regular preallocated ones. Being a surplus page is an
> implementation detail that we use for an internal accounting rather than
> something to exhibit to the userspace even more than we do currently.

I apologize for having confused.

The hugetlb pages obtained from the pool do not waste the buddy pool. On
the other hand, surplus hugetlb pages waste the buddy pool. Due to this
difference in property, I thought it could be distinguished.

Although my memcg knowledge is extremely limited, memcg is accounting for
various kinds of pages obtained from the buddy pool by the task belonging
to it. I would like to argue that surplus hugepage has 

Re: [PATCH v2 0/7] mm: pages for hugetlb's overcommit may be able to charge to memcg

[TSUKADA Koutaro]

On 2018/05/23 3:54, Michal Hocko wrote:
> On Tue 22-05-18 22:04:23, TSUKADA Koutaro wrote:
>> On 2018/05/22 3:07, Mike Kravetz wrote:
>>> On 05/17/2018 09:27 PM, TSUKADA Koutaro wrote:
 Thanks to Mike Kravetz for comment on the previous version patch.

 The purpose of this patch-set is to make it possible to control whether or
 not to charge surplus hugetlb pages obtained by overcommitting to memory
 cgroup. In the future, I am trying to accomplish limiting the memory usage
 of applications that use both normal pages and hugetlb pages by the memory
 cgroup(not use the hugetlb cgroup).

 Applications that use shared libraries like libhugetlbfs.so use both normal
 pages and hugetlb pages, but we do not know how much to use each. Please
 suppose you want to manage the memory usage of such applications by cgroup
 How do you set the memory cgroup and hugetlb cgroup limit when you want to
 limit memory usage to 10GB?

 If you set a limit of 10GB for each, the user can use a total of 20GB of
 memory and can not limit it well. Since it is difficult to estimate the
 ratio used by user of normal pages and hugetlb pages, setting limits of 2GB
 to memory cgroup and 8GB to hugetlb cgroup is not very good idea. In such a
 case, I thought that by using my patch-set, we could manage resources just
 by setting 10GB as the limit of memory cgoup(there is no limit to hugetlb
 cgroup).

 In this patch-set, introduce the charge_surplus_huge_pages(boolean) to
 struct hstate. If it is true, it charges to the memory cgroup to which the
 task that obtained surplus hugepages belongs. If it is false, do nothing as
 before, and the default value is false. The charge_surplus_huge_pages can
 be controlled procfs or sysfs interfaces.

 Since THP is very effective in environments with kernel page size of 4KB,
 such as x86, there is no reason to positively use HugeTLBfs, so I think
 that there is no situation to enable charge_surplus_huge_pages. However, in
 some distributions such as arm64, the page size of the kernel is 64KB, and
 the size of THP is too huge as 512MB, making it difficult to use. HugeTLBfs
 may support multiple huge page sizes, and in such a special environment
 there is a desire to use HugeTLBfs.
>>>
>>> One of the basic questions/concerns I have is accounting for surplus huge
>>> pages in the default memory resource controller.  The existing huegtlb
>>> resource controller already takes hugetlbfs huge pages into account,
>>> including surplus pages.  This series would allow surplus pages to be
>>> accounted for in the default  memory controller, or the hugetlb controller
>>> or both.
>>>
>>> I understand that current mechanisms do not meet the needs of the above
>>> use case.  The question is whether this is an appropriate way to approach
>>> the issue.
> 
> I do share your view Mike!
> 
>>> My cgroup experience and knowledge is extremely limited, but
>>> it does not appear that any other resource can be controlled by multiple
>>> controllers.  Therefore, I am concerned that this may be going against
>>> basic cgroup design philosophy.
>>
>> Thank you for your feedback.
>> That makes sense, surplus hugepages are charged to both memcg and hugetlb
>> cgroup, which may be contrary to cgroup design philosophy.
>>
>> Based on the above advice, I have considered the following improvements,
>> what do you think about?
>>
>> The 'charge_surplus_hugepages' of v2 patch-set was an option to switch
>> "whether to charge memcg in addition to hugetlb cgroup", but it will be
>> abolished. Instead, change to "switch only to memcg instead of hugetlb
>> cgroup" option. This is called 'surplus_charge_to_memcg'.
> 
> This all looks so hackish and ad-hoc that I would be tempted to give it
> an outright nack, but let's here more about why do we need this fiddling
> at all. I've asked in other email so I guess I will get an answer there
> but let me just emphasize again that I absolutely detest a possibility
> to put hugetlb pages into the memcg mix. They just do not belong there.
> Try to look at previous discussions why it has been decided to have a
> separate hugetlb pages at all.
> 
> I am also quite confused why you keep distinguishing surplus hugetlb
> pages from regular preallocated ones. Being a surplus page is an
> implementation detail that we use for an internal accounting rather than
> something to exhibit to the userspace even more than we do currently.

I apologize for having confused.

The hugetlb pages obtained from the pool do not waste the buddy pool. On
the other hand, surplus hugetlb pages waste the buddy pool. Due to this
difference in property, I thought it could be distinguished.

Although my memcg knowledge is extremely limited, memcg is accounting for
various kinds of pages obtained from the buddy pool by the task belonging
to it. I would like to argue that surplus hugepage has 

Re: [PATCH v11 1/2] cpufreq: Add Kryo CPU scaling driver

[Viresh Kumar]

On 23-05-18, 14:25, Sudeep Holla wrote:
> On 23/05/18 13:38, Ilia Lin wrote:
> > +static int __init qcom_cpufreq_kryo_init(void)
> > +{
> > +   /*
> > +* Since the driver depends on smem and nvmem drivers, which may
> > +* return EPROBE_DEFER, all the real activity is done in the probe,
> > +* which may be defered as well. The init here is only registering
> > +* a platform device.
> > +*/
> > +   platform_device_register_simple("qcom-cpufreq-kryo", -1, NULL, 0);
> > +   return 0;
> > +}
> > +module_init(qcom_cpufreq_kryo_init);
> 
> Do you need this at all ? See below on how to eliminate the need for this.
> 
> > +
> > +static struct platform_driver qcom_cpufreq_kryo_driver = {
> > +   .probe = qcom_cpufreq_kryo_probe,
> > +   .driver = {
> > +   .name = "qcom-cpufreq-kryo",
> > +   },
> > +};
> > +builtin_platform_driver(qcom_cpufreq_kryo_driver);
> 
> Use builtin_platform_driver_probe and remove qcom_cpufreq_kryo_init
> or use module_platform_driver_probe if it can be module.

I agree with this, just use a single init routine to register both the driver
and device.

-- 
viresh

Re: [PATCH v11 1/2] cpufreq: Add Kryo CPU scaling driver

[Viresh Kumar]

On 23-05-18, 14:25, Sudeep Holla wrote:
> On 23/05/18 13:38, Ilia Lin wrote:
> > +static int __init qcom_cpufreq_kryo_init(void)
> > +{
> > +   /*
> > +* Since the driver depends on smem and nvmem drivers, which may
> > +* return EPROBE_DEFER, all the real activity is done in the probe,
> > +* which may be defered as well. The init here is only registering
> > +* a platform device.
> > +*/
> > +   platform_device_register_simple("qcom-cpufreq-kryo", -1, NULL, 0);
> > +   return 0;
> > +}
> > +module_init(qcom_cpufreq_kryo_init);
> 
> Do you need this at all ? See below on how to eliminate the need for this.
> 
> > +
> > +static struct platform_driver qcom_cpufreq_kryo_driver = {
> > +   .probe = qcom_cpufreq_kryo_probe,
> > +   .driver = {
> > +   .name = "qcom-cpufreq-kryo",
> > +   },
> > +};
> > +builtin_platform_driver(qcom_cpufreq_kryo_driver);
> 
> Use builtin_platform_driver_probe and remove qcom_cpufreq_kryo_init
> or use module_platform_driver_probe if it can be module.

I agree with this, just use a single init routine to register both the driver
and device.

-- 
viresh

Re: KASAN: use-after-free Read in vgacon_invert_region

[Kyungtae Kim]

(We analyzed the crash and added the result below.)

We report the crash:
"KASAN: use-after-free Read in vgacon_invert_region"

This crash was found in v4.17-rc3. Specifically, memory access (read
operation) is invalid and which is detected by KASAN.

Analysis:
The function "vt_do_resize" basically allows for resizing the screen
buffer (i.e., vc_data) beyond memory address 0x10
(i.e., 0x8810 in this case).
We think, however, a certain memory area starting from 0x10 is protected.
So subsequent memory access beyond this address (by
"vgacon_invert_region") causes memory access violation.

C repro code:
 https://kiwi.cs.purdue.edu/static/alexkkid-fuzzer/repro-ba6c1.c
kernel config:
 https://kiwi.cs.purdue.edu/static/alexkkid-fuzzer/kernel-config-v4.17-rc3

Crash log:
==
BUG: KASAN: use-after-free in vgacon_invert_region+0xf9/0x100
drivers/video/console/vgacon.c:663
Read of size 2 at addr 8810 by task syz-executor3/525

CPU: 0 PID: 525 Comm: syz-executor3 Not tainted 4.17.0-rc3 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0xc7/0x138 lib/dump_stack.c:113
 print_address_description+0x78/0x290 mm/kasan/report.c:256
 kasan_report_error mm/kasan/report.c:354 [inline]
 kasan_report+0x234/0x350 mm/kasan/report.c:412
 __asan_report_load2_noabort+0x19/0x20 mm/kasan/report.c:431
 vgacon_invert_region+0xf9/0x100 drivers/video/console/vgacon.c:663
 invert_screen+0x197/0x630 drivers/tty/vt/vt.c:461
 highlight drivers/tty/vt/selection.c:51 [inline]
 set_selection+0x6b7/0xf60 drivers/tty/vt/selection.c:276
 tioclinux+0x126/0x410 drivers/tty/vt/vt.c:2691
 vt_ioctl+0x1036/0x2580 drivers/tty/vt/vt_ioctl.c:362
 tty_ioctl+0x288/0x14c0 drivers/tty/tty_io.c:2646
 vfs_ioctl fs/ioctl.c:46 [inline]
 do_vfs_ioctl+0x191/0xfe0 fs/ioctl.c:686
 ksys_ioctl+0x99/0xb0 fs/ioctl.c:701
 __do_sys_ioctl fs/ioctl.c:708 [inline]
 __se_sys_ioctl fs/ioctl.c:706 [inline]
 __x64_sys_ioctl+0x78/0xb0 fs/ioctl.c:706
 do_syscall_64+0xb0/0x460 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4497b9
RSP: 002b:7f720c4bec68 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 7f720c4bf6cc RCX: 004497b9
RDX: 2040 RSI: 0002541c RDI: 0013
RBP: 0071bf58 R08:  R09: 
R10:  R11: 0246 R12: 
R13: 5aa8 R14: 006ecb48 R15: 7f720c4bf700

The buggy address belongs to the page:
page:ea004000 count:0 mapcount:-127 mapping: index:0x0
flags: 0x0()
raw:    ff80
raw: 88013fff9300 88013fff9300 0008 
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 880fff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 880fff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>8810: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   ^
 88100080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 88100100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
==


Thanks,
Kyungtae Kim

On Thu, May 17, 2018 at 2:04 PM, Kyungtae Kim  wrote:
> We report the crash:
> "KASAN: use-after-free Read in vgacon_invert_region"
>
> This crash was found in v4.17-rc3. Specifically, memory access (read
> operation) is invalid, and it is detected by KASAN.
>
> C repro code:
>  https://kiwi.cs.purdue.edu/static/alexkkid-fuzzer/repro-ba6c1.c
> kernel config:
>  https://kiwi.cs.purdue.edu/static/alexkkid-fuzzer/kernel-config-v4.17-rc3
>
> Crash log:
> ==
> BUG: KASAN: use-after-free in vgacon_invert_region+0xf9/0x100
> drivers/video/console/vgacon.c:663
> Read of size 2 at addr 8810 by task syz-executor3/525
>
> CPU: 0 PID: 525 Comm: syz-executor3 Not tainted 4.17.0-rc3 #3
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:77 [inline]
>  dump_stack+0xc7/0x138 lib/dump_stack.c:113
>  print_address_description+0x78/0x290 mm/kasan/report.c:256
>  kasan_report_error mm/kasan/report.c:354 [inline]
>  kasan_report+0x234/0x350 mm/kasan/report.c:412
>  __asan_report_load2_noabort+0x19/0x20 mm/kasan/report.c:431
>  vgacon_invert_region+0xf9/0x100 drivers/video/console/vgacon.c:663
>  invert_screen+0x197/0x630 drivers/tty/vt/vt.c:461
>  highlight drivers/tty/vt/selection.c:51 [inline]
>  set_selection+0x6b7/0xf60 drivers/tty/vt/selection.c:276
>  tioclinux+0x126/0x410 drivers/tty/vt/vt.c:2691
>  vt_ioctl+0x1036/0x2580 drivers/tty/vt/vt_ioctl.c:362
>  tty_ioctl+0x288/0x14c0 drivers/tty/tty_io.c:2646
>  

Re: KASAN: use-after-free Read in vgacon_invert_region

[Kyungtae Kim]

(We analyzed the crash and added the result below.)

We report the crash:
"KASAN: use-after-free Read in vgacon_invert_region"

This crash was found in v4.17-rc3. Specifically, memory access (read
operation) is invalid and which is detected by KASAN.

Analysis:
The function "vt_do_resize" basically allows for resizing the screen
buffer (i.e., vc_data) beyond memory address 0x10
(i.e., 0x8810 in this case).
We think, however, a certain memory area starting from 0x10 is protected.
So subsequent memory access beyond this address (by
"vgacon_invert_region") causes memory access violation.

C repro code:
 https://kiwi.cs.purdue.edu/static/alexkkid-fuzzer/repro-ba6c1.c
kernel config:
 https://kiwi.cs.purdue.edu/static/alexkkid-fuzzer/kernel-config-v4.17-rc3

Crash log:
==
BUG: KASAN: use-after-free in vgacon_invert_region+0xf9/0x100
drivers/video/console/vgacon.c:663
Read of size 2 at addr 8810 by task syz-executor3/525

CPU: 0 PID: 525 Comm: syz-executor3 Not tainted 4.17.0-rc3 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0xc7/0x138 lib/dump_stack.c:113
 print_address_description+0x78/0x290 mm/kasan/report.c:256
 kasan_report_error mm/kasan/report.c:354 [inline]
 kasan_report+0x234/0x350 mm/kasan/report.c:412
 __asan_report_load2_noabort+0x19/0x20 mm/kasan/report.c:431
 vgacon_invert_region+0xf9/0x100 drivers/video/console/vgacon.c:663
 invert_screen+0x197/0x630 drivers/tty/vt/vt.c:461
 highlight drivers/tty/vt/selection.c:51 [inline]
 set_selection+0x6b7/0xf60 drivers/tty/vt/selection.c:276
 tioclinux+0x126/0x410 drivers/tty/vt/vt.c:2691
 vt_ioctl+0x1036/0x2580 drivers/tty/vt/vt_ioctl.c:362
 tty_ioctl+0x288/0x14c0 drivers/tty/tty_io.c:2646
 vfs_ioctl fs/ioctl.c:46 [inline]
 do_vfs_ioctl+0x191/0xfe0 fs/ioctl.c:686
 ksys_ioctl+0x99/0xb0 fs/ioctl.c:701
 __do_sys_ioctl fs/ioctl.c:708 [inline]
 __se_sys_ioctl fs/ioctl.c:706 [inline]
 __x64_sys_ioctl+0x78/0xb0 fs/ioctl.c:706
 do_syscall_64+0xb0/0x460 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4497b9
RSP: 002b:7f720c4bec68 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 7f720c4bf6cc RCX: 004497b9
RDX: 2040 RSI: 0002541c RDI: 0013
RBP: 0071bf58 R08:  R09: 
R10:  R11: 0246 R12: 
R13: 5aa8 R14: 006ecb48 R15: 7f720c4bf700

The buggy address belongs to the page:
page:ea004000 count:0 mapcount:-127 mapping: index:0x0
flags: 0x0()
raw:    ff80
raw: 88013fff9300 88013fff9300 0008 
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 880fff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 880fff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>8810: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   ^
 88100080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 88100100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
==


Thanks,
Kyungtae Kim

On Thu, May 17, 2018 at 2:04 PM, Kyungtae Kim  wrote:
> We report the crash:
> "KASAN: use-after-free Read in vgacon_invert_region"
>
> This crash was found in v4.17-rc3. Specifically, memory access (read
> operation) is invalid, and it is detected by KASAN.
>
> C repro code:
>  https://kiwi.cs.purdue.edu/static/alexkkid-fuzzer/repro-ba6c1.c
> kernel config:
>  https://kiwi.cs.purdue.edu/static/alexkkid-fuzzer/kernel-config-v4.17-rc3
>
> Crash log:
> ==
> BUG: KASAN: use-after-free in vgacon_invert_region+0xf9/0x100
> drivers/video/console/vgacon.c:663
> Read of size 2 at addr 8810 by task syz-executor3/525
>
> CPU: 0 PID: 525 Comm: syz-executor3 Not tainted 4.17.0-rc3 #3
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:77 [inline]
>  dump_stack+0xc7/0x138 lib/dump_stack.c:113
>  print_address_description+0x78/0x290 mm/kasan/report.c:256
>  kasan_report_error mm/kasan/report.c:354 [inline]
>  kasan_report+0x234/0x350 mm/kasan/report.c:412
>  __asan_report_load2_noabort+0x19/0x20 mm/kasan/report.c:431
>  vgacon_invert_region+0xf9/0x100 drivers/video/console/vgacon.c:663
>  invert_screen+0x197/0x630 drivers/tty/vt/vt.c:461
>  highlight drivers/tty/vt/selection.c:51 [inline]
>  set_selection+0x6b7/0xf60 drivers/tty/vt/selection.c:276
>  tioclinux+0x126/0x410 drivers/tty/vt/vt.c:2691
>  vt_ioctl+0x1036/0x2580 drivers/tty/vt/vt_ioctl.c:362
>  tty_ioctl+0x288/0x14c0 drivers/tty/tty_io.c:2646
>  vfs_ioctl 

Re: [PATCH v11 1/2] cpufreq: Add Kryo CPU scaling driver

[Viresh Kumar]

On 23-05-18, 14:25, Sudeep Holla wrote:
> On 23/05/18 13:38, Ilia Lin wrote:
> > +config ARM_QCOM_CPUFREQ_KRYO
> > +   bool "Qualcomm Kryo based CPUFreq"
> > +   depends on QCOM_QFPROM
> > +   depends on QCOM_SMEM
> > +   select PM_OPP
> > +   help
> > + This adds the CPUFreq driver for Qualcomm Kryo SoC based boards.
> > +
> > + If in doubt, say N.
> > +
> 
> Sorry but just noticed now, any reason why this can't be module. I can't
> imagine any.

Actually I asked him to do that as cpufreq-dt itself can be compiled
in as module and this driver wasn't doing much and isn't big enough
(size wise) as well.

-- 
viresh

Re: [PATCH v11 1/2] cpufreq: Add Kryo CPU scaling driver

[Viresh Kumar]

On 23-05-18, 14:25, Sudeep Holla wrote:
> On 23/05/18 13:38, Ilia Lin wrote:
> > +config ARM_QCOM_CPUFREQ_KRYO
> > +   bool "Qualcomm Kryo based CPUFreq"
> > +   depends on QCOM_QFPROM
> > +   depends on QCOM_SMEM
> > +   select PM_OPP
> > +   help
> > + This adds the CPUFreq driver for Qualcomm Kryo SoC based boards.
> > +
> > + If in doubt, say N.
> > +
> 
> Sorry but just noticed now, any reason why this can't be module. I can't
> imagine any.

Actually I asked him to do that as cpufreq-dt itself can be compiled
in as module and this driver wasn't doing much and isn't big enough
(size wise) as well.

-- 
viresh

Re: [PATCH v1 2/2] cpufreq: tegra20: Use PLL_C as intermediate clock source

[Viresh Kumar]

On 23-05-18, 19:00, Dmitry Osipenko wrote:
> PLL_C is running at 600MHz which is significantly higher than the 216MHz
> of the PLL_P and it is known that PLL_C is always-ON because AHB BUS is
> running on that PLL. Let's use PLL_C as intermediate clock source, making
> CPU snappier a tad during of the frequency transition.
> 
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/cpufreq/tegra20-cpufreq.c | 25 +
>  1 file changed, 21 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/cpufreq/tegra20-cpufreq.c 
> b/drivers/cpufreq/tegra20-cpufreq.c
> index 3ad6bded6efc..4bf5ba7da40b 100644
> --- a/drivers/cpufreq/tegra20-cpufreq.c
> +++ b/drivers/cpufreq/tegra20-cpufreq.c
> @@ -25,12 +25,13 @@
>  #include 
>  
>  #define PLL_P_FREQ   216000
> +#define PLL_C_FREQ   60
>  
>  static struct cpufreq_frequency_table freq_table[] = {
>   { .frequency = 216000 },
>   { .frequency = 312000 },
>   { .frequency = 456000 },
> - { .frequency = 608000 },
> + { .frequency = 60 },
>   { .frequency = 76 },
>   { .frequency = 816000 },
>   { .frequency = 912000 },
> @@ -44,6 +45,7 @@ struct tegra20_cpufreq {
>   struct clk *cpu_clk;
>   struct clk *pll_x_clk;
>   struct clk *pll_p_clk;
> + struct clk *pll_c_clk;
>   bool pll_x_prepared;
>  };
>  
> @@ -58,7 +60,10 @@ static unsigned int tegra_get_intermediate(struct 
> cpufreq_policy *policy,
>   if (index == 0 || policy->cur == PLL_P_FREQ)
>   return 0;
>  
> - return PLL_P_FREQ;
> + if (index == 3 || policy->cur == PLL_C_FREQ)
> + return 0;

So we can choose between two different intermediate frequencies ? And
I didn't like the way magic number 3 is used here. Its prone to errors
and we better use a macro or something else here.

Like instead of doing index == 3, what about freq_table[index].freq ==
PLL_C_FREQ ? Same for the previous patch as well.

-- 
viresh

Re: [PATCH v1 2/2] cpufreq: tegra20: Use PLL_C as intermediate clock source

[Viresh Kumar]

On 23-05-18, 19:00, Dmitry Osipenko wrote:
> PLL_C is running at 600MHz which is significantly higher than the 216MHz
> of the PLL_P and it is known that PLL_C is always-ON because AHB BUS is
> running on that PLL. Let's use PLL_C as intermediate clock source, making
> CPU snappier a tad during of the frequency transition.
> 
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/cpufreq/tegra20-cpufreq.c | 25 +
>  1 file changed, 21 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/cpufreq/tegra20-cpufreq.c 
> b/drivers/cpufreq/tegra20-cpufreq.c
> index 3ad6bded6efc..4bf5ba7da40b 100644
> --- a/drivers/cpufreq/tegra20-cpufreq.c
> +++ b/drivers/cpufreq/tegra20-cpufreq.c
> @@ -25,12 +25,13 @@
>  #include 
>  
>  #define PLL_P_FREQ   216000
> +#define PLL_C_FREQ   60
>  
>  static struct cpufreq_frequency_table freq_table[] = {
>   { .frequency = 216000 },
>   { .frequency = 312000 },
>   { .frequency = 456000 },
> - { .frequency = 608000 },
> + { .frequency = 60 },
>   { .frequency = 76 },
>   { .frequency = 816000 },
>   { .frequency = 912000 },
> @@ -44,6 +45,7 @@ struct tegra20_cpufreq {
>   struct clk *cpu_clk;
>   struct clk *pll_x_clk;
>   struct clk *pll_p_clk;
> + struct clk *pll_c_clk;
>   bool pll_x_prepared;
>  };
>  
> @@ -58,7 +60,10 @@ static unsigned int tegra_get_intermediate(struct 
> cpufreq_policy *policy,
>   if (index == 0 || policy->cur == PLL_P_FREQ)
>   return 0;
>  
> - return PLL_P_FREQ;
> + if (index == 3 || policy->cur == PLL_C_FREQ)
> + return 0;

So we can choose between two different intermediate frequencies ? And
I didn't like the way magic number 3 is used here. Its prone to errors
and we better use a macro or something else here.

Like instead of doing index == 3, what about freq_table[index].freq ==
PLL_C_FREQ ? Same for the previous patch as well.

-- 
viresh

Re: [PATCH v1 1/2] cpufreq: tegra20: Constify rate value of the intermediate clk

[Viresh Kumar]

On 23-05-18, 19:00, Dmitry Osipenko wrote:
> PLL_P is known to be always running at 216MHz, hence there is no need to
> query its rate.
> 
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/cpufreq/tegra20-cpufreq.c | 12 +---
>  1 file changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/cpufreq/tegra20-cpufreq.c 
> b/drivers/cpufreq/tegra20-cpufreq.c
> index 05f57dcd5215..3ad6bded6efc 100644
> --- a/drivers/cpufreq/tegra20-cpufreq.c
> +++ b/drivers/cpufreq/tegra20-cpufreq.c
> @@ -24,6 +24,8 @@
>  #include 
>  #include 
>  
> +#define PLL_P_FREQ   216000
> +
>  static struct cpufreq_frequency_table freq_table[] = {
>   { .frequency = 216000 },
>   { .frequency = 312000 },
> @@ -48,18 +50,15 @@ struct tegra20_cpufreq {
>  static unsigned int tegra_get_intermediate(struct cpufreq_policy *policy,
>  unsigned int index)
>  {
> - struct tegra20_cpufreq *cpufreq = cpufreq_get_driver_data();
> - unsigned int ifreq = clk_get_rate(cpufreq->pll_p_clk) / 1000;
> -
>   /*
>* Don't switch to intermediate freq if:
>* - we are already at it, i.e. policy->cur == ifreq
>* - index corresponds to ifreq
>*/
> - if (freq_table[index].frequency == ifreq || policy->cur == ifreq)
> + if (index == 0 || policy->cur == PLL_P_FREQ)
>   return 0;
>  
> - return ifreq;
> + return PLL_P_FREQ;
>  }
>  
>  static int tegra_target_intermediate(struct cpufreq_policy *policy,
> @@ -93,14 +92,13 @@ static int tegra_target(struct cpufreq_policy *policy, 
> unsigned int index)
>  {
>   struct tegra20_cpufreq *cpufreq = cpufreq_get_driver_data();
>   unsigned long rate = freq_table[index].frequency;
> - unsigned int ifreq = clk_get_rate(cpufreq->pll_p_clk) / 1000;
>   int ret;
>  
>   /*
>* target freq == pll_p, don't need to take extra reference to pll_x_clk
>* as it isn't used anymore.
>*/
> - if (rate == ifreq)
> + if (index == 0)
>   return clk_set_parent(cpufreq->cpu_clk, cpufreq->pll_p_clk);
>  
>   ret = clk_set_rate(cpufreq->pll_x_clk, rate * 1000);

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH v1 1/2] cpufreq: tegra20: Constify rate value of the intermediate clk

[Viresh Kumar]

On 23-05-18, 19:00, Dmitry Osipenko wrote:
> PLL_P is known to be always running at 216MHz, hence there is no need to
> query its rate.
> 
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/cpufreq/tegra20-cpufreq.c | 12 +---
>  1 file changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/cpufreq/tegra20-cpufreq.c 
> b/drivers/cpufreq/tegra20-cpufreq.c
> index 05f57dcd5215..3ad6bded6efc 100644
> --- a/drivers/cpufreq/tegra20-cpufreq.c
> +++ b/drivers/cpufreq/tegra20-cpufreq.c
> @@ -24,6 +24,8 @@
>  #include 
>  #include 
>  
> +#define PLL_P_FREQ   216000
> +
>  static struct cpufreq_frequency_table freq_table[] = {
>   { .frequency = 216000 },
>   { .frequency = 312000 },
> @@ -48,18 +50,15 @@ struct tegra20_cpufreq {
>  static unsigned int tegra_get_intermediate(struct cpufreq_policy *policy,
>  unsigned int index)
>  {
> - struct tegra20_cpufreq *cpufreq = cpufreq_get_driver_data();
> - unsigned int ifreq = clk_get_rate(cpufreq->pll_p_clk) / 1000;
> -
>   /*
>* Don't switch to intermediate freq if:
>* - we are already at it, i.e. policy->cur == ifreq
>* - index corresponds to ifreq
>*/
> - if (freq_table[index].frequency == ifreq || policy->cur == ifreq)
> + if (index == 0 || policy->cur == PLL_P_FREQ)
>   return 0;
>  
> - return ifreq;
> + return PLL_P_FREQ;
>  }
>  
>  static int tegra_target_intermediate(struct cpufreq_policy *policy,
> @@ -93,14 +92,13 @@ static int tegra_target(struct cpufreq_policy *policy, 
> unsigned int index)
>  {
>   struct tegra20_cpufreq *cpufreq = cpufreq_get_driver_data();
>   unsigned long rate = freq_table[index].frequency;
> - unsigned int ifreq = clk_get_rate(cpufreq->pll_p_clk) / 1000;
>   int ret;
>  
>   /*
>* target freq == pll_p, don't need to take extra reference to pll_x_clk
>* as it isn't used anymore.
>*/
> - if (rate == ifreq)
> + if (index == 0)
>   return clk_set_parent(cpufreq->cpu_clk, cpufreq->pll_p_clk);
>  
>   ret = clk_set_rate(cpufreq->pll_x_clk, rate * 1000);

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH v2 0/7] mm: pages for hugetlb's overcommit may be able to charge to memcg

[TSUKADA Koutaro]

On 2018/05/22 22:51, Michal Hocko wrote:
> On Fri 18-05-18 13:27:27, TSUKADA Koutaro wrote:
>> The purpose of this patch-set is to make it possible to control whether or
>> not to charge surplus hugetlb pages obtained by overcommitting to memory
>> cgroup. In the future, I am trying to accomplish limiting the memory usage
>> of applications that use both normal pages and hugetlb pages by the memory
>> cgroup(not use the hugetlb cgroup).
> 
> There was a deliberate decision to keep hugetlb and "normal" memory
> cgroup controllers separate. Mostly because hugetlb memory is an
> artificial memory subsystem on its own and it doesn't fit into the rest
> of memcg accounted memory very well. I believe we want to keep that
> status quo.
> 
>> Applications that use shared libraries like libhugetlbfs.so use both normal
>> pages and hugetlb pages, but we do not know how much to use each. Please
>> suppose you want to manage the memory usage of such applications by cgroup
>> How do you set the memory cgroup and hugetlb cgroup limit when you want to
>> limit memory usage to 10GB?
> 
> Well such a usecase requires an explicit configuration already. Either
> by using special wrappers or modifying the code. So I would argue that
> you have quite a good knowlege of the setup. If you need a greater
> flexibility then just do not use hugetlb at all and rely on THP.
> [...]
> 
>> In this patch-set, introduce the charge_surplus_huge_pages(boolean) to
>> struct hstate. If it is true, it charges to the memory cgroup to which the
>> task that obtained surplus hugepages belongs. If it is false, do nothing as
>> before, and the default value is false. The charge_surplus_huge_pages can
>> be controlled procfs or sysfs interfaces.
> 
> I do not really think this is a good idea. We really do not want to make
> the current hugetlb code more complex than it is already. The current
> hugetlb cgroup controller is simple and works at least somehow. I would
> not add more on top unless there is a _really_ strong usecase behind.
> Please make sure to describe such a usecase in details before we even
> start considering the code.

Thank you for your time.

I do not know if it is really a strong use case, but I will explain my
motive in detail. English is not my native language, so please pardon
my poor English.

I am one of the developers for software that managing the resource used
from user job at HPC-Cluster with Linux. The resource is memory mainly.
The HPC-Cluster may be shared by multiple people and used. Therefore, the
memory used by each user must be strictly controlled, otherwise the
user's job will runaway, not only will it hamper the other users, it will
crash the entire system in OOM.

Some users of HPC are very nervous about performance. Jobs are executed
while synchronizing with MPI communication using multiple compute nodes.
Since CPU wait time will occur when synchronizing, they want to minimize
the variation in execution time at each node to reduce waiting times as
much as possible. We call this variation a noise.

THP does not guarantee to use the Huge Page, but may use the normal page.
This mechanism is one cause of variation(noise).

The users who know this mechanism will be hesitant to use THP. However,
the users also know the benefits of the Huge Page's TLB hit rate
performance, and the Huge Page seems to be attractive. It seems natural
that these users are interested in HugeTLBfs, I do not know at all
whether it is the right approach or not.

At the very least, our HPC system is pursuing high versatility and we
have to consider whether we can provide it if users want to use HugeTLBfs.

In order to use HugeTLBfs we need to create a persistent pool, but in
our use case sharing nodes, it would be impossible to create, delete or
resize the pool.

One of the answers I have reached is to use HugeTLBfs by overcommitting
without creating a pool(this is the surplus hugepage).

Surplus hugepages is hugetlb page, but I think at least that consuming
buddy pool is a decisive difference from hugetlb page of persistent pool.
If nr_overcommit_hugepages is assumed to be infinite, allocating pages for
surplus hugepages from buddy pool is all unlimited even if being limited
by memcg. In extreme cases, overcommitment will allow users to exhaust
the entire memory of the system. Of course, this can be prevented by the
hugetlb cgroup, but even if we set the limit for memcg and hugetlb cgroup
respectively, as I asked in the first mail(set limit to 10GB), the
control will not work.

I thought I could charge surplus hugepages to memcg, but maybe I did not
have enough knowledge about memcg. I would like to reply to another mail
for details.

>> Since THP is very effective in environments with kernel page size of 4KB,
>> such as x86, there is no reason to positively use HugeTLBfs, so I think
>> that there is no situation to enable charge_surplus_huge_pages. However, in
>> some distributions such as arm64, the page size of the kernel is 64KB, and

Re: [PATCH v2 0/7] mm: pages for hugetlb's overcommit may be able to charge to memcg

[TSUKADA Koutaro]

On 2018/05/22 22:51, Michal Hocko wrote:
> On Fri 18-05-18 13:27:27, TSUKADA Koutaro wrote:
>> The purpose of this patch-set is to make it possible to control whether or
>> not to charge surplus hugetlb pages obtained by overcommitting to memory
>> cgroup. In the future, I am trying to accomplish limiting the memory usage
>> of applications that use both normal pages and hugetlb pages by the memory
>> cgroup(not use the hugetlb cgroup).
> 
> There was a deliberate decision to keep hugetlb and "normal" memory
> cgroup controllers separate. Mostly because hugetlb memory is an
> artificial memory subsystem on its own and it doesn't fit into the rest
> of memcg accounted memory very well. I believe we want to keep that
> status quo.
> 
>> Applications that use shared libraries like libhugetlbfs.so use both normal
>> pages and hugetlb pages, but we do not know how much to use each. Please
>> suppose you want to manage the memory usage of such applications by cgroup
>> How do you set the memory cgroup and hugetlb cgroup limit when you want to
>> limit memory usage to 10GB?
> 
> Well such a usecase requires an explicit configuration already. Either
> by using special wrappers or modifying the code. So I would argue that
> you have quite a good knowlege of the setup. If you need a greater
> flexibility then just do not use hugetlb at all and rely on THP.
> [...]
> 
>> In this patch-set, introduce the charge_surplus_huge_pages(boolean) to
>> struct hstate. If it is true, it charges to the memory cgroup to which the
>> task that obtained surplus hugepages belongs. If it is false, do nothing as
>> before, and the default value is false. The charge_surplus_huge_pages can
>> be controlled procfs or sysfs interfaces.
> 
> I do not really think this is a good idea. We really do not want to make
> the current hugetlb code more complex than it is already. The current
> hugetlb cgroup controller is simple and works at least somehow. I would
> not add more on top unless there is a _really_ strong usecase behind.
> Please make sure to describe such a usecase in details before we even
> start considering the code.

Thank you for your time.

I do not know if it is really a strong use case, but I will explain my
motive in detail. English is not my native language, so please pardon
my poor English.

I am one of the developers for software that managing the resource used
from user job at HPC-Cluster with Linux. The resource is memory mainly.
The HPC-Cluster may be shared by multiple people and used. Therefore, the
memory used by each user must be strictly controlled, otherwise the
user's job will runaway, not only will it hamper the other users, it will
crash the entire system in OOM.

Some users of HPC are very nervous about performance. Jobs are executed
while synchronizing with MPI communication using multiple compute nodes.
Since CPU wait time will occur when synchronizing, they want to minimize
the variation in execution time at each node to reduce waiting times as
much as possible. We call this variation a noise.

THP does not guarantee to use the Huge Page, but may use the normal page.
This mechanism is one cause of variation(noise).

The users who know this mechanism will be hesitant to use THP. However,
the users also know the benefits of the Huge Page's TLB hit rate
performance, and the Huge Page seems to be attractive. It seems natural
that these users are interested in HugeTLBfs, I do not know at all
whether it is the right approach or not.

At the very least, our HPC system is pursuing high versatility and we
have to consider whether we can provide it if users want to use HugeTLBfs.

In order to use HugeTLBfs we need to create a persistent pool, but in
our use case sharing nodes, it would be impossible to create, delete or
resize the pool.

One of the answers I have reached is to use HugeTLBfs by overcommitting
without creating a pool(this is the surplus hugepage).

Surplus hugepages is hugetlb page, but I think at least that consuming
buddy pool is a decisive difference from hugetlb page of persistent pool.
If nr_overcommit_hugepages is assumed to be infinite, allocating pages for
surplus hugepages from buddy pool is all unlimited even if being limited
by memcg. In extreme cases, overcommitment will allow users to exhaust
the entire memory of the system. Of course, this can be prevented by the
hugetlb cgroup, but even if we set the limit for memcg and hugetlb cgroup
respectively, as I asked in the first mail(set limit to 10GB), the
control will not work.

I thought I could charge surplus hugepages to memcg, but maybe I did not
have enough knowledge about memcg. I would like to reply to another mail
for details.

>> Since THP is very effective in environments with kernel page size of 4KB,
>> such as x86, there is no reason to positively use HugeTLBfs, so I think
>> that there is no situation to enable charge_surplus_huge_pages. However, in
>> some distributions such as arm64, the page size of the kernel is 64KB, and

Re: linux-next: build warning after merge of the mac80211-next tree

[Kalle Valo]

Arnd Bergmann  writes:

> On Fri, May 11, 2018 at 2:20 PM, Kalle Valo  wrote:
>> Stephen Rothwell  writes:
>>
>>> After merging the mac80211-next tree, today's linux-next build (arm_multi
>>> v7_defconfig) produced this warning:
>>>
>>> drivers/net/wireless/marvell/mwifiex/uap_event.c: In function 
>>> 'mwifiex_process_uap_event':
>>> drivers/net/wireless/marvell/mwifiex/uap_event.c:333:1: warning: the frame 
>>> size of 1680 bytes is larger than 1024 bytes [-Wframe-larger-than=]
>>>  }
>>>  ^
>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c: In function 
>>> 'brcmf_notify_connect_status_ap':
>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:5530:1: 
>>> warning: the frame size of 1680 bytes is larger than 1024 bytes 
>>> [-Wframe-larger-than=]
>>>  }
>>>  ^
>>>
>>> Maybe introduced by commit
>>>
>>>   52539ca89f36 ("cfg80211: Expose TXQ stats and parameters to userspace")
>>
>> Btw Stephen for mac80211 reports it would be a good idea to also cc
>> linux-wireless list, in case Johannes is not around etc.
>
> I also bisected this new warning to the same commit above:
>
> net/batman-adv/bat_v_elp.c: In function 'batadv_v_elp_get_throughput':
> net/batman-adv/bat_v_elp.c:154:1: warning: the frame size of 1736
> bytes is larger than 1024 bytes [-Wframe-larger-than=]

This should fix it:

8689c051a201 cfg80211: dynamically allocate per-tid stats for station info

https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git/commit/?id=8689c051a20195b228e19acb155c7d6e48a86753

-- 
Kalle Valo

Re: [PATCH] sound: Use octal not symbolic permissions

[Vinod]

On 23-05-18, 12:20, Joe Perches wrote:
> Convert the S_ symbolic permissions to their octal equivalents as
> using octal and not symbolic permissions is preferred by many as more
> readable.
> 
> see: https://lkml.org/lkml/2016/8/2/1945
> 
> Done with automated conversion via:
> $ ./scripts/checkpatch.pl -f --types=SYMBOLIC_PERMS --fix-inplace 
> 
> Miscellanea:
> 
> o Wrapped one multi-line call to a single line
> 
> Signed-off-by: Joe Perches 
> ---
>  sound/core/compress_offload.c |  2 +-

Acked-By: Vinod Koul 

-- 
~Vinod

Re: linux-next: build warning after merge of the mac80211-next tree

[Kalle Valo]

Arnd Bergmann  writes:

> On Fri, May 11, 2018 at 2:20 PM, Kalle Valo  wrote:
>> Stephen Rothwell  writes:
>>
>>> After merging the mac80211-next tree, today's linux-next build (arm_multi
>>> v7_defconfig) produced this warning:
>>>
>>> drivers/net/wireless/marvell/mwifiex/uap_event.c: In function 
>>> 'mwifiex_process_uap_event':
>>> drivers/net/wireless/marvell/mwifiex/uap_event.c:333:1: warning: the frame 
>>> size of 1680 bytes is larger than 1024 bytes [-Wframe-larger-than=]
>>>  }
>>>  ^
>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c: In function 
>>> 'brcmf_notify_connect_status_ap':
>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:5530:1: 
>>> warning: the frame size of 1680 bytes is larger than 1024 bytes 
>>> [-Wframe-larger-than=]
>>>  }
>>>  ^
>>>
>>> Maybe introduced by commit
>>>
>>>   52539ca89f36 ("cfg80211: Expose TXQ stats and parameters to userspace")
>>
>> Btw Stephen for mac80211 reports it would be a good idea to also cc
>> linux-wireless list, in case Johannes is not around etc.
>
> I also bisected this new warning to the same commit above:
>
> net/batman-adv/bat_v_elp.c: In function 'batadv_v_elp_get_throughput':
> net/batman-adv/bat_v_elp.c:154:1: warning: the frame size of 1736
> bytes is larger than 1024 bytes [-Wframe-larger-than=]

This should fix it:

8689c051a201 cfg80211: dynamically allocate per-tid stats for station info

https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git/commit/?id=8689c051a20195b228e19acb155c7d6e48a86753

-- 
Kalle Valo

Re: [PATCH] sound: Use octal not symbolic permissions

[Vinod]

On 23-05-18, 12:20, Joe Perches wrote:
> Convert the S_ symbolic permissions to their octal equivalents as
> using octal and not symbolic permissions is preferred by many as more
> readable.
> 
> see: https://lkml.org/lkml/2016/8/2/1945
> 
> Done with automated conversion via:
> $ ./scripts/checkpatch.pl -f --types=SYMBOLIC_PERMS --fix-inplace 
> 
> Miscellanea:
> 
> o Wrapped one multi-line call to a single line
> 
> Signed-off-by: Joe Perches 
> ---
>  sound/core/compress_offload.c |  2 +-

Acked-By: Vinod Koul 

-- 
~Vinod

Re: Bugs involving maliciously crafted file system

[Dave Chinner]

On Wed, May 23, 2018 at 08:59:06PM -0400, Theodore Y. Ts'o wrote:
> On Thu, May 24, 2018 at 10:49:31AM +1000, Dave Chinner wrote:
> > 
> > We've learnt this lesson the hard way over and over again: don't
> > parse untrusted input in privileged contexts. How many times do we
> > have to make the same mistakes before people start to learn from
> > them?
> 
> Good question.  For how many years (or is it decades, now) has Fedora
> auto-mounted USB sticks?  :-) Let me know when you successfully get
> Fedora to turn of a feature which appears to have great user appeal.

They'll do that when we provide them with a safe, easy to use
solution to the problem. This is our problem to solve, not
blame-shift it away.

> And I'll note that Eric Beiderman just posted a patch series allowing
> unprivileged processes to mount file systems in containers.

Yup, that's to make it easy for virtual kernel filesystems to be
mounted inside containers, and to solve some of FUSEs security
issues caused by needing root permissions to mount FUSE filesystems.

Enabling unprivileged mounts requires an opt-in flag in the
filesystem fs-type definition, and we most certainly won't be
setting that flag on XFS. I also doubt it will ever get set on any
other existing block device based filesystem because of the trust
model problems it exposes.

> And remember the mantra which the containner people keep chanting.
> Containers are just as secure as VM's.   Hahahaha.

So your solution is to have VM guests and container users spin up
sandboxed VMs to access filesystem images safely? That's not really
a practical solution. :/

> > User automounting of removable storage should be done via a
> > privilege separation mechanism and hence avoid this whole class of
> > security problems. We can get this separation by using FUSE in these
> > situations, right?
> 
> FUSE is a pretty terrible security boundary.

That may be true, but it's so much better than using the kernel to
parse untrusted filesystem metadata.

> And not all file systems
> have FUSE support.

Except there is now fusefs-lkl, so all kernel filesystem are fully
accessible through FUSE.

> > Bugs don't have to be exploitable to be a "security issue". Detected
> > filesystem corruptions on a errors=panic mount, or undetected
> > problems that cause a x/NULL deref are still a user-triggerable
> > kernel crash (i.e. a DOS) and therefore considered a security
> > problem.
> 
> I disagree here.  I think it's worth it to disambiguate the two.

Been trying to get security people to understand this for years.
I've given up because there's always some new security person who
follows The Process and simply does not understand that there is a
difference.

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: Bugs involving maliciously crafted file system

[Dave Chinner]

On Wed, May 23, 2018 at 08:59:06PM -0400, Theodore Y. Ts'o wrote:
> On Thu, May 24, 2018 at 10:49:31AM +1000, Dave Chinner wrote:
> > 
> > We've learnt this lesson the hard way over and over again: don't
> > parse untrusted input in privileged contexts. How many times do we
> > have to make the same mistakes before people start to learn from
> > them?
> 
> Good question.  For how many years (or is it decades, now) has Fedora
> auto-mounted USB sticks?  :-) Let me know when you successfully get
> Fedora to turn of a feature which appears to have great user appeal.

They'll do that when we provide them with a safe, easy to use
solution to the problem. This is our problem to solve, not
blame-shift it away.

> And I'll note that Eric Beiderman just posted a patch series allowing
> unprivileged processes to mount file systems in containers.

Yup, that's to make it easy for virtual kernel filesystems to be
mounted inside containers, and to solve some of FUSEs security
issues caused by needing root permissions to mount FUSE filesystems.

Enabling unprivileged mounts requires an opt-in flag in the
filesystem fs-type definition, and we most certainly won't be
setting that flag on XFS. I also doubt it will ever get set on any
other existing block device based filesystem because of the trust
model problems it exposes.

> And remember the mantra which the containner people keep chanting.
> Containers are just as secure as VM's.   Hahahaha.

So your solution is to have VM guests and container users spin up
sandboxed VMs to access filesystem images safely? That's not really
a practical solution. :/

> > User automounting of removable storage should be done via a
> > privilege separation mechanism and hence avoid this whole class of
> > security problems. We can get this separation by using FUSE in these
> > situations, right?
> 
> FUSE is a pretty terrible security boundary.

That may be true, but it's so much better than using the kernel to
parse untrusted filesystem metadata.

> And not all file systems
> have FUSE support.

Except there is now fusefs-lkl, so all kernel filesystem are fully
accessible through FUSE.

> > Bugs don't have to be exploitable to be a "security issue". Detected
> > filesystem corruptions on a errors=panic mount, or undetected
> > problems that cause a x/NULL deref are still a user-triggerable
> > kernel crash (i.e. a DOS) and therefore considered a security
> > problem.
> 
> I disagree here.  I think it's worth it to disambiguate the two.

Been trying to get security people to understand this for years.
I've given up because there's always some new security person who
follows The Process and simply does not understand that there is a
difference.

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: [PATCH 3/4] rcu: Use better variable names in funnel locking loop

[Paul E. McKenney]

On Wed, May 23, 2018 at 05:54:50PM -0700, Joel Fernandes wrote:
> On Wed, May 23, 2018 at 12:23:49PM -0700, Paul E. McKenney wrote:
> > On Wed, May 23, 2018 at 09:06:17AM -0700, Paul E. McKenney wrote:
> > > On Tue, May 22, 2018 at 11:38:14PM -0700, Joel Fernandes wrote:
> > > > From: "Joel Fernandes (Google)" 
> > > > 
> > > > The funnel locking loop in rcu_start_this_gp uses rcu_root as a
> > > > temporary variable while walking the combining tree. This causes a
> > > > tiresome exercise of a code reader reminding themselves that rcu_root
> > > > may not be root. Lets just call it rnp, and rename other variables as
> > > > well to be more appropriate.
> > > > 
> > > > Original patch: https://patchwork.kernel.org/patch/10396577/
> > > > 
> > > > Signed-off-by: Joel Fernandes 
> > > > Signed-off-by: Joel Fernandes (Google) 
> > > 
> > > I used to have double Signed-off-by back when I was seconded to Linaro.
> > > But I am guessing that you want the second and don't need the first
> > > one.  Unless you tell me otherwise, I will remove the first one on
> > > my next rebase.
> > > 
> > > Anyway, the new variable names are much more clear, good stuff,
> > > queued for further review and testing, thank you!
> > 
> > And it looks to me like I should fold in the patchlet below to change to
> > rnp_start in a comment.  Please let me know if this would mess things up.
> 
> Yes, missed that. Sorry. It looks great, thanks!

Done!  And not a problem -- this is after all why we do reviews.

Thanx, Paul

Re: [PATCH 3/4] rcu: Use better variable names in funnel locking loop

[Paul E. McKenney]

On Wed, May 23, 2018 at 05:54:50PM -0700, Joel Fernandes wrote:
> On Wed, May 23, 2018 at 12:23:49PM -0700, Paul E. McKenney wrote:
> > On Wed, May 23, 2018 at 09:06:17AM -0700, Paul E. McKenney wrote:
> > > On Tue, May 22, 2018 at 11:38:14PM -0700, Joel Fernandes wrote:
> > > > From: "Joel Fernandes (Google)" 
> > > > 
> > > > The funnel locking loop in rcu_start_this_gp uses rcu_root as a
> > > > temporary variable while walking the combining tree. This causes a
> > > > tiresome exercise of a code reader reminding themselves that rcu_root
> > > > may not be root. Lets just call it rnp, and rename other variables as
> > > > well to be more appropriate.
> > > > 
> > > > Original patch: https://patchwork.kernel.org/patch/10396577/
> > > > 
> > > > Signed-off-by: Joel Fernandes 
> > > > Signed-off-by: Joel Fernandes (Google) 
> > > 
> > > I used to have double Signed-off-by back when I was seconded to Linaro.
> > > But I am guessing that you want the second and don't need the first
> > > one.  Unless you tell me otherwise, I will remove the first one on
> > > my next rebase.
> > > 
> > > Anyway, the new variable names are much more clear, good stuff,
> > > queued for further review and testing, thank you!
> > 
> > And it looks to me like I should fold in the patchlet below to change to
> > rnp_start in a comment.  Please let me know if this would mess things up.
> 
> Yes, missed that. Sorry. It looks great, thanks!

Done!  And not a problem -- this is after all why we do reviews.

Thanx, Paul

[PATCH] scripts: Fixed printf format mismatch

[nixiaoming]

scripts/kallsyms.c: function write_src:
"printf", the #1 format specifier "d" need arg type "int",
but the according arg "table_cnt" has type "unsigned int"

scripts/recordmcount.c: function do_file:
"fprintf", the #1 format specifier "d" need arg type "int",
but the according arg "(*w2)(ehdr->e_machine)" has type "unsigned int"

scripts/recordmcount.h: function find_secsym_ndx:
"fprintf", the #1 format specifier "d" need arg type "int",
but the according arg "txtndx" has type "unsigned int"

Signed-off-by: nixiaoming 
---
 scripts/kallsyms.c | 2 +-
 scripts/recordmcount.c | 2 +-
 scripts/recordmcount.h | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
index 5abfbf1..e0c416a 100644
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
@@ -424,7 +424,7 @@ static void write_src(void)
}
 
output_label("kallsyms_num_syms");
-   printf("\tPTR\t%d\n", table_cnt);
+   printf("\tPTR\t%u\n", table_cnt);
printf("\n");
 
/* table of offset markers, that give the offset in the compressed 
stream
diff --git a/scripts/recordmcount.c b/scripts/recordmcount.c
index 8c9691c..895c40e 100644
--- a/scripts/recordmcount.c
+++ b/scripts/recordmcount.c
@@ -500,7 +500,7 @@ do_file(char const *const fname)
gpfx = 0;
switch (w2(ehdr->e_machine)) {
default:
-   fprintf(stderr, "unrecognized e_machine %d %s\n",
+   fprintf(stderr, "unrecognized e_machine %u %s\n",
w2(ehdr->e_machine), fname);
fail_file();
break;
diff --git a/scripts/recordmcount.h b/scripts/recordmcount.h
index b9897e2..2e77937 100644
--- a/scripts/recordmcount.h
+++ b/scripts/recordmcount.h
@@ -441,7 +441,7 @@ static unsigned find_secsym_ndx(unsigned const txtndx,
return symp - sym0;
}
}
-   fprintf(stderr, "Cannot find symbol for section %d: %s.\n",
+   fprintf(stderr, "Cannot find symbol for section %u: %s.\n",
txtndx, txtname);
fail_file();
 }
-- 
2.10.1

[PATCH] scripts: Fixed printf format mismatch

[nixiaoming]

scripts/kallsyms.c: function write_src:
"printf", the #1 format specifier "d" need arg type "int",
but the according arg "table_cnt" has type "unsigned int"

scripts/recordmcount.c: function do_file:
"fprintf", the #1 format specifier "d" need arg type "int",
but the according arg "(*w2)(ehdr->e_machine)" has type "unsigned int"

scripts/recordmcount.h: function find_secsym_ndx:
"fprintf", the #1 format specifier "d" need arg type "int",
but the according arg "txtndx" has type "unsigned int"

Signed-off-by: nixiaoming 
---
 scripts/kallsyms.c | 2 +-
 scripts/recordmcount.c | 2 +-
 scripts/recordmcount.h | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
index 5abfbf1..e0c416a 100644
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
@@ -424,7 +424,7 @@ static void write_src(void)
}
 
output_label("kallsyms_num_syms");
-   printf("\tPTR\t%d\n", table_cnt);
+   printf("\tPTR\t%u\n", table_cnt);
printf("\n");
 
/* table of offset markers, that give the offset in the compressed 
stream
diff --git a/scripts/recordmcount.c b/scripts/recordmcount.c
index 8c9691c..895c40e 100644
--- a/scripts/recordmcount.c
+++ b/scripts/recordmcount.c
@@ -500,7 +500,7 @@ do_file(char const *const fname)
gpfx = 0;
switch (w2(ehdr->e_machine)) {
default:
-   fprintf(stderr, "unrecognized e_machine %d %s\n",
+   fprintf(stderr, "unrecognized e_machine %u %s\n",
w2(ehdr->e_machine), fname);
fail_file();
break;
diff --git a/scripts/recordmcount.h b/scripts/recordmcount.h
index b9897e2..2e77937 100644
--- a/scripts/recordmcount.h
+++ b/scripts/recordmcount.h
@@ -441,7 +441,7 @@ static unsigned find_secsym_ndx(unsigned const txtndx,
return symp - sym0;
}
}
-   fprintf(stderr, "Cannot find symbol for section %d: %s.\n",
+   fprintf(stderr, "Cannot find symbol for section %u: %s.\n",
txtndx, txtname);
fail_file();
 }
-- 
2.10.1

Re: [alsa-devel] [RFC/RFT PATCH] ASoC: topology: Improve backwards compatibility with v4 topology files

[Pierre-Louis Bossart]

+static int skl_tplg_get_pvt_data_v4(struct snd_soc_tplg_dapm_widget

*tplg_w,

+ struct skl *skl, struct device *dev,
+ struct skl_module_cfg *mconfig)
+{
+ struct skl_dfw_v4_module *dfw =
+ (struct skl_dfw_v4_module

*)tplg_w->priv.data;

+ int ret;
+
+ dev_dbg(dev, "Parsing Skylake v4 widget topology data\n");
+
+ ret = guid_parse(dfw->uuid, (guid_t *)mconfig->guid);
+ if (ret)
+ return ret;
+ mconfig->id.module_id = -1;
+ mconfig->id.instance_id = dfw->instance_id;
+ mconfig->module->resources[0].cps = dfw->max_mcps;
+ mconfig->module->resources[0].ibs = dfw->ibs;
+ mconfig->module->resources[0].obs = dfw->obs;
+ mconfig->core_id = dfw->core_id;
+ mconfig->module->max_input_pins = dfw->max_in_queue;
+ mconfig->module->max_output_pins = dfw->max_out_queue;
+ mconfig->module->loadable = dfw->is_loadable;
+ skl_tplg_fill_fmt_v4(mconfig->module->formats[0].inputs,

dfw->in_fmt,

+  MAX_IN_QUEUE);
+ skl_tplg_fill_fmt_v4(mconfig->module->formats[0].outputs,

dfw->out_fmt,

+  MAX_OUT_QUEUE);

Not clear to me if there is a confusion between MAX_IN_QUEUE and
MODULE_MAX_IN_PINS. The two values happen to be identical.



The target (mconfig->module->formats[]) size is MAX_IN_QUEUE. Upstream
v4.4/v4.5
use both defines interchangeably as far as I can see.

sound/soc/intel/skylake/skl-topology.h: struct skl_module_fmt
in_fmt[MODULE_MAX_IN_PINS];
sound/soc/intel/skylake/skl-tplg-interface.h:   struct skl_dfw_module_fmt
in_fmt[MAX_IN_QUEUE];

I could make it
   min(MAX_IN_QUEUE, dfw->max_in_queue)
Would that be better ?


Looks like your code was fine in the first place.



+
+ mconfig->params_fixup = dfw->params_fixup;
+ mconfig->converter = dfw->converter;
+ mconfig->m_type = dfw->module_type;
+ mconfig->vbus_id = dfw->vbus_id;
+ mconfig->module->resources[0].is_pages = dfw->mem_pages;
+
+ ret = skl_tplg_add_pipe_v4(dev, mconfig, skl, >pipe);
+ if (ret)
+ return ret;
+
+ mconfig->dev_type = dfw->dev_type;
+ mconfig->hw_conn_type = dfw->hw_conn_type;
+ mconfig->time_slot = dfw->time_slot;
+ mconfig->formats_config.caps_size = dfw->caps.caps_size;



chromeos-3.18 has this:
   if (dfw_config->is_loadable)
   memcpy(mconfig->guid, dfw_config->uuid,
   ARRAY_SIZE(dfw_config->uuid));



Is this needed here?



Direct memcpy doesn't work anymore since the uuid format is different. The
above is replaced
with (unconditional)

  ret = guid_parse(dfw->uuid, (guid_t *)mconfig->guid);
  if (ret)
  return ret;

at the beginning of skl_tplg_get_pvt_data_v4(). The new code, as far as I
can see, loads
the uuid unconditionally if it finds SND_SOC_TPLG_TUPLE_TYPE_UUID. I wanted
to
be on the safe side and decided to do the same.


ok.

Re: [alsa-devel] [RFC/RFT PATCH] ASoC: topology: Improve backwards compatibility with v4 topology files

[Pierre-Louis Bossart]

+static int skl_tplg_get_pvt_data_v4(struct snd_soc_tplg_dapm_widget

*tplg_w,

+ struct skl *skl, struct device *dev,
+ struct skl_module_cfg *mconfig)
+{
+ struct skl_dfw_v4_module *dfw =
+ (struct skl_dfw_v4_module

*)tplg_w->priv.data;

+ int ret;
+
+ dev_dbg(dev, "Parsing Skylake v4 widget topology data\n");
+
+ ret = guid_parse(dfw->uuid, (guid_t *)mconfig->guid);
+ if (ret)
+ return ret;
+ mconfig->id.module_id = -1;
+ mconfig->id.instance_id = dfw->instance_id;
+ mconfig->module->resources[0].cps = dfw->max_mcps;
+ mconfig->module->resources[0].ibs = dfw->ibs;
+ mconfig->module->resources[0].obs = dfw->obs;
+ mconfig->core_id = dfw->core_id;
+ mconfig->module->max_input_pins = dfw->max_in_queue;
+ mconfig->module->max_output_pins = dfw->max_out_queue;
+ mconfig->module->loadable = dfw->is_loadable;
+ skl_tplg_fill_fmt_v4(mconfig->module->formats[0].inputs,

dfw->in_fmt,

+  MAX_IN_QUEUE);
+ skl_tplg_fill_fmt_v4(mconfig->module->formats[0].outputs,

dfw->out_fmt,

+  MAX_OUT_QUEUE);

Not clear to me if there is a confusion between MAX_IN_QUEUE and
MODULE_MAX_IN_PINS. The two values happen to be identical.



The target (mconfig->module->formats[]) size is MAX_IN_QUEUE. Upstream
v4.4/v4.5
use both defines interchangeably as far as I can see.

sound/soc/intel/skylake/skl-topology.h: struct skl_module_fmt
in_fmt[MODULE_MAX_IN_PINS];
sound/soc/intel/skylake/skl-tplg-interface.h:   struct skl_dfw_module_fmt
in_fmt[MAX_IN_QUEUE];

I could make it
   min(MAX_IN_QUEUE, dfw->max_in_queue)
Would that be better ?


Looks like your code was fine in the first place.



+
+ mconfig->params_fixup = dfw->params_fixup;
+ mconfig->converter = dfw->converter;
+ mconfig->m_type = dfw->module_type;
+ mconfig->vbus_id = dfw->vbus_id;
+ mconfig->module->resources[0].is_pages = dfw->mem_pages;
+
+ ret = skl_tplg_add_pipe_v4(dev, mconfig, skl, >pipe);
+ if (ret)
+ return ret;
+
+ mconfig->dev_type = dfw->dev_type;
+ mconfig->hw_conn_type = dfw->hw_conn_type;
+ mconfig->time_slot = dfw->time_slot;
+ mconfig->formats_config.caps_size = dfw->caps.caps_size;



chromeos-3.18 has this:
   if (dfw_config->is_loadable)
   memcpy(mconfig->guid, dfw_config->uuid,
   ARRAY_SIZE(dfw_config->uuid));



Is this needed here?



Direct memcpy doesn't work anymore since the uuid format is different. The
above is replaced
with (unconditional)

  ret = guid_parse(dfw->uuid, (guid_t *)mconfig->guid);
  if (ret)
  return ret;

at the beginning of skl_tplg_get_pvt_data_v4(). The new code, as far as I
can see, loads
the uuid unconditionally if it finds SND_SOC_TPLG_TUPLE_TYPE_UUID. I wanted
to
be on the safe side and decided to do the same.


ok.