[PATCH v2 2/2] ARM: dts: imx: Use new CODEC reset pin name
The correct DT property for specifying a GPIO used for reset
is "reset-gpios", the driver now accepts this name use this here.
Signed-off-by: Andrew F. Davis
---
Changes from v1:
- Remove "fix" from commit message
arch/arm/boot/dts/imx6qdl-gw5903.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6qdl-gw5903.dtsi
b/arch/arm/boot/dts/imx6qdl-gw5903.dtsi
index 368132274a91..ddabab168a8a 100644
--- a/arch/arm/boot/dts/imx6qdl-gw5903.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw5903.dtsi
@@ -310,7 +310,7 @@
tlv320aic3105: codec@18 {
compatible = "ti,tlv320aic3x";
reg = <0x18>;
- gpio-reset = < 17 GPIO_ACTIVE_LOW>;
+ reset-gpios = < 17 GPIO_ACTIVE_LOW>;
clocks = < IMX6QDL_CLK_CKO>;
ai3x-micbias-vg = <2>; /* MICBIAS_2_5V */
/* Regulators */
--
2.18.0
[PATCH v2 1/2] ARM: dts: imx6: RDU2: Use new CODEC reset pin name
The correct DT property for specifying a GPIO used for reset
is "reset-gpios", the driver now accepts this name use this here.
Signed-off-by: Andrew F. Davis
---
Changes from v1:
- Remove "fix" from commit message
arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
index 7fff3717cf7c..a0f5cfda0055 100644
--- a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
@@ -384,7 +384,7 @@
AVDD-supply = <_3p3v>;
IOVDD-supply = <_3p3v>;
DVDD-supply = <_reg>;
- gpio-reset = < 2 GPIO_ACTIVE_HIGH>;
+ reset-gpios = < 2 GPIO_ACTIVE_LOW>;
};
accel@1c {
@@ -572,7 +572,7 @@
AVDD-supply = <_3p3v>;
IOVDD-supply = <_3p3v>;
DVDD-supply = <_reg>;
- gpio-reset = < 0 GPIO_ACTIVE_HIGH>;
+ reset-gpios = < 0 GPIO_ACTIVE_LOW>;
};
touchscreen@20 {
--
2.18.0
Re: [RFC] perf tool improvement requests
On Tue, Sep 04, 2018 at 10:42:18AM -0300, Arnaldo Carvalho de Melo wrote: > Then I need to get the DW_AT_location stuff parsed in pahole, so > that with those offsets (second column, ending with :) with hits (first > column, there its local period, but we can ask for some specific metric > [1]), I'll be able to figure out what DW_TAG_variable or > DW_TAG_formal_parameter is living there at that time, get the offset > from the decoded instruction, say that xor, 0x138 offset from the type > for %r15 at that offset (85) from kmem_cache_alloc, right? I'm not sure how the DWARF location stuff works; it could be it already includes the offset and decoding the instruction is not needed. But yes, that's the basic idea; get DWARF to tell you what variable is used at a certain IP. > In a first milestone we'd have something like: > > perf annotate --hits function | pahole --annotate -C task_struct > > perf annotate --hits | pahole --annotate Not sure keeping it two proglets makes sense, but whatever :-) The alternative I suppose is making perf do the IP->struct::member mapping and freed that to pahole, which then only uses it to annotate the output. Or, munge the entirety of pahole into perf..
Re: [RFC] perf tool improvement requests
On Tue, Sep 04, 2018 at 10:42:18AM -0300, Arnaldo Carvalho de Melo wrote: > Then I need to get the DW_AT_location stuff parsed in pahole, so > that with those offsets (second column, ending with :) with hits (first > column, there its local period, but we can ask for some specific metric > [1]), I'll be able to figure out what DW_TAG_variable or > DW_TAG_formal_parameter is living there at that time, get the offset > from the decoded instruction, say that xor, 0x138 offset from the type > for %r15 at that offset (85) from kmem_cache_alloc, right? I'm not sure how the DWARF location stuff works; it could be it already includes the offset and decoding the instruction is not needed. But yes, that's the basic idea; get DWARF to tell you what variable is used at a certain IP. > In a first milestone we'd have something like: > > perf annotate --hits function | pahole --annotate -C task_struct > > perf annotate --hits | pahole --annotate Not sure keeping it two proglets makes sense, but whatever :-) The alternative I suppose is making perf do the IP->struct::member mapping and freed that to pahole, which then only uses it to annotate the output. Or, munge the entirety of pahole into perf..
Re: [PATCH v5 2/4] dt: bindings: Document ZynqMP DDRC in Synopsys documentation
On Fri, Aug 31, 2018 at 06:57:48PM +0530, Manish Narani wrote: > Add information of ZynqMP DDRC which reports the single bit errors that > are corrected and the double bit errors that are detected. > > Signed-off-by: Manish Narani > --- > .../bindings/memory-controllers/synopsys.txt | 27 > ++ > 1 file changed, 22 insertions(+), 5 deletions(-) Please add acks/reviewed-bys when posting new versions. Rob
Re: [PATCH v5 2/4] dt: bindings: Document ZynqMP DDRC in Synopsys documentation
On Fri, Aug 31, 2018 at 06:57:48PM +0530, Manish Narani wrote: > Add information of ZynqMP DDRC which reports the single bit errors that > are corrected and the double bit errors that are detected. > > Signed-off-by: Manish Narani > --- > .../bindings/memory-controllers/synopsys.txt | 27 > ++ > 1 file changed, 22 insertions(+), 5 deletions(-) Please add acks/reviewed-bys when posting new versions. Rob
[PATCH] mfd: arizona: make array mclk_name static, shrinks object size
From: Colin Ian King
Don't populate the array mclk_name on the stack but instead make it
static. Makes the object code smaller by 23 bytes:
Before:
textdata bss dec hex filename
38050 11604 64 49718c236 linux/drivers/mfd/arizona-core.o
After:
textdata bss dec hex filename
38027 11604 64 49695c21f linux/drivers/mfd/arizona-core.o
(gcc version 8.2.0 x86_64)
Signed-off-by: Colin Ian King
---
drivers/mfd/arizona-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
index 5f1e37d23943..918d81a00b37 100644
--- a/drivers/mfd/arizona-core.c
+++ b/drivers/mfd/arizona-core.c
@@ -990,7 +990,7 @@ static const struct mfd_cell wm8998_devs[] = {
int arizona_dev_init(struct arizona *arizona)
{
- const char * const mclk_name[] = { "mclk1", "mclk2" };
+ static const char * const mclk_name[] = { "mclk1", "mclk2" };
struct device *dev = arizona->dev;
const char *type_name = NULL;
unsigned int reg, val;
--
2.17.1
[PATCH] mfd: arizona: make array mclk_name static, shrinks object size
From: Colin Ian King
Don't populate the array mclk_name on the stack but instead make it
static. Makes the object code smaller by 23 bytes:
Before:
textdata bss dec hex filename
38050 11604 64 49718c236 linux/drivers/mfd/arizona-core.o
After:
textdata bss dec hex filename
38027 11604 64 49695c21f linux/drivers/mfd/arizona-core.o
(gcc version 8.2.0 x86_64)
Signed-off-by: Colin Ian King
---
drivers/mfd/arizona-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
index 5f1e37d23943..918d81a00b37 100644
--- a/drivers/mfd/arizona-core.c
+++ b/drivers/mfd/arizona-core.c
@@ -990,7 +990,7 @@ static const struct mfd_cell wm8998_devs[] = {
int arizona_dev_init(struct arizona *arizona)
{
- const char * const mclk_name[] = { "mclk1", "mclk2" };
+ static const char * const mclk_name[] = { "mclk1", "mclk2" };
struct device *dev = arizona->dev;
const char *type_name = NULL;
unsigned int reg, val;
--
2.17.1
[PATCH 3/3] dt-bindings: adxl372: Document the adxl372 I2C bindings
The adxl372 is designed to communicate in either SPI or I2C protocol.
This patch adds the documentation of device tree bindings for adxl372
I2C.
Signed-off-by: Stefan Popa
---
Documentation/devicetree/bindings/iio/accel/adxl372.txt | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/iio/accel/adxl372.txt
b/Documentation/devicetree/bindings/iio/accel/adxl372.txt
index 9409984..a289964 100644
--- a/Documentation/devicetree/bindings/iio/accel/adxl372.txt
+++ b/Documentation/devicetree/bindings/iio/accel/adxl372.txt
@@ -4,14 +4,25 @@
http://www.analog.com/media/en/technical-documentation/data-sheets/adxl372.pdf
Required properties:
- compatible : should be "adi,adxl372"
- - reg: SPI chip select number for the device
+ - reg: the I2C address or SPI chip select number for the device
+
+Required properties for SPI bus usage:
- spi-max-frequency: Max SPI frequency to use
Optional properties:
- interrupts: interrupt mapping for IRQ as documented in
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
-Example:
+Example for a I2C device node:
+
+ accelerometer@53 {
+ compatible = "adi,adxl372";
+ reg = <0x53>;
+ interrupt-parent = <>;
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+ };
+
+Example for a SPI device node:
accelerometer@0 {
compatible = "adi,adxl372";
--
2.7.4
[PATCH 3/3] dt-bindings: adxl372: Document the adxl372 I2C bindings
The adxl372 is designed to communicate in either SPI or I2C protocol.
This patch adds the documentation of device tree bindings for adxl372
I2C.
Signed-off-by: Stefan Popa
---
Documentation/devicetree/bindings/iio/accel/adxl372.txt | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/iio/accel/adxl372.txt
b/Documentation/devicetree/bindings/iio/accel/adxl372.txt
index 9409984..a289964 100644
--- a/Documentation/devicetree/bindings/iio/accel/adxl372.txt
+++ b/Documentation/devicetree/bindings/iio/accel/adxl372.txt
@@ -4,14 +4,25 @@
http://www.analog.com/media/en/technical-documentation/data-sheets/adxl372.pdf
Required properties:
- compatible : should be "adi,adxl372"
- - reg: SPI chip select number for the device
+ - reg: the I2C address or SPI chip select number for the device
+
+Required properties for SPI bus usage:
- spi-max-frequency: Max SPI frequency to use
Optional properties:
- interrupts: interrupt mapping for IRQ as documented in
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
-Example:
+Example for a I2C device node:
+
+ accelerometer@53 {
+ compatible = "adi,adxl372";
+ reg = <0x53>;
+ interrupt-parent = <>;
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+ };
+
+Example for a SPI device node:
accelerometer@0 {
compatible = "adi,adxl372";
--
2.7.4
[PATCH 2/3] iio: adxl372: Add support for I2C communication
The adxl372 is designed to communicate in either SPI or I2C protocol. It
autodetects the format being used, requiring no configuration control to
select the format.
Signed-off-by: Stefan Popa
---
MAINTAINERS | 1 +
drivers/iio/accel/Kconfig | 11
drivers/iio/accel/Makefile | 1 +
drivers/iio/accel/adxl372.c | 1 -
drivers/iio/accel/adxl372.h | 2 ++
drivers/iio/accel/adxl372_i2c.c | 61 +
6 files changed, 76 insertions(+), 1 deletion(-)
create mode 100644 drivers/iio/accel/adxl372_i2c.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 2938632..2b9a364 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -549,6 +549,7 @@ W: http://ez.analog.com/community/linux-device-drivers
S: Supported
F: drivers/iio/accel/adxl372.c
F: drivers/iio/accel/adxl372_spi.c
+F: drivers/iio/accel/adxl372_i2c.c
F: Documentation/devicetree/bindings/iio/accel/adxl372.txt
AF9013 MEDIA DRIVER
diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
index bed5da8..7993a67 100644
--- a/drivers/iio/accel/Kconfig
+++ b/drivers/iio/accel/Kconfig
@@ -76,6 +76,17 @@ config ADXL372_SPI
To compile this driver as a module, choose M here: the
module will be called adxl372_spi.
+config ADXL372_I2C
+ tristate "Analog Devices ADXL372 3-Axis Accelerometer I2C Driver"
+ depends on I2C
+ select ADXL372
+ select REGMAP_I2C
+ help
+ Say yes here to add support for the Analog Devices ADXL372 triaxial
+ acceleration sensor.
+ To compile this driver as a module, choose M here: the
+ module will be called adxl372_i2c.
+
config BMA180
tristate "Bosch BMA180/BMA250 3-Axis Accelerometer Driver"
depends on I2C
diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
index c9c5db9..56bd021 100644
--- a/drivers/iio/accel/Makefile
+++ b/drivers/iio/accel/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_ADXL345) += adxl345_core.o
obj-$(CONFIG_ADXL345_I2C) += adxl345_i2c.o
obj-$(CONFIG_ADXL345_SPI) += adxl345_spi.o
obj-$(CONFIG_ADXL372) += adxl372.o
+obj-$(CONFIG_ADXL372_I2C) += adxl372_i2c.o
obj-$(CONFIG_ADXL372_SPI) += adxl372_spi.o
obj-$(CONFIG_BMA180) += bma180.o
obj-$(CONFIG_BMA220) += bma220_spi.o
diff --git a/drivers/iio/accel/adxl372.c b/drivers/iio/accel/adxl372.c
index f1df89d..3b84cb2 100644
--- a/drivers/iio/accel/adxl372.c
+++ b/drivers/iio/accel/adxl372.c
@@ -26,7 +26,6 @@
#define ADXL372_DEVID 0x00
#define ADXL372_DEVID_MST 0x01
#define ADXL372_PARTID 0x02
-#define ADXL372_REVID 0x03
#define ADXL372_STATUS_1 0x04
#define ADXL372_STATUS_2 0x05
#define ADXL372_FIFO_ENTRIES_2 0x06
diff --git a/drivers/iio/accel/adxl372.h b/drivers/iio/accel/adxl372.h
index 5da89b1..80a0aa9 100644
--- a/drivers/iio/accel/adxl372.h
+++ b/drivers/iio/accel/adxl372.h
@@ -8,6 +8,8 @@
#ifndef _ADXL372_H_
#define _ADXL372_H_
+#define ADXL372_REVID 0x03
+
int adxl372_probe(struct device *dev, struct regmap *regmap,
int irq, const char *name);
bool adxl372_readable_noinc_reg(struct device *dev, unsigned int reg);
diff --git a/drivers/iio/accel/adxl372_i2c.c b/drivers/iio/accel/adxl372_i2c.c
new file mode 100644
index 000..e1affe4
--- /dev/null
+++ b/drivers/iio/accel/adxl372_i2c.c
@@ -0,0 +1,61 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * ADXL372 3-Axis Digital Accelerometer I2C driver
+ *
+ * Copyright 2018 Analog Devices Inc.
+ */
+
+#include
+#include
+#include
+
+#include "adxl372.h"
+
+static const struct regmap_config adxl372_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .readable_noinc_reg = adxl372_readable_noinc_reg,
+};
+
+static int adxl372_i2c_probe(struct i2c_client *client,
+const struct i2c_device_id *id)
+{
+ struct regmap *regmap;
+ unsigned int regval;
+ int ret;
+
+ regmap = devm_regmap_init_i2c(client, _regmap_config);
+ if (IS_ERR(regmap))
+ return PTR_ERR(regmap);
+
+ ret = regmap_read(regmap, ADXL372_REVID, );
+ if (ret < 0)
+ return ret;
+
+ /* Starting with the 3rd revision an I2C chip bug was fixed */
+ if (regval < 3)
+ dev_warn(>dev,
+ "I2C might not work properly with other devices on the bus");
+
+ return adxl372_probe(>dev, regmap, client->irq, id->name);
+}
+
+static const struct i2c_device_id adxl372_i2c_id[] = {
+ { "adxl372", 0 },
+ {}
+};
+MODULE_DEVICE_TABLE(i2c, adxl372_i2c_id);
+
+static struct i2c_driver adxl372_i2c_driver = {
+ .driver = {
+ .name = "adxl372_i2c",
+ },
+ .probe = adxl372_i2c_probe,
+ .id_table = adxl372_i2c_id,
+};
+
+module_i2c_driver(adxl372_i2c_driver);
+
+MODULE_AUTHOR("Stefan Popa ");
+MODULE_DESCRIPTION("Analog Devices ADXL372
[PATCH 2/3] iio: adxl372: Add support for I2C communication
The adxl372 is designed to communicate in either SPI or I2C protocol. It
autodetects the format being used, requiring no configuration control to
select the format.
Signed-off-by: Stefan Popa
---
MAINTAINERS | 1 +
drivers/iio/accel/Kconfig | 11
drivers/iio/accel/Makefile | 1 +
drivers/iio/accel/adxl372.c | 1 -
drivers/iio/accel/adxl372.h | 2 ++
drivers/iio/accel/adxl372_i2c.c | 61 +
6 files changed, 76 insertions(+), 1 deletion(-)
create mode 100644 drivers/iio/accel/adxl372_i2c.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 2938632..2b9a364 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -549,6 +549,7 @@ W: http://ez.analog.com/community/linux-device-drivers
S: Supported
F: drivers/iio/accel/adxl372.c
F: drivers/iio/accel/adxl372_spi.c
+F: drivers/iio/accel/adxl372_i2c.c
F: Documentation/devicetree/bindings/iio/accel/adxl372.txt
AF9013 MEDIA DRIVER
diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
index bed5da8..7993a67 100644
--- a/drivers/iio/accel/Kconfig
+++ b/drivers/iio/accel/Kconfig
@@ -76,6 +76,17 @@ config ADXL372_SPI
To compile this driver as a module, choose M here: the
module will be called adxl372_spi.
+config ADXL372_I2C
+ tristate "Analog Devices ADXL372 3-Axis Accelerometer I2C Driver"
+ depends on I2C
+ select ADXL372
+ select REGMAP_I2C
+ help
+ Say yes here to add support for the Analog Devices ADXL372 triaxial
+ acceleration sensor.
+ To compile this driver as a module, choose M here: the
+ module will be called adxl372_i2c.
+
config BMA180
tristate "Bosch BMA180/BMA250 3-Axis Accelerometer Driver"
depends on I2C
diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
index c9c5db9..56bd021 100644
--- a/drivers/iio/accel/Makefile
+++ b/drivers/iio/accel/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_ADXL345) += adxl345_core.o
obj-$(CONFIG_ADXL345_I2C) += adxl345_i2c.o
obj-$(CONFIG_ADXL345_SPI) += adxl345_spi.o
obj-$(CONFIG_ADXL372) += adxl372.o
+obj-$(CONFIG_ADXL372_I2C) += adxl372_i2c.o
obj-$(CONFIG_ADXL372_SPI) += adxl372_spi.o
obj-$(CONFIG_BMA180) += bma180.o
obj-$(CONFIG_BMA220) += bma220_spi.o
diff --git a/drivers/iio/accel/adxl372.c b/drivers/iio/accel/adxl372.c
index f1df89d..3b84cb2 100644
--- a/drivers/iio/accel/adxl372.c
+++ b/drivers/iio/accel/adxl372.c
@@ -26,7 +26,6 @@
#define ADXL372_DEVID 0x00
#define ADXL372_DEVID_MST 0x01
#define ADXL372_PARTID 0x02
-#define ADXL372_REVID 0x03
#define ADXL372_STATUS_1 0x04
#define ADXL372_STATUS_2 0x05
#define ADXL372_FIFO_ENTRIES_2 0x06
diff --git a/drivers/iio/accel/adxl372.h b/drivers/iio/accel/adxl372.h
index 5da89b1..80a0aa9 100644
--- a/drivers/iio/accel/adxl372.h
+++ b/drivers/iio/accel/adxl372.h
@@ -8,6 +8,8 @@
#ifndef _ADXL372_H_
#define _ADXL372_H_
+#define ADXL372_REVID 0x03
+
int adxl372_probe(struct device *dev, struct regmap *regmap,
int irq, const char *name);
bool adxl372_readable_noinc_reg(struct device *dev, unsigned int reg);
diff --git a/drivers/iio/accel/adxl372_i2c.c b/drivers/iio/accel/adxl372_i2c.c
new file mode 100644
index 000..e1affe4
--- /dev/null
+++ b/drivers/iio/accel/adxl372_i2c.c
@@ -0,0 +1,61 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * ADXL372 3-Axis Digital Accelerometer I2C driver
+ *
+ * Copyright 2018 Analog Devices Inc.
+ */
+
+#include
+#include
+#include
+
+#include "adxl372.h"
+
+static const struct regmap_config adxl372_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .readable_noinc_reg = adxl372_readable_noinc_reg,
+};
+
+static int adxl372_i2c_probe(struct i2c_client *client,
+const struct i2c_device_id *id)
+{
+ struct regmap *regmap;
+ unsigned int regval;
+ int ret;
+
+ regmap = devm_regmap_init_i2c(client, _regmap_config);
+ if (IS_ERR(regmap))
+ return PTR_ERR(regmap);
+
+ ret = regmap_read(regmap, ADXL372_REVID, );
+ if (ret < 0)
+ return ret;
+
+ /* Starting with the 3rd revision an I2C chip bug was fixed */
+ if (regval < 3)
+ dev_warn(>dev,
+ "I2C might not work properly with other devices on the bus");
+
+ return adxl372_probe(>dev, regmap, client->irq, id->name);
+}
+
+static const struct i2c_device_id adxl372_i2c_id[] = {
+ { "adxl372", 0 },
+ {}
+};
+MODULE_DEVICE_TABLE(i2c, adxl372_i2c_id);
+
+static struct i2c_driver adxl372_i2c_driver = {
+ .driver = {
+ .name = "adxl372_i2c",
+ },
+ .probe = adxl372_i2c_probe,
+ .id_table = adxl372_i2c_id,
+};
+
+module_i2c_driver(adxl372_i2c_driver);
+
+MODULE_AUTHOR("Stefan Popa ");
+MODULE_DESCRIPTION("Analog Devices ADXL372
Re: [PATCH 3/4] PCI/portdrv: Check platform supported service IRQ's
On Fri, Aug 10, 2018 at 09:09:39PM +0530, Bharat Kumar Gogada wrote:
> Platforms may have dedicated IRQ lines for PCIe services like
> AER/PME etc., check for such IRQ lines.
> Check mask and fill legacy irq line for services other than
Capitalize "IRQ" consistently in English text like this.
Insert blank lines between paragraphs.
Add a reference to the relevant spec sections. PCIe r4.0, sec
6.2.4.1.2, 6.2.6, 7.5.3.12 seem pertinent.
> platform supported service IRQ number.
>
> Signed-off-by: Bharat Kumar Gogada
> ---
> drivers/pci/pcie/portdrv_core.c | 19 +--
> 1 files changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
> index e0261ad..a7d024c 100644
> --- a/drivers/pci/pcie/portdrv_core.c
> +++ b/drivers/pci/pcie/portdrv_core.c
> @@ -166,6 +166,19 @@ static int pcie_init_service_irqs(struct pci_dev *dev,
> int *irqs, int mask)
> irqs[i] = -1;
>
> /*
> + * Some platforms have dedicated interrupt line from root complex to
> + * interrupt controller for PCIe services like AER/PME etc., check
> + * if platform registered with any such IRQ.
> + */
> + if (pci_pcie_type(dev) == PCI_EXP_TYPE_ROOT_PORT) {
> + int plat_mask;
> +
> + plat_mask = pci_check_platform_service_irqs(dev, irqs, mask);
> + if (plat_mask > 0)
Masks should be unsigned and tested for zero or "mask & bit". The
rest of this file uses "int", which is sloppy because it does the
wrong thing if we happen to use the high-order bit in the mask.
> + mask = mask & plat_mask;
> + }
I think these platform IRQs are neither MSI-X/MSI nor PCI INTx wires.
But as written, I think this patch executes pcie_port_enable_irq_vec(),
which only does MSI-X/MSI stuff. So this must rely on that failing?
And then we fall through to run pci_alloc_irq_vectors(), which is for
PCI INTx interrupts, which doesn't seem appropriate either.
It seems like this platform IRQ case should be completely separated
from the other MSI/INTx cases, i.e., set
irqs[PCIE_PORT_SERVICE_AER_SHIFT] directly (I think you already do
this inside pci_check_platform_service_irqs()) and immediately return.
Then I think you wouldn't need the other hunk below.
> +
> + /*
>* If we support PME but can't use MSI/MSI-X for it, we have to
>* fall back to INTx or other interrupts, e.g., a system shared
>* interrupt.
> @@ -183,8 +196,10 @@ static int pcie_init_service_irqs(struct pci_dev *dev,
> int *irqs, int mask)
> if (ret < 0)
> return -ENODEV;
>
> - for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++)
> - irqs[i] = pci_irq_vector(dev, 0);
> + for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++) {
> + if (mask & (1 << i))
> + irqs[i] = pci_irq_vector(dev, 0);
> + }
>
> return 0;
> }
> --
> 1.7.1
>
Re: [PATCH 3/4] PCI/portdrv: Check platform supported service IRQ's
On Fri, Aug 10, 2018 at 09:09:39PM +0530, Bharat Kumar Gogada wrote:
> Platforms may have dedicated IRQ lines for PCIe services like
> AER/PME etc., check for such IRQ lines.
> Check mask and fill legacy irq line for services other than
Capitalize "IRQ" consistently in English text like this.
Insert blank lines between paragraphs.
Add a reference to the relevant spec sections. PCIe r4.0, sec
6.2.4.1.2, 6.2.6, 7.5.3.12 seem pertinent.
> platform supported service IRQ number.
>
> Signed-off-by: Bharat Kumar Gogada
> ---
> drivers/pci/pcie/portdrv_core.c | 19 +--
> 1 files changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
> index e0261ad..a7d024c 100644
> --- a/drivers/pci/pcie/portdrv_core.c
> +++ b/drivers/pci/pcie/portdrv_core.c
> @@ -166,6 +166,19 @@ static int pcie_init_service_irqs(struct pci_dev *dev,
> int *irqs, int mask)
> irqs[i] = -1;
>
> /*
> + * Some platforms have dedicated interrupt line from root complex to
> + * interrupt controller for PCIe services like AER/PME etc., check
> + * if platform registered with any such IRQ.
> + */
> + if (pci_pcie_type(dev) == PCI_EXP_TYPE_ROOT_PORT) {
> + int plat_mask;
> +
> + plat_mask = pci_check_platform_service_irqs(dev, irqs, mask);
> + if (plat_mask > 0)
Masks should be unsigned and tested for zero or "mask & bit". The
rest of this file uses "int", which is sloppy because it does the
wrong thing if we happen to use the high-order bit in the mask.
> + mask = mask & plat_mask;
> + }
I think these platform IRQs are neither MSI-X/MSI nor PCI INTx wires.
But as written, I think this patch executes pcie_port_enable_irq_vec(),
which only does MSI-X/MSI stuff. So this must rely on that failing?
And then we fall through to run pci_alloc_irq_vectors(), which is for
PCI INTx interrupts, which doesn't seem appropriate either.
It seems like this platform IRQ case should be completely separated
from the other MSI/INTx cases, i.e., set
irqs[PCIE_PORT_SERVICE_AER_SHIFT] directly (I think you already do
this inside pci_check_platform_service_irqs()) and immediately return.
Then I think you wouldn't need the other hunk below.
> +
> + /*
>* If we support PME but can't use MSI/MSI-X for it, we have to
>* fall back to INTx or other interrupts, e.g., a system shared
>* interrupt.
> @@ -183,8 +196,10 @@ static int pcie_init_service_irqs(struct pci_dev *dev,
> int *irqs, int mask)
> if (ret < 0)
> return -ENODEV;
>
> - for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++)
> - irqs[i] = pci_irq_vector(dev, 0);
> + for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++) {
> + if (mask & (1 << i))
> + irqs[i] = pci_irq_vector(dev, 0);
> + }
>
> return 0;
> }
> --
> 1.7.1
>
Re: [RFC] perf tool improvement requests
Em Tue, Sep 04, 2018 at 03:58:35PM +0200, Jiri Olsa escreveu: > On Tue, Sep 04, 2018 at 03:53:25PM +0200, Peter Zijlstra wrote: > > On Tue, Sep 04, 2018 at 10:42:18AM -0300, Arnaldo Carvalho de Melo wrote: > > > So, use 'c2c record' to get the samples: > > IIRC that uses numa events and is completely useless. > I guess perf record on any other event would work > in Arnaldo's workflow Right. I should've avoided useless events ;-) - Arnaldo
Re: [RFC] perf tool improvement requests
Em Tue, Sep 04, 2018 at 03:58:35PM +0200, Jiri Olsa escreveu: > On Tue, Sep 04, 2018 at 03:53:25PM +0200, Peter Zijlstra wrote: > > On Tue, Sep 04, 2018 at 10:42:18AM -0300, Arnaldo Carvalho de Melo wrote: > > > So, use 'c2c record' to get the samples: > > IIRC that uses numa events and is completely useless. > I guess perf record on any other event would work > in Arnaldo's workflow Right. I should've avoided useless events ;-) - Arnaldo
[RFC PATCH v2] irqchip/gic-v3: Add quirk for msm8996 secured registers
Access to GICR_WAKER is restricted on msm8996 SoC in Hypervisor.
Its been more than 2 years of wait for this to be fixed, which has
no hopes to be fixed. This change was introduced for the "lead device"
on msm8996 platform. It looks like all publicly available msm8996
devices have this implementation.
So add a quirk to not access this register on msm8996.
With this quirk MSM8996 can at least boot out of mainline,
which can help community to work with boards based on MSM8996.
Without this patch Qualcomm DB820c board reboots when GICR_WAKER
is accessed.
Signed-off-by: Srinivas Kandagatla
---
Hi Marc,
There is no errata associated with this quirk, so I could not add
any entries into Documentation/arm64/silicon-errata.txt Or add
any number to the quirk description.
Changes since v1:
- renamed gic_v3 references to gic
- added full mask for iidr register match
thanks,
srini
drivers/irqchip/irq-gic-v3.c | 29 -
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index d5912f1ec884..406d4a44c887 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -41,6 +41,8 @@
#include "irq-gic-common.h"
+#define FLAGS_WORKAROUND_GICR_WAKER_MSM8996(1ULL << 0)
+
struct redist_region {
void __iomem*redist_base;
phys_addr_t phys_base;
@@ -55,6 +57,7 @@ struct gic_chip_data {
struct irq_domain *domain;
u64 redist_stride;
u32 nr_redist_regions;
+ u64 flags;
boolhas_rss;
unsigned intirq_nr;
struct partition_desc *ppi_descs[16];
@@ -139,6 +142,9 @@ static void gic_enable_redist(bool enable)
u32 count = 100;/* 1s! */
u32 val;
+ if (gic_data.flags & FLAGS_WORKAROUND_GICR_WAKER_MSM8996)
+ return;
+
rbase = gic_data_rdist_rd_base();
val = readl_relaxed(rbase + GICR_WAKER);
@@ -1068,13 +1074,31 @@ static const struct irq_domain_ops partition_domain_ops
= {
.select = gic_irq_domain_select,
};
+static bool __maybe_unused gic_enable_quirk_msm8996(void *data)
+{
+ struct gic_chip_data *d = data;
+
+ d->flags |= FLAGS_WORKAROUND_GICR_WAKER_MSM8996;
+
+ return true;
+}
+
+static const struct gic_quirk gic_quirks[] = {
+ {
+ .desc = "GICv3: Qualcomm MSM8996 skip GICR_WAKER Read/Write",
+ .iidr = 0x1070, /* MSM8996 */
+ .mask = 0x,
+ .init = gic_enable_quirk_msm8996,
+ },
+};
+
static int __init gic_init_bases(void __iomem *dist_base,
struct redist_region *rdist_regs,
u32 nr_redist_regions,
u64 redist_stride,
struct fwnode_handle *handle)
{
- u32 typer;
+ u32 typer, iidr;
int gic_irqs;
int err;
@@ -1130,6 +1154,9 @@ static int __init gic_init_bases(void __iomem *dist_base,
if (IS_ENABLED(CONFIG_ARM_GIC_V3_ITS) && gic_dist_supports_lpis())
its_init(handle, _data.rdists, gic_data.domain);
+ iidr = readl_relaxed(dist_base + GICD_IIDR);
+ gic_enable_quirks(iidr, gic_quirks, _data);
+
gic_smp_init();
gic_dist_init();
gic_cpu_init();
--
2.18.0
[RFC PATCH v2] irqchip/gic-v3: Add quirk for msm8996 secured registers
Access to GICR_WAKER is restricted on msm8996 SoC in Hypervisor.
Its been more than 2 years of wait for this to be fixed, which has
no hopes to be fixed. This change was introduced for the "lead device"
on msm8996 platform. It looks like all publicly available msm8996
devices have this implementation.
So add a quirk to not access this register on msm8996.
With this quirk MSM8996 can at least boot out of mainline,
which can help community to work with boards based on MSM8996.
Without this patch Qualcomm DB820c board reboots when GICR_WAKER
is accessed.
Signed-off-by: Srinivas Kandagatla
---
Hi Marc,
There is no errata associated with this quirk, so I could not add
any entries into Documentation/arm64/silicon-errata.txt Or add
any number to the quirk description.
Changes since v1:
- renamed gic_v3 references to gic
- added full mask for iidr register match
thanks,
srini
drivers/irqchip/irq-gic-v3.c | 29 -
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index d5912f1ec884..406d4a44c887 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -41,6 +41,8 @@
#include "irq-gic-common.h"
+#define FLAGS_WORKAROUND_GICR_WAKER_MSM8996(1ULL << 0)
+
struct redist_region {
void __iomem*redist_base;
phys_addr_t phys_base;
@@ -55,6 +57,7 @@ struct gic_chip_data {
struct irq_domain *domain;
u64 redist_stride;
u32 nr_redist_regions;
+ u64 flags;
boolhas_rss;
unsigned intirq_nr;
struct partition_desc *ppi_descs[16];
@@ -139,6 +142,9 @@ static void gic_enable_redist(bool enable)
u32 count = 100;/* 1s! */
u32 val;
+ if (gic_data.flags & FLAGS_WORKAROUND_GICR_WAKER_MSM8996)
+ return;
+
rbase = gic_data_rdist_rd_base();
val = readl_relaxed(rbase + GICR_WAKER);
@@ -1068,13 +1074,31 @@ static const struct irq_domain_ops partition_domain_ops
= {
.select = gic_irq_domain_select,
};
+static bool __maybe_unused gic_enable_quirk_msm8996(void *data)
+{
+ struct gic_chip_data *d = data;
+
+ d->flags |= FLAGS_WORKAROUND_GICR_WAKER_MSM8996;
+
+ return true;
+}
+
+static const struct gic_quirk gic_quirks[] = {
+ {
+ .desc = "GICv3: Qualcomm MSM8996 skip GICR_WAKER Read/Write",
+ .iidr = 0x1070, /* MSM8996 */
+ .mask = 0x,
+ .init = gic_enable_quirk_msm8996,
+ },
+};
+
static int __init gic_init_bases(void __iomem *dist_base,
struct redist_region *rdist_regs,
u32 nr_redist_regions,
u64 redist_stride,
struct fwnode_handle *handle)
{
- u32 typer;
+ u32 typer, iidr;
int gic_irqs;
int err;
@@ -1130,6 +1154,9 @@ static int __init gic_init_bases(void __iomem *dist_base,
if (IS_ENABLED(CONFIG_ARM_GIC_V3_ITS) && gic_dist_supports_lpis())
its_init(handle, _data.rdists, gic_data.domain);
+ iidr = readl_relaxed(dist_base + GICD_IIDR);
+ gic_enable_quirks(iidr, gic_quirks, _data);
+
gic_smp_init();
gic_dist_init();
gic_cpu_init();
--
2.18.0
Re: [PATCH 0/8] gpio-addr-flash: Support for device-tree and cleanup
Hi! Any other comment before I resubmit v2 tomorrow from https://github.com/ribalda/linux/tree/gpio-addr-flash-v2 So far the diff for v2 I have >From Boris Brezillon: -Add Fixes and cc:stable >From kbuild: - Fix warnings - Rebase Thanks! On Tue, Aug 21, 2018 at 4:31 PM Ricardo Ribalda Delgado wrote: > > This patch series does the following: > > 1) Fix bug regarding ioremap size > 2) Cleanup code to use new APIs > 3) Simplify numerical operations > 4) Add support for device-tree devices > > Thanks! > > Ricardo Ribalda Delgado (8): > mtd: maps: gpio-addr-flash: Replace custom printk > mtd: maps: gpio-addr-flash: Fix ioremapped size > mtd: maps: gpio-addr-flash: Use devm_* functions > mtd: maps: gpio-addr-flash: Use order insted of size > mtd: maps: gpio-addr-flash: Replace array with an integer > mtd: maps: gpio-addr-flash: Split allocation in two > mtd: maps: gpio-addr-flash: Add support for device-tree devices > dt-binding: mtd: Document gpio-addr-flash > > .../bindings/mtd/gpio-addr-flash.txt | 46 +++ > drivers/mtd/maps/gpio-addr-flash.c| 277 -- > 2 files changed, 237 insertions(+), 86 deletions(-) > create mode 100644 Documentation/devicetree/bindings/mtd/gpio-addr-flash.txt > > -- > 2.18.0 > -- Ricardo Ribalda
Re: [PATCH 0/8] gpio-addr-flash: Support for device-tree and cleanup
Hi! Any other comment before I resubmit v2 tomorrow from https://github.com/ribalda/linux/tree/gpio-addr-flash-v2 So far the diff for v2 I have >From Boris Brezillon: -Add Fixes and cc:stable >From kbuild: - Fix warnings - Rebase Thanks! On Tue, Aug 21, 2018 at 4:31 PM Ricardo Ribalda Delgado wrote: > > This patch series does the following: > > 1) Fix bug regarding ioremap size > 2) Cleanup code to use new APIs > 3) Simplify numerical operations > 4) Add support for device-tree devices > > Thanks! > > Ricardo Ribalda Delgado (8): > mtd: maps: gpio-addr-flash: Replace custom printk > mtd: maps: gpio-addr-flash: Fix ioremapped size > mtd: maps: gpio-addr-flash: Use devm_* functions > mtd: maps: gpio-addr-flash: Use order insted of size > mtd: maps: gpio-addr-flash: Replace array with an integer > mtd: maps: gpio-addr-flash: Split allocation in two > mtd: maps: gpio-addr-flash: Add support for device-tree devices > dt-binding: mtd: Document gpio-addr-flash > > .../bindings/mtd/gpio-addr-flash.txt | 46 +++ > drivers/mtd/maps/gpio-addr-flash.c| 277 -- > 2 files changed, 237 insertions(+), 86 deletions(-) > create mode 100644 Documentation/devicetree/bindings/mtd/gpio-addr-flash.txt > > -- > 2.18.0 > -- Ricardo Ribalda
Re: [PATCH v5 06/16] x86/nops: init ideal_nops for Hygon
On Wed, Aug 29, 2018 at 08:44:07PM +0800, Pu Wen wrote:
> The ideal_nops for Dhyana processors should be p6_nops.
>
> Signed-off-by: Pu Wen
> ---
> arch/x86/kernel/alternative.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
> index 014f214..3f51d1c 100644
> --- a/arch/x86/kernel/alternative.c
> +++ b/arch/x86/kernel/alternative.c
> @@ -222,6 +222,10 @@ void __init arch_init_ideal_nops(void)
> }
> break;
>
> + case X86_VENDOR_HYGON:
> + ideal_nops = p6_nops;
> + return;
> +
> case X86_VENDOR_AMD:
> if (boot_cpu_data.x86 > 0xf) {
> ideal_nops = p6_nops;
> --
Reviewed-by: Borislav Petkov
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH v5 06/16] x86/nops: init ideal_nops for Hygon
On Wed, Aug 29, 2018 at 08:44:07PM +0800, Pu Wen wrote:
> The ideal_nops for Dhyana processors should be p6_nops.
>
> Signed-off-by: Pu Wen
> ---
> arch/x86/kernel/alternative.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
> index 014f214..3f51d1c 100644
> --- a/arch/x86/kernel/alternative.c
> +++ b/arch/x86/kernel/alternative.c
> @@ -222,6 +222,10 @@ void __init arch_init_ideal_nops(void)
> }
> break;
>
> + case X86_VENDOR_HYGON:
> + ideal_nops = p6_nops;
> + return;
> +
> case X86_VENDOR_AMD:
> if (boot_cpu_data.x86 > 0xf) {
> ideal_nops = p6_nops;
> --
Reviewed-by: Borislav Petkov
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH v6 1/2] mm: migration: fix migration of huge PMD shared pages
On Mon, Sep 03, 2018 at 07:56:54AM +0200, Michal Hocko wrote: > On Thu 30-08-18 14:39:44, Jerome Glisse wrote: > > On Thu, Aug 30, 2018 at 11:05:16AM -0700, Mike Kravetz wrote: > > > On 08/30/2018 09:57 AM, Jerome Glisse wrote: > > > > On Thu, Aug 30, 2018 at 06:19:52PM +0200, Michal Hocko wrote: > > > >> On Thu 30-08-18 10:08:25, Jerome Glisse wrote: > > > >>> On Thu, Aug 30, 2018 at 12:56:16PM +0200, Michal Hocko wrote: > > > On Wed 29-08-18 17:11:07, Jerome Glisse wrote: > > > > On Wed, Aug 29, 2018 at 08:39:06PM +0200, Michal Hocko wrote: > > > >> On Wed 29-08-18 14:14:25, Jerome Glisse wrote: > > > >>> On Wed, Aug 29, 2018 at 10:24:44AM -0700, Mike Kravetz wrote: > > > >> [...] > > > What would be the best mmu notifier interface to use where there > > > are no > > > start/end calls? > > > Or, is the best solution to add the start/end calls as is done > > > in later > > > versions of the code? If that is the suggestion, has there been > > > any change > > > in invalidate start/end semantics that we should take into > > > account? > > > >>> > > > >>> start/end would be the one to add, 4.4 seems broken in respect to > > > >>> THP > > > >>> and mmu notification. Another solution is to fix user of mmu > > > >>> notifier, > > > >>> they were only a handful back then. For instance properly adjust > > > >>> the > > > >>> address to match first address covered by pmd or pud and passing > > > >>> down > > > >>> correct page size to mmu_notifier_invalidate_page() would allow > > > >>> to fix > > > >>> this easily. > > > >>> > > > >>> This is ok because user of try_to_unmap_one() replace the > > > >>> pte/pmd/pud > > > >>> with an invalid one (either poison, migration or swap) inside the > > > >>> function. So anyone racing would synchronize on those special > > > >>> entry > > > >>> hence why it is fine to delay mmu_notifier_invalidate_page() to > > > >>> after > > > >>> dropping the page table lock. > > > >>> > > > >>> Adding start/end might the solution with less code churn as you > > > >>> would > > > >>> only need to change try_to_unmap_one(). > > > >> > > > >> What about dependencies? 369ea8242c0fb sounds like it needs work > > > >> for all > > > >> notifiers need to be updated as well. > > > > > > > > This commit remove mmu_notifier_invalidate_page() hence why > > > > everything > > > > need to be updated. But in 4.4 you can get away with just adding > > > > start/ > > > > end and keep around mmu_notifier_invalidate_page() to minimize > > > > disruption. > > > > > > OK, this is really interesting. I was really worried to change the > > > semantic of the mmu notifiers in stable kernels because this is > > > really > > > a hard to review change and high risk for anybody running those old > > > kernels. If we can keep the mmu_notifier_invalidate_page and wrap > > > them > > > into the range scope API then this sounds like the best way forward. > > > > > > So just to make sure we are at the same page. Does this sounds goo > > > for > > > stable 4.4. backport? Mike's hugetlb pmd shared fixup can be applied > > > on > > > top. What do you think? > > > >>> > > > >>> You need to invalidate outside page table lock so before the call to > > > >>> page_check_address(). For instance like below patch, which also only > > > >>> do the range invalidation for huge page which would avoid too much of > > > >>> a behavior change for user of mmu notifier. > > > >> > > > >> Right. I would rather not make this PageHuge special though. So the > > > >> fixed version should be. > > > > > > > > Why not testing for huge ? Only huge is broken and thus only that > > > > need the extra range invalidation. Doing the double invalidation > > > > for single page is bit overkill. > > > > > > I am a bit confused, and hope this does not add to any confusion by > > > others. > > > > > > IIUC, the patch below does not attempt to 'fix' anything. It is simply > > > there to add the start/end notifiers to the v4.4 version of this routine > > > so that a subsequent patch can use them (with modified ranges) to handle > > > unmapping a shared pmd huge page. That is the mainline fix which started > > > this thread. > > > > > > Since we are only/mostly interested in fixing the shared pmd issue in > > > 4.4, how about just adding the start/end notifiers to the very specific > > > case where pmd sharing is possible? > > > > > > I can see the value in trying to back port dependent patches such as this > > > so that stable releases look more like mainline. However, I am not sure > > > of > > > the value in this case as this patch was part of a larger set changing > > > notifier semantics. > > > > For all intents
Re: [PATCH v6 1/2] mm: migration: fix migration of huge PMD shared pages
On Mon, Sep 03, 2018 at 07:56:54AM +0200, Michal Hocko wrote: > On Thu 30-08-18 14:39:44, Jerome Glisse wrote: > > On Thu, Aug 30, 2018 at 11:05:16AM -0700, Mike Kravetz wrote: > > > On 08/30/2018 09:57 AM, Jerome Glisse wrote: > > > > On Thu, Aug 30, 2018 at 06:19:52PM +0200, Michal Hocko wrote: > > > >> On Thu 30-08-18 10:08:25, Jerome Glisse wrote: > > > >>> On Thu, Aug 30, 2018 at 12:56:16PM +0200, Michal Hocko wrote: > > > On Wed 29-08-18 17:11:07, Jerome Glisse wrote: > > > > On Wed, Aug 29, 2018 at 08:39:06PM +0200, Michal Hocko wrote: > > > >> On Wed 29-08-18 14:14:25, Jerome Glisse wrote: > > > >>> On Wed, Aug 29, 2018 at 10:24:44AM -0700, Mike Kravetz wrote: > > > >> [...] > > > What would be the best mmu notifier interface to use where there > > > are no > > > start/end calls? > > > Or, is the best solution to add the start/end calls as is done > > > in later > > > versions of the code? If that is the suggestion, has there been > > > any change > > > in invalidate start/end semantics that we should take into > > > account? > > > >>> > > > >>> start/end would be the one to add, 4.4 seems broken in respect to > > > >>> THP > > > >>> and mmu notification. Another solution is to fix user of mmu > > > >>> notifier, > > > >>> they were only a handful back then. For instance properly adjust > > > >>> the > > > >>> address to match first address covered by pmd or pud and passing > > > >>> down > > > >>> correct page size to mmu_notifier_invalidate_page() would allow > > > >>> to fix > > > >>> this easily. > > > >>> > > > >>> This is ok because user of try_to_unmap_one() replace the > > > >>> pte/pmd/pud > > > >>> with an invalid one (either poison, migration or swap) inside the > > > >>> function. So anyone racing would synchronize on those special > > > >>> entry > > > >>> hence why it is fine to delay mmu_notifier_invalidate_page() to > > > >>> after > > > >>> dropping the page table lock. > > > >>> > > > >>> Adding start/end might the solution with less code churn as you > > > >>> would > > > >>> only need to change try_to_unmap_one(). > > > >> > > > >> What about dependencies? 369ea8242c0fb sounds like it needs work > > > >> for all > > > >> notifiers need to be updated as well. > > > > > > > > This commit remove mmu_notifier_invalidate_page() hence why > > > > everything > > > > need to be updated. But in 4.4 you can get away with just adding > > > > start/ > > > > end and keep around mmu_notifier_invalidate_page() to minimize > > > > disruption. > > > > > > OK, this is really interesting. I was really worried to change the > > > semantic of the mmu notifiers in stable kernels because this is > > > really > > > a hard to review change and high risk for anybody running those old > > > kernels. If we can keep the mmu_notifier_invalidate_page and wrap > > > them > > > into the range scope API then this sounds like the best way forward. > > > > > > So just to make sure we are at the same page. Does this sounds goo > > > for > > > stable 4.4. backport? Mike's hugetlb pmd shared fixup can be applied > > > on > > > top. What do you think? > > > >>> > > > >>> You need to invalidate outside page table lock so before the call to > > > >>> page_check_address(). For instance like below patch, which also only > > > >>> do the range invalidation for huge page which would avoid too much of > > > >>> a behavior change for user of mmu notifier. > > > >> > > > >> Right. I would rather not make this PageHuge special though. So the > > > >> fixed version should be. > > > > > > > > Why not testing for huge ? Only huge is broken and thus only that > > > > need the extra range invalidation. Doing the double invalidation > > > > for single page is bit overkill. > > > > > > I am a bit confused, and hope this does not add to any confusion by > > > others. > > > > > > IIUC, the patch below does not attempt to 'fix' anything. It is simply > > > there to add the start/end notifiers to the v4.4 version of this routine > > > so that a subsequent patch can use them (with modified ranges) to handle > > > unmapping a shared pmd huge page. That is the mainline fix which started > > > this thread. > > > > > > Since we are only/mostly interested in fixing the shared pmd issue in > > > 4.4, how about just adding the start/end notifiers to the very specific > > > case where pmd sharing is possible? > > > > > > I can see the value in trying to back port dependent patches such as this > > > so that stable releases look more like mainline. However, I am not sure > > > of > > > the value in this case as this patch was part of a larger set changing > > > notifier semantics. > > > > For all intents
Re: [PATCH] mm: hugepage: mark splitted page dirty when needed
On 4 Sep 2018, at 4:01, Kirill A. Shutemov wrote: > On Tue, Sep 04, 2018 at 03:55:10PM +0800, Peter Xu wrote: >> When splitting a huge page, we should set all small pages as dirty if >> the original huge page has the dirty bit set before. Otherwise we'll >> lose the original dirty bit. > > We don't lose it. It got transfered to struct page flag: > > if (pmd_dirty(old_pmd)) > SetPageDirty(page); > Plus, when split_huge_page_to_list() splits a THP, its subroutine __split_huge_page() propagates the dirty bit in the head page flag to all subpages in __split_huge_page_tail(). -- Best Regards Yan Zi signature.asc Description: OpenPGP digital signature
Re: [PATCH] mm: hugepage: mark splitted page dirty when needed
On 4 Sep 2018, at 4:01, Kirill A. Shutemov wrote: > On Tue, Sep 04, 2018 at 03:55:10PM +0800, Peter Xu wrote: >> When splitting a huge page, we should set all small pages as dirty if >> the original huge page has the dirty bit set before. Otherwise we'll >> lose the original dirty bit. > > We don't lose it. It got transfered to struct page flag: > > if (pmd_dirty(old_pmd)) > SetPageDirty(page); > Plus, when split_huge_page_to_list() splits a THP, its subroutine __split_huge_page() propagates the dirty bit in the head page flag to all subpages in __split_huge_page_tail(). -- Best Regards Yan Zi signature.asc Description: OpenPGP digital signature
Re: [RFC] perf tool improvement requests
On Tue, Sep 04, 2018 at 03:53:25PM +0200, Peter Zijlstra wrote: > On Tue, Sep 04, 2018 at 10:42:18AM -0300, Arnaldo Carvalho de Melo wrote: > > So, use 'c2c record' to get the samples: > > IIRC that uses numa events and is completely useless. I guess perf record on any other event would work in Arnaldo's workflow jirka
Re: [RFC] perf tool improvement requests
On Tue, Sep 04, 2018 at 03:53:25PM +0200, Peter Zijlstra wrote: > On Tue, Sep 04, 2018 at 10:42:18AM -0300, Arnaldo Carvalho de Melo wrote: > > So, use 'c2c record' to get the samples: > > IIRC that uses numa events and is completely useless. I guess perf record on any other event would work in Arnaldo's workflow jirka
Re: [PATCH 3/3] ASoC: qdsp6: q6asm-dai: Add support to compress offload
On 03-09-18, 13:34, Srinivas Kandagatla wrote:
> +static void compress_event_handler(uint32_t opcode, uint32_t token,
> +uint32_t *payload, void *priv)
> +{
> + struct q6asm_dai_rtd *prtd = priv;
> + struct snd_compr_stream *substream = prtd->cstream;
> + unsigned long flags;
> + uint64_t avail;
> +
> + switch (opcode) {
> + case ASM_CLIENT_EVENT_CMD_RUN_DONE:
> + spin_lock_irqsave(>lock, flags);
> + avail = prtd->bytes_received - prtd->bytes_sent;
> + if (!prtd->bytes_sent) {
> + if (avail < substream->runtime->fragment_size) {
> + prtd->xrun = 1;
so you are trying to detect xrun :) So in compress core we added support
for .ack callback which tells driver how much data is valid in ring
buffer and we can send this to DSP, so DSP "knows" valid data and should
not overrun, ofcourse DSP needs support for it
> + } else {
> + q6asm_write_async(prtd->audio_client,
> + prtd->pcm_count,
> + 0, 0, NO_TIMESTAMP);
> + prtd->bytes_sent += prtd->pcm_count;
> + }
> + }
> +
> + spin_unlock_irqrestore(>lock, flags);
> + break;
empty line after break helps readability
> + case ASM_CLIENT_EVENT_CMD_EOS_DONE:
> + prtd->state = Q6ASM_STREAM_STOPPED;
> + break;
> + case ASM_CLIENT_EVENT_DATA_WRITE_DONE:
> + spin_lock_irqsave(>lock, flags);
> + prtd->byte_offset += prtd->pcm_count;
> + prtd->copied_total += prtd->pcm_count;
so should you need two counters, copied_total should give you byte_offset
as well, we know the ring buffer size
> +
> + if (prtd->byte_offset >= prtd->pcm_size)
> + prtd->byte_offset -= prtd->pcm_size;
:)
> +
> + snd_compr_fragment_elapsed(substream);
so will ASM_CLIENT_EVENT_DATA_WRITE_DONE be invoked on fragment bytes
consumed?
> +static int q6asm_dai_compr_set_params(struct snd_compr_stream *stream,
> + struct snd_compr_params *params)
> +{
> +
redundant empty line
> +static int q6asm_dai_compr_trigger(struct snd_compr_stream *stream, int cmd)
> +{
> + struct snd_compr_runtime *runtime = stream->runtime;
> + struct q6asm_dai_rtd *prtd = runtime->private_data;
> + int ret = 0;
> +
> + switch (cmd) {
> + case SNDRV_PCM_TRIGGER_START:
> + case SNDRV_PCM_TRIGGER_RESUME:
> + case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
> + ret = q6asm_run_nowait(prtd->audio_client, 0, 0, 0);
the triggers are not in atomic context, do we have q6asm_run()
> +static int q6asm_dai_compr_copy(struct snd_compr_stream *stream,
> + char __user *buf, size_t count)
> +{
> + struct snd_compr_runtime *runtime = stream->runtime;
> + struct q6asm_dai_rtd *prtd = runtime->private_data;
> + uint64_t avail = 0;
> + unsigned long flags;
> + size_t copy;
> + void *dstn;
> +
> + dstn = prtd->buffer + prtd->copy_pointer;
> + if (count < prtd->pcm_size - prtd->copy_pointer) {
> + if (copy_from_user(dstn, buf, count))
> + return -EFAULT;
> +
> + prtd->copy_pointer += count;
> + } else {
> + copy = prtd->pcm_size - prtd->copy_pointer;
> + if (copy_from_user(dstn, buf, copy))
> + return -EFAULT;
> +
> + if (copy_from_user(prtd->buffer, buf + copy, count - copy))
> + return -EFAULT;
> + prtd->copy_pointer = count - copy;
> + }
> +
> + spin_lock_irqsave(>lock, flags);
> + prtd->bytes_received += count;
why not use core copy method and...
> +
> + if (prtd->state == Q6ASM_STREAM_RUNNING && prtd->xrun) {
> + avail = prtd->bytes_received - prtd->copied_total;
> + if (avail >= runtime->fragment_size) {
> + prtd->xrun = 0;
> + q6asm_write_async(prtd->audio_client,
> +prtd->pcm_count, 0, 0, NO_TIMESTAMP);
> + prtd->bytes_sent += prtd->pcm_count;
> + }
> + }
move this to .ack
> +static int q6asm_dai_compr_get_codec_caps(struct snd_compr_stream *stream,
> + struct snd_compr_codec_caps *codec)
> +{
> + switch (codec->codec) {
> + case SND_AUDIOCODEC_MP3:
> + codec->num_descriptors = 2;
> + codec->descriptor[0].max_ch = 2;
> + memcpy(codec->descriptor[0].sample_rates,
> +supported_sample_rates,
> +sizeof(supported_sample_rates));
> + codec->descriptor[0].num_sample_rates =
> + sizeof(supported_sample_rates)/sizeof(unsigned
Re: [PATCH] ASoC: tlv320aic31xx: Add MICBIAS off setting
On 09/03/2018 06:26 AM, Mark Brown wrote: > On Fri, Aug 31, 2018 at 01:05:07PM -0500, Andrew F. Davis wrote: >> Leaving microphone bias off is a valid setting and even used in the DT >> binding document example. Add this setting here and document the same. >> Although it may not make much sense to enable a microphone here without >> any bias, it is a valid setting that can be chosen by DT and may be >> needed for some boards. > > If we really want to pay attention to something setting this up we'd > need to completely remove the widget - what the code is doing at the > minute is setting the voltage that the bias will go to when enabled, > there's still a widget for turning it on and off. There's some chance > that this will break existing boards. > Turning on bias is controlled separately, automatically in user-space in many cases, not based on the board. The DT needs to have a way to state that 0v is the needed bias on this board, without this you can not set 0v bias and 2v is chosen by default (which is IMHO should be 0v but that would change existing behavior so I won't touch that).
Re: [PATCH 3/3] ASoC: qdsp6: q6asm-dai: Add support to compress offload
On 03-09-18, 13:34, Srinivas Kandagatla wrote:
> +static void compress_event_handler(uint32_t opcode, uint32_t token,
> +uint32_t *payload, void *priv)
> +{
> + struct q6asm_dai_rtd *prtd = priv;
> + struct snd_compr_stream *substream = prtd->cstream;
> + unsigned long flags;
> + uint64_t avail;
> +
> + switch (opcode) {
> + case ASM_CLIENT_EVENT_CMD_RUN_DONE:
> + spin_lock_irqsave(>lock, flags);
> + avail = prtd->bytes_received - prtd->bytes_sent;
> + if (!prtd->bytes_sent) {
> + if (avail < substream->runtime->fragment_size) {
> + prtd->xrun = 1;
so you are trying to detect xrun :) So in compress core we added support
for .ack callback which tells driver how much data is valid in ring
buffer and we can send this to DSP, so DSP "knows" valid data and should
not overrun, ofcourse DSP needs support for it
> + } else {
> + q6asm_write_async(prtd->audio_client,
> + prtd->pcm_count,
> + 0, 0, NO_TIMESTAMP);
> + prtd->bytes_sent += prtd->pcm_count;
> + }
> + }
> +
> + spin_unlock_irqrestore(>lock, flags);
> + break;
empty line after break helps readability
> + case ASM_CLIENT_EVENT_CMD_EOS_DONE:
> + prtd->state = Q6ASM_STREAM_STOPPED;
> + break;
> + case ASM_CLIENT_EVENT_DATA_WRITE_DONE:
> + spin_lock_irqsave(>lock, flags);
> + prtd->byte_offset += prtd->pcm_count;
> + prtd->copied_total += prtd->pcm_count;
so should you need two counters, copied_total should give you byte_offset
as well, we know the ring buffer size
> +
> + if (prtd->byte_offset >= prtd->pcm_size)
> + prtd->byte_offset -= prtd->pcm_size;
:)
> +
> + snd_compr_fragment_elapsed(substream);
so will ASM_CLIENT_EVENT_DATA_WRITE_DONE be invoked on fragment bytes
consumed?
> +static int q6asm_dai_compr_set_params(struct snd_compr_stream *stream,
> + struct snd_compr_params *params)
> +{
> +
redundant empty line
> +static int q6asm_dai_compr_trigger(struct snd_compr_stream *stream, int cmd)
> +{
> + struct snd_compr_runtime *runtime = stream->runtime;
> + struct q6asm_dai_rtd *prtd = runtime->private_data;
> + int ret = 0;
> +
> + switch (cmd) {
> + case SNDRV_PCM_TRIGGER_START:
> + case SNDRV_PCM_TRIGGER_RESUME:
> + case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
> + ret = q6asm_run_nowait(prtd->audio_client, 0, 0, 0);
the triggers are not in atomic context, do we have q6asm_run()
> +static int q6asm_dai_compr_copy(struct snd_compr_stream *stream,
> + char __user *buf, size_t count)
> +{
> + struct snd_compr_runtime *runtime = stream->runtime;
> + struct q6asm_dai_rtd *prtd = runtime->private_data;
> + uint64_t avail = 0;
> + unsigned long flags;
> + size_t copy;
> + void *dstn;
> +
> + dstn = prtd->buffer + prtd->copy_pointer;
> + if (count < prtd->pcm_size - prtd->copy_pointer) {
> + if (copy_from_user(dstn, buf, count))
> + return -EFAULT;
> +
> + prtd->copy_pointer += count;
> + } else {
> + copy = prtd->pcm_size - prtd->copy_pointer;
> + if (copy_from_user(dstn, buf, copy))
> + return -EFAULT;
> +
> + if (copy_from_user(prtd->buffer, buf + copy, count - copy))
> + return -EFAULT;
> + prtd->copy_pointer = count - copy;
> + }
> +
> + spin_lock_irqsave(>lock, flags);
> + prtd->bytes_received += count;
why not use core copy method and...
> +
> + if (prtd->state == Q6ASM_STREAM_RUNNING && prtd->xrun) {
> + avail = prtd->bytes_received - prtd->copied_total;
> + if (avail >= runtime->fragment_size) {
> + prtd->xrun = 0;
> + q6asm_write_async(prtd->audio_client,
> +prtd->pcm_count, 0, 0, NO_TIMESTAMP);
> + prtd->bytes_sent += prtd->pcm_count;
> + }
> + }
move this to .ack
> +static int q6asm_dai_compr_get_codec_caps(struct snd_compr_stream *stream,
> + struct snd_compr_codec_caps *codec)
> +{
> + switch (codec->codec) {
> + case SND_AUDIOCODEC_MP3:
> + codec->num_descriptors = 2;
> + codec->descriptor[0].max_ch = 2;
> + memcpy(codec->descriptor[0].sample_rates,
> +supported_sample_rates,
> +sizeof(supported_sample_rates));
> + codec->descriptor[0].num_sample_rates =
> + sizeof(supported_sample_rates)/sizeof(unsigned
Re: [PATCH] ASoC: tlv320aic31xx: Add MICBIAS off setting
On 09/03/2018 06:26 AM, Mark Brown wrote: > On Fri, Aug 31, 2018 at 01:05:07PM -0500, Andrew F. Davis wrote: >> Leaving microphone bias off is a valid setting and even used in the DT >> binding document example. Add this setting here and document the same. >> Although it may not make much sense to enable a microphone here without >> any bias, it is a valid setting that can be chosen by DT and may be >> needed for some boards. > > If we really want to pay attention to something setting this up we'd > need to completely remove the widget - what the code is doing at the > minute is setting the voltage that the bias will go to when enabled, > there's still a widget for turning it on and off. There's some chance > that this will break existing boards. > Turning on bias is controlled separately, automatically in user-space in many cases, not based on the board. The DT needs to have a way to state that 0v is the needed bias on this board, without this you can not set 0v bias and 2v is chosen by default (which is IMHO should be 0v but that would change existing behavior so I won't touch that).
Re: [RFC] perf tool improvement requests
On Tue, Sep 04, 2018 at 10:42:18AM -0300, Arnaldo Carvalho de Melo wrote: > So, use 'c2c record' to get the samples: IIRC that uses numa events and is completely useless.
Re: [RFC] perf tool improvement requests
On Tue, Sep 04, 2018 at 10:42:18AM -0300, Arnaldo Carvalho de Melo wrote: > So, use 'c2c record' to get the samples: IIRC that uses numa events and is completely useless.
Re: [PATCH 4/4] PCI: xilinx-nwl: Add method to setup_platform_service_irq hook
On Fri, Aug 10, 2018 at 09:09:40PM +0530, Bharat Kumar Gogada wrote:
> Add nwl_setup_service_irqs hook to setup_platform_service_irq IRQs to
> register platform provided IRQ number to kernel AER service.
>
> Signed-off-by: Bharat Kumar Gogada
> ---
> drivers/pci/controller/pcie-xilinx-nwl.c | 16
> 1 files changed, 16 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-xilinx-nwl.c
> b/drivers/pci/controller/pcie-xilinx-nwl.c
> index fb32840..285647b 100644
> --- a/drivers/pci/controller/pcie-xilinx-nwl.c
> +++ b/drivers/pci/controller/pcie-xilinx-nwl.c
> @@ -22,6 +22,7 @@
> #include
>
> #include "../pci.h"
> +#include "../pcie/portdrv.h"
>
> /* Bridge core config registers */
> #define BRCFG_PCIE_RX0 0x
> @@ -819,6 +820,20 @@ static int nwl_pcie_parse_dt(struct nwl_pcie *pcie,
> return 0;
> }
>
> +int nwl_setup_service_irqs(struct pci_host_bridge *bridge, int *irqs,
> +int plat_mask)
> +{
> + struct nwl_pcie *pcie;
> +
> + pcie = pci_host_bridge_priv(bridge);
> + if (plat_mask & PCIE_PORT_SERVICE_AER) {
> + irqs[PCIE_PORT_SERVICE_AER_SHIFT] = pcie->irq_misc;
> + plat_mask &= ~(1 << PCIE_PORT_SERVICE_AER_SHIFT);
> + }
If I understand correctly, this ultimately results in pcie->irq_misc
being hooked up to aer_irq() via the aer_probe() path. We already
have pcie->irq_misc being hooked up to nwl_pcie_misc_handler() via
nwl_pcie_bridge_init().
We can't rely on the ordering of the two handlers. Is it safe if
nwl_pcie_misc_handler() runs first, followed by aer_irq()? It looks
like nwl_pcie_misc_handler() might log messages and clear AER-related
errors. If that's the case aer_irq() might not find anything to do.
> +
> + return plat_mask;
> +}
> +
> static const struct of_device_id nwl_pcie_of_match[] = {
> { .compatible = "xlnx,nwl-pcie-2.11", },
> {}
> @@ -880,6 +895,7 @@ static int nwl_pcie_probe(struct platform_device *pdev)
> bridge->ops = _pcie_ops;
> bridge->map_irq = of_irq_parse_and_map_pci;
> bridge->swizzle_irq = pci_common_swizzle;
> + bridge->setup_platform_service_irq = nwl_setup_service_irqs;
>
> if (IS_ENABLED(CONFIG_PCI_MSI)) {
> err = nwl_pcie_enable_msi(pcie);
> --
> 1.7.1
>
Re: [PATCH 4/4] PCI: xilinx-nwl: Add method to setup_platform_service_irq hook
On Fri, Aug 10, 2018 at 09:09:40PM +0530, Bharat Kumar Gogada wrote:
> Add nwl_setup_service_irqs hook to setup_platform_service_irq IRQs to
> register platform provided IRQ number to kernel AER service.
>
> Signed-off-by: Bharat Kumar Gogada
> ---
> drivers/pci/controller/pcie-xilinx-nwl.c | 16
> 1 files changed, 16 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-xilinx-nwl.c
> b/drivers/pci/controller/pcie-xilinx-nwl.c
> index fb32840..285647b 100644
> --- a/drivers/pci/controller/pcie-xilinx-nwl.c
> +++ b/drivers/pci/controller/pcie-xilinx-nwl.c
> @@ -22,6 +22,7 @@
> #include
>
> #include "../pci.h"
> +#include "../pcie/portdrv.h"
>
> /* Bridge core config registers */
> #define BRCFG_PCIE_RX0 0x
> @@ -819,6 +820,20 @@ static int nwl_pcie_parse_dt(struct nwl_pcie *pcie,
> return 0;
> }
>
> +int nwl_setup_service_irqs(struct pci_host_bridge *bridge, int *irqs,
> +int plat_mask)
> +{
> + struct nwl_pcie *pcie;
> +
> + pcie = pci_host_bridge_priv(bridge);
> + if (plat_mask & PCIE_PORT_SERVICE_AER) {
> + irqs[PCIE_PORT_SERVICE_AER_SHIFT] = pcie->irq_misc;
> + plat_mask &= ~(1 << PCIE_PORT_SERVICE_AER_SHIFT);
> + }
If I understand correctly, this ultimately results in pcie->irq_misc
being hooked up to aer_irq() via the aer_probe() path. We already
have pcie->irq_misc being hooked up to nwl_pcie_misc_handler() via
nwl_pcie_bridge_init().
We can't rely on the ordering of the two handlers. Is it safe if
nwl_pcie_misc_handler() runs first, followed by aer_irq()? It looks
like nwl_pcie_misc_handler() might log messages and clear AER-related
errors. If that's the case aer_irq() might not find anything to do.
> +
> + return plat_mask;
> +}
> +
> static const struct of_device_id nwl_pcie_of_match[] = {
> { .compatible = "xlnx,nwl-pcie-2.11", },
> {}
> @@ -880,6 +895,7 @@ static int nwl_pcie_probe(struct platform_device *pdev)
> bridge->ops = _pcie_ops;
> bridge->map_irq = of_irq_parse_and_map_pci;
> bridge->swizzle_irq = pci_common_swizzle;
> + bridge->setup_platform_service_irq = nwl_setup_service_irqs;
>
> if (IS_ENABLED(CONFIG_PCI_MSI)) {
> err = nwl_pcie_enable_msi(pcie);
> --
> 1.7.1
>
Re: [PATCH v4 14/16] sched/core: uclamp: request CAP_SYS_ADMIN by default
Hi,
On 28/08/18 14:53, Patrick Bellasi wrote:
> The number of clamp groups supported is limited and defined at compile
> time. However, a malicious user can currently ask for many different
Even if not malicious.. :-)
> clamp values thus consuming all the available clamp groups.
>
> Since on properly configured systems we expect only a limited set of
> different clamp values, the previous problem can be mitigated by
> allowing access to clamp groups configuration only to privileged tasks.
> This should still allow a System Management Software to properly
> pre-configure the system.
>
> Let's restrict the tuning of utilization clamp values, by default, to
> tasks with CAP_SYS_ADMIN capabilities.
>
> Whenever this should be considered too restrictive and/or not required
> for a specific platforms, a kernel boot option is provided to change
> this default behavior thus allowing non privileged tasks to change their
> utilization clamp values.
>
> Signed-off-by: Patrick Bellasi
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Rafael J. Wysocki
> Cc: Paul Turner
> Cc: Suren Baghdasaryan
> Cc: Todd Kjos
> Cc: Joel Fernandes
> Cc: Steve Muckle
> Cc: Juri Lelli
> Cc: Quentin Perret
> Cc: Dietmar Eggemann
> Cc: Morten Rasmussen
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@vger.kernel.org
>
> ---
> Changes in v4:
> Others:
> - new patch added in this version
> - rebased on v4.19-rc1
> ---
> .../admin-guide/kernel-parameters.txt | 3 +++
> kernel/sched/core.c | 22 ---
> 2 files changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt
> b/Documentation/admin-guide/kernel-parameters.txt
> index 9871e649ffef..481f8214ea9a 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -4561,6 +4561,9 @@
> ,,,
> See also
> Documentation/input/devices/joystick-parport.rst
>
> + uclamp_user [KNL] Enable task-specific utilization clamping tuning
> + also from tasks without CAP_SYS_ADMIN capability.
> +
> udbg-immortal [PPC] When debugging early kernel crashes that
> happen after console_init() and before a proper
> console driver takes over, this boot options might
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 222397edb8a7..8341ce580a9a 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -1510,14 +1510,29 @@ static inline int alloc_uclamp_sched_group(struct
> task_group *tg,
> static inline void free_uclamp_sched_group(struct task_group *tg) { }
> #endif /* CONFIG_UCLAMP_TASK_GROUP */
>
> +static bool uclamp_user_allowed __read_mostly;
> +static int __init uclamp_user_allow(char *str)
> +{
> + uclamp_user_allowed = true;
> +
> + return 0;
> +}
> +early_param("uclamp_user", uclamp_user_allow);
> +
> static inline int __setscheduler_uclamp(struct task_struct *p,
> - const struct sched_attr *attr)
> + const struct sched_attr *attr,
> + bool user)
Wondering if you want to fold the check below inside the
if (user && !capable(CAP_SYS_NICE)) {
...
}
block. It would also save you from adding another parameter to the
function.
> {
> int group_id[UCLAMP_CNT] = { UCLAMP_NOT_VALID };
> int lower_bound, upper_bound;
> struct uclamp_se *uc_se;
> int result = 0;
>
> + if (!capable(CAP_SYS_ADMIN) &&
> + user && !uclamp_user_allowed) {
> + return -EPERM;
> + }
> +
Best,
- Juri
Re: [PATCH v4 14/16] sched/core: uclamp: request CAP_SYS_ADMIN by default
Hi,
On 28/08/18 14:53, Patrick Bellasi wrote:
> The number of clamp groups supported is limited and defined at compile
> time. However, a malicious user can currently ask for many different
Even if not malicious.. :-)
> clamp values thus consuming all the available clamp groups.
>
> Since on properly configured systems we expect only a limited set of
> different clamp values, the previous problem can be mitigated by
> allowing access to clamp groups configuration only to privileged tasks.
> This should still allow a System Management Software to properly
> pre-configure the system.
>
> Let's restrict the tuning of utilization clamp values, by default, to
> tasks with CAP_SYS_ADMIN capabilities.
>
> Whenever this should be considered too restrictive and/or not required
> for a specific platforms, a kernel boot option is provided to change
> this default behavior thus allowing non privileged tasks to change their
> utilization clamp values.
>
> Signed-off-by: Patrick Bellasi
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Rafael J. Wysocki
> Cc: Paul Turner
> Cc: Suren Baghdasaryan
> Cc: Todd Kjos
> Cc: Joel Fernandes
> Cc: Steve Muckle
> Cc: Juri Lelli
> Cc: Quentin Perret
> Cc: Dietmar Eggemann
> Cc: Morten Rasmussen
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@vger.kernel.org
>
> ---
> Changes in v4:
> Others:
> - new patch added in this version
> - rebased on v4.19-rc1
> ---
> .../admin-guide/kernel-parameters.txt | 3 +++
> kernel/sched/core.c | 22 ---
> 2 files changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt
> b/Documentation/admin-guide/kernel-parameters.txt
> index 9871e649ffef..481f8214ea9a 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -4561,6 +4561,9 @@
> ,,,
> See also
> Documentation/input/devices/joystick-parport.rst
>
> + uclamp_user [KNL] Enable task-specific utilization clamping tuning
> + also from tasks without CAP_SYS_ADMIN capability.
> +
> udbg-immortal [PPC] When debugging early kernel crashes that
> happen after console_init() and before a proper
> console driver takes over, this boot options might
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 222397edb8a7..8341ce580a9a 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -1510,14 +1510,29 @@ static inline int alloc_uclamp_sched_group(struct
> task_group *tg,
> static inline void free_uclamp_sched_group(struct task_group *tg) { }
> #endif /* CONFIG_UCLAMP_TASK_GROUP */
>
> +static bool uclamp_user_allowed __read_mostly;
> +static int __init uclamp_user_allow(char *str)
> +{
> + uclamp_user_allowed = true;
> +
> + return 0;
> +}
> +early_param("uclamp_user", uclamp_user_allow);
> +
> static inline int __setscheduler_uclamp(struct task_struct *p,
> - const struct sched_attr *attr)
> + const struct sched_attr *attr,
> + bool user)
Wondering if you want to fold the check below inside the
if (user && !capable(CAP_SYS_NICE)) {
...
}
block. It would also save you from adding another parameter to the
function.
> {
> int group_id[UCLAMP_CNT] = { UCLAMP_NOT_VALID };
> int lower_bound, upper_bound;
> struct uclamp_se *uc_se;
> int result = 0;
>
> + if (!capable(CAP_SYS_ADMIN) &&
> + user && !uclamp_user_allowed) {
> + return -EPERM;
> + }
> +
Best,
- Juri
Re: REGRESSION: boot stalls on several old dual core Intel CPUs
On Mon, Sep 03, 2018 at 11:33:05AM +0200, Peter Zijlstra wrote:
> On Mon, Sep 03, 2018 at 10:54:23AM +0200, Peter Zijlstra wrote:
> > On Mon, Sep 03, 2018 at 09:38:15AM +0200, Thomas Gleixner wrote:
> > > On Mon, 3 Sep 2018, Peter Zijlstra wrote:
> > > > On Sat, Sep 01, 2018 at 11:51:26AM +0930, Kevin Shanahan wrote:
> > > > > commit 01548f4d3e8e94caf323a4f664eb347fd34a34ab
> > > > > Author: Martin Schwidefsky
> > > > > Date: Tue Aug 18 17:09:42 2009 +0200
> > > > >
> > > > > clocksource: Avoid clocksource watchdog circular locking
> > > > > dependency
> > > > >
> > > > > stop_machine from a multithreaded workqueue is not allowed because
> > > > > of a circular locking dependency between cpu_down and the
> > > > > workqueue
> > > > > execution. Use a kernel thread to do the clocksource downgrade.
> > > >
> > > > I cannot find stop_machine usage there; either it went away or I need to
> > > > like wake up.
> > >
> > > timekeeping_notify() which is involved in switching clock source uses
> > > stomp
> > > machine.
> >
> > ARGH... OK, lemme see if I can come up with something other than
> > endlessly spawning that kthread.
> >
> > A special purpose kthread_worker would make more sense than that.
>
> Can someone test this?
>
> ---
> kernel/time/clocksource.c | 28 ++--
> 1 file changed, 22 insertions(+), 6 deletions(-)
>
> diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
> index f74fb00d8064..898976d0082a 100644
> --- a/kernel/time/clocksource.c
> +++ b/kernel/time/clocksource.c
> @@ -112,13 +112,28 @@ static int finished_booting;
> static u64 suspend_start;
>
> #ifdef CONFIG_CLOCKSOURCE_WATCHDOG
> -static void clocksource_watchdog_work(struct work_struct *work);
> +static void clocksource_watchdog_work(struct kthread_work *work);
> static void clocksource_select(void);
>
> static LIST_HEAD(watchdog_list);
> static struct clocksource *watchdog;
> static struct timer_list watchdog_timer;
> -static DECLARE_WORK(watchdog_work, clocksource_watchdog_work);
> +
> +/*
> + * We must use a kthread_worker here, because:
> + *
> + * clocksource_watchdog_work()
> + * clocksource_select()
> + * __clocksource_select()
> + * timekeeping_notify()
> + * stop_machine()
> + *
> + * cannot be called from a reqular workqueue, because of deadlocks between
> + * workqueue and stopmachine.
> + */
> +static struct kthread_worker *watchdog_worker;
> +static DEFINE_KTHREAD_WORK(watchdog_work, clocksource_watchdog_work);
> +
> static DEFINE_SPINLOCK(watchdog_lock);
> static int watchdog_running;
> static atomic_t watchdog_reset_pending;
> @@ -158,7 +173,7 @@ static void __clocksource_unstable(struct clocksource *cs)
>
> /* kick clocksource_watchdog_work() */
> if (finished_booting)
> - schedule_work(_work);
> + kthread_queue_work(watchdog_worker, _work);
> }
>
> /**
> @@ -199,7 +214,7 @@ static void clocksource_watchdog(struct timer_list
> *unused)
> /* Clocksource already marked unstable? */
> if (cs->flags & CLOCK_SOURCE_UNSTABLE) {
> if (finished_booting)
> - schedule_work(_work);
> + kthread_queue_work(watchdog_worker,
> _work);
> continue;
> }
>
> @@ -269,7 +284,7 @@ static void clocksource_watchdog(struct timer_list
> *unused)
>*/
> if (cs != curr_clocksource) {
> cs->flags |= CLOCK_SOURCE_RESELECT;
> - schedule_work(_work);
> + kthread_queue_work(watchdog_worker,
> _work);
> } else {
> tick_clock_notify();
> }
> @@ -418,7 +433,7 @@ static int __clocksource_watchdog_work(void)
> return select;
> }
>
> -static void clocksource_watchdog_work(struct work_struct *work)
> +static void clocksource_watchdog_work(struct kthread_work *work)
> {
> mutex_lock(_mutex);
> if (__clocksource_watchdog_work())
> @@ -806,6 +821,7 @@ static int __init clocksource_done_booting(void)
> {
> mutex_lock(_mutex);
> curr_clocksource = clocksource_default_clock();
> + watchdog_worker = kthread_create_worker(0, "cs-watchdog");
Hello Peter,
watchdog_worker is only defined if CONFIG_CLOCKSOURCE_WATCHDOG is set,
so you might want to wrap it with an ifdef to avoid build errors.
Kind regards,
Niklas
> finished_booting = 1;
> /*
>* Run the watchdog first to eliminate unstable clock sources
Re: REGRESSION: boot stalls on several old dual core Intel CPUs
On Mon, Sep 03, 2018 at 11:33:05AM +0200, Peter Zijlstra wrote:
> On Mon, Sep 03, 2018 at 10:54:23AM +0200, Peter Zijlstra wrote:
> > On Mon, Sep 03, 2018 at 09:38:15AM +0200, Thomas Gleixner wrote:
> > > On Mon, 3 Sep 2018, Peter Zijlstra wrote:
> > > > On Sat, Sep 01, 2018 at 11:51:26AM +0930, Kevin Shanahan wrote:
> > > > > commit 01548f4d3e8e94caf323a4f664eb347fd34a34ab
> > > > > Author: Martin Schwidefsky
> > > > > Date: Tue Aug 18 17:09:42 2009 +0200
> > > > >
> > > > > clocksource: Avoid clocksource watchdog circular locking
> > > > > dependency
> > > > >
> > > > > stop_machine from a multithreaded workqueue is not allowed because
> > > > > of a circular locking dependency between cpu_down and the
> > > > > workqueue
> > > > > execution. Use a kernel thread to do the clocksource downgrade.
> > > >
> > > > I cannot find stop_machine usage there; either it went away or I need to
> > > > like wake up.
> > >
> > > timekeeping_notify() which is involved in switching clock source uses
> > > stomp
> > > machine.
> >
> > ARGH... OK, lemme see if I can come up with something other than
> > endlessly spawning that kthread.
> >
> > A special purpose kthread_worker would make more sense than that.
>
> Can someone test this?
>
> ---
> kernel/time/clocksource.c | 28 ++--
> 1 file changed, 22 insertions(+), 6 deletions(-)
>
> diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
> index f74fb00d8064..898976d0082a 100644
> --- a/kernel/time/clocksource.c
> +++ b/kernel/time/clocksource.c
> @@ -112,13 +112,28 @@ static int finished_booting;
> static u64 suspend_start;
>
> #ifdef CONFIG_CLOCKSOURCE_WATCHDOG
> -static void clocksource_watchdog_work(struct work_struct *work);
> +static void clocksource_watchdog_work(struct kthread_work *work);
> static void clocksource_select(void);
>
> static LIST_HEAD(watchdog_list);
> static struct clocksource *watchdog;
> static struct timer_list watchdog_timer;
> -static DECLARE_WORK(watchdog_work, clocksource_watchdog_work);
> +
> +/*
> + * We must use a kthread_worker here, because:
> + *
> + * clocksource_watchdog_work()
> + * clocksource_select()
> + * __clocksource_select()
> + * timekeeping_notify()
> + * stop_machine()
> + *
> + * cannot be called from a reqular workqueue, because of deadlocks between
> + * workqueue and stopmachine.
> + */
> +static struct kthread_worker *watchdog_worker;
> +static DEFINE_KTHREAD_WORK(watchdog_work, clocksource_watchdog_work);
> +
> static DEFINE_SPINLOCK(watchdog_lock);
> static int watchdog_running;
> static atomic_t watchdog_reset_pending;
> @@ -158,7 +173,7 @@ static void __clocksource_unstable(struct clocksource *cs)
>
> /* kick clocksource_watchdog_work() */
> if (finished_booting)
> - schedule_work(_work);
> + kthread_queue_work(watchdog_worker, _work);
> }
>
> /**
> @@ -199,7 +214,7 @@ static void clocksource_watchdog(struct timer_list
> *unused)
> /* Clocksource already marked unstable? */
> if (cs->flags & CLOCK_SOURCE_UNSTABLE) {
> if (finished_booting)
> - schedule_work(_work);
> + kthread_queue_work(watchdog_worker,
> _work);
> continue;
> }
>
> @@ -269,7 +284,7 @@ static void clocksource_watchdog(struct timer_list
> *unused)
>*/
> if (cs != curr_clocksource) {
> cs->flags |= CLOCK_SOURCE_RESELECT;
> - schedule_work(_work);
> + kthread_queue_work(watchdog_worker,
> _work);
> } else {
> tick_clock_notify();
> }
> @@ -418,7 +433,7 @@ static int __clocksource_watchdog_work(void)
> return select;
> }
>
> -static void clocksource_watchdog_work(struct work_struct *work)
> +static void clocksource_watchdog_work(struct kthread_work *work)
> {
> mutex_lock(_mutex);
> if (__clocksource_watchdog_work())
> @@ -806,6 +821,7 @@ static int __init clocksource_done_booting(void)
> {
> mutex_lock(_mutex);
> curr_clocksource = clocksource_default_clock();
> + watchdog_worker = kthread_create_worker(0, "cs-watchdog");
Hello Peter,
watchdog_worker is only defined if CONFIG_CLOCKSOURCE_WATCHDOG is set,
so you might want to wrap it with an ifdef to avoid build errors.
Kind regards,
Niklas
> finished_booting = 1;
> /*
>* Run the watchdog first to eliminate unstable clock sources
Re: [RFC] perf tool improvement requests
Em Tue, Sep 04, 2018 at 09:10:49AM +0200, Peter Zijlstra escreveu:
> On Mon, Sep 03, 2018 at 07:45:48PM -0700, Stephane Eranian wrote:
> > A few weeks ago, you had asked if I had more requests for the perf tool.
> I have one long standing one; that is IP based data structure
> annotation.
> When we get an exact IP (using PEBS) and were sampling a data related
> event (say L1 misses), we can get the data type from the instruction
> itself; that is, through DWARF. We _know_ what type (structure::member)
> is read/written to.
> I would love to get that in a pahole style output.
> Better yet, when you measure both hits and misses, you can get a
> structure usage overview, and see what lines are used lots and what
> members inside that line are rarely used. Ideal information for data
> structure layout optimization.
> 1000x more useful than that c2c crap.
> Can we please get that?
So, use 'c2c record' to get the samples:
[root@jouet ~]# perf c2c record
^C[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 5.152 MB perf.data (4555 samples) ]
Events collected:
[root@jouet ~]# perf evlist -v
cpu/mem-loads,ldlat=30/P: type: 4, size: 112, config: 0x1cd, { sample_period,
sample_freq }: 4000, sample_type:
IP|TID|TIME|ADDR|ID|CPU|PERIOD|DATA_SRC|WEIGHT|PHYS_ADDR, read_format: ID,
disabled: 1, inherit: 1, mmap: 1, comm: 1, freq: 1, task: 1, precise_ip: 3,
mmap_data: 1, sample_id_all: 1, mmap2: 1, comm_exec: 1, { bp_addr, config1 }:
0x1f
cpu/mem-stores/P: type: 4, size: 112, config: 0x82d0, { sample_period,
sample_freq }: 4000, sample_type:
IP|TID|TIME|ADDR|ID|CPU|PERIOD|DATA_SRC|WEIGHT|PHYS_ADDR, read_format: ID,
disabled: 1, inherit: 1, freq: 1, precise_ip: 3, sample_id_all: 1
Then we'll get a 'annotate --hits' option (just cooked up, will
polish) that will show the name of the function, info about it globally,
i.e. what annotate already produced, we may get this in CSV for better
post processing consumption:
[root@jouet ~]# perf annotate --hits kmem_cache_alloc
Samples: 20 of event 'cpu/mem-loads,ldlat=30/P', 4000 Hz, Event count
(approx.): 875, [percent: local period]
kmem_cache_alloc() /usr/lib/debug/lib/modules/4.17.17-100.fc27.x86_64/vmlinux
4.91 15: movgfp_allowed_mask,%ebx
2.51 51: mov(%r15),%r8
17.14 54: mov%gs:0x8(%r8),%rdx
6.51 61: cmpq $0x0,0x10(%r8)
17.14 66: mov(%r8),%r14
6.29 78: mov0x20(%r15),%ebx
5.71 7c: mov(%r15),%rdi
29.49 85: xor0x138(%r15),%rbx
2.86 9d: lea(%rdi),%rsi
3.43 d7: pop%rbx
2.29 dc: pop%r12
1.71 ed: testb $0x4,0xb(%rbp)
[root@jouet ~]#
Then I need to get the DW_AT_location stuff parsed in pahole, so
that with those offsets (second column, ending with :) with hits (first
column, there its local period, but we can ask for some specific metric
[1]), I'll be able to figure out what DW_TAG_variable or
DW_TAG_formal_parameter is living there at that time, get the offset
from the decoded instruction, say that xor, 0x138 offset from the type
for %r15 at that offset (85) from kmem_cache_alloc, right?
In a first milestone we'd have something like:
perf annotate --hits function | pahole --annotate -C task_struct
perf annotate --hits | pahole --annotate
Would show all structs with hits, for all functions with hits.
Other options would show which struct has more hits, etc.
- Arnaldo
[1]
[root@jouet ~]# perf annotate -h local
Usage: perf annotate []
--percent-type
Set percent type local/global-period/hits
[root@jouet ~]#
- Arnaldo
Re: [RFC] perf tool improvement requests
Em Tue, Sep 04, 2018 at 09:10:49AM +0200, Peter Zijlstra escreveu:
> On Mon, Sep 03, 2018 at 07:45:48PM -0700, Stephane Eranian wrote:
> > A few weeks ago, you had asked if I had more requests for the perf tool.
> I have one long standing one; that is IP based data structure
> annotation.
> When we get an exact IP (using PEBS) and were sampling a data related
> event (say L1 misses), we can get the data type from the instruction
> itself; that is, through DWARF. We _know_ what type (structure::member)
> is read/written to.
> I would love to get that in a pahole style output.
> Better yet, when you measure both hits and misses, you can get a
> structure usage overview, and see what lines are used lots and what
> members inside that line are rarely used. Ideal information for data
> structure layout optimization.
> 1000x more useful than that c2c crap.
> Can we please get that?
So, use 'c2c record' to get the samples:
[root@jouet ~]# perf c2c record
^C[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 5.152 MB perf.data (4555 samples) ]
Events collected:
[root@jouet ~]# perf evlist -v
cpu/mem-loads,ldlat=30/P: type: 4, size: 112, config: 0x1cd, { sample_period,
sample_freq }: 4000, sample_type:
IP|TID|TIME|ADDR|ID|CPU|PERIOD|DATA_SRC|WEIGHT|PHYS_ADDR, read_format: ID,
disabled: 1, inherit: 1, mmap: 1, comm: 1, freq: 1, task: 1, precise_ip: 3,
mmap_data: 1, sample_id_all: 1, mmap2: 1, comm_exec: 1, { bp_addr, config1 }:
0x1f
cpu/mem-stores/P: type: 4, size: 112, config: 0x82d0, { sample_period,
sample_freq }: 4000, sample_type:
IP|TID|TIME|ADDR|ID|CPU|PERIOD|DATA_SRC|WEIGHT|PHYS_ADDR, read_format: ID,
disabled: 1, inherit: 1, freq: 1, precise_ip: 3, sample_id_all: 1
Then we'll get a 'annotate --hits' option (just cooked up, will
polish) that will show the name of the function, info about it globally,
i.e. what annotate already produced, we may get this in CSV for better
post processing consumption:
[root@jouet ~]# perf annotate --hits kmem_cache_alloc
Samples: 20 of event 'cpu/mem-loads,ldlat=30/P', 4000 Hz, Event count
(approx.): 875, [percent: local period]
kmem_cache_alloc() /usr/lib/debug/lib/modules/4.17.17-100.fc27.x86_64/vmlinux
4.91 15: movgfp_allowed_mask,%ebx
2.51 51: mov(%r15),%r8
17.14 54: mov%gs:0x8(%r8),%rdx
6.51 61: cmpq $0x0,0x10(%r8)
17.14 66: mov(%r8),%r14
6.29 78: mov0x20(%r15),%ebx
5.71 7c: mov(%r15),%rdi
29.49 85: xor0x138(%r15),%rbx
2.86 9d: lea(%rdi),%rsi
3.43 d7: pop%rbx
2.29 dc: pop%r12
1.71 ed: testb $0x4,0xb(%rbp)
[root@jouet ~]#
Then I need to get the DW_AT_location stuff parsed in pahole, so
that with those offsets (second column, ending with :) with hits (first
column, there its local period, but we can ask for some specific metric
[1]), I'll be able to figure out what DW_TAG_variable or
DW_TAG_formal_parameter is living there at that time, get the offset
from the decoded instruction, say that xor, 0x138 offset from the type
for %r15 at that offset (85) from kmem_cache_alloc, right?
In a first milestone we'd have something like:
perf annotate --hits function | pahole --annotate -C task_struct
perf annotate --hits | pahole --annotate
Would show all structs with hits, for all functions with hits.
Other options would show which struct has more hits, etc.
- Arnaldo
[1]
[root@jouet ~]# perf annotate -h local
Usage: perf annotate []
--percent-type
Set percent type local/global-period/hits
[root@jouet ~]#
- Arnaldo
Re: [PATCH v2] arm64: dts: ti: k3-am65: Change #address-cells and #size-cells of interconnect to 2
On 15:22-20180903, Kishon Vijay Abraham I wrote: > AM65 has two PCIe controllers and each PCIe controller has '2' address > spaces one within the 4GB address space of the SoC and the other above > the 4GB address space of the SoC (cbass_main) in addition to the > register space. The size of the address space above the 4GB SoC address > space is 4GB. These address ranges will be used by CPU/DMA to access > the PCIe address space. In order to represent the address space above > the 4GB SoC address space and to represent the size of this address > space as 4GB, change address-cells and size-cells of interconnect to 2. > > Since OSPI has similar need in MCU Domain Memory Map, change > address-cells and size-cells of cbass_mcu interconnect also to 2. > Please add Fixes Vignesh, Sekhar, Tony, Do we agree this is the right way to go forward? if yes, please ack. -- Regards, Nishanth Menon
Re: [PATCH v2] arm64: dts: ti: k3-am65: Change #address-cells and #size-cells of interconnect to 2
On 15:22-20180903, Kishon Vijay Abraham I wrote: > AM65 has two PCIe controllers and each PCIe controller has '2' address > spaces one within the 4GB address space of the SoC and the other above > the 4GB address space of the SoC (cbass_main) in addition to the > register space. The size of the address space above the 4GB SoC address > space is 4GB. These address ranges will be used by CPU/DMA to access > the PCIe address space. In order to represent the address space above > the 4GB SoC address space and to represent the size of this address > space as 4GB, change address-cells and size-cells of interconnect to 2. > > Since OSPI has similar need in MCU Domain Memory Map, change > address-cells and size-cells of cbass_mcu interconnect also to 2. > Please add Fixes Vignesh, Sekhar, Tony, Do we agree this is the right way to go forward? if yes, please ack. -- Regards, Nishanth Menon
Re: [PATCH 1/2] ARM: dts: imx6: RDU2: Fix the audio CODEC's reset pin
On 09/02/2018 11:54 PM, Shawn Guo wrote:
> On Fri, Aug 31, 2018 at 02:17:31PM -0500, Andrew F. Davis wrote:
>> The correct DT property for specifying a GPIO used for reset
>> is "reset-gpios", fix this here.
>>
>> Fixes: d763762e3b58 ("ARM: dts: imx6: add ZII RDU2 boards")
>
> This Fixes tag and word 'Fix' in subject is inappropriate to me, as you
> are not fixing something wrong from the beginning, but actually
> replacing a deprecated property with new one.
>
reset-gpios was standard before this driver got it backwards, but it
also wasn't required to be one way or the other as far as I can tell, so
I can see your point that this isn't technically "broken". I have no
preference, so I'll change the subject and drop the fixes for v2.
Andrew
> Shawn
>
>>
>> Signed-off-by: Andrew F. Davis
>> ---
>> arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
>> b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
>> index 7fff3717cf7c..a0f5cfda0055 100644
>> --- a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
>> +++ b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
>> @@ -384,7 +384,7 @@
>> AVDD-supply = <_3p3v>;
>> IOVDD-supply = <_3p3v>;
>> DVDD-supply = <_reg>;
>> -gpio-reset = < 2 GPIO_ACTIVE_HIGH>;
>> +reset-gpios = < 2 GPIO_ACTIVE_LOW>;
>> };
>>
>> accel@1c {
>> @@ -572,7 +572,7 @@
>> AVDD-supply = <_3p3v>;
>> IOVDD-supply = <_3p3v>;
>> DVDD-supply = <_reg>;
>> -gpio-reset = < 0 GPIO_ACTIVE_HIGH>;
>> +reset-gpios = < 0 GPIO_ACTIVE_LOW>;
>> };
>>
>> touchscreen@20 {
>> --
>> 2.18.0
>>
Re: [PATCH 1/2] ARM: dts: imx6: RDU2: Fix the audio CODEC's reset pin
On 09/02/2018 11:54 PM, Shawn Guo wrote:
> On Fri, Aug 31, 2018 at 02:17:31PM -0500, Andrew F. Davis wrote:
>> The correct DT property for specifying a GPIO used for reset
>> is "reset-gpios", fix this here.
>>
>> Fixes: d763762e3b58 ("ARM: dts: imx6: add ZII RDU2 boards")
>
> This Fixes tag and word 'Fix' in subject is inappropriate to me, as you
> are not fixing something wrong from the beginning, but actually
> replacing a deprecated property with new one.
>
reset-gpios was standard before this driver got it backwards, but it
also wasn't required to be one way or the other as far as I can tell, so
I can see your point that this isn't technically "broken". I have no
preference, so I'll change the subject and drop the fixes for v2.
Andrew
> Shawn
>
>>
>> Signed-off-by: Andrew F. Davis
>> ---
>> arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
>> b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
>> index 7fff3717cf7c..a0f5cfda0055 100644
>> --- a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
>> +++ b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
>> @@ -384,7 +384,7 @@
>> AVDD-supply = <_3p3v>;
>> IOVDD-supply = <_3p3v>;
>> DVDD-supply = <_reg>;
>> -gpio-reset = < 2 GPIO_ACTIVE_HIGH>;
>> +reset-gpios = < 2 GPIO_ACTIVE_LOW>;
>> };
>>
>> accel@1c {
>> @@ -572,7 +572,7 @@
>> AVDD-supply = <_3p3v>;
>> IOVDD-supply = <_3p3v>;
>> DVDD-supply = <_reg>;
>> -gpio-reset = < 0 GPIO_ACTIVE_HIGH>;
>> +reset-gpios = < 0 GPIO_ACTIVE_LOW>;
>> };
>>
>> touchscreen@20 {
>> --
>> 2.18.0
>>
Re: [PATCH] Partially revert "HID: generic: create one input report per application type"
On Tue, Sep 4, 2018 at 1:55 PM Benjamin Tissoires wrote: > > On Fri, Aug 31, 2018 at 11:36 AM Benjamin Tissoires > wrote: > > > > This partially reverts commit f07b3c1da92db108662f99417a212fc1eddc44d1. > > > > It looks like some mice are not correctly treated by > > HID_QUIRK_INPUT_PER_APP. Those mice have the following > > report descriptor: > > > > 0x05, 0x01,// Usage Page (Generic Desktop)0 > > 0x09, 0x02,// Usage (Mouse) 2 > > 0xa1, 0x01,// Collection (Application)4 > > 0x85, 0x01,// Report ID (1) 6 > > 0x09, 0x01,// Usage (Pointer)8 > > 0xa1, 0x00,// Collection (Physical) 10 > > 0x95, 0x05,// Report Count (5) 12 > > 0x75, 0x01,// Report Size (1) 14 > > 0x05, 0x09,// Usage Page (Button) 16 > > 0x19, 0x01,// Usage Minimum (1) 18 > > 0x29, 0x05,// Usage Maximum (5) 20 > > 0x15, 0x00,// Logical Minimum (0) 22 > > 0x25, 0x01,// Logical Maximum (1) 24 > > 0x81, 0x02,// Input (Data,Var,Abs) 26 > > ... > > 0xc0, // End Collection 57 > > 0x85, 0x02,// Report ID (2) 58 > > 0x09, 0x01,// Usage (Consumer Control) 60 > > 0xa1, 0x00,// Collection (Physical) 62 > > 0x75, 0x0c,// Report Size (12) 64 > > 0x95, 0x02,// Report Count (2) 66 > > 0x05, 0x01,// Usage Page (Generic Desktop) 68 > > 0x09, 0x30,// Usage (X) 70 > > 0x09, 0x31,// Usage (Y) 72 > > 0x16, 0x01, 0xf8, // Logical Minimum (-2047) 74 > > 0x26, 0xff, 0x07, // Logical Maximum (2047)77 > > 0x81, 0x06,// Input (Data,Var,Rel) 80 > > 0xc0, // End Collection 82 > > 0xc0, // End Collection 83 > > ... > > > > Both the cursor position and the buttons are located in the > > same application collection (Mouse) and the kernel should > > only create one input device for those. > > > > However, for an undetermined reason, the kernel splits the > > device in 2, making systemd not tagging the second mouse > > with the coordinates only as a mouse. And then userspace > > ignores it which leads to a mouse where only the buttons > > are working. > > > > Until the quirk gets properly fixed, we should probably > > revert applying it to all of the generic devices and > > re-enable it when the root reason has been found. > > Jiri, > > I actually just got the proper fix today. I think it would be better > to directly take the fix instead of the revert and a revert of the > revert later. > > I just need to make sure the tests are correctly handled and I should > be able to submit the patch today. Patch now submitted: https://patchwork.kernel.org/patch/10587369/ Cheers, Benjamin
Re: [PATCH] Partially revert "HID: generic: create one input report per application type"
On Tue, Sep 4, 2018 at 1:55 PM Benjamin Tissoires wrote: > > On Fri, Aug 31, 2018 at 11:36 AM Benjamin Tissoires > wrote: > > > > This partially reverts commit f07b3c1da92db108662f99417a212fc1eddc44d1. > > > > It looks like some mice are not correctly treated by > > HID_QUIRK_INPUT_PER_APP. Those mice have the following > > report descriptor: > > > > 0x05, 0x01,// Usage Page (Generic Desktop)0 > > 0x09, 0x02,// Usage (Mouse) 2 > > 0xa1, 0x01,// Collection (Application)4 > > 0x85, 0x01,// Report ID (1) 6 > > 0x09, 0x01,// Usage (Pointer)8 > > 0xa1, 0x00,// Collection (Physical) 10 > > 0x95, 0x05,// Report Count (5) 12 > > 0x75, 0x01,// Report Size (1) 14 > > 0x05, 0x09,// Usage Page (Button) 16 > > 0x19, 0x01,// Usage Minimum (1) 18 > > 0x29, 0x05,// Usage Maximum (5) 20 > > 0x15, 0x00,// Logical Minimum (0) 22 > > 0x25, 0x01,// Logical Maximum (1) 24 > > 0x81, 0x02,// Input (Data,Var,Abs) 26 > > ... > > 0xc0, // End Collection 57 > > 0x85, 0x02,// Report ID (2) 58 > > 0x09, 0x01,// Usage (Consumer Control) 60 > > 0xa1, 0x00,// Collection (Physical) 62 > > 0x75, 0x0c,// Report Size (12) 64 > > 0x95, 0x02,// Report Count (2) 66 > > 0x05, 0x01,// Usage Page (Generic Desktop) 68 > > 0x09, 0x30,// Usage (X) 70 > > 0x09, 0x31,// Usage (Y) 72 > > 0x16, 0x01, 0xf8, // Logical Minimum (-2047) 74 > > 0x26, 0xff, 0x07, // Logical Maximum (2047)77 > > 0x81, 0x06,// Input (Data,Var,Rel) 80 > > 0xc0, // End Collection 82 > > 0xc0, // End Collection 83 > > ... > > > > Both the cursor position and the buttons are located in the > > same application collection (Mouse) and the kernel should > > only create one input device for those. > > > > However, for an undetermined reason, the kernel splits the > > device in 2, making systemd not tagging the second mouse > > with the coordinates only as a mouse. And then userspace > > ignores it which leads to a mouse where only the buttons > > are working. > > > > Until the quirk gets properly fixed, we should probably > > revert applying it to all of the generic devices and > > re-enable it when the root reason has been found. > > Jiri, > > I actually just got the proper fix today. I think it would be better > to directly take the fix instead of the revert and a revert of the > revert later. > > I just need to make sure the tests are correctly handled and I should > be able to submit the patch today. Patch now submitted: https://patchwork.kernel.org/patch/10587369/ Cheers, Benjamin
Re: [PATCH 1/3] ASoC: q6asm-dai: dt-bindings: Add support to compress dais
On 03-09-18, 13:34, Srinivas Kandagatla wrote: > This patch adds board specific bindings required for dais, In particular > for compressed dais and dai direction. > > Board specific setup involves setting up some of dais as compressed dais > and also specify direction of any dai. Some of the dais might only > support capture/playback depending on the board level wiring. > > These two new dt properties will allow such flexibilty at board level dts. Reviewed-by: Vinod Koul -- ~Vinod
Re: [PATCH v5 05/16] x86/pmu: enable Hygon support to PMU infrastructure
On 2018/9/4 18:48, Borislav Petkov wrote:
On Wed, Aug 29, 2018 at 08:43:54PM +0800, Pu Wen wrote:
Hygon PMU arch is similar to AMD Family 17h. To support Hygon PMU, the
initialization flow for it just call amd_pmu_init() and change PMU name
That sentence reads funny.
Will rewrite this sentence to make it more understandable. :)
In general, you seem to be explaining *what* your patches do and not
*why*. This is the wrong. Always explain the *why* - the *what* is
visible from the diff.
You probably need to brush up on
Documentation/process/submitting-patches.rst, section 2.
All right, will relearn the document and rework the patch descriptions.
+ case 0x18:
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) {
+ pr_cont("Fam18h ");
Didn't we agree that you'll verify whether family 0x18 is going to be
Hygon only?
What happened to that checking?
...
Same here.
What's up?
Will remove all the remaining unneeded Hygon vendor checking through
the whole patch set to minimize the code modification.
Thanks,
Pu Wen
Re: [PATCH 1/3] ASoC: q6asm-dai: dt-bindings: Add support to compress dais
On 03-09-18, 13:34, Srinivas Kandagatla wrote: > This patch adds board specific bindings required for dais, In particular > for compressed dais and dai direction. > > Board specific setup involves setting up some of dais as compressed dais > and also specify direction of any dai. Some of the dais might only > support capture/playback depending on the board level wiring. > > These two new dt properties will allow such flexibilty at board level dts. Reviewed-by: Vinod Koul -- ~Vinod
Re: [PATCH v5 05/16] x86/pmu: enable Hygon support to PMU infrastructure
On 2018/9/4 18:48, Borislav Petkov wrote:
On Wed, Aug 29, 2018 at 08:43:54PM +0800, Pu Wen wrote:
Hygon PMU arch is similar to AMD Family 17h. To support Hygon PMU, the
initialization flow for it just call amd_pmu_init() and change PMU name
That sentence reads funny.
Will rewrite this sentence to make it more understandable. :)
In general, you seem to be explaining *what* your patches do and not
*why*. This is the wrong. Always explain the *why* - the *what* is
visible from the diff.
You probably need to brush up on
Documentation/process/submitting-patches.rst, section 2.
All right, will relearn the document and rework the patch descriptions.
+ case 0x18:
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) {
+ pr_cont("Fam18h ");
Didn't we agree that you'll verify whether family 0x18 is going to be
Hygon only?
What happened to that checking?
...
Same here.
What's up?
Will remove all the remaining unneeded Hygon vendor checking through
the whole patch set to minimize the code modification.
Thanks,
Pu Wen
[PATCH 3/4] HID: core: fix grouping by application
commit f07b3c1da92d ("HID: generic: create one input report per
application type") was effectively the same as MULTI_INPUT:
hidinput->report was never set, so hidinput_match_application()
always returned null.
Fix that by testing against the real application.
Note that this breaks some old eGalax touchscreens that expect MULTI_INPUT
instead of HID_QUIRK_INPUT_PER_APP. Enable this quirk for backward
compatibility on all non-Win8 touchscreens.
link: https://bugzilla.kernel.org/show_bug.cgi?id=200847
link: https://bugzilla.kernel.org/show_bug.cgi?id=200849
link: https://bugs.archlinux.org/task/59699
link: https://github.com/NixOS/nixpkgs/issues/45165
Cc: sta...@vger.kernel.org # v4.18+
Signed-off-by: Benjamin Tissoires
---
This replaces https://patchwork.kernel.org/patch/10583471/
A proper fix is better than a revert.
drivers/hid/hid-input.c | 4 ++--
drivers/hid/hid-multitouch.c | 3 +++
include/linux/hid.h | 1 +
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 1e9ba8f7a16b..907b08e50a9b 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -1588,6 +1588,7 @@ static struct hid_input *hidinput_allocate(struct
hid_device *hid,
input_dev->dev.parent = >dev;
hidinput->input = input_dev;
+ hidinput->application = application;
list_add_tail(>list, >inputs);
INIT_LIST_HEAD(>reports);
@@ -1683,8 +1684,7 @@ static struct hid_input
*hidinput_match_application(struct hid_report *report)
struct hid_input *hidinput;
list_for_each_entry(hidinput, >inputs, list) {
- if (hidinput->report &&
- hidinput->report->application == report->application)
+ if (hidinput->application == report->application)
return hidinput;
}
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 88da991ef256..da954f3f4da7 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -1697,6 +1697,9 @@ static int mt_probe(struct hid_device *hdev, const struct
hid_device_id *id)
*/
hdev->quirks |= HID_QUIRK_INPUT_PER_APP;
+ if (id->group != HID_GROUP_MULTITOUCH_WIN_8)
+ hdev->quirks |= HID_QUIRK_MULTI_INPUT;
+
timer_setup(>release_timer, mt_expired_timeout, 0);
ret = hid_parse(hdev);
diff --git a/include/linux/hid.h b/include/linux/hid.h
index 834e6461a690..d44a78362942 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -526,6 +526,7 @@ struct hid_input {
const char *name;
bool registered;
struct list_head reports; /* the list of reports */
+ unsigned int application; /* application usage for this input */
};
enum hid_type {
--
2.14.3
[PATCH 2/4] HID: input: do not append a suffix if the name already has it
Or it creates some weird input names like:
"MI Dongle MI Wireless Mouse Mouse"
Signed-off-by: Benjamin Tissoires
---
drivers/hid/hid-input.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index ac201817a2dd..1e9ba8f7a16b 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -1516,6 +1516,7 @@ static struct hid_input *hidinput_allocate(struct
hid_device *hid,
struct hid_input *hidinput = kzalloc(sizeof(*hidinput), GFP_KERNEL);
struct input_dev *input_dev = input_allocate_device();
const char *suffix = NULL;
+ size_t suffix_len, name_len;
if (!hidinput || !input_dev)
goto fail;
@@ -1559,10 +1560,15 @@ static struct hid_input *hidinput_allocate(struct
hid_device *hid,
}
if (suffix) {
- hidinput->name = kasprintf(GFP_KERNEL, "%s %s",
- hid->name, suffix);
- if (!hidinput->name)
- goto fail;
+ name_len = strlen(hid->name);
+ suffix_len = strlen(suffix);
+ if ((name_len < suffix_len) ||
+ strcmp(hid->name + name_len - suffix_len, suffix)) {
+ hidinput->name = kasprintf(GFP_KERNEL, "%s %s",
+ hid->name, suffix);
+ if (!hidinput->name)
+ goto fail;
+ }
}
input_set_drvdata(input_dev, hid);
--
2.14.3
[PATCH 1/4] HID: multitouch: fix Elan panels with 2 input modes declaration
When implementing commit 7f81c8db5489 ("HID: multitouch: simplify
the settings of the various features"), I wrongly removed a test
that made sure we never try to set the second InputMode feature
to something else than 0.
This broke badly some recent Elan panels that now forget to send the
click button in some area of the touchpad.
Fixes 7f81c8db5489
Link: https://bugzilla.kernel.org/show_bug.cgi?id=200899
Cc: sta...@vger.kernel.org # v4.18+
Signed-off-by: Benjamin Tissoires
---
drivers/hid/hid-multitouch.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 40fbb7c52723..88da991ef256 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -1375,7 +1375,8 @@ static bool mt_need_to_apply_feature(struct hid_device
*hdev,
struct hid_usage *usage,
enum latency_mode latency,
bool surface_switch,
-bool button_switch)
+bool button_switch,
+bool *inputmode_found)
{
struct mt_device *td = hid_get_drvdata(hdev);
struct mt_class *cls = >mtclass;
@@ -1387,6 +1388,14 @@ static bool mt_need_to_apply_feature(struct hid_device
*hdev,
switch (usage->hid) {
case HID_DG_INPUTMODE:
+ /*
+* Some elan panels wrongly declare 2 input mode features,
+* and silently ignore when we set the value in the second
+* field. Skip the second feature and hope for the best.
+*/
+ if (*inputmode_found)
+ return false;
+
if (cls->quirks & MT_QUIRK_FORCE_GET_FEATURE) {
report_len = hid_report_len(report);
buf = hid_alloc_report_buf(report, GFP_KERNEL);
@@ -1402,6 +1411,7 @@ static bool mt_need_to_apply_feature(struct hid_device
*hdev,
}
field->value[index] = td->inputmode_value;
+ *inputmode_found = true;
return true;
case HID_DG_CONTACTMAX:
@@ -1439,6 +1449,7 @@ static void mt_set_modes(struct hid_device *hdev, enum
latency_mode latency,
struct hid_usage *usage;
int i, j;
bool update_report;
+ bool inputmode_found = false;
rep_enum = >report_enum[HID_FEATURE_REPORT];
list_for_each_entry(rep, _enum->report_list, list) {
@@ -1457,7 +1468,8 @@ static void mt_set_modes(struct hid_device *hdev, enum
latency_mode latency,
usage,
latency,
surface_switch,
-button_switch))
+button_switch,
+_found))
update_report = true;
}
}
--
2.14.3
[PATCH 4/4] HID: multitouch: simplify the application retrieval
Now that the application is simply stored in struct hid_input, we can
overwrite it in mt_input_mapping() for the faulty egalax and have a
simpler suffix processing in mt_input_configured()
Signed-off-by: Benjamin Tissoires
---
drivers/hid/hid-multitouch.c | 72
1 file changed, 32 insertions(+), 40 deletions(-)
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index da954f3f4da7..f7c6de2b6730 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -1319,6 +1319,13 @@ static int mt_input_mapping(struct hid_device *hdev,
struct hid_input *hi,
return mt_touch_input_mapping(hdev, hi, field, usage, bit, max,
application);
+ /*
+* some egalax touchscreens have "application == DG_TOUCHSCREEN"
+* for the stylus. Overwrite the hid_input application
+*/
+ if (field->physical == HID_DG_STYLUS)
+ hi->application = HID_DG_STYLUS;
+
/* let hid-core decide for the others */
return 0;
}
@@ -1507,14 +1514,12 @@ static int mt_input_configured(struct hid_device *hdev,
struct hid_input *hi)
struct mt_device *td = hid_get_drvdata(hdev);
char *name;
const char *suffix = NULL;
- unsigned int application = 0;
struct mt_report_data *rdata;
struct mt_application *mt_application = NULL;
struct hid_report *report;
int ret;
list_for_each_entry(report, >reports, hidinput_list) {
- application = report->application;
rdata = mt_find_report_data(td, report);
if (!rdata) {
hid_err(hdev, "failed to allocate data for report\n");
@@ -1529,46 +1534,33 @@ static int mt_input_configured(struct hid_device *hdev,
struct hid_input *hi)
if (ret)
return ret;
}
-
- /*
-* some egalax touchscreens have "application == DG_TOUCHSCREEN"
-* for the stylus. Check this first, and then rely on
-* the application field.
-*/
- if (report->field[0]->physical == HID_DG_STYLUS) {
- suffix = "Pen";
- /* force BTN_STYLUS to allow tablet matching in udev */
- __set_bit(BTN_STYLUS, hi->input->keybit);
- }
}
- if (!suffix) {
- switch (application) {
- case HID_GD_KEYBOARD:
- case HID_GD_KEYPAD:
- case HID_GD_MOUSE:
- case HID_DG_TOUCHPAD:
- case HID_GD_SYSTEM_CONTROL:
- case HID_CP_CONSUMER_CONTROL:
- case HID_GD_WIRELESS_RADIO_CTLS:
- case HID_GD_SYSTEM_MULTIAXIS:
- /* already handled by hid core */
- break;
- case HID_DG_TOUCHSCREEN:
- /* we do not set suffix = "Touchscreen" */
- hi->input->name = hdev->name;
- break;
- case HID_DG_STYLUS:
- /* force BTN_STYLUS to allow tablet matching in udev */
- __set_bit(BTN_STYLUS, hi->input->keybit);
- break;
- case HID_VD_ASUS_CUSTOM_MEDIA_KEYS:
- suffix = "Custom Media Keys";
- break;
- default:
- suffix = "UNKNOWN";
- break;
- }
+ switch (hi->application) {
+ case HID_GD_KEYBOARD:
+ case HID_GD_KEYPAD:
+ case HID_GD_MOUSE:
+ case HID_DG_TOUCHPAD:
+ case HID_GD_SYSTEM_CONTROL:
+ case HID_CP_CONSUMER_CONTROL:
+ case HID_GD_WIRELESS_RADIO_CTLS:
+ case HID_GD_SYSTEM_MULTIAXIS:
+ /* already handled by hid core */
+ break;
+ case HID_DG_TOUCHSCREEN:
+ /* we do not set suffix = "Touchscreen" */
+ hi->input->name = hdev->name;
+ break;
+ case HID_DG_STYLUS:
+ /* force BTN_STYLUS to allow tablet matching in udev */
+ __set_bit(BTN_STYLUS, hi->input->keybit);
+ break;
+ case HID_VD_ASUS_CUSTOM_MEDIA_KEYS:
+ suffix = "Custom Media Keys";
+ break;
+ default:
+ suffix = "UNKNOWN";
+ break;
}
if (suffix) {
--
2.14.3
[PATCH 3/4] HID: core: fix grouping by application
commit f07b3c1da92d ("HID: generic: create one input report per
application type") was effectively the same as MULTI_INPUT:
hidinput->report was never set, so hidinput_match_application()
always returned null.
Fix that by testing against the real application.
Note that this breaks some old eGalax touchscreens that expect MULTI_INPUT
instead of HID_QUIRK_INPUT_PER_APP. Enable this quirk for backward
compatibility on all non-Win8 touchscreens.
link: https://bugzilla.kernel.org/show_bug.cgi?id=200847
link: https://bugzilla.kernel.org/show_bug.cgi?id=200849
link: https://bugs.archlinux.org/task/59699
link: https://github.com/NixOS/nixpkgs/issues/45165
Cc: sta...@vger.kernel.org # v4.18+
Signed-off-by: Benjamin Tissoires
---
This replaces https://patchwork.kernel.org/patch/10583471/
A proper fix is better than a revert.
drivers/hid/hid-input.c | 4 ++--
drivers/hid/hid-multitouch.c | 3 +++
include/linux/hid.h | 1 +
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 1e9ba8f7a16b..907b08e50a9b 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -1588,6 +1588,7 @@ static struct hid_input *hidinput_allocate(struct
hid_device *hid,
input_dev->dev.parent = >dev;
hidinput->input = input_dev;
+ hidinput->application = application;
list_add_tail(>list, >inputs);
INIT_LIST_HEAD(>reports);
@@ -1683,8 +1684,7 @@ static struct hid_input
*hidinput_match_application(struct hid_report *report)
struct hid_input *hidinput;
list_for_each_entry(hidinput, >inputs, list) {
- if (hidinput->report &&
- hidinput->report->application == report->application)
+ if (hidinput->application == report->application)
return hidinput;
}
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 88da991ef256..da954f3f4da7 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -1697,6 +1697,9 @@ static int mt_probe(struct hid_device *hdev, const struct
hid_device_id *id)
*/
hdev->quirks |= HID_QUIRK_INPUT_PER_APP;
+ if (id->group != HID_GROUP_MULTITOUCH_WIN_8)
+ hdev->quirks |= HID_QUIRK_MULTI_INPUT;
+
timer_setup(>release_timer, mt_expired_timeout, 0);
ret = hid_parse(hdev);
diff --git a/include/linux/hid.h b/include/linux/hid.h
index 834e6461a690..d44a78362942 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -526,6 +526,7 @@ struct hid_input {
const char *name;
bool registered;
struct list_head reports; /* the list of reports */
+ unsigned int application; /* application usage for this input */
};
enum hid_type {
--
2.14.3
[PATCH 2/4] HID: input: do not append a suffix if the name already has it
Or it creates some weird input names like:
"MI Dongle MI Wireless Mouse Mouse"
Signed-off-by: Benjamin Tissoires
---
drivers/hid/hid-input.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index ac201817a2dd..1e9ba8f7a16b 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -1516,6 +1516,7 @@ static struct hid_input *hidinput_allocate(struct
hid_device *hid,
struct hid_input *hidinput = kzalloc(sizeof(*hidinput), GFP_KERNEL);
struct input_dev *input_dev = input_allocate_device();
const char *suffix = NULL;
+ size_t suffix_len, name_len;
if (!hidinput || !input_dev)
goto fail;
@@ -1559,10 +1560,15 @@ static struct hid_input *hidinput_allocate(struct
hid_device *hid,
}
if (suffix) {
- hidinput->name = kasprintf(GFP_KERNEL, "%s %s",
- hid->name, suffix);
- if (!hidinput->name)
- goto fail;
+ name_len = strlen(hid->name);
+ suffix_len = strlen(suffix);
+ if ((name_len < suffix_len) ||
+ strcmp(hid->name + name_len - suffix_len, suffix)) {
+ hidinput->name = kasprintf(GFP_KERNEL, "%s %s",
+ hid->name, suffix);
+ if (!hidinput->name)
+ goto fail;
+ }
}
input_set_drvdata(input_dev, hid);
--
2.14.3
[PATCH 1/4] HID: multitouch: fix Elan panels with 2 input modes declaration
When implementing commit 7f81c8db5489 ("HID: multitouch: simplify
the settings of the various features"), I wrongly removed a test
that made sure we never try to set the second InputMode feature
to something else than 0.
This broke badly some recent Elan panels that now forget to send the
click button in some area of the touchpad.
Fixes 7f81c8db5489
Link: https://bugzilla.kernel.org/show_bug.cgi?id=200899
Cc: sta...@vger.kernel.org # v4.18+
Signed-off-by: Benjamin Tissoires
---
drivers/hid/hid-multitouch.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 40fbb7c52723..88da991ef256 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -1375,7 +1375,8 @@ static bool mt_need_to_apply_feature(struct hid_device
*hdev,
struct hid_usage *usage,
enum latency_mode latency,
bool surface_switch,
-bool button_switch)
+bool button_switch,
+bool *inputmode_found)
{
struct mt_device *td = hid_get_drvdata(hdev);
struct mt_class *cls = >mtclass;
@@ -1387,6 +1388,14 @@ static bool mt_need_to_apply_feature(struct hid_device
*hdev,
switch (usage->hid) {
case HID_DG_INPUTMODE:
+ /*
+* Some elan panels wrongly declare 2 input mode features,
+* and silently ignore when we set the value in the second
+* field. Skip the second feature and hope for the best.
+*/
+ if (*inputmode_found)
+ return false;
+
if (cls->quirks & MT_QUIRK_FORCE_GET_FEATURE) {
report_len = hid_report_len(report);
buf = hid_alloc_report_buf(report, GFP_KERNEL);
@@ -1402,6 +1411,7 @@ static bool mt_need_to_apply_feature(struct hid_device
*hdev,
}
field->value[index] = td->inputmode_value;
+ *inputmode_found = true;
return true;
case HID_DG_CONTACTMAX:
@@ -1439,6 +1449,7 @@ static void mt_set_modes(struct hid_device *hdev, enum
latency_mode latency,
struct hid_usage *usage;
int i, j;
bool update_report;
+ bool inputmode_found = false;
rep_enum = >report_enum[HID_FEATURE_REPORT];
list_for_each_entry(rep, _enum->report_list, list) {
@@ -1457,7 +1468,8 @@ static void mt_set_modes(struct hid_device *hdev, enum
latency_mode latency,
usage,
latency,
surface_switch,
-button_switch))
+button_switch,
+_found))
update_report = true;
}
}
--
2.14.3
[PATCH 4/4] HID: multitouch: simplify the application retrieval
Now that the application is simply stored in struct hid_input, we can
overwrite it in mt_input_mapping() for the faulty egalax and have a
simpler suffix processing in mt_input_configured()
Signed-off-by: Benjamin Tissoires
---
drivers/hid/hid-multitouch.c | 72
1 file changed, 32 insertions(+), 40 deletions(-)
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index da954f3f4da7..f7c6de2b6730 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -1319,6 +1319,13 @@ static int mt_input_mapping(struct hid_device *hdev,
struct hid_input *hi,
return mt_touch_input_mapping(hdev, hi, field, usage, bit, max,
application);
+ /*
+* some egalax touchscreens have "application == DG_TOUCHSCREEN"
+* for the stylus. Overwrite the hid_input application
+*/
+ if (field->physical == HID_DG_STYLUS)
+ hi->application = HID_DG_STYLUS;
+
/* let hid-core decide for the others */
return 0;
}
@@ -1507,14 +1514,12 @@ static int mt_input_configured(struct hid_device *hdev,
struct hid_input *hi)
struct mt_device *td = hid_get_drvdata(hdev);
char *name;
const char *suffix = NULL;
- unsigned int application = 0;
struct mt_report_data *rdata;
struct mt_application *mt_application = NULL;
struct hid_report *report;
int ret;
list_for_each_entry(report, >reports, hidinput_list) {
- application = report->application;
rdata = mt_find_report_data(td, report);
if (!rdata) {
hid_err(hdev, "failed to allocate data for report\n");
@@ -1529,46 +1534,33 @@ static int mt_input_configured(struct hid_device *hdev,
struct hid_input *hi)
if (ret)
return ret;
}
-
- /*
-* some egalax touchscreens have "application == DG_TOUCHSCREEN"
-* for the stylus. Check this first, and then rely on
-* the application field.
-*/
- if (report->field[0]->physical == HID_DG_STYLUS) {
- suffix = "Pen";
- /* force BTN_STYLUS to allow tablet matching in udev */
- __set_bit(BTN_STYLUS, hi->input->keybit);
- }
}
- if (!suffix) {
- switch (application) {
- case HID_GD_KEYBOARD:
- case HID_GD_KEYPAD:
- case HID_GD_MOUSE:
- case HID_DG_TOUCHPAD:
- case HID_GD_SYSTEM_CONTROL:
- case HID_CP_CONSUMER_CONTROL:
- case HID_GD_WIRELESS_RADIO_CTLS:
- case HID_GD_SYSTEM_MULTIAXIS:
- /* already handled by hid core */
- break;
- case HID_DG_TOUCHSCREEN:
- /* we do not set suffix = "Touchscreen" */
- hi->input->name = hdev->name;
- break;
- case HID_DG_STYLUS:
- /* force BTN_STYLUS to allow tablet matching in udev */
- __set_bit(BTN_STYLUS, hi->input->keybit);
- break;
- case HID_VD_ASUS_CUSTOM_MEDIA_KEYS:
- suffix = "Custom Media Keys";
- break;
- default:
- suffix = "UNKNOWN";
- break;
- }
+ switch (hi->application) {
+ case HID_GD_KEYBOARD:
+ case HID_GD_KEYPAD:
+ case HID_GD_MOUSE:
+ case HID_DG_TOUCHPAD:
+ case HID_GD_SYSTEM_CONTROL:
+ case HID_CP_CONSUMER_CONTROL:
+ case HID_GD_WIRELESS_RADIO_CTLS:
+ case HID_GD_SYSTEM_MULTIAXIS:
+ /* already handled by hid core */
+ break;
+ case HID_DG_TOUCHSCREEN:
+ /* we do not set suffix = "Touchscreen" */
+ hi->input->name = hdev->name;
+ break;
+ case HID_DG_STYLUS:
+ /* force BTN_STYLUS to allow tablet matching in udev */
+ __set_bit(BTN_STYLUS, hi->input->keybit);
+ break;
+ case HID_VD_ASUS_CUSTOM_MEDIA_KEYS:
+ suffix = "Custom Media Keys";
+ break;
+ default:
+ suffix = "UNKNOWN";
+ break;
}
if (suffix) {
--
2.14.3
[PATCH 0/4] HID fixes
Hi Jiri, there is no real link between those 4 commit but the fact that I wrote them today ;) 2 patches should at least be scheduled for v4.19: 1/4 and 3/4 Both are stable fixes for mistakes I made in v4.18. Patch 2 and 4 are just nice to have, so v4.20 should be fine. Cheers, Benjamin Benjamin Tissoires (4): HID: multitouch: fix Elan panels with 2 input modes declaration HID: input: do not append a suffix if the name already has it HID: core: fix grouping by application HID: multitouch: simplify the application retrieval drivers/hid/hid-input.c | 18 ++--- drivers/hid/hid-multitouch.c | 91 include/linux/hid.h | 1 + 3 files changed, 62 insertions(+), 48 deletions(-) -- 2.14.3
[PATCH 0/4] HID fixes
Hi Jiri, there is no real link between those 4 commit but the fact that I wrote them today ;) 2 patches should at least be scheduled for v4.19: 1/4 and 3/4 Both are stable fixes for mistakes I made in v4.18. Patch 2 and 4 are just nice to have, so v4.20 should be fine. Cheers, Benjamin Benjamin Tissoires (4): HID: multitouch: fix Elan panels with 2 input modes declaration HID: input: do not append a suffix if the name already has it HID: core: fix grouping by application HID: multitouch: simplify the application retrieval drivers/hid/hid-input.c | 18 ++--- drivers/hid/hid-multitouch.c | 91 include/linux/hid.h | 1 + 3 files changed, 62 insertions(+), 48 deletions(-) -- 2.14.3
[PATCH v4] EDAC, ghes: use CPER module handles to locate DIMMs
For platforms whose firmwares provide valid module handles
(SMBIOS type 17) in error records, this patch uses the module
handles to locate corresponding DIMMs and enables per-DIMM
error counter update.
Signed-off-by: Fan Wu
Reviewed-by: Tyler Baicar
Tested-by: Toshi Kani
---
Changes from v3:
* Updated Reviewed-by list
Changes from v2:
* Fixed coding style glitch
* Added Tested-by/Reviewed-by
Changes from v1:
* Changed the new function name to get_dimm_smbios_index
* Removed unnecessary checks inside get_dimm_smbios_index
* Reverted the change of the DMI handle print
* Updated commit message
---
drivers/edac/ghes_edac.c | 23 +++
include/linux/edac.h | 2 ++
2 files changed, 25 insertions(+)
diff --git a/drivers/edac/ghes_edac.c b/drivers/edac/ghes_edac.c
index 473aeec..ba46160 100644
--- a/drivers/edac/ghes_edac.c
+++ b/drivers/edac/ghes_edac.c
@@ -81,6 +81,18 @@ static void ghes_edac_count_dimms(const struct dmi_header
*dh, void *arg)
(*num_dimm)++;
}
+static int get_dimm_smbios_index(u16 handle)
+{
+ int i;
+ struct mem_ctl_info *mci = ghes_pvt->mci;
+
+ for (i = 0; i < mci->tot_dimms; i++) {
+ if (mci->dimms[i]->smbios_handle == handle)
+ return i;
+ }
+ return -1;
+}
+
static void ghes_edac_dmidecode(const struct dmi_header *dh, void *arg)
{
struct ghes_edac_dimm_fill *dimm_fill = arg;
@@ -177,6 +189,8 @@ static void ghes_edac_dmidecode(const struct dmi_header
*dh, void *arg)
entry->total_width, entry->data_width);
}
+ dimm->smbios_handle = entry->handle;
+
dimm_fill->count++;
}
}
@@ -327,12 +341,21 @@ void ghes_edac_report_mem_error(int sev, struct
cper_sec_mem_err *mem_err)
p += sprintf(p, "bit_pos:%d ", mem_err->bit_pos);
if (mem_err->validation_bits & CPER_MEM_VALID_MODULE_HANDLE) {
const char *bank = NULL, *device = NULL;
+ int index = -1;
+
dmi_memdev_name(mem_err->mem_dev_handle, , );
if (bank != NULL && device != NULL)
p += sprintf(p, "DIMM location:%s %s ", bank, device);
else
p += sprintf(p, "DIMM DMI handle: 0x%.4x ",
mem_err->mem_dev_handle);
+
+ index = get_dimm_smbios_index(mem_err->mem_dev_handle);
+ if (index >= 0) {
+ e->top_layer = index;
+ e->enable_per_layer_report = true;
+ }
+
}
if (p > e->location)
*(p - 1) = '\0';
diff --git a/include/linux/edac.h b/include/linux/edac.h
index bffb978..a45ce1f 100644
--- a/include/linux/edac.h
+++ b/include/linux/edac.h
@@ -451,6 +451,8 @@ struct dimm_info {
u32 nr_pages; /* number of pages on this dimm */
unsigned csrow, cschannel; /* Points to the old API data */
+
+ u16 smbios_handle; /* Handle for SMBIOS type 17 */
};
/**
--
2.7.4
[PATCH v4] EDAC, ghes: use CPER module handles to locate DIMMs
For platforms whose firmwares provide valid module handles
(SMBIOS type 17) in error records, this patch uses the module
handles to locate corresponding DIMMs and enables per-DIMM
error counter update.
Signed-off-by: Fan Wu
Reviewed-by: Tyler Baicar
Tested-by: Toshi Kani
---
Changes from v3:
* Updated Reviewed-by list
Changes from v2:
* Fixed coding style glitch
* Added Tested-by/Reviewed-by
Changes from v1:
* Changed the new function name to get_dimm_smbios_index
* Removed unnecessary checks inside get_dimm_smbios_index
* Reverted the change of the DMI handle print
* Updated commit message
---
drivers/edac/ghes_edac.c | 23 +++
include/linux/edac.h | 2 ++
2 files changed, 25 insertions(+)
diff --git a/drivers/edac/ghes_edac.c b/drivers/edac/ghes_edac.c
index 473aeec..ba46160 100644
--- a/drivers/edac/ghes_edac.c
+++ b/drivers/edac/ghes_edac.c
@@ -81,6 +81,18 @@ static void ghes_edac_count_dimms(const struct dmi_header
*dh, void *arg)
(*num_dimm)++;
}
+static int get_dimm_smbios_index(u16 handle)
+{
+ int i;
+ struct mem_ctl_info *mci = ghes_pvt->mci;
+
+ for (i = 0; i < mci->tot_dimms; i++) {
+ if (mci->dimms[i]->smbios_handle == handle)
+ return i;
+ }
+ return -1;
+}
+
static void ghes_edac_dmidecode(const struct dmi_header *dh, void *arg)
{
struct ghes_edac_dimm_fill *dimm_fill = arg;
@@ -177,6 +189,8 @@ static void ghes_edac_dmidecode(const struct dmi_header
*dh, void *arg)
entry->total_width, entry->data_width);
}
+ dimm->smbios_handle = entry->handle;
+
dimm_fill->count++;
}
}
@@ -327,12 +341,21 @@ void ghes_edac_report_mem_error(int sev, struct
cper_sec_mem_err *mem_err)
p += sprintf(p, "bit_pos:%d ", mem_err->bit_pos);
if (mem_err->validation_bits & CPER_MEM_VALID_MODULE_HANDLE) {
const char *bank = NULL, *device = NULL;
+ int index = -1;
+
dmi_memdev_name(mem_err->mem_dev_handle, , );
if (bank != NULL && device != NULL)
p += sprintf(p, "DIMM location:%s %s ", bank, device);
else
p += sprintf(p, "DIMM DMI handle: 0x%.4x ",
mem_err->mem_dev_handle);
+
+ index = get_dimm_smbios_index(mem_err->mem_dev_handle);
+ if (index >= 0) {
+ e->top_layer = index;
+ e->enable_per_layer_report = true;
+ }
+
}
if (p > e->location)
*(p - 1) = '\0';
diff --git a/include/linux/edac.h b/include/linux/edac.h
index bffb978..a45ce1f 100644
--- a/include/linux/edac.h
+++ b/include/linux/edac.h
@@ -451,6 +451,8 @@ struct dimm_info {
u32 nr_pages; /* number of pages on this dimm */
unsigned csrow, cschannel; /* Points to the old API data */
+
+ u16 smbios_handle; /* Handle for SMBIOS type 17 */
};
/**
--
2.7.4
Re: [PATCH 0/2] Drop node-local allocation during host controller initialisation
On Tue, Aug 28, 2018 at 04:05:11PM +0100, Punit Agrawal wrote: > Hi Bjorn, > > As discussed before[0], here are a couple of patches to drop > node-local allocations during host contoller initialisation. This set > covers both arm64 and x86. > > I'm posting early to give the patches time on the list as well in next > in case there are issues we've missed. > > The patches are based on v4.19-rc1 and has been boot tested on arm64 > and compile tested on x86. > > Thanks, > Punit > > [0] https://www.spinics.net/lists/arm-kernel/msg669746.html > > Punit Agrawal (2): > arm64: PCI: Remove node-local allocations when initialising host > controller > x86/PCI: Remove node-local allocation when initialising host > controller > > arch/arm64/kernel/pci.c | 5 ++--- > arch/x86/pci/acpi.c | 2 +- > 2 files changed, 3 insertions(+), 4 deletions(-) Applied with Will's ack on the arm64 patch to pci/enumeration for v4.20, thanks!
Re: [PATCH 0/2] Drop node-local allocation during host controller initialisation
On Tue, Aug 28, 2018 at 04:05:11PM +0100, Punit Agrawal wrote: > Hi Bjorn, > > As discussed before[0], here are a couple of patches to drop > node-local allocations during host contoller initialisation. This set > covers both arm64 and x86. > > I'm posting early to give the patches time on the list as well in next > in case there are issues we've missed. > > The patches are based on v4.19-rc1 and has been boot tested on arm64 > and compile tested on x86. > > Thanks, > Punit > > [0] https://www.spinics.net/lists/arm-kernel/msg669746.html > > Punit Agrawal (2): > arm64: PCI: Remove node-local allocations when initialising host > controller > x86/PCI: Remove node-local allocation when initialising host > controller > > arch/arm64/kernel/pci.c | 5 ++--- > arch/x86/pci/acpi.c | 2 +- > 2 files changed, 3 insertions(+), 4 deletions(-) Applied with Will's ack on the arm64 patch to pci/enumeration for v4.20, thanks!
RE: [PATCH v3] EDAC, ghes: use CPER module handles to locate DIMMs
> -Original Message- > From: Borislav Petkov > Sent: Tuesday, September 4, 2018 1:29 AM > To: Fan Wu > Cc: mche...@kernel.org; james.mo...@arm.com; baicar.ty...@gmail.com; > linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm- > ker...@lists.infradead.org; john.ga...@huawei.com; toshi.k...@hpe.com; > tanxiao...@huawei.com; wanghuiqi...@huawei.com; > shiju.j...@huawei.com > Subject: Re: [PATCH v3] EDAC, ghes: use CPER module handles to locate > DIMMs > > On Tue, Sep 04, 2018 at 03:50:55AM +, Fan Wu wrote: > > For platforms whose firmwares provide valid module handles (SMBIOS > > type 17) in error records, this patch uses the module handles to > > locate corresponding DIMMs and enables per-DIMM error counter update. > > > > Signed-off-by: Fan Wu > > Reviewed-by: Tyler Baicar > > Tested-by: Toshi Kani > > Those two tags I did see being given to you ... > > > Reviewed-by: Borislav Petkov > > Reviewed-by: James Morse > > Reviewed-by: tanxiaofei > > ... but how in the world did you come up with those? Sorry. Will remove these in v4. Thanks, Fan > Do you understand how Reviewed-by works or do you need to look at > Documentation/process/submitting-patches.rst, section 13 ? > > -- > Regards/Gruss, > Boris. > > Good mailing practices for 400: avoid top-posting and trim the reply.
RE: [PATCH v3] EDAC, ghes: use CPER module handles to locate DIMMs
> -Original Message- > From: Borislav Petkov > Sent: Tuesday, September 4, 2018 1:29 AM > To: Fan Wu > Cc: mche...@kernel.org; james.mo...@arm.com; baicar.ty...@gmail.com; > linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm- > ker...@lists.infradead.org; john.ga...@huawei.com; toshi.k...@hpe.com; > tanxiao...@huawei.com; wanghuiqi...@huawei.com; > shiju.j...@huawei.com > Subject: Re: [PATCH v3] EDAC, ghes: use CPER module handles to locate > DIMMs > > On Tue, Sep 04, 2018 at 03:50:55AM +, Fan Wu wrote: > > For platforms whose firmwares provide valid module handles (SMBIOS > > type 17) in error records, this patch uses the module handles to > > locate corresponding DIMMs and enables per-DIMM error counter update. > > > > Signed-off-by: Fan Wu > > Reviewed-by: Tyler Baicar > > Tested-by: Toshi Kani > > Those two tags I did see being given to you ... > > > Reviewed-by: Borislav Petkov > > Reviewed-by: James Morse > > Reviewed-by: tanxiaofei > > ... but how in the world did you come up with those? Sorry. Will remove these in v4. Thanks, Fan > Do you understand how Reviewed-by works or do you need to look at > Documentation/process/submitting-patches.rst, section 13 ? > > -- > Regards/Gruss, > Boris. > > Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH v6 3/5] clk: imx: add SCCG PLL type
On Tue, Aug 28, 2018 at 12:11:13PM -0700, Andrey Smirnov wrote:
> On Tue, Aug 28, 2018 at 3:58 AM Abel Vesa wrote:
> >
> > On Fri, Aug 24, 2018 at 09:40:11AM +0200, Sascha Hauer wrote:
> > > +Cc Andrey Smirnov who made me aware of this issue.
> > >
> > > On Wed, Aug 22, 2018 at 04:48:21PM +0300, Abel Vesa wrote:
> > > > From: Lucas Stach
> > > >
> > > > The SCCG is a new PLL type introduced on i.MX8. Add support for this.
> > > > The driver currently misses the PLL lock check, as the preliminary
> > > > documentation mentions lock configurations, but is quiet about where
> > > > to find the actual lock status signal.
> > > >
> > > > Signed-off-by: Lucas Stach
> > > > Signed-off-by: Abel Vesa
> > > > ---
> > > > +static int clk_pll1_set_rate(struct clk_hw *hw, unsigned long rate,
> > > > + unsigned long parent_rate)
> > > > +{
> > > > + struct clk_sccg_pll *pll = to_clk_sccg_pll(hw);
> > > > + u32 val;
> > > > + u32 divf;
> > > > +
> > > > + divf = rate / (parent_rate * 2);
> > > > +
> > > > + val = readl_relaxed(pll->base + PLL_CFG2);
> > > > + val &= ~(PLL_DIVF_MASK << PLL_DIVF1_SHIFT);
> > > > + val |= (divf - 1) << PLL_DIVF1_SHIFT;
> > > > + writel_relaxed(val, pll->base + PLL_CFG2);
> > > > +
> > > > + /* FIXME: PLL lock check */
> > >
> > > Shouldn't be too hard to add, no?
> >
> > Added to the next version which I intend to send today.
> >
> > >
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > +static int clk_pll1_prepare(struct clk_hw *hw)
> > > > +{
> > > > + struct clk_sccg_pll *pll = to_clk_sccg_pll(hw);
> > > > + u32 val;
> > > > +
> > > > + val = readl_relaxed(pll->base);
> > > > + val &= ~(1 << PLL_PD);
> > > > + writel_relaxed(val, pll->base);
> > >
> > > pll->base + PLL_CFG0 please.
> >
> > Same as above.
> >
> > >
> > > > +static const struct clk_ops clk_sccg_pll1_ops = {
> > > > + .is_prepared= clk_pll1_is_prepared,
> > > > + .recalc_rate= clk_pll1_recalc_rate,
> > > > + .round_rate = clk_pll1_round_rate,
> > > > + .set_rate = clk_pll1_set_rate,
> > > > +};
> > > > +
> > > > +static const struct clk_ops clk_sccg_pll2_ops = {
> > > > + .prepare= clk_pll1_prepare,
> > > > + .unprepare = clk_pll1_unprepare,
> > > > + .recalc_rate= clk_pll2_recalc_rate,
> > > > + .round_rate = clk_pll2_round_rate,
> > > > + .set_rate = clk_pll2_set_rate,
> > > > +};
> > >
> > > So these are two PLLs that share the same enable register. Doing the
> > > prepare/unprepare for only one PLL can lead to all kinds of trouble.
> > > Finding a good abstraction the properly handles this case with the
> > > clock framework is probably also not easy.
> > >
> > > I could imagine we'll need to track the enable state on both PLLs and
> > > only if both are disabled we disable it in hardware.
> > >
> > > With the current code we disable the PLLs when all consumers are
> > > reparented to pll1, which probably has bad effects.
> > >
> >
> > So it took me a while to understand exactly why this needs to stay like it
> > is.
> >
>
> IMHO this means that, if nothing else, all of the below should be
> documented in code as a comment, otherwise simpletons like me are
> going to continue stumbling over it and wondering what's going on.
Will try to add proper comment to explain what's happening.
>
> > The PLL1 is never used by any device, instead it is used as a source for
> > PLL2.
> >
> > But because the interlink between the two of them is too complicated,
> > the PLLs 1 and 2 need to be separate clocks.
> >
>
> Can you go a little bit more into detail as for why PLL1 needs to be
> exposed in the first place and can't just be dealt with behind the
> scenes as a part of PLL2 abstraction? Are there use-cases where the
> rates of the two are going to be adjusted individually in Linux?
>
Here is the SCCG PLL Block Diagram:
https://www.nxp.com/docs/en/reference-manual/IMX8MDQLQRM.pdf#page=834
Now lets take the System PLL 2 for example. If you follow the hierarchy,
when you reach the sys2_pll1_out you can see that one of its selectors is
actually sys1_pll1_ref_sel. Same thing applies to sys3_pll2_out with
sys2_pll1_ref_sel. This means there is an input reference clock interlinking
between different System PLLs.
> Thanks,
> Andrey Smirnov
--
Re: [PATCH v6 3/5] clk: imx: add SCCG PLL type
On Tue, Aug 28, 2018 at 12:11:13PM -0700, Andrey Smirnov wrote:
> On Tue, Aug 28, 2018 at 3:58 AM Abel Vesa wrote:
> >
> > On Fri, Aug 24, 2018 at 09:40:11AM +0200, Sascha Hauer wrote:
> > > +Cc Andrey Smirnov who made me aware of this issue.
> > >
> > > On Wed, Aug 22, 2018 at 04:48:21PM +0300, Abel Vesa wrote:
> > > > From: Lucas Stach
> > > >
> > > > The SCCG is a new PLL type introduced on i.MX8. Add support for this.
> > > > The driver currently misses the PLL lock check, as the preliminary
> > > > documentation mentions lock configurations, but is quiet about where
> > > > to find the actual lock status signal.
> > > >
> > > > Signed-off-by: Lucas Stach
> > > > Signed-off-by: Abel Vesa
> > > > ---
> > > > +static int clk_pll1_set_rate(struct clk_hw *hw, unsigned long rate,
> > > > + unsigned long parent_rate)
> > > > +{
> > > > + struct clk_sccg_pll *pll = to_clk_sccg_pll(hw);
> > > > + u32 val;
> > > > + u32 divf;
> > > > +
> > > > + divf = rate / (parent_rate * 2);
> > > > +
> > > > + val = readl_relaxed(pll->base + PLL_CFG2);
> > > > + val &= ~(PLL_DIVF_MASK << PLL_DIVF1_SHIFT);
> > > > + val |= (divf - 1) << PLL_DIVF1_SHIFT;
> > > > + writel_relaxed(val, pll->base + PLL_CFG2);
> > > > +
> > > > + /* FIXME: PLL lock check */
> > >
> > > Shouldn't be too hard to add, no?
> >
> > Added to the next version which I intend to send today.
> >
> > >
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > +static int clk_pll1_prepare(struct clk_hw *hw)
> > > > +{
> > > > + struct clk_sccg_pll *pll = to_clk_sccg_pll(hw);
> > > > + u32 val;
> > > > +
> > > > + val = readl_relaxed(pll->base);
> > > > + val &= ~(1 << PLL_PD);
> > > > + writel_relaxed(val, pll->base);
> > >
> > > pll->base + PLL_CFG0 please.
> >
> > Same as above.
> >
> > >
> > > > +static const struct clk_ops clk_sccg_pll1_ops = {
> > > > + .is_prepared= clk_pll1_is_prepared,
> > > > + .recalc_rate= clk_pll1_recalc_rate,
> > > > + .round_rate = clk_pll1_round_rate,
> > > > + .set_rate = clk_pll1_set_rate,
> > > > +};
> > > > +
> > > > +static const struct clk_ops clk_sccg_pll2_ops = {
> > > > + .prepare= clk_pll1_prepare,
> > > > + .unprepare = clk_pll1_unprepare,
> > > > + .recalc_rate= clk_pll2_recalc_rate,
> > > > + .round_rate = clk_pll2_round_rate,
> > > > + .set_rate = clk_pll2_set_rate,
> > > > +};
> > >
> > > So these are two PLLs that share the same enable register. Doing the
> > > prepare/unprepare for only one PLL can lead to all kinds of trouble.
> > > Finding a good abstraction the properly handles this case with the
> > > clock framework is probably also not easy.
> > >
> > > I could imagine we'll need to track the enable state on both PLLs and
> > > only if both are disabled we disable it in hardware.
> > >
> > > With the current code we disable the PLLs when all consumers are
> > > reparented to pll1, which probably has bad effects.
> > >
> >
> > So it took me a while to understand exactly why this needs to stay like it
> > is.
> >
>
> IMHO this means that, if nothing else, all of the below should be
> documented in code as a comment, otherwise simpletons like me are
> going to continue stumbling over it and wondering what's going on.
Will try to add proper comment to explain what's happening.
>
> > The PLL1 is never used by any device, instead it is used as a source for
> > PLL2.
> >
> > But because the interlink between the two of them is too complicated,
> > the PLLs 1 and 2 need to be separate clocks.
> >
>
> Can you go a little bit more into detail as for why PLL1 needs to be
> exposed in the first place and can't just be dealt with behind the
> scenes as a part of PLL2 abstraction? Are there use-cases where the
> rates of the two are going to be adjusted individually in Linux?
>
Here is the SCCG PLL Block Diagram:
https://www.nxp.com/docs/en/reference-manual/IMX8MDQLQRM.pdf#page=834
Now lets take the System PLL 2 for example. If you follow the hierarchy,
when you reach the sys2_pll1_out you can see that one of its selectors is
actually sys1_pll1_ref_sel. Same thing applies to sys3_pll2_out with
sys2_pll1_ref_sel. This means there is an input reference clock interlinking
between different System PLLs.
> Thanks,
> Andrey Smirnov
--
Re: [PATCH v2 0/9] of: fix compatible-child-node lookups
Hi all, On Mon, Aug 27, 2018 at 10:21:44AM +0200, Johan Hovold wrote: > Several drivers currently use of_find_compatible_node() to lookup child > nodes while failing to notice that the of_find_ functions search the > entire tree depth-first (from a given start node) and therefore can > match unrelated nodes. > > The fact that these functions also drop a reference to the node they > start searching from (e.g. the parent node) is typically also > overlooked, something which can lead to use-after-free bugs (e.g. after > probe deferrals). > > This series adds a new helper, similar to of_get_child_by_name(), > that can be used to lookup compatible child nodes, and uses the new > helper to fix child-node lookups throughout the tree. > > This is related to the fixes I posted about a year ago, which addressed > a similar anti-pattern when looking up child nodes by name. Since it > took me more than a year to get all those fixes into Linus' tree (one > fix is still pending), and as these fixes depend on the new helper, I'm > suggesting that these all go in through Rob's or Greg's trees. > > Alternatively, the helper could go into to -rc2, and I'll be pinging > submaintainers for the coming year as well. ;) Rob has gotten the helper into -rc2 now: 36156f9241cb of: add helper to lookup compatible child node so feel free to pick these fixes up directly for 4.19-rc or -next, whichever you prefer. I've been able to trigger crashes after probe deferrals due to the use-after-free, but this seems unlikely to be exploitable. I think Rob will be picking up any patches that remain by the end of the release cycle for 4.20. Thanks, Johan > Johan Hovold (9): > of: add helper to lookup compatible child node > drm/mediatek: fix OF sibling-node lookup > drm/msm: fix OF child-node lookup > mmc: meson-mx-sdio: fix OF child-node lookup > mtd: nand: atmel: fix OF child-node lookup > net: bcmgenet: fix OF child-node lookup > net: stmmac: dwmac-sun8i: fix OF child-node lookup > NFC: nfcmrvl_uart: fix OF child-node lookup > power: supply: twl4030-charger: fix OF sibling-node lookup > > drivers/gpu/drm/mediatek/mtk_hdmi.c | 5 ++-- > drivers/gpu/drm/msm/adreno/adreno_gpu.c | 5 ++-- > drivers/mmc/host/meson-mx-sdio.c | 8 -- > drivers/mtd/nand/raw/atmel/nand-controller.c | 11 +--- > drivers/net/ethernet/broadcom/genet/bcmmii.c | 2 +- > .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 12 +++-- > drivers/nfc/nfcmrvl/uart.c| 5 ++-- > drivers/of/base.c | 25 +++ > drivers/power/supply/twl4030_charger.c| 5 ++-- > include/linux/of.h| 8 ++ > 10 files changed, 68 insertions(+), 18 deletions(-)
Re: [PATCH v2 0/9] of: fix compatible-child-node lookups
Hi all, On Mon, Aug 27, 2018 at 10:21:44AM +0200, Johan Hovold wrote: > Several drivers currently use of_find_compatible_node() to lookup child > nodes while failing to notice that the of_find_ functions search the > entire tree depth-first (from a given start node) and therefore can > match unrelated nodes. > > The fact that these functions also drop a reference to the node they > start searching from (e.g. the parent node) is typically also > overlooked, something which can lead to use-after-free bugs (e.g. after > probe deferrals). > > This series adds a new helper, similar to of_get_child_by_name(), > that can be used to lookup compatible child nodes, and uses the new > helper to fix child-node lookups throughout the tree. > > This is related to the fixes I posted about a year ago, which addressed > a similar anti-pattern when looking up child nodes by name. Since it > took me more than a year to get all those fixes into Linus' tree (one > fix is still pending), and as these fixes depend on the new helper, I'm > suggesting that these all go in through Rob's or Greg's trees. > > Alternatively, the helper could go into to -rc2, and I'll be pinging > submaintainers for the coming year as well. ;) Rob has gotten the helper into -rc2 now: 36156f9241cb of: add helper to lookup compatible child node so feel free to pick these fixes up directly for 4.19-rc or -next, whichever you prefer. I've been able to trigger crashes after probe deferrals due to the use-after-free, but this seems unlikely to be exploitable. I think Rob will be picking up any patches that remain by the end of the release cycle for 4.20. Thanks, Johan > Johan Hovold (9): > of: add helper to lookup compatible child node > drm/mediatek: fix OF sibling-node lookup > drm/msm: fix OF child-node lookup > mmc: meson-mx-sdio: fix OF child-node lookup > mtd: nand: atmel: fix OF child-node lookup > net: bcmgenet: fix OF child-node lookup > net: stmmac: dwmac-sun8i: fix OF child-node lookup > NFC: nfcmrvl_uart: fix OF child-node lookup > power: supply: twl4030-charger: fix OF sibling-node lookup > > drivers/gpu/drm/mediatek/mtk_hdmi.c | 5 ++-- > drivers/gpu/drm/msm/adreno/adreno_gpu.c | 5 ++-- > drivers/mmc/host/meson-mx-sdio.c | 8 -- > drivers/mtd/nand/raw/atmel/nand-controller.c | 11 +--- > drivers/net/ethernet/broadcom/genet/bcmmii.c | 2 +- > .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 12 +++-- > drivers/nfc/nfcmrvl/uart.c| 5 ++-- > drivers/of/base.c | 25 +++ > drivers/power/supply/twl4030_charger.c| 5 ++-- > include/linux/of.h| 8 ++ > 10 files changed, 68 insertions(+), 18 deletions(-)
Re: [PATCH v2 6/9] net: bcmgenet: fix OF child-node lookup
On Thu, Aug 30, 2018 at 05:47:33PM -0700, Florian Fainelli wrote:
> On 08/27/2018 01:21 AM, Johan Hovold wrote:
> > Use the new of_get_compatible_child() helper to lookup the mdio child
> > node instead of using of_find_compatible_node(), which searches the
> > entire tree from a given start node and thus can return an unrelated
> > (i.e. non-child) node.
> >
> > This also addresses a potential use-after-free (e.g. after probe
> > deferral) as the tree-wide helper drops a reference to its first
> > argument (i.e. the node of the device being probed).
> >
> > Fixes: aa09677cba42 ("net: bcmgenet: add MDIO routines")
> > Cc: stable # 3.15
> > Cc: Florian Fainelli
> > Cc: David S. Miller
> > Signed-off-by: Johan Hovold
>
> Reviewed-by: Florian Fainelli
Thanks for reviewing.
Rob's gotten the helper into -rc2:
36156f9241cb of: add helper to lookup compatible child node
so feel free to pick this one up directly to whichever net tree you
prefer. I've been able to trigger crashes after probe deferrals due to
the use-after-free, but this seems unlikely to be exploitable.
Thanks,
Johan
Re: [PATCH v2 6/9] net: bcmgenet: fix OF child-node lookup
On Thu, Aug 30, 2018 at 05:47:33PM -0700, Florian Fainelli wrote:
> On 08/27/2018 01:21 AM, Johan Hovold wrote:
> > Use the new of_get_compatible_child() helper to lookup the mdio child
> > node instead of using of_find_compatible_node(), which searches the
> > entire tree from a given start node and thus can return an unrelated
> > (i.e. non-child) node.
> >
> > This also addresses a potential use-after-free (e.g. after probe
> > deferral) as the tree-wide helper drops a reference to its first
> > argument (i.e. the node of the device being probed).
> >
> > Fixes: aa09677cba42 ("net: bcmgenet: add MDIO routines")
> > Cc: stable # 3.15
> > Cc: Florian Fainelli
> > Cc: David S. Miller
> > Signed-off-by: Johan Hovold
>
> Reviewed-by: Florian Fainelli
Thanks for reviewing.
Rob's gotten the helper into -rc2:
36156f9241cb of: add helper to lookup compatible child node
so feel free to pick this one up directly to whichever net tree you
prefer. I've been able to trigger crashes after probe deferrals due to
the use-after-free, but this seems unlikely to be exploitable.
Thanks,
Johan
[PATCH v2] ACPI / bus: Only call dmi_check_system on X86
Calling dmi_check_system() early only works on X86. Other
architectures initialize the DMI subsystem later so it's not
ready yet when ACPI itself gets initialized.
In the best case it results in a useless call to a function which
will do nothing. But depending on the dmi implementation, it could
also result in warnings. Best is to not call the function when it
can't work and isn't needed.
Additionally, if anyone ever needs to add non-x86 quirks, it would
surprisingly not work, so document the limitation to avoid confusion.
Signed-off-by: Jean Delvare
Fixes: cce4f632db20 ("ACPI: fix early DSDT dmi check warnings on ia64")
Cc: sta...@vger.kernel.org
Cc: Takashi Iwai
Cc: "Rafael J. Wysocki"
Cc: Len Brown
---
Changes since v1:
* Rebased on top of v4.19-rc2 to avoid conflicts with recent ACPI
changes.
* Fix typo in comment.
drivers/acpi/bus.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
--- linux-4.19-rc2.orig/drivers/acpi/bus.c 2018-09-02 23:37:30.0
+0200
+++ linux-4.19-rc2/drivers/acpi/bus.c 2018-09-04 10:34:34.995013240 +0200
@@ -35,11 +35,11 @@
#include
#ifdef CONFIG_X86
#include
+#include
#endif
#include
#include
#include
-#include
#include
#include "internal.h"
@@ -82,10 +82,6 @@ static const struct dmi_system_id dsdt_d
},
{}
};
-#else
-static const struct dmi_system_id dsdt_dmi_table[] __initconst = {
- {}
-};
#endif
/* --
@@ -1033,11 +1029,16 @@ void __init acpi_early_init(void)
acpi_permanent_mmap = true;
+#ifdef CONFIG_X86
/*
* If the machine falls into the DMI check table,
-* DSDT will be copied to memory
+* DSDT will be copied to memory.
+* Note that calling dmi_check_system here on other architectures
+* would not be OK because only x86 initializes dmi early enough.
+* Thankfully only x86 systems need such quirks for now.
*/
dmi_check_system(dsdt_dmi_table);
+#endif
status = acpi_reallocate_root_table();
if (ACPI_FAILURE(status)) {
--
Jean Delvare
SUSE L3 Support
[PATCH v2] ACPI / bus: Only call dmi_check_system on X86
Calling dmi_check_system() early only works on X86. Other
architectures initialize the DMI subsystem later so it's not
ready yet when ACPI itself gets initialized.
In the best case it results in a useless call to a function which
will do nothing. But depending on the dmi implementation, it could
also result in warnings. Best is to not call the function when it
can't work and isn't needed.
Additionally, if anyone ever needs to add non-x86 quirks, it would
surprisingly not work, so document the limitation to avoid confusion.
Signed-off-by: Jean Delvare
Fixes: cce4f632db20 ("ACPI: fix early DSDT dmi check warnings on ia64")
Cc: sta...@vger.kernel.org
Cc: Takashi Iwai
Cc: "Rafael J. Wysocki"
Cc: Len Brown
---
Changes since v1:
* Rebased on top of v4.19-rc2 to avoid conflicts with recent ACPI
changes.
* Fix typo in comment.
drivers/acpi/bus.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
--- linux-4.19-rc2.orig/drivers/acpi/bus.c 2018-09-02 23:37:30.0
+0200
+++ linux-4.19-rc2/drivers/acpi/bus.c 2018-09-04 10:34:34.995013240 +0200
@@ -35,11 +35,11 @@
#include
#ifdef CONFIG_X86
#include
+#include
#endif
#include
#include
#include
-#include
#include
#include "internal.h"
@@ -82,10 +82,6 @@ static const struct dmi_system_id dsdt_d
},
{}
};
-#else
-static const struct dmi_system_id dsdt_dmi_table[] __initconst = {
- {}
-};
#endif
/* --
@@ -1033,11 +1029,16 @@ void __init acpi_early_init(void)
acpi_permanent_mmap = true;
+#ifdef CONFIG_X86
/*
* If the machine falls into the DMI check table,
-* DSDT will be copied to memory
+* DSDT will be copied to memory.
+* Note that calling dmi_check_system here on other architectures
+* would not be OK because only x86 initializes dmi early enough.
+* Thankfully only x86 systems need such quirks for now.
*/
dmi_check_system(dsdt_dmi_table);
+#endif
status = acpi_reallocate_root_table();
if (ACPI_FAILURE(status)) {
--
Jean Delvare
SUSE L3 Support
Re: [PATCH v2 4/9] mmc: meson-mx-sdio: fix OF child-node lookup
On Mon, Aug 27, 2018 at 04:44:44PM +0200, Ulf Hansson wrote:
> On 27 August 2018 at 10:21, Johan Hovold wrote:
> > Use the new of_get_compatible_child() helper to lookup the slot child
> > node instead of using of_find_compatible_node(), which searches the
> > entire tree from a given start node and thus can return an unrelated
> > (i.e. non-child) node.
> >
> > This also addresses a potential use-after-free (e.g. after probe
> > deferral) as the tree-wide helper drops a reference to its first
> > argument (i.e. the node of the device being probed).
> >
> > While at it, also fix up the related slot-node reference leak.
> >
> > Fixes: ed80a13bb4c4 ("mmc: meson-mx-sdio: Add a driver for the Amlogic
> > Meson8 and Meson8b SoCs")
> > Cc: stable # 4.15
> > Cc: Carlo Caione
> > Cc: Martin Blumenstingl
> > Cc: Ulf Hansson
> > Acked-by: Martin Blumenstingl
> > Signed-off-by: Johan Hovold
>
> Acked-by: Ulf Hansson
Thanks for the ack. Rob's gotten the helper into -rc2, so feel free to
pick this one up directly to whichever mmc branch you prefer. I've been
able to trigger crashes after probe deferrals due to the use-after-free,
but this seems unlikely to be exploitable.
Thanks,
Johan
Re: [PATCH v2 4/9] mmc: meson-mx-sdio: fix OF child-node lookup
On Mon, Aug 27, 2018 at 04:44:44PM +0200, Ulf Hansson wrote:
> On 27 August 2018 at 10:21, Johan Hovold wrote:
> > Use the new of_get_compatible_child() helper to lookup the slot child
> > node instead of using of_find_compatible_node(), which searches the
> > entire tree from a given start node and thus can return an unrelated
> > (i.e. non-child) node.
> >
> > This also addresses a potential use-after-free (e.g. after probe
> > deferral) as the tree-wide helper drops a reference to its first
> > argument (i.e. the node of the device being probed).
> >
> > While at it, also fix up the related slot-node reference leak.
> >
> > Fixes: ed80a13bb4c4 ("mmc: meson-mx-sdio: Add a driver for the Amlogic
> > Meson8 and Meson8b SoCs")
> > Cc: stable # 4.15
> > Cc: Carlo Caione
> > Cc: Martin Blumenstingl
> > Cc: Ulf Hansson
> > Acked-by: Martin Blumenstingl
> > Signed-off-by: Johan Hovold
>
> Acked-by: Ulf Hansson
Thanks for the ack. Rob's gotten the helper into -rc2, so feel free to
pick this one up directly to whichever mmc branch you prefer. I've been
able to trigger crashes after probe deferrals due to the use-after-free,
but this seems unlikely to be exploitable.
Thanks,
Johan
Re: [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI driver
On Mon, 3 Sep 2018 09:54:08 + Prabhakar Kushwaha wrote: > Dear Yogesh, > > > -Original Message- > > From: linux-kernel-ow...@vger.kernel.org > ow...@vger.kernel.org> On Behalf Of Yogesh Gaur > > Sent: Friday, August 31, 2018 4:00 PM > > To: linux-...@lists.infradead.org; boris.brezil...@bootlin.com; > > marek.va...@gmail.com; linux-...@vger.kernel.org; > > devicet...@vger.kernel.org > > Cc: r...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; linux- > > arm-ker...@lists.infradead.org; computersforpe...@gmail.com; > > frieder.schre...@exceet.de; linux-kernel@vger.kernel.org; Yogesh > > Narayan Gaur > > Subject: [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI > > driver > > > > Add binding file for NXP FlexSPI driver. > > > > Signed-off-by: Yogesh Gaur > > --- > > .../devicetree/bindings/spi/spi-nxp-fspi.txt | 42 > > ++ > > 1 file changed, 42 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/spi/spi-nxp- > > fspi.txt > > > > diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > new file mode 100644 > > index 000..9f07116 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > @@ -0,0 +1,42 @@ > > +* NXP Flex Serial Peripheral Interface (FSPI) > > + > > +Required properties: > > + - compatible : Should be "nxp,lx2160a-fspi" > > + - reg :First contains the register location and length, > > + Second contains the memory mapping address and length > > Why are we overriding reg property. Is there any special requirement. > > Can we use "reg" and "ranges" property in device tree. > Here "reg" represents controller registers and "ranges" represent the memory > address of flash. No, ranges is not used for that. It's used when you need to convert from one address space to another, which is not what you're describing here. Check section 2.38 of this document [1] for more details. [1]https://elinux.org/images/c/cf/Power_ePAPR_APPROVED_v1.1.pdf
Re: linux-next: manual merge of the dmi tree with Linus' tree
Hi Stephen,
On Tue, 4 Sep 2018 09:19:50 +1000, Stephen Rothwell wrote:
> Today's linux-next merge of the dmi tree got a conflict in:
>
> drivers/acpi/bus.c
>
> between commit:
>
> ae976358cd7b ("Revert "ACPI / bus: Parse tables as term_list for Dell XPS
> 9570 and Precision M5530"")
>
> from Linus' tree and commit:
>
> 767b174cad46 ("ACPI / bus: Only call dmi_check_system on X86")
>
> from the dmi tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
Thanks for the heads up. I have rebased my dmi tree on top of 4.19-rc2,
and this solves the conflict.
--
Jean Delvare
SUSE L3 Support
Re: [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI driver
On Mon, 3 Sep 2018 09:54:08 + Prabhakar Kushwaha wrote: > Dear Yogesh, > > > -Original Message- > > From: linux-kernel-ow...@vger.kernel.org > ow...@vger.kernel.org> On Behalf Of Yogesh Gaur > > Sent: Friday, August 31, 2018 4:00 PM > > To: linux-...@lists.infradead.org; boris.brezil...@bootlin.com; > > marek.va...@gmail.com; linux-...@vger.kernel.org; > > devicet...@vger.kernel.org > > Cc: r...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; linux- > > arm-ker...@lists.infradead.org; computersforpe...@gmail.com; > > frieder.schre...@exceet.de; linux-kernel@vger.kernel.org; Yogesh > > Narayan Gaur > > Subject: [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI > > driver > > > > Add binding file for NXP FlexSPI driver. > > > > Signed-off-by: Yogesh Gaur > > --- > > .../devicetree/bindings/spi/spi-nxp-fspi.txt | 42 > > ++ > > 1 file changed, 42 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/spi/spi-nxp- > > fspi.txt > > > > diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > new file mode 100644 > > index 000..9f07116 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > @@ -0,0 +1,42 @@ > > +* NXP Flex Serial Peripheral Interface (FSPI) > > + > > +Required properties: > > + - compatible : Should be "nxp,lx2160a-fspi" > > + - reg :First contains the register location and length, > > + Second contains the memory mapping address and length > > Why are we overriding reg property. Is there any special requirement. > > Can we use "reg" and "ranges" property in device tree. > Here "reg" represents controller registers and "ranges" represent the memory > address of flash. No, ranges is not used for that. It's used when you need to convert from one address space to another, which is not what you're describing here. Check section 2.38 of this document [1] for more details. [1]https://elinux.org/images/c/cf/Power_ePAPR_APPROVED_v1.1.pdf
Re: linux-next: manual merge of the dmi tree with Linus' tree
Hi Stephen,
On Tue, 4 Sep 2018 09:19:50 +1000, Stephen Rothwell wrote:
> Today's linux-next merge of the dmi tree got a conflict in:
>
> drivers/acpi/bus.c
>
> between commit:
>
> ae976358cd7b ("Revert "ACPI / bus: Parse tables as term_list for Dell XPS
> 9570 and Precision M5530"")
>
> from Linus' tree and commit:
>
> 767b174cad46 ("ACPI / bus: Only call dmi_check_system on X86")
>
> from the dmi tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
Thanks for the heads up. I have rebased my dmi tree on top of 4.19-rc2,
and this solves the conflict.
--
Jean Delvare
SUSE L3 Support
[RFC PATCH 4/5] irqchip: RISC-V Local Interrupt Controller Driver
The RISC-V local interrupt controller manages software interrupts,
timer interrupts, external interrupts (which are routed via the
platform level interrupt controller) and per-HART local interrupts.
This patch add a driver for RISC-V local interrupt controller. It's
a major re-write over perviously submitted version.
(Refer, https://www.spinics.net/lists/devicetree/msg241230.html)
Few advantages of this new driver over previous one are:
1. It registers all local interrupts as per-CPU interrupts
2. We can develop drivers for devices with per-CPU local interrupts
without changing arch code or this driver
3. It allows local interrupt controller DT node under each CPU DT node
as well as single system-wide DT node for local interrupt controller.
The RISC-V INTC driver is compliant with RISC-V Hart-Level Interrupt
Controller DT bindings located at:
Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt
Signed-off-by: Anup Patel
Signed-off-by: Palmer Dabbelt
---
arch/riscv/include/asm/irq.h | 15 ++-
arch/riscv/kernel/irq.c | 59 +--
drivers/irqchip/Kconfig | 15 ++-
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-riscv-intc.c | 164 ++
drivers/irqchip/irq-sifive-plic.c | 21 +++-
include/linux/cpuhotplug.h| 1 +
7 files changed, 214 insertions(+), 62 deletions(-)
create mode 100644 drivers/irqchip/irq-riscv-intc.c
diff --git a/arch/riscv/include/asm/irq.h b/arch/riscv/include/asm/irq.h
index 93eb75eac4ff..fe503d71876a 100644
--- a/arch/riscv/include/asm/irq.h
+++ b/arch/riscv/include/asm/irq.h
@@ -15,7 +15,20 @@
#ifndef _ASM_RISCV_IRQ_H
#define _ASM_RISCV_IRQ_H
-#define NR_IRQS 0
+/*
+ * Possible interrupt causes:
+ */
+#define INTERRUPT_CAUSE_SOFTWARE1
+#define INTERRUPT_CAUSE_TIMER 5
+#define INTERRUPT_CAUSE_EXTERNAL9
+
+/*
+ * The high order bit of the trap cause register is always set for
+ * interrupts, which allows us to differentiate them from exceptions
+ * quickly. The INTERRUPT_CAUSE_* macros don't contain that bit, so we
+ * need to mask it off.
+ */
+#define INTERRUPT_CAUSE_FLAG (1UL << (__riscv_xlen - 1))
void riscv_timer_interrupt(void);
diff --git a/arch/riscv/kernel/irq.c b/arch/riscv/kernel/irq.c
index c51c9b402e87..46a311e5f0f6 100644
--- a/arch/riscv/kernel/irq.c
+++ b/arch/riscv/kernel/irq.c
@@ -7,69 +7,16 @@
#include
#include
-#include
-
-#include
-
-/*
- * Possible interrupt causes:
- */
-#define INTERRUPT_CAUSE_SOFTWARE1
-#define INTERRUPT_CAUSE_TIMER 5
-#define INTERRUPT_CAUSE_EXTERNAL9
-
-/*
- * The high order bit of the trap cause register is always set for
- * interrupts, which allows us to differentiate them from exceptions
- * quickly. The INTERRUPT_CAUSE_* macros don't contain that bit, so we
- * need to mask it off.
- */
-#define INTERRUPT_CAUSE_FLAG (1UL << (__riscv_xlen - 1))
asmlinkage void __irq_entry do_IRQ(struct pt_regs *regs)
{
- struct pt_regs *old_regs;
-
- switch (regs->scause & ~INTERRUPT_CAUSE_FLAG) {
- case INTERRUPT_CAUSE_TIMER:
- old_regs = set_irq_regs(regs);
- irq_enter();
- riscv_timer_interrupt();
- irq_exit();
- set_irq_regs(old_regs);
- break;
-#ifdef CONFIG_SMP
- case INTERRUPT_CAUSE_SOFTWARE:
- /*
-* We only use software interrupts to pass IPIs, so if a non-SMP
-* system gets one, then we don't know what to do.
-*/
- handle_IPI(regs);
- break;
-#endif
- case INTERRUPT_CAUSE_EXTERNAL:
- old_regs = set_irq_regs(regs);
- irq_enter();
+ if (handle_arch_irq)
handle_arch_irq(regs);
- irq_exit();
- set_irq_regs(old_regs);
- break;
- default:
- panic("unexpected interrupt cause");
- }
-}
-
-#ifdef CONFIG_SMP
-static void smp_ipi_trigger_sbi(const struct cpumask *to_whom)
-{
- sbi_send_ipi(cpumask_bits(to_whom));
}
-#endif
void __init init_IRQ(void)
{
irqchip_init();
-#ifdef CONFIG_SMP
- set_smp_ipi_trigger(smp_ipi_trigger_sbi);
-#endif
+ if (!handle_arch_irq)
+ panic("No interrupt controller found.");
}
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 383e7b70221d..885e182586f4 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -371,7 +371,18 @@ config QCOM_PDC
Power Domain Controller driver to manage and configure wakeup
IRQs for Qualcomm Technologies Inc (QTI) mobile chips.
-endmenu
+config RISCV_INTC
+ bool "RISC-V Interrupt Controller"
+ depends on RISCV
+ default y
+ help
+ This enables support for the local interrupt controller found in
+ standard RISC-V systems. The local interrupt controller handles
+ timer
[RFC PATCH 4/5] irqchip: RISC-V Local Interrupt Controller Driver
The RISC-V local interrupt controller manages software interrupts,
timer interrupts, external interrupts (which are routed via the
platform level interrupt controller) and per-HART local interrupts.
This patch add a driver for RISC-V local interrupt controller. It's
a major re-write over perviously submitted version.
(Refer, https://www.spinics.net/lists/devicetree/msg241230.html)
Few advantages of this new driver over previous one are:
1. It registers all local interrupts as per-CPU interrupts
2. We can develop drivers for devices with per-CPU local interrupts
without changing arch code or this driver
3. It allows local interrupt controller DT node under each CPU DT node
as well as single system-wide DT node for local interrupt controller.
The RISC-V INTC driver is compliant with RISC-V Hart-Level Interrupt
Controller DT bindings located at:
Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt
Signed-off-by: Anup Patel
Signed-off-by: Palmer Dabbelt
---
arch/riscv/include/asm/irq.h | 15 ++-
arch/riscv/kernel/irq.c | 59 +--
drivers/irqchip/Kconfig | 15 ++-
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-riscv-intc.c | 164 ++
drivers/irqchip/irq-sifive-plic.c | 21 +++-
include/linux/cpuhotplug.h| 1 +
7 files changed, 214 insertions(+), 62 deletions(-)
create mode 100644 drivers/irqchip/irq-riscv-intc.c
diff --git a/arch/riscv/include/asm/irq.h b/arch/riscv/include/asm/irq.h
index 93eb75eac4ff..fe503d71876a 100644
--- a/arch/riscv/include/asm/irq.h
+++ b/arch/riscv/include/asm/irq.h
@@ -15,7 +15,20 @@
#ifndef _ASM_RISCV_IRQ_H
#define _ASM_RISCV_IRQ_H
-#define NR_IRQS 0
+/*
+ * Possible interrupt causes:
+ */
+#define INTERRUPT_CAUSE_SOFTWARE1
+#define INTERRUPT_CAUSE_TIMER 5
+#define INTERRUPT_CAUSE_EXTERNAL9
+
+/*
+ * The high order bit of the trap cause register is always set for
+ * interrupts, which allows us to differentiate them from exceptions
+ * quickly. The INTERRUPT_CAUSE_* macros don't contain that bit, so we
+ * need to mask it off.
+ */
+#define INTERRUPT_CAUSE_FLAG (1UL << (__riscv_xlen - 1))
void riscv_timer_interrupt(void);
diff --git a/arch/riscv/kernel/irq.c b/arch/riscv/kernel/irq.c
index c51c9b402e87..46a311e5f0f6 100644
--- a/arch/riscv/kernel/irq.c
+++ b/arch/riscv/kernel/irq.c
@@ -7,69 +7,16 @@
#include
#include
-#include
-
-#include
-
-/*
- * Possible interrupt causes:
- */
-#define INTERRUPT_CAUSE_SOFTWARE1
-#define INTERRUPT_CAUSE_TIMER 5
-#define INTERRUPT_CAUSE_EXTERNAL9
-
-/*
- * The high order bit of the trap cause register is always set for
- * interrupts, which allows us to differentiate them from exceptions
- * quickly. The INTERRUPT_CAUSE_* macros don't contain that bit, so we
- * need to mask it off.
- */
-#define INTERRUPT_CAUSE_FLAG (1UL << (__riscv_xlen - 1))
asmlinkage void __irq_entry do_IRQ(struct pt_regs *regs)
{
- struct pt_regs *old_regs;
-
- switch (regs->scause & ~INTERRUPT_CAUSE_FLAG) {
- case INTERRUPT_CAUSE_TIMER:
- old_regs = set_irq_regs(regs);
- irq_enter();
- riscv_timer_interrupt();
- irq_exit();
- set_irq_regs(old_regs);
- break;
-#ifdef CONFIG_SMP
- case INTERRUPT_CAUSE_SOFTWARE:
- /*
-* We only use software interrupts to pass IPIs, so if a non-SMP
-* system gets one, then we don't know what to do.
-*/
- handle_IPI(regs);
- break;
-#endif
- case INTERRUPT_CAUSE_EXTERNAL:
- old_regs = set_irq_regs(regs);
- irq_enter();
+ if (handle_arch_irq)
handle_arch_irq(regs);
- irq_exit();
- set_irq_regs(old_regs);
- break;
- default:
- panic("unexpected interrupt cause");
- }
-}
-
-#ifdef CONFIG_SMP
-static void smp_ipi_trigger_sbi(const struct cpumask *to_whom)
-{
- sbi_send_ipi(cpumask_bits(to_whom));
}
-#endif
void __init init_IRQ(void)
{
irqchip_init();
-#ifdef CONFIG_SMP
- set_smp_ipi_trigger(smp_ipi_trigger_sbi);
-#endif
+ if (!handle_arch_irq)
+ panic("No interrupt controller found.");
}
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 383e7b70221d..885e182586f4 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -371,7 +371,18 @@ config QCOM_PDC
Power Domain Controller driver to manage and configure wakeup
IRQs for Qualcomm Technologies Inc (QTI) mobile chips.
-endmenu
+config RISCV_INTC
+ bool "RISC-V Interrupt Controller"
+ depends on RISCV
+ default y
+ help
+ This enables support for the local interrupt controller found in
+ standard RISC-V systems. The local interrupt controller handles
+ timer
[RFC PATCH 2/5] RISC-V: No need to pass scause as arg to do_IRQ()
The scause is already part of pt_regs so no need to pass
scause as separate arg to do_IRQ().
Signed-off-by: Anup Patel
---
arch/riscv/kernel/entry.S | 1 -
arch/riscv/kernel/irq.c | 4 ++--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S
index fa2c08e3c05e..6eaacfa5b63d 100644
--- a/arch/riscv/kernel/entry.S
+++ b/arch/riscv/kernel/entry.S
@@ -168,7 +168,6 @@ ENTRY(handle_exception)
/* Handle interrupts */
move a0, sp /* pt_regs */
- move a1, s4 /* scause */
tail do_IRQ
1:
/* Exceptions run with interrupts enabled */
diff --git a/arch/riscv/kernel/irq.c b/arch/riscv/kernel/irq.c
index 5532e7cedaec..c51c9b402e87 100644
--- a/arch/riscv/kernel/irq.c
+++ b/arch/riscv/kernel/irq.c
@@ -26,11 +26,11 @@
*/
#define INTERRUPT_CAUSE_FLAG (1UL << (__riscv_xlen - 1))
-asmlinkage void __irq_entry do_IRQ(struct pt_regs *regs, unsigned long cause)
+asmlinkage void __irq_entry do_IRQ(struct pt_regs *regs)
{
struct pt_regs *old_regs;
- switch (cause & ~INTERRUPT_CAUSE_FLAG) {
+ switch (regs->scause & ~INTERRUPT_CAUSE_FLAG) {
case INTERRUPT_CAUSE_TIMER:
old_regs = set_irq_regs(regs);
irq_enter();
--
2.17.1
[RFC PATCH 0/5] New RISC-V Local Interrupt Controller Driver
This patchset provides a new RISC-V Local Interrupt Controller Driver for managing per-CPU local interrupts. The overall approach is inspired from the way per-CPU local interrupts are handled by Linux ARM64 and ARM GICv3 driver. Few advantages of having this new driver are as follows: 1. It registers all local interrupts as per-CPU interrupts 2. We can develop drivers for devices with per-CPU local interrupts without changing arch code or this driver 3. It allows local interrupt controller DT node under each CPU DT node as well as single system-wide DT node for local interrupt controller. With this patchset, output of "cat /proc/interrupts" looks as follows: CPU0 CPU1 CPU2 CPU3 5:995 1012997 1015 RISC-V INTC 5 Edge riscv_timer 8: 23 6 10 7 SiFive PLIC 8 Edge virtio0 10: 9 10 5 4 SiFive PLIC 10 Edge ttyS0 The patchset is based up Linux-4.19-rc2 and can be found at riscv_intc_v1 branch of: https://github.com/avpatel/linux.git Anup Patel (5): RISC-V: Make IPI triggering flexible RISC-V: No need to pass scause as arg to do_IRQ() RISC-V: Select useful GENERIC_IRQ kconfig options irqchip: RISC-V Local Interrupt Controller Driver clocksource: riscv_timer: Make timer interrupt as a per-CPU interrupt arch/riscv/Kconfig| 4 + arch/riscv/include/asm/irq.h | 16 ++- arch/riscv/include/asm/smp.h | 10 ++ arch/riscv/kernel/entry.S | 1 - arch/riscv/kernel/irq.c | 45 + arch/riscv/kernel/smp.c | 23 - drivers/clocksource/riscv_timer.c | 76 --- drivers/irqchip/Kconfig | 15 ++- drivers/irqchip/Makefile | 1 + drivers/irqchip/irq-riscv-intc.c | 156 ++ drivers/irqchip/irq-sifive-plic.c | 21 +++- include/linux/cpuhotplug.h| 1 + 12 files changed, 301 insertions(+), 68 deletions(-) create mode 100644 drivers/irqchip/irq-riscv-intc.c -- 2.17.1
[RFC PATCH 1/5] RISC-V: Make IPI triggering flexible
The mechanism to trigger IPI is generally part of interrupt-controller
driver for various architectures. On RISC-V, we have an option to trigger
IPI using SBI or SOC vendor can implement RISC-V CPU where IPI will be
triggered using SOC interrupt-controller (e.g. custom PLIC).
This patch makes IPI triggering flexible by providing a mechanism for
interrupt-controller driver to register IPI trigger function using
set_smp_ipi_trigger() function.
Signed-off-by: Anup Patel
---
arch/riscv/include/asm/irq.h | 1 -
arch/riscv/include/asm/smp.h | 10 ++
arch/riscv/kernel/irq.c | 26 +-
arch/riscv/kernel/smp.c | 23 +++
4 files changed, 50 insertions(+), 10 deletions(-)
diff --git a/arch/riscv/include/asm/irq.h b/arch/riscv/include/asm/irq.h
index 996b6fbe17a6..93eb75eac4ff 100644
--- a/arch/riscv/include/asm/irq.h
+++ b/arch/riscv/include/asm/irq.h
@@ -18,7 +18,6 @@
#define NR_IRQS 0
void riscv_timer_interrupt(void);
-void riscv_software_interrupt(void);
#include
diff --git a/arch/riscv/include/asm/smp.h b/arch/riscv/include/asm/smp.h
index 36016845461d..72671580e1d4 100644
--- a/arch/riscv/include/asm/smp.h
+++ b/arch/riscv/include/asm/smp.h
@@ -27,6 +27,16 @@
/* SMP initialization hook for setup_arch */
void __init setup_smp(void);
+/*
+ * Called from C code, this handles an IPI.
+ */
+void handle_IPI(struct pt_regs *regs);
+
+/*
+ * Provide a function to raise an IPI on CPUs in callmap.
+ */
+void __init set_smp_ipi_trigger(void (*fn)(const struct cpumask *));
+
/* Hook for the generic smp_call_function_many() routine. */
void arch_send_call_function_ipi_mask(struct cpumask *mask);
diff --git a/arch/riscv/kernel/irq.c b/arch/riscv/kernel/irq.c
index 0cfac48a1272..5532e7cedaec 100644
--- a/arch/riscv/kernel/irq.c
+++ b/arch/riscv/kernel/irq.c
@@ -9,6 +9,8 @@
#include
#include
+#include
+
/*
* Possible interrupt causes:
*/
@@ -26,12 +28,15 @@
asmlinkage void __irq_entry do_IRQ(struct pt_regs *regs, unsigned long cause)
{
- struct pt_regs *old_regs = set_irq_regs(regs);
+ struct pt_regs *old_regs;
- irq_enter();
switch (cause & ~INTERRUPT_CAUSE_FLAG) {
case INTERRUPT_CAUSE_TIMER:
+ old_regs = set_irq_regs(regs);
+ irq_enter();
riscv_timer_interrupt();
+ irq_exit();
+ set_irq_regs(old_regs);
break;
#ifdef CONFIG_SMP
case INTERRUPT_CAUSE_SOFTWARE:
@@ -39,21 +44,32 @@ asmlinkage void __irq_entry do_IRQ(struct pt_regs *regs,
unsigned long cause)
* We only use software interrupts to pass IPIs, so if a non-SMP
* system gets one, then we don't know what to do.
*/
- riscv_software_interrupt();
+ handle_IPI(regs);
break;
#endif
case INTERRUPT_CAUSE_EXTERNAL:
+ old_regs = set_irq_regs(regs);
+ irq_enter();
handle_arch_irq(regs);
+ irq_exit();
+ set_irq_regs(old_regs);
break;
default:
panic("unexpected interrupt cause");
}
- irq_exit();
+}
- set_irq_regs(old_regs);
+#ifdef CONFIG_SMP
+static void smp_ipi_trigger_sbi(const struct cpumask *to_whom)
+{
+ sbi_send_ipi(cpumask_bits(to_whom));
}
+#endif
void __init init_IRQ(void)
{
irqchip_init();
+#ifdef CONFIG_SMP
+ set_smp_ipi_trigger(smp_ipi_trigger_sbi);
+#endif
}
diff --git a/arch/riscv/kernel/smp.c b/arch/riscv/kernel/smp.c
index 906fe21ea21b..04571d77eceb 100644
--- a/arch/riscv/kernel/smp.c
+++ b/arch/riscv/kernel/smp.c
@@ -38,17 +38,19 @@ enum ipi_message_type {
IPI_MAX
};
-
/* Unsupported */
int setup_profiling_timer(unsigned int multiplier)
{
return -EINVAL;
}
-void riscv_software_interrupt(void)
+void handle_IPI(struct pt_regs *regs)
{
+ struct pt_regs *old_regs = set_irq_regs(regs);
unsigned long *pending_ipis = _data[smp_processor_id()].bits;
+ irq_enter();
+
/* Clear pending IPI */
csr_clear(sip, SIE_SSIE);
@@ -60,7 +62,7 @@ void riscv_software_interrupt(void)
ops = xchg(pending_ipis, 0);
if (ops == 0)
- return;
+ goto done;
if (ops & (1 << IPI_RESCHEDULE))
scheduler_ipi();
@@ -73,6 +75,17 @@ void riscv_software_interrupt(void)
/* Order data access and bit testing. */
mb();
}
+
+done:
+ irq_exit();
+ set_irq_regs(old_regs);
+}
+
+static void (*__smp_ipi_trigger)(const struct cpumask *);
+
+void __init set_smp_ipi_trigger(void (*fn)(const struct cpumask *))
+{
+ __smp_ipi_trigger = fn;
}
static void
@@ -85,7 +98,9 @@ send_ipi_message(const struct cpumask *to_whom, enum
ipi_message_type operation)
[RFC PATCH 3/5] RISC-V: Select useful GENERIC_IRQ kconfig options
This patch selects following GENERIC_IRQ kconfig options: GENERIC_IRQ_MULTI_HANDLER GENERIC_IRQ_PROBE GENERIC_IRQ_SHOW_LEVEL HANDLE_DOMAIN_IRQ Signed-off-by: Anup Patel --- arch/riscv/Kconfig | 4 1 file changed, 4 insertions(+) diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index a344980287a5..026abe3d6cb0 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -22,7 +22,10 @@ config RISCV select DMA_DIRECT_OPS select GENERIC_CLOCKEVENTS select GENERIC_CPU_DEVICES + select GENERIC_IRQ_MULTI_HANDLER + select GENERIC_IRQ_PROBE select GENERIC_IRQ_SHOW + select GENERIC_IRQ_SHOW_LEVEL select GENERIC_PCI_IOMAP select GENERIC_STRNCPY_FROM_USER select GENERIC_STRNLEN_USER @@ -33,6 +36,7 @@ config RISCV select HAVE_DMA_CONTIGUOUS select HAVE_GENERIC_DMA_COHERENT select HAVE_PERF_EVENTS + select HANDLE_DOMAIN_IRQ select IRQ_DOMAIN select NO_BOOTMEM select RISCV_ISA_A if SMP -- 2.17.1
[RFC PATCH 2/5] RISC-V: No need to pass scause as arg to do_IRQ()
The scause is already part of pt_regs so no need to pass
scause as separate arg to do_IRQ().
Signed-off-by: Anup Patel
---
arch/riscv/kernel/entry.S | 1 -
arch/riscv/kernel/irq.c | 4 ++--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S
index fa2c08e3c05e..6eaacfa5b63d 100644
--- a/arch/riscv/kernel/entry.S
+++ b/arch/riscv/kernel/entry.S
@@ -168,7 +168,6 @@ ENTRY(handle_exception)
/* Handle interrupts */
move a0, sp /* pt_regs */
- move a1, s4 /* scause */
tail do_IRQ
1:
/* Exceptions run with interrupts enabled */
diff --git a/arch/riscv/kernel/irq.c b/arch/riscv/kernel/irq.c
index 5532e7cedaec..c51c9b402e87 100644
--- a/arch/riscv/kernel/irq.c
+++ b/arch/riscv/kernel/irq.c
@@ -26,11 +26,11 @@
*/
#define INTERRUPT_CAUSE_FLAG (1UL << (__riscv_xlen - 1))
-asmlinkage void __irq_entry do_IRQ(struct pt_regs *regs, unsigned long cause)
+asmlinkage void __irq_entry do_IRQ(struct pt_regs *regs)
{
struct pt_regs *old_regs;
- switch (cause & ~INTERRUPT_CAUSE_FLAG) {
+ switch (regs->scause & ~INTERRUPT_CAUSE_FLAG) {
case INTERRUPT_CAUSE_TIMER:
old_regs = set_irq_regs(regs);
irq_enter();
--
2.17.1
[RFC PATCH 0/5] New RISC-V Local Interrupt Controller Driver
This patchset provides a new RISC-V Local Interrupt Controller Driver for managing per-CPU local interrupts. The overall approach is inspired from the way per-CPU local interrupts are handled by Linux ARM64 and ARM GICv3 driver. Few advantages of having this new driver are as follows: 1. It registers all local interrupts as per-CPU interrupts 2. We can develop drivers for devices with per-CPU local interrupts without changing arch code or this driver 3. It allows local interrupt controller DT node under each CPU DT node as well as single system-wide DT node for local interrupt controller. With this patchset, output of "cat /proc/interrupts" looks as follows: CPU0 CPU1 CPU2 CPU3 5:995 1012997 1015 RISC-V INTC 5 Edge riscv_timer 8: 23 6 10 7 SiFive PLIC 8 Edge virtio0 10: 9 10 5 4 SiFive PLIC 10 Edge ttyS0 The patchset is based up Linux-4.19-rc2 and can be found at riscv_intc_v1 branch of: https://github.com/avpatel/linux.git Anup Patel (5): RISC-V: Make IPI triggering flexible RISC-V: No need to pass scause as arg to do_IRQ() RISC-V: Select useful GENERIC_IRQ kconfig options irqchip: RISC-V Local Interrupt Controller Driver clocksource: riscv_timer: Make timer interrupt as a per-CPU interrupt arch/riscv/Kconfig| 4 + arch/riscv/include/asm/irq.h | 16 ++- arch/riscv/include/asm/smp.h | 10 ++ arch/riscv/kernel/entry.S | 1 - arch/riscv/kernel/irq.c | 45 + arch/riscv/kernel/smp.c | 23 - drivers/clocksource/riscv_timer.c | 76 --- drivers/irqchip/Kconfig | 15 ++- drivers/irqchip/Makefile | 1 + drivers/irqchip/irq-riscv-intc.c | 156 ++ drivers/irqchip/irq-sifive-plic.c | 21 +++- include/linux/cpuhotplug.h| 1 + 12 files changed, 301 insertions(+), 68 deletions(-) create mode 100644 drivers/irqchip/irq-riscv-intc.c -- 2.17.1
[RFC PATCH 1/5] RISC-V: Make IPI triggering flexible
The mechanism to trigger IPI is generally part of interrupt-controller
driver for various architectures. On RISC-V, we have an option to trigger
IPI using SBI or SOC vendor can implement RISC-V CPU where IPI will be
triggered using SOC interrupt-controller (e.g. custom PLIC).
This patch makes IPI triggering flexible by providing a mechanism for
interrupt-controller driver to register IPI trigger function using
set_smp_ipi_trigger() function.
Signed-off-by: Anup Patel
---
arch/riscv/include/asm/irq.h | 1 -
arch/riscv/include/asm/smp.h | 10 ++
arch/riscv/kernel/irq.c | 26 +-
arch/riscv/kernel/smp.c | 23 +++
4 files changed, 50 insertions(+), 10 deletions(-)
diff --git a/arch/riscv/include/asm/irq.h b/arch/riscv/include/asm/irq.h
index 996b6fbe17a6..93eb75eac4ff 100644
--- a/arch/riscv/include/asm/irq.h
+++ b/arch/riscv/include/asm/irq.h
@@ -18,7 +18,6 @@
#define NR_IRQS 0
void riscv_timer_interrupt(void);
-void riscv_software_interrupt(void);
#include
diff --git a/arch/riscv/include/asm/smp.h b/arch/riscv/include/asm/smp.h
index 36016845461d..72671580e1d4 100644
--- a/arch/riscv/include/asm/smp.h
+++ b/arch/riscv/include/asm/smp.h
@@ -27,6 +27,16 @@
/* SMP initialization hook for setup_arch */
void __init setup_smp(void);
+/*
+ * Called from C code, this handles an IPI.
+ */
+void handle_IPI(struct pt_regs *regs);
+
+/*
+ * Provide a function to raise an IPI on CPUs in callmap.
+ */
+void __init set_smp_ipi_trigger(void (*fn)(const struct cpumask *));
+
/* Hook for the generic smp_call_function_many() routine. */
void arch_send_call_function_ipi_mask(struct cpumask *mask);
diff --git a/arch/riscv/kernel/irq.c b/arch/riscv/kernel/irq.c
index 0cfac48a1272..5532e7cedaec 100644
--- a/arch/riscv/kernel/irq.c
+++ b/arch/riscv/kernel/irq.c
@@ -9,6 +9,8 @@
#include
#include
+#include
+
/*
* Possible interrupt causes:
*/
@@ -26,12 +28,15 @@
asmlinkage void __irq_entry do_IRQ(struct pt_regs *regs, unsigned long cause)
{
- struct pt_regs *old_regs = set_irq_regs(regs);
+ struct pt_regs *old_regs;
- irq_enter();
switch (cause & ~INTERRUPT_CAUSE_FLAG) {
case INTERRUPT_CAUSE_TIMER:
+ old_regs = set_irq_regs(regs);
+ irq_enter();
riscv_timer_interrupt();
+ irq_exit();
+ set_irq_regs(old_regs);
break;
#ifdef CONFIG_SMP
case INTERRUPT_CAUSE_SOFTWARE:
@@ -39,21 +44,32 @@ asmlinkage void __irq_entry do_IRQ(struct pt_regs *regs,
unsigned long cause)
* We only use software interrupts to pass IPIs, so if a non-SMP
* system gets one, then we don't know what to do.
*/
- riscv_software_interrupt();
+ handle_IPI(regs);
break;
#endif
case INTERRUPT_CAUSE_EXTERNAL:
+ old_regs = set_irq_regs(regs);
+ irq_enter();
handle_arch_irq(regs);
+ irq_exit();
+ set_irq_regs(old_regs);
break;
default:
panic("unexpected interrupt cause");
}
- irq_exit();
+}
- set_irq_regs(old_regs);
+#ifdef CONFIG_SMP
+static void smp_ipi_trigger_sbi(const struct cpumask *to_whom)
+{
+ sbi_send_ipi(cpumask_bits(to_whom));
}
+#endif
void __init init_IRQ(void)
{
irqchip_init();
+#ifdef CONFIG_SMP
+ set_smp_ipi_trigger(smp_ipi_trigger_sbi);
+#endif
}
diff --git a/arch/riscv/kernel/smp.c b/arch/riscv/kernel/smp.c
index 906fe21ea21b..04571d77eceb 100644
--- a/arch/riscv/kernel/smp.c
+++ b/arch/riscv/kernel/smp.c
@@ -38,17 +38,19 @@ enum ipi_message_type {
IPI_MAX
};
-
/* Unsupported */
int setup_profiling_timer(unsigned int multiplier)
{
return -EINVAL;
}
-void riscv_software_interrupt(void)
+void handle_IPI(struct pt_regs *regs)
{
+ struct pt_regs *old_regs = set_irq_regs(regs);
unsigned long *pending_ipis = _data[smp_processor_id()].bits;
+ irq_enter();
+
/* Clear pending IPI */
csr_clear(sip, SIE_SSIE);
@@ -60,7 +62,7 @@ void riscv_software_interrupt(void)
ops = xchg(pending_ipis, 0);
if (ops == 0)
- return;
+ goto done;
if (ops & (1 << IPI_RESCHEDULE))
scheduler_ipi();
@@ -73,6 +75,17 @@ void riscv_software_interrupt(void)
/* Order data access and bit testing. */
mb();
}
+
+done:
+ irq_exit();
+ set_irq_regs(old_regs);
+}
+
+static void (*__smp_ipi_trigger)(const struct cpumask *);
+
+void __init set_smp_ipi_trigger(void (*fn)(const struct cpumask *))
+{
+ __smp_ipi_trigger = fn;
}
static void
@@ -85,7 +98,9 @@ send_ipi_message(const struct cpumask *to_whom, enum
ipi_message_type operation)
[RFC PATCH 3/5] RISC-V: Select useful GENERIC_IRQ kconfig options
This patch selects following GENERIC_IRQ kconfig options: GENERIC_IRQ_MULTI_HANDLER GENERIC_IRQ_PROBE GENERIC_IRQ_SHOW_LEVEL HANDLE_DOMAIN_IRQ Signed-off-by: Anup Patel --- arch/riscv/Kconfig | 4 1 file changed, 4 insertions(+) diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index a344980287a5..026abe3d6cb0 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -22,7 +22,10 @@ config RISCV select DMA_DIRECT_OPS select GENERIC_CLOCKEVENTS select GENERIC_CPU_DEVICES + select GENERIC_IRQ_MULTI_HANDLER + select GENERIC_IRQ_PROBE select GENERIC_IRQ_SHOW + select GENERIC_IRQ_SHOW_LEVEL select GENERIC_PCI_IOMAP select GENERIC_STRNCPY_FROM_USER select GENERIC_STRNLEN_USER @@ -33,6 +36,7 @@ config RISCV select HAVE_DMA_CONTIGUOUS select HAVE_GENERIC_DMA_COHERENT select HAVE_PERF_EVENTS + select HANDLE_DOMAIN_IRQ select IRQ_DOMAIN select NO_BOOTMEM select RISCV_ISA_A if SMP -- 2.17.1
[RFC PATCH 5/5] clocksource: riscv_timer: Make timer interrupt as a per-CPU interrupt
Instead of directly calling RISC-V timer interrupt handler from
RISC-V local interrupt conntroller driver, this patch implements
RISC-V timer interrupt as a per-CPU interrupt using per-CPU APIs
of Linux IRQ subsystem.
Signed-off-by: Anup Patel
---
arch/riscv/include/asm/irq.h | 2 -
drivers/clocksource/riscv_timer.c | 76 +--
drivers/irqchip/irq-riscv-intc.c | 8
3 files changed, 62 insertions(+), 24 deletions(-)
diff --git a/arch/riscv/include/asm/irq.h b/arch/riscv/include/asm/irq.h
index fe503d71876a..7ff3751e7816 100644
--- a/arch/riscv/include/asm/irq.h
+++ b/arch/riscv/include/asm/irq.h
@@ -30,8 +30,6 @@
*/
#define INTERRUPT_CAUSE_FLAG (1UL << (__riscv_xlen - 1))
-void riscv_timer_interrupt(void);
-
#include
#endif /* _ASM_RISCV_IRQ_H */
diff --git a/drivers/clocksource/riscv_timer.c
b/drivers/clocksource/riscv_timer.c
index 4e8b347e43e2..c7ac60a82754 100644
--- a/drivers/clocksource/riscv_timer.c
+++ b/drivers/clocksource/riscv_timer.c
@@ -3,11 +3,17 @@
* Copyright (C) 2012 Regents of the University of California
* Copyright (C) 2017 SiFive
*/
+#define pr_fmt(fmt) "riscv-timer: " fmt
#include
#include
#include
#include
#include
+#include
+#include
+#include
+#include
+#include
#include
/*
@@ -31,6 +37,7 @@ static int riscv_clock_next_event(unsigned long delta,
return 0;
}
+static unsigned int riscv_clock_event_irq;
static DEFINE_PER_CPU(struct clock_event_device, riscv_clock_event) = {
.name = "riscv_timer_clockevent",
.features = CLOCK_EVT_FEAT_ONESHOT,
@@ -38,6 +45,11 @@ static DEFINE_PER_CPU(struct clock_event_device,
riscv_clock_event) = {
.set_next_event = riscv_clock_next_event,
};
+static u64 riscv_sched_clock(void)
+{
+ return get_cycles64();
+}
+
/*
* It is guaranteed that all the timers across all the harts are synchronized
* within one tick of each other, so while this could technically go
@@ -48,7 +60,7 @@ static unsigned long long riscv_clocksource_rdtime(struct
clocksource *cs)
return get_cycles64();
}
-static DEFINE_PER_CPU(struct clocksource, riscv_clocksource) = {
+static struct clocksource riscv_clocksource = {
.name = "riscv_clocksource",
.rating = 300,
.mask = CLOCKSOURCE_MASK(BITS_PER_LONG),
@@ -61,45 +73,81 @@ static int riscv_timer_starting_cpu(unsigned int cpu)
struct clock_event_device *ce = per_cpu_ptr(_clock_event, cpu);
ce->cpumask = cpumask_of(cpu);
+ ce->irq = riscv_clock_event_irq;
clockevents_config_and_register(ce, riscv_timebase, 100, 0x7fff);
- csr_set(sie, SIE_STIE);
+ enable_percpu_irq(riscv_clock_event_irq, IRQ_TYPE_NONE);
return 0;
}
static int riscv_timer_dying_cpu(unsigned int cpu)
{
- csr_clear(sie, SIE_STIE);
+ disable_percpu_irq(riscv_clock_event_irq);
return 0;
}
-/* called directly from the low-level interrupt handler */
-void riscv_timer_interrupt(void)
+static irqreturn_t riscv_timer_interrupt(int irq, void *dev_id)
{
struct clock_event_device *evdev = this_cpu_ptr(_clock_event);
csr_clear(sie, SIE_STIE);
evdev->event_handler(evdev);
+
+ return IRQ_HANDLED;
}
static int __init riscv_timer_init_dt(struct device_node *n)
{
- int cpu_id = riscv_of_processor_hart(n), error;
- struct clocksource *cs;
-
- if (cpu_id != smp_processor_id())
+ int error;
+ struct irq_domain *domain;
+ struct of_phandle_args oirq;
+
+ /*
+* Either we have one INTC DT node under each CPU DT node
+* or a single system wide INTC DT node. Irrespective to
+* number of INTC DT nodes, we only proceed if we are able
+* to find irq_domain of INTC.
+*
+* Once we have INTC irq_domain, we create mapping for timer
+* interrupt HWIRQ and request_percpu_irq() on it.
+*/
+
+ if (riscv_clock_event_irq)
return 0;
- cs = per_cpu_ptr(_clocksource, cpu_id);
- clocksource_register_hz(cs, riscv_timebase);
+ oirq.np = n;
+ oirq.args_count = 1;
+ oirq.args[0] = INTERRUPT_CAUSE_TIMER;
+
+ domain = irq_find_host(oirq.np);
+ if (!domain)
+ return -ENODEV;
+
+ riscv_clock_event_irq = irq_create_of_mapping();
+ if (!riscv_clock_event_irq)
+ return -ENODEV;
+
+ clocksource_register_hz(_clocksource, riscv_timebase);
+ sched_clock_register(riscv_sched_clock,
+BITS_PER_LONG, riscv_timebase);
+
+ error = request_percpu_irq(riscv_clock_event_irq,
+ riscv_timer_interrupt,
+ "riscv_timer", _clock_event);
+ if (error)
+ return error;
error = cpuhp_setup_state(CPUHP_AP_RISCV_TIMER_STARTING,
[RFC PATCH 5/5] clocksource: riscv_timer: Make timer interrupt as a per-CPU interrupt
Instead of directly calling RISC-V timer interrupt handler from
RISC-V local interrupt conntroller driver, this patch implements
RISC-V timer interrupt as a per-CPU interrupt using per-CPU APIs
of Linux IRQ subsystem.
Signed-off-by: Anup Patel
---
arch/riscv/include/asm/irq.h | 2 -
drivers/clocksource/riscv_timer.c | 76 +--
drivers/irqchip/irq-riscv-intc.c | 8
3 files changed, 62 insertions(+), 24 deletions(-)
diff --git a/arch/riscv/include/asm/irq.h b/arch/riscv/include/asm/irq.h
index fe503d71876a..7ff3751e7816 100644
--- a/arch/riscv/include/asm/irq.h
+++ b/arch/riscv/include/asm/irq.h
@@ -30,8 +30,6 @@
*/
#define INTERRUPT_CAUSE_FLAG (1UL << (__riscv_xlen - 1))
-void riscv_timer_interrupt(void);
-
#include
#endif /* _ASM_RISCV_IRQ_H */
diff --git a/drivers/clocksource/riscv_timer.c
b/drivers/clocksource/riscv_timer.c
index 4e8b347e43e2..c7ac60a82754 100644
--- a/drivers/clocksource/riscv_timer.c
+++ b/drivers/clocksource/riscv_timer.c
@@ -3,11 +3,17 @@
* Copyright (C) 2012 Regents of the University of California
* Copyright (C) 2017 SiFive
*/
+#define pr_fmt(fmt) "riscv-timer: " fmt
#include
#include
#include
#include
#include
+#include
+#include
+#include
+#include
+#include
#include
/*
@@ -31,6 +37,7 @@ static int riscv_clock_next_event(unsigned long delta,
return 0;
}
+static unsigned int riscv_clock_event_irq;
static DEFINE_PER_CPU(struct clock_event_device, riscv_clock_event) = {
.name = "riscv_timer_clockevent",
.features = CLOCK_EVT_FEAT_ONESHOT,
@@ -38,6 +45,11 @@ static DEFINE_PER_CPU(struct clock_event_device,
riscv_clock_event) = {
.set_next_event = riscv_clock_next_event,
};
+static u64 riscv_sched_clock(void)
+{
+ return get_cycles64();
+}
+
/*
* It is guaranteed that all the timers across all the harts are synchronized
* within one tick of each other, so while this could technically go
@@ -48,7 +60,7 @@ static unsigned long long riscv_clocksource_rdtime(struct
clocksource *cs)
return get_cycles64();
}
-static DEFINE_PER_CPU(struct clocksource, riscv_clocksource) = {
+static struct clocksource riscv_clocksource = {
.name = "riscv_clocksource",
.rating = 300,
.mask = CLOCKSOURCE_MASK(BITS_PER_LONG),
@@ -61,45 +73,81 @@ static int riscv_timer_starting_cpu(unsigned int cpu)
struct clock_event_device *ce = per_cpu_ptr(_clock_event, cpu);
ce->cpumask = cpumask_of(cpu);
+ ce->irq = riscv_clock_event_irq;
clockevents_config_and_register(ce, riscv_timebase, 100, 0x7fff);
- csr_set(sie, SIE_STIE);
+ enable_percpu_irq(riscv_clock_event_irq, IRQ_TYPE_NONE);
return 0;
}
static int riscv_timer_dying_cpu(unsigned int cpu)
{
- csr_clear(sie, SIE_STIE);
+ disable_percpu_irq(riscv_clock_event_irq);
return 0;
}
-/* called directly from the low-level interrupt handler */
-void riscv_timer_interrupt(void)
+static irqreturn_t riscv_timer_interrupt(int irq, void *dev_id)
{
struct clock_event_device *evdev = this_cpu_ptr(_clock_event);
csr_clear(sie, SIE_STIE);
evdev->event_handler(evdev);
+
+ return IRQ_HANDLED;
}
static int __init riscv_timer_init_dt(struct device_node *n)
{
- int cpu_id = riscv_of_processor_hart(n), error;
- struct clocksource *cs;
-
- if (cpu_id != smp_processor_id())
+ int error;
+ struct irq_domain *domain;
+ struct of_phandle_args oirq;
+
+ /*
+* Either we have one INTC DT node under each CPU DT node
+* or a single system wide INTC DT node. Irrespective to
+* number of INTC DT nodes, we only proceed if we are able
+* to find irq_domain of INTC.
+*
+* Once we have INTC irq_domain, we create mapping for timer
+* interrupt HWIRQ and request_percpu_irq() on it.
+*/
+
+ if (riscv_clock_event_irq)
return 0;
- cs = per_cpu_ptr(_clocksource, cpu_id);
- clocksource_register_hz(cs, riscv_timebase);
+ oirq.np = n;
+ oirq.args_count = 1;
+ oirq.args[0] = INTERRUPT_CAUSE_TIMER;
+
+ domain = irq_find_host(oirq.np);
+ if (!domain)
+ return -ENODEV;
+
+ riscv_clock_event_irq = irq_create_of_mapping();
+ if (!riscv_clock_event_irq)
+ return -ENODEV;
+
+ clocksource_register_hz(_clocksource, riscv_timebase);
+ sched_clock_register(riscv_sched_clock,
+BITS_PER_LONG, riscv_timebase);
+
+ error = request_percpu_irq(riscv_clock_event_irq,
+ riscv_timer_interrupt,
+ "riscv_timer", _clock_event);
+ if (error)
+ return error;
error = cpuhp_setup_state(CPUHP_AP_RISCV_TIMER_STARTING,
Re: [PATCH v2 00/15] soc: octeontx2: Add RVU admin function driver
On Tue, Sep 04, 2018 at 05:24:35PM +0530, sunil.kovv...@gmail.com wrote: > From: Sunil Goutham > > Resource virtualization unit (RVU) on Marvell's OcteonTX2 SOC supports > multiple PCIe SRIOV physical functions (PFs) and virtual functions (VFs). > PF0 is called administrative / admin function (AF) and has privilege access > to registers to provision different RVU functional blocks to each of > PF/VF. Hi Sunil Please keep netdev in the loop. The people with most experience with PF/VF tend to hang out there, not arm-soc. Andrew
Re: [PATCH v2 00/15] soc: octeontx2: Add RVU admin function driver
On Tue, Sep 04, 2018 at 05:24:35PM +0530, sunil.kovv...@gmail.com wrote: > From: Sunil Goutham > > Resource virtualization unit (RVU) on Marvell's OcteonTX2 SOC supports > multiple PCIe SRIOV physical functions (PFs) and virtual functions (VFs). > PF0 is called administrative / admin function (AF) and has privilege access > to registers to provision different RVU functional blocks to each of > PF/VF. Hi Sunil Please keep netdev in the loop. The people with most experience with PF/VF tend to hang out there, not arm-soc. Andrew
Re: [PATCH v5 03/16] x86/mtrr: get MTRR number and support TOP_MEM2
On 2018/9/4 16:02, Borislav Petkov wrote: shows only old mails so I'm going to assume this got fixed, finally! And you probably have received a *fixed* BIOS even, allegedly. So what's up? I tested the function on Hygon Dhyana platforms with the latest BIOS, found that this problem is indeed fixed. So the workaround is not needed for Hygon Dhyana platforms any more, and the vendor checking for Hygon will be removed in next version of patch. Thanks, Pu Wen
Re: [PATCH v5 03/16] x86/mtrr: get MTRR number and support TOP_MEM2
On 2018/9/4 16:02, Borislav Petkov wrote: shows only old mails so I'm going to assume this got fixed, finally! And you probably have received a *fixed* BIOS even, allegedly. So what's up? I tested the function on Hygon Dhyana platforms with the latest BIOS, found that this problem is indeed fixed. So the workaround is not needed for Hygon Dhyana platforms any more, and the vendor checking for Hygon will be removed in next version of patch. Thanks, Pu Wen
Re: [PATCH 0/7] spi: spi-mem: Add a driver for NXP FlexSPI controller
Hi Yogesh, On Fri, 31 Aug 2018 15:59:57 +0530 Yogesh Gaur wrote: > - Add a driver for NXP FlexSPI host controller > > FlexSPI is a flexsible SPI host controller [1], Chapter 30 page 1475, > which supports two SPI channels and up to 4 external devices. > Each channel supports Single/Dual/Quad/Octal mode data transfer (1/2/4/8 > bidirectional data lines) > i.e. FlexSPI acts as an interface to external devices, maximum 4, each with > up to 8 > bidirectional data lines. > > FlexSPI controller is similar to the existing Freescale/NXP QuadSPI > controller with advanced features. > > - Tested this driver with mtd_debug(Erase/Write/Read) utility and JFFS2 > filesystem mounting and booting on NXP LX2160ARDB[2] and LX2160AQDS targets. > LX2160ARDB is having two NOR slave device connected on single bus A > i.e. A0 and A1 (CS0 and CS1). > LX2160AQDS is having two NOR slave device connected on separate buses > one flash on A0 and second on B1 i.e. (CS0 and CS3). > Verified this driver on following SPI NOR flashes: > Micron, mt35xu512aba[3], [Read - 1 bit mode] > Cypress, s25fl512s, [Read - 1/2/4 bit mode] > > Patch 1 adds variable size in spi_device struct, to save the > size of connected slave device. > Patch 2 adds flags for octal I/O data transfer. > Support for octal flash commands and other framework changes would going to > be done in different > patch set. > Patch 3 adds a driver for the NXP FlexSPI controller, driver is based on > new spi-mem framework. Can we please omit octa mode support for now and focus on single/dual/quad SPI support? That is, drop patch 2, and do not set the OCTAL flags in patch 3. Regards, Boris > Patch 4 add binding file for this driver. > Patch 5 add device node property for FlexSPI driver for lx2160 SoC. > Patch 6 enables the config option. > Patch 7 add MAINTAINERS file. > > [1] https://www.nxp.com/docs/en/reference-manual/IMXRT1050RM.pdf > [2] https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=9721 > [3] https://patchwork.ozlabs.org/project/linux-mtd/list/?series=63445 > > This series adds below patches: > Yogesh Gaur (7): > spi: add slave device size in spi_device struct > spi: add flags for octal I/O data transfer > spi: spi-mem: Add a driver for NXP FlexSPI controller > dt-bindings: spi: add binding file for NXP FlexSPI driver > arm64: dts: lx2160a: add fspi node property > arm64: defconfig: enable NXP FlexSPI driver > MAINTAINERS: add maintainers for the NXP FlexSPI driver > > .../devicetree/bindings/spi/spi-nxp-fspi.txt | 42 + > MAINTAINERS|6 + > arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 21 + > arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 12 + > arch/arm64/configs/defconfig |1 + > drivers/mtd/devices/m25p80.c |6 + > drivers/mtd/spi-nor/spi-nor.c |2 + > drivers/spi/Kconfig| 10 + > drivers/spi/Makefile |1 + > drivers/spi/spi-nxp-fspi.c | 1242 > > include/linux/spi/spi.h|4 + > 11 files changed, 1347 insertions(+) > create mode 100644 Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > create mode 100644 drivers/spi/spi-nxp-fspi.c >
Re: [PATCH 0/7] spi: spi-mem: Add a driver for NXP FlexSPI controller
Hi Yogesh, On Fri, 31 Aug 2018 15:59:57 +0530 Yogesh Gaur wrote: > - Add a driver for NXP FlexSPI host controller > > FlexSPI is a flexsible SPI host controller [1], Chapter 30 page 1475, > which supports two SPI channels and up to 4 external devices. > Each channel supports Single/Dual/Quad/Octal mode data transfer (1/2/4/8 > bidirectional data lines) > i.e. FlexSPI acts as an interface to external devices, maximum 4, each with > up to 8 > bidirectional data lines. > > FlexSPI controller is similar to the existing Freescale/NXP QuadSPI > controller with advanced features. > > - Tested this driver with mtd_debug(Erase/Write/Read) utility and JFFS2 > filesystem mounting and booting on NXP LX2160ARDB[2] and LX2160AQDS targets. > LX2160ARDB is having two NOR slave device connected on single bus A > i.e. A0 and A1 (CS0 and CS1). > LX2160AQDS is having two NOR slave device connected on separate buses > one flash on A0 and second on B1 i.e. (CS0 and CS3). > Verified this driver on following SPI NOR flashes: > Micron, mt35xu512aba[3], [Read - 1 bit mode] > Cypress, s25fl512s, [Read - 1/2/4 bit mode] > > Patch 1 adds variable size in spi_device struct, to save the > size of connected slave device. > Patch 2 adds flags for octal I/O data transfer. > Support for octal flash commands and other framework changes would going to > be done in different > patch set. > Patch 3 adds a driver for the NXP FlexSPI controller, driver is based on > new spi-mem framework. Can we please omit octa mode support for now and focus on single/dual/quad SPI support? That is, drop patch 2, and do not set the OCTAL flags in patch 3. Regards, Boris > Patch 4 add binding file for this driver. > Patch 5 add device node property for FlexSPI driver for lx2160 SoC. > Patch 6 enables the config option. > Patch 7 add MAINTAINERS file. > > [1] https://www.nxp.com/docs/en/reference-manual/IMXRT1050RM.pdf > [2] https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=9721 > [3] https://patchwork.ozlabs.org/project/linux-mtd/list/?series=63445 > > This series adds below patches: > Yogesh Gaur (7): > spi: add slave device size in spi_device struct > spi: add flags for octal I/O data transfer > spi: spi-mem: Add a driver for NXP FlexSPI controller > dt-bindings: spi: add binding file for NXP FlexSPI driver > arm64: dts: lx2160a: add fspi node property > arm64: defconfig: enable NXP FlexSPI driver > MAINTAINERS: add maintainers for the NXP FlexSPI driver > > .../devicetree/bindings/spi/spi-nxp-fspi.txt | 42 + > MAINTAINERS|6 + > arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 21 + > arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 12 + > arch/arm64/configs/defconfig |1 + > drivers/mtd/devices/m25p80.c |6 + > drivers/mtd/spi-nor/spi-nor.c |2 + > drivers/spi/Kconfig| 10 + > drivers/spi/Makefile |1 + > drivers/spi/spi-nxp-fspi.c | 1242 > > include/linux/spi/spi.h|4 + > 11 files changed, 1347 insertions(+) > create mode 100644 Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > create mode 100644 drivers/spi/spi-nxp-fspi.c >
