* [PATCH v2 3/3] dt-bindings: i2c: pxa: Update the documentation for the Armada 3700
From: Romain Perier @ 2016-11-09 8:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109081431.10115-1-romain.perier@free-electrons.com>
This commit documents the compatible string to have the compatibility for
the I2C unit found in the Armada 3700.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
Changes in v2:
- Fixed wrong compatible string, it should be "marvell,armada-3700-i2c"
and not "marvell,armada-3700".
Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
index 12b78ac..d30f0b1 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
@@ -7,6 +7,7 @@ Required properties :
compatible processor, e.g. pxa168, pxa910, mmp2, mmp3.
For the pxa2xx/pxa3xx, an additional node "mrvl,pxa-i2c" is required
as shown in the example below.
+ For the Armada 3700, the compatible should be "marvell,armada-3700-i2c".
Recommended properties :
--
2.9.3
^ permalink raw reply related
* [PATCH v2 3/3] dt-bindings: i2c: pxa: Update the documentation for the Armada 3700
From: Romain Perier @ 2016-11-09 8:14 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Nadav Haklai, Omri Itach, Shadi Ammouri,
Yahuda Yitschak, Hanna Hawa, Neta Zur Hershkovits, Igal Liberman,
Marcin Wojtas <mw>
In-Reply-To: <20161109081431.10115-1-romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
This commit documents the compatible string to have the compatibility for
the I2C unit found in the Armada 3700.
Signed-off-by: Romain Perier <romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
Changes in v2:
- Fixed wrong compatible string, it should be "marvell,armada-3700-i2c"
and not "marvell,armada-3700".
Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
index 12b78ac..d30f0b1 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
@@ -7,6 +7,7 @@ Required properties :
compatible processor, e.g. pxa168, pxa910, mmp2, mmp3.
For the pxa2xx/pxa3xx, an additional node "mrvl,pxa-i2c" is required
as shown in the example below.
+ For the Armada 3700, the compatible should be "marvell,armada-3700-i2c".
Recommended properties :
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 2/3] arm64: dts: marvell: Add I2C definitions for the Armada 3700
From: Romain Perier @ 2016-11-09 8:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109081431.10115-1-romain.perier@free-electrons.com>
The Armada 3700 has two i2c bus interface units, this commit adds the
definitions of the corresponding device nodes. It also enables the node
on the development board for this SoC.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm64/boot/dts/marvell/armada-3720-db.dts | 4 ++++
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 18 ++++++++++++++++++
2 files changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-db.dts b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
index 1372e9a6..16d84af 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
@@ -62,6 +62,10 @@
};
};
+&i2c0 {
+ status = "okay";
+};
+
/* CON3 */
&sata {
status = "okay";
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index c476253..bf2d73d 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -98,6 +98,24 @@
/* 32M internal register @ 0xd000_0000 */
ranges = <0x0 0x0 0xd0000000 0x2000000>;
+ i2c0: i2c at 11000 {
+ compatible = "marvell,armada-3700-i2c";
+ reg = <0x11000 0x24>;
+ clocks = <&nb_perih_clk 10>;
+ interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+ mrvl,i2c-fast-mode;
+ status = "disabled";
+ };
+
+ i2c1: i2c at 11080 {
+ compatible = "marvell,armada-3700-i2c";
+ reg = <0x11080 0x24>;
+ clocks = <&nb_perih_clk 9>;
+ interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+ mrvl,i2c-fast-mode;
+ status = "disabled";
+ };
+
uart0: serial at 12000 {
compatible = "marvell,armada-3700-uart";
reg = <0x12000 0x400>;
--
2.9.3
^ permalink raw reply related
* [PATCH v2 2/3] arm64: dts: marvell: Add I2C definitions for the Armada 3700
From: Romain Perier @ 2016-11-09 8:14 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Nadav Haklai, Omri Itach, Shadi Ammouri,
Yahuda Yitschak, Hanna Hawa, Neta Zur Hershkovits, Igal Liberman,
Marcin Wojtas <mw>
In-Reply-To: <20161109081431.10115-1-romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
The Armada 3700 has two i2c bus interface units, this commit adds the
definitions of the corresponding device nodes. It also enables the node
on the development board for this SoC.
Signed-off-by: Romain Perier <romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
arch/arm64/boot/dts/marvell/armada-3720-db.dts | 4 ++++
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 18 ++++++++++++++++++
2 files changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-db.dts b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
index 1372e9a6..16d84af 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
@@ -62,6 +62,10 @@
};
};
+&i2c0 {
+ status = "okay";
+};
+
/* CON3 */
&sata {
status = "okay";
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index c476253..bf2d73d 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -98,6 +98,24 @@
/* 32M internal register @ 0xd000_0000 */
ranges = <0x0 0x0 0xd0000000 0x2000000>;
+ i2c0: i2c@11000 {
+ compatible = "marvell,armada-3700-i2c";
+ reg = <0x11000 0x24>;
+ clocks = <&nb_perih_clk 10>;
+ interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+ mrvl,i2c-fast-mode;
+ status = "disabled";
+ };
+
+ i2c1: i2c@11080 {
+ compatible = "marvell,armada-3700-i2c";
+ reg = <0x11080 0x24>;
+ clocks = <&nb_perih_clk 9>;
+ interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+ mrvl,i2c-fast-mode;
+ status = "disabled";
+ };
+
uart0: serial@12000 {
compatible = "marvell,armada-3700-uart";
reg = <0x12000 0x400>;
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 1/3] i2c: pxa: Add support for the I2C units found in Armada 3700
From: Romain Perier @ 2016-11-09 8:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109081431.10115-1-romain.perier@free-electrons.com>
The Armada 3700 has two I2C controllers that is compliant with the I2C
Bus Specificiation 2.1, supports multi-master and different bus speed:
Standard mode (up to 100 KHz), Fast mode (up to 400 KHz),
High speed mode (up to 3.4 Mhz).
This IP block has a lot of similarity with the PXA, except some register
offsets and bitfield. This commits adds a basic support for this I2C
unit.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/i2c/busses/Kconfig | 2 +-
drivers/i2c/busses/i2c-pxa.c | 25 +++++++++++++++++++++++--
2 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index d252276..2f56a26 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -763,7 +763,7 @@ config I2C_PUV3
config I2C_PXA
tristate "Intel PXA2XX I2C adapter"
- depends on ARCH_PXA || ARCH_MMP || (X86_32 && PCI && OF)
+ depends on ARCH_PXA || ARCH_MMP || ARCH_MVEBU || (X86_32 && PCI && OF)
help
If you have devices in the PXA I2C bus, say yes to this option.
This driver can also be built as a module. If so, the module
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index e28b825..34ea830 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -55,6 +55,7 @@ enum pxa_i2c_types {
REGS_PXA3XX,
REGS_CE4100,
REGS_PXA910,
+ REGS_A3700,
};
/*
@@ -91,6 +92,13 @@ static struct pxa_reg_layout pxa_reg_layout[] = {
.ilcr = 0x28,
.iwcr = 0x30,
},
+ [REGS_A3700] = {
+ .ibmr = 0x00,
+ .idbr = 0x04,
+ .icr = 0x08,
+ .isr = 0x0c,
+ .isar = 0x10,
+ },
};
static const struct platform_device_id i2c_pxa_id_table[] = {
@@ -98,6 +106,7 @@ static const struct platform_device_id i2c_pxa_id_table[] = {
{ "pxa3xx-pwri2c", REGS_PXA3XX },
{ "ce4100-i2c", REGS_CE4100 },
{ "pxa910-i2c", REGS_PXA910 },
+ { "armada-3700-i2c", REGS_A3700 },
{ },
};
MODULE_DEVICE_TABLE(platform, i2c_pxa_id_table);
@@ -122,7 +131,9 @@ MODULE_DEVICE_TABLE(platform, i2c_pxa_id_table);
#define ICR_SADIE (1 << 13) /* slave address detected int enable */
#define ICR_UR (1 << 14) /* unit reset */
#define ICR_FM (1 << 15) /* fast mode */
+#define ICR_BUSMODE_FM (1 << 16) /* shifted fast mode for armada-3700 */
#define ICR_HS (1 << 16) /* High Speed mode */
+#define ICR_BUSMODE_HS (1 << 17) /* shifted high speed mode for armada-3700 */
#define ICR_GPIOEN (1 << 19) /* enable GPIO mode for SCL in HS */
#define ISR_RWM (1 << 0) /* read/write mode */
@@ -193,6 +204,8 @@ struct pxa_i2c {
unsigned char master_code;
unsigned long rate;
bool highmode_enter;
+ unsigned long fm_mask;
+ unsigned long hs_mask;
};
#define _IBMR(i2c) ((i2c)->reg_ibmr)
@@ -503,8 +516,8 @@ static void i2c_pxa_reset(struct pxa_i2c *i2c)
writel(i2c->slave_addr, _ISAR(i2c));
/* set control register values */
- writel(I2C_ICR_INIT | (i2c->fast_mode ? ICR_FM : 0), _ICR(i2c));
- writel(readl(_ICR(i2c)) | (i2c->high_mode ? ICR_HS : 0), _ICR(i2c));
+ writel(I2C_ICR_INIT | (i2c->fast_mode ? i2c->fm_mask : 0), _ICR(i2c));
+ writel(readl(_ICR(i2c)) | (i2c->high_mode ? i2c->hs_mask : 0), _ICR(i2c));
#ifdef CONFIG_I2C_PXA_SLAVE
dev_info(&i2c->adap.dev, "Enabling slave mode\n");
@@ -1137,6 +1150,7 @@ static const struct of_device_id i2c_pxa_dt_ids[] = {
{ .compatible = "mrvl,pxa-i2c", .data = (void *)REGS_PXA2XX },
{ .compatible = "mrvl,pwri2c", .data = (void *)REGS_PXA3XX },
{ .compatible = "mrvl,mmp-twsi", .data = (void *)REGS_PXA910 },
+ { .compatible = "marvell,armada-3700-i2c", .data = (void *)REGS_A3700 },
{}
};
MODULE_DEVICE_TABLE(of, i2c_pxa_dt_ids);
@@ -1158,6 +1172,13 @@ static int i2c_pxa_probe_dt(struct platform_device *pdev, struct pxa_i2c *i2c,
i2c->use_pio = 1;
if (of_get_property(np, "mrvl,i2c-fast-mode", NULL))
i2c->fast_mode = 1;
+ if (of_device_is_compatible(np, "marvell,armada-3700-i2c")) {
+ i2c->fm_mask = ICR_BUSMODE_FM;
+ i2c->hs_mask = ICR_BUSMODE_HS;
+ } else {
+ i2c->fm_mask = ICR_FM;
+ i2c->hs_mask = ICR_HS;
+ }
*i2c_types = (enum pxa_i2c_types)(of_id->data);
--
2.9.3
^ permalink raw reply related
* [PATCH v2 1/3] i2c: pxa: Add support for the I2C units found in Armada 3700
From: Romain Perier @ 2016-11-09 8:14 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Nadav Haklai, Omri Itach, Shadi Ammouri,
Yahuda Yitschak, Hanna Hawa, Neta Zur Hershkovits, Igal Liberman,
Marcin Wojtas <mw>
In-Reply-To: <20161109081431.10115-1-romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
The Armada 3700 has two I2C controllers that is compliant with the I2C
Bus Specificiation 2.1, supports multi-master and different bus speed:
Standard mode (up to 100 KHz), Fast mode (up to 400 KHz),
High speed mode (up to 3.4 Mhz).
This IP block has a lot of similarity with the PXA, except some register
offsets and bitfield. This commits adds a basic support for this I2C
unit.
Signed-off-by: Romain Perier <romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Tested-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
drivers/i2c/busses/Kconfig | 2 +-
drivers/i2c/busses/i2c-pxa.c | 25 +++++++++++++++++++++++--
2 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index d252276..2f56a26 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -763,7 +763,7 @@ config I2C_PUV3
config I2C_PXA
tristate "Intel PXA2XX I2C adapter"
- depends on ARCH_PXA || ARCH_MMP || (X86_32 && PCI && OF)
+ depends on ARCH_PXA || ARCH_MMP || ARCH_MVEBU || (X86_32 && PCI && OF)
help
If you have devices in the PXA I2C bus, say yes to this option.
This driver can also be built as a module. If so, the module
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index e28b825..34ea830 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -55,6 +55,7 @@ enum pxa_i2c_types {
REGS_PXA3XX,
REGS_CE4100,
REGS_PXA910,
+ REGS_A3700,
};
/*
@@ -91,6 +92,13 @@ static struct pxa_reg_layout pxa_reg_layout[] = {
.ilcr = 0x28,
.iwcr = 0x30,
},
+ [REGS_A3700] = {
+ .ibmr = 0x00,
+ .idbr = 0x04,
+ .icr = 0x08,
+ .isr = 0x0c,
+ .isar = 0x10,
+ },
};
static const struct platform_device_id i2c_pxa_id_table[] = {
@@ -98,6 +106,7 @@ static const struct platform_device_id i2c_pxa_id_table[] = {
{ "pxa3xx-pwri2c", REGS_PXA3XX },
{ "ce4100-i2c", REGS_CE4100 },
{ "pxa910-i2c", REGS_PXA910 },
+ { "armada-3700-i2c", REGS_A3700 },
{ },
};
MODULE_DEVICE_TABLE(platform, i2c_pxa_id_table);
@@ -122,7 +131,9 @@ MODULE_DEVICE_TABLE(platform, i2c_pxa_id_table);
#define ICR_SADIE (1 << 13) /* slave address detected int enable */
#define ICR_UR (1 << 14) /* unit reset */
#define ICR_FM (1 << 15) /* fast mode */
+#define ICR_BUSMODE_FM (1 << 16) /* shifted fast mode for armada-3700 */
#define ICR_HS (1 << 16) /* High Speed mode */
+#define ICR_BUSMODE_HS (1 << 17) /* shifted high speed mode for armada-3700 */
#define ICR_GPIOEN (1 << 19) /* enable GPIO mode for SCL in HS */
#define ISR_RWM (1 << 0) /* read/write mode */
@@ -193,6 +204,8 @@ struct pxa_i2c {
unsigned char master_code;
unsigned long rate;
bool highmode_enter;
+ unsigned long fm_mask;
+ unsigned long hs_mask;
};
#define _IBMR(i2c) ((i2c)->reg_ibmr)
@@ -503,8 +516,8 @@ static void i2c_pxa_reset(struct pxa_i2c *i2c)
writel(i2c->slave_addr, _ISAR(i2c));
/* set control register values */
- writel(I2C_ICR_INIT | (i2c->fast_mode ? ICR_FM : 0), _ICR(i2c));
- writel(readl(_ICR(i2c)) | (i2c->high_mode ? ICR_HS : 0), _ICR(i2c));
+ writel(I2C_ICR_INIT | (i2c->fast_mode ? i2c->fm_mask : 0), _ICR(i2c));
+ writel(readl(_ICR(i2c)) | (i2c->high_mode ? i2c->hs_mask : 0), _ICR(i2c));
#ifdef CONFIG_I2C_PXA_SLAVE
dev_info(&i2c->adap.dev, "Enabling slave mode\n");
@@ -1137,6 +1150,7 @@ static const struct of_device_id i2c_pxa_dt_ids[] = {
{ .compatible = "mrvl,pxa-i2c", .data = (void *)REGS_PXA2XX },
{ .compatible = "mrvl,pwri2c", .data = (void *)REGS_PXA3XX },
{ .compatible = "mrvl,mmp-twsi", .data = (void *)REGS_PXA910 },
+ { .compatible = "marvell,armada-3700-i2c", .data = (void *)REGS_A3700 },
{}
};
MODULE_DEVICE_TABLE(of, i2c_pxa_dt_ids);
@@ -1158,6 +1172,13 @@ static int i2c_pxa_probe_dt(struct platform_device *pdev, struct pxa_i2c *i2c,
i2c->use_pio = 1;
if (of_get_property(np, "mrvl,i2c-fast-mode", NULL))
i2c->fast_mode = 1;
+ if (of_device_is_compatible(np, "marvell,armada-3700-i2c")) {
+ i2c->fm_mask = ICR_BUSMODE_FM;
+ i2c->hs_mask = ICR_BUSMODE_HS;
+ } else {
+ i2c->fm_mask = ICR_FM;
+ i2c->hs_mask = ICR_HS;
+ }
*i2c_types = (enum pxa_i2c_types)(of_id->data);
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 0/3] Add basic support for the I2C units of the Armada 3700
From: Romain Perier @ 2016-11-09 8:14 UTC (permalink / raw)
To: linux-arm-kernel
This series add basic support for the I2C bus interface units present
in the Armada 3700 to the pxa-i2c driver. It also add the definitions of
the device nodes to the devicetree at the SoC level and for its official
development board: the Armada 3720 DB.
Romain Perier (3):
i2c: pxa: Add support for the I2C units found in Armada 3700
arm64: dts: marvell: Add I2C definitions for the Armada 3700
dt-bindings: i2c: pxa: Update the documentation for the Armada 3700
Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 1 +
arch/arm64/boot/dts/marvell/armada-3720-db.dts | 4 ++++
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 18 ++++++++++++++++
drivers/i2c/busses/Kconfig | 2 +-
drivers/i2c/busses/i2c-pxa.c | 25 +++++++++++++++++++++--
5 files changed, 47 insertions(+), 3 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH v2 0/3] Add basic support for the I2C units of the Armada 3700
From: Romain Perier @ 2016-11-09 8:14 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Nadav Haklai, Omri Itach, Shadi Ammouri,
Yahuda Yitschak, Hanna Hawa, Neta Zur Hershkovits, Igal Liberman,
Marcin Wojtas <mw>
This series add basic support for the I2C bus interface units present
in the Armada 3700 to the pxa-i2c driver. It also add the definitions of
the device nodes to the devicetree at the SoC level and for its official
development board: the Armada 3720 DB.
Romain Perier (3):
i2c: pxa: Add support for the I2C units found in Armada 3700
arm64: dts: marvell: Add I2C definitions for the Armada 3700
dt-bindings: i2c: pxa: Update the documentation for the Armada 3700
Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 1 +
arch/arm64/boot/dts/marvell/armada-3720-db.dts | 4 ++++
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 18 ++++++++++++++++
drivers/i2c/busses/Kconfig | 2 +-
drivers/i2c/busses/i2c-pxa.c | 25 +++++++++++++++++++++--
5 files changed, 47 insertions(+), 3 deletions(-)
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] gpio: davinci: Use unique labels for each gpio chip
From: Linus Walleij @ 2016-11-09 8:14 UTC (permalink / raw)
To: Axel Haslam
Cc: Alexandre Courbot, Nori, Sekhar, Kevin Hilman, David Lechner,
Grygorii Strashko, keerthy, linux-gpio@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20161103113410.2163-1-ahaslam@baylibre.com>
On Thu, Nov 3, 2016 at 12:34 PM, Axel Haslam <ahaslam@baylibre.com> wrote:
> The gpiod framework uses the chip label to match a specific chip.
> The davinci gpio driver, creates several chips using always the same
> label, which is not compatible with gpiod.
>
> To allow platform data to declare gpio lookup tables, and for drivers
> to use the gpiod framework, allocate unique label per registered chip.
>
> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
Patch applied with the ACKs.
Yours,
Linus Walleij
^ permalink raw reply
* FAILED: patch "[PATCH] drm/imx: ipuv3-plane: Skip setting u/vbo only when we don't" failed to apply to 4.8-stable tree
From: gregkh @ 2016-11-09 8:14 UTC (permalink / raw)
To: gnuiyl, p.zabel; +Cc: stable
The patch below does not apply to the 4.8-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 81d553545a1510ff7c7c00cbc9b57d6172d411a4 Mon Sep 17 00:00:00 2001
From: Liu Ying <gnuiyl@gmail.com>
Date: Mon, 10 Oct 2016 14:50:07 +0800
Subject: [PATCH] drm/imx: ipuv3-plane: Skip setting u/vbo only when we don't
need modeset
We added active plane reconfiguration support by forcing a full modeset
operation. So, looking at old_plane_state->fb to determine whether we need
to set u/v offset(aka, u/vbo for IPUv3) in ipu_plane_atomic_set_base()
or not is no more correct. Instead, we should do that only when we don't
need modeset.
Fixes: c6c1f9bc798b ("drm/imx: Add active plane reconfiguration support")
Cc: stable@vger.kernel.org # 4.8
Signed-off-by: Liu Ying <gnuiyl@gmail.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c b/drivers/gpu/drm/imx/ipuv3-plane.c
index f5861d9b0df7..cfb34b595d15 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -103,8 +103,7 @@ drm_plane_state_to_vbo(struct drm_plane_state *state)
(state->src_x >> 16) / 2 - eba;
}
-static void ipu_plane_atomic_set_base(struct ipu_plane *ipu_plane,
- struct drm_plane_state *old_state)
+static void ipu_plane_atomic_set_base(struct ipu_plane *ipu_plane)
{
struct drm_plane *plane = &ipu_plane->base;
struct drm_plane_state *state = plane->state;
@@ -118,7 +117,7 @@ static void ipu_plane_atomic_set_base(struct ipu_plane *ipu_plane,
switch (fb->pixel_format) {
case DRM_FORMAT_YUV420:
case DRM_FORMAT_YVU420:
- if (old_state->fb)
+ if (!drm_atomic_crtc_needs_modeset(crtc_state))
break;
/*
@@ -393,7 +392,7 @@ static void ipu_plane_atomic_update(struct drm_plane *plane,
struct drm_crtc_state *crtc_state = state->crtc->state;
if (!drm_atomic_crtc_needs_modeset(crtc_state)) {
- ipu_plane_atomic_set_base(ipu_plane, old_state);
+ ipu_plane_atomic_set_base(ipu_plane);
return;
}
}
@@ -438,7 +437,7 @@ static void ipu_plane_atomic_update(struct drm_plane *plane,
ipu_cpmem_set_high_priority(ipu_plane->ipu_ch);
ipu_idmac_set_double_buffer(ipu_plane->ipu_ch, 1);
ipu_cpmem_set_stride(ipu_plane->ipu_ch, state->fb->pitches[0]);
- ipu_plane_atomic_set_base(ipu_plane, old_state);
+ ipu_plane_atomic_set_base(ipu_plane);
ipu_plane_enable(ipu_plane);
}
^ permalink raw reply related
* Re: [PATCH] net/ixgbe: fix link never come up problem with x552
From: Lu, Wenzhuo @ 2016-11-09 8:14 UTC (permalink / raw)
To: Zhao1, Wei, dev@dpdk.org; +Cc: Zhao1, Wei
In-Reply-To: <1478674828-41011-1-git-send-email-wei.zhao1@intel.com>
Hi,
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wei Zhao
> Sent: Wednesday, November 9, 2016 3:00 PM
> To: dev@dpdk.org
> Cc: Zhao1, Wei
> Subject: [dpdk-dev] [PATCH] net/ixgbe: fix link never come up problem with x552
>
> From: zhao wei <wei.zhao1@intel.com>
>
> The links never coming up with DPDK16.11 when bring up x552 NIC, device id is
> 15ac.This is caused by delete some code which casing removes X550em SFP iXFI
> setup for the drivers in function ixgbe_setup_mac_link_sfp_x550em().Fix
> methord is recover the deleted code.
>
> Fixes: 1726b9cd9c40 ("net/ixgbe/base: remove X550em SFP iXFI setup")
>
> Signed-off-by: zhao wei <wei.zhao1@intel.com>
Acked-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
Thanks for the patch. It's a critical issue. We need to fix it. I'll report it to our kernel driver developers.
^ permalink raw reply
* [PATCH] ARM: integrator: drop EBI access use syscon
From: Linus Walleij @ 2016-11-09 8:12 UTC (permalink / raw)
To: linux-arm-kernel
The EBI lookup is not longer in use: this has been moved to the
NAND chip driver. The syscon node is better accessed indirectly
using the regmap like the NAND chip driver does, so let's use
the syscon to set the modem control signals RTS/CTS through the
dedicated syscon register.
We also migrate the decoder status "SC_DEC" register that
enumerate the logic modules using syscon.
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ARM SoC folks: please apply this patch directly to the tree
wherever it fits. I do not plan to send more Integrator patches
this merge window.
---
arch/arm/mach-integrator/integrator_ap.c | 54 ++++++++++++++++++--------------
1 file changed, 30 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-integrator/integrator_ap.c b/arch/arm/mach-integrator/integrator_ap.c
index 23b98fd414bf..a1af634f8709 100644
--- a/arch/arm/mach-integrator/integrator_ap.c
+++ b/arch/arm/mach-integrator/integrator_ap.c
@@ -27,6 +27,8 @@
#include <linux/of_address.h>
#include <linux/of_platform.h>
#include <linux/termios.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
#include <asm/mach/arch.h>
#include <asm/mach/map.h>
@@ -37,11 +39,8 @@
#include "pci_v3.h"
#include "lm.h"
-/* Base address to the AP system controller */
-void __iomem *ap_syscon_base;
-/* Base address to the external bus interface */
-static void __iomem *ebi_base;
-
+/* Regmap to the AP system controller */
+static struct regmap *ap_syscon_map;
/*
* All IO addresses are mapped onto VA 0xFFFx.xxxx, where x.xxxx
@@ -125,6 +124,7 @@ static void integrator_uart_set_mctrl(struct amba_device *dev,
{
unsigned int ctrls = 0, ctrlc = 0, rts_mask, dtr_mask;
u32 phybase = dev->res.start;
+ int ret;
if (phybase == INTEGRATOR_UART0_BASE) {
/* UART0 */
@@ -146,8 +146,17 @@ static void integrator_uart_set_mctrl(struct amba_device *dev,
else
ctrls |= dtr_mask;
- __raw_writel(ctrls, ap_syscon_base + INTEGRATOR_SC_CTRLS_OFFSET);
- __raw_writel(ctrlc, ap_syscon_base + INTEGRATOR_SC_CTRLC_OFFSET);
+ ret = regmap_write(ap_syscon_map,
+ INTEGRATOR_SC_CTRLS_OFFSET,
+ ctrls);
+ if (ret)
+ pr_err("MODEM: unable to write PL010 UART CTRLS\n");
+
+ ret = regmap_write(ap_syscon_map,
+ INTEGRATOR_SC_CTRLC_OFFSET,
+ ctrlc);
+ if (ret)
+ pr_err("MODEM: unable to write PL010 UART CRTLC\n");
}
struct amba_pl010_data ap_uart_data = {
@@ -178,35 +187,32 @@ static const struct of_device_id ap_syscon_match[] = {
{ },
};
-static const struct of_device_id ebi_match[] = {
- { .compatible = "arm,external-bus-interface"},
- { },
-};
-
static void __init ap_init_of(void)
{
- unsigned long sc_dec;
+ u32 sc_dec;
struct device_node *syscon;
- struct device_node *ebi;
+ int ret;
int i;
+ of_platform_default_populate(NULL, ap_auxdata_lookup, NULL);
+
syscon = of_find_matching_node(NULL, ap_syscon_match);
if (!syscon)
return;
- ebi = of_find_matching_node(NULL, ebi_match);
- if (!ebi)
+ ap_syscon_map = syscon_node_to_regmap(syscon);
+ if (IS_ERR(ap_syscon_map)) {
+ pr_crit("could not find Integrator/AP system controller\n");
return;
+ }
- ap_syscon_base = of_iomap(syscon, 0);
- if (!ap_syscon_base)
- return;
- ebi_base = of_iomap(ebi, 0);
- if (!ebi_base)
+ ret = regmap_read(ap_syscon_map,
+ INTEGRATOR_SC_DEC_OFFSET,
+ &sc_dec);
+ if (ret) {
+ pr_crit("could not read from Integrator/AP syscon\n");
return;
+ }
- of_platform_default_populate(NULL, ap_auxdata_lookup, NULL);
-
- sc_dec = readl(ap_syscon_base + INTEGRATOR_SC_DEC_OFFSET);
for (i = 0; i < 4; i++) {
struct lm_device *lmdev;
--
2.7.4
^ permalink raw reply related
* FAILED: patch "[PATCH] md: be careful not lot leak internal curr_resync value into" failed to apply to 4.4-stable tree
From: gregkh @ 2016-11-09 8:12 UTC (permalink / raw)
To: neilb, shli, viswesh.vichu; +Cc: stable
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 1217e1d1999ed6c9c1e1b1acae0a74ab70464ae2 Mon Sep 17 00:00:00 2001
From: NeilBrown <neilb@suse.com>
Date: Fri, 28 Oct 2016 15:59:41 +1100
Subject: [PATCH] md: be careful not lot leak internal curr_resync value into
metadata. -- (all)
mddev->curr_resync usually records where the current resync is up to,
but during the starting phase it has some "magic" values.
1 - means that the array is trying to start a resync, but has yielded
to another array which shares physical devices, and also needs to
start a resync
2 - means the array is trying to start resync, but has found another
array which shares physical devices and has already started resync.
3 - means that resync has commensed, but it is possible that nothing
has actually been resynced yet.
It is important that this value not be visible to user-space and
particularly that it doesn't get written to the metadata, as the
resync or recovery checkpoint. In part, this is because it may be
slightly higher than the correct value, though this is very rare.
In part, because it is not a multiple of 4K, and some devices only
support 4K aligned accesses.
There are two places where this value is propagates into either
->curr_resync_completed or ->recovery_cp or ->recovery_offset.
These currently avoid the propagation of values 1 and 3, but will
allow 3 to leak through.
Change them to only propagate the value if it is > 3.
As this can cause an array to fail, the patch is suitable for -stable.
Cc: stable@vger.kernel.org (v3.7+)
Reported-by: Viswesh <viswesh.vichu@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 25b57a55db1a..2089d46b0eb8 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -8144,14 +8144,14 @@ void md_do_sync(struct md_thread *thread)
if (!test_bit(MD_RECOVERY_RESHAPE, &mddev->recovery) &&
!test_bit(MD_RECOVERY_INTR, &mddev->recovery) &&
- mddev->curr_resync > 2) {
+ mddev->curr_resync > 3) {
mddev->curr_resync_completed = mddev->curr_resync;
sysfs_notify(&mddev->kobj, NULL, "sync_completed");
}
mddev->pers->sync_request(mddev, max_sectors, &skipped);
if (!test_bit(MD_RECOVERY_CHECK, &mddev->recovery) &&
- mddev->curr_resync > 2) {
+ mddev->curr_resync > 3) {
if (test_bit(MD_RECOVERY_SYNC, &mddev->recovery)) {
if (test_bit(MD_RECOVERY_INTR, &mddev->recovery)) {
if (mddev->curr_resync >= mddev->recovery_cp) {
^ permalink raw reply related
* FAILED: patch "[PATCH] RAID1: ignore discard error" failed to apply to 4.4-stable tree
From: gregkh @ 2016-11-09 8:11 UTC (permalink / raw)
To: shli, sitsofe; +Cc: stable
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From e3f948cd3283e4fbe5907f1f3967c839912f480e Mon Sep 17 00:00:00 2001
From: Shaohua Li <shli@fb.com>
Date: Thu, 6 Oct 2016 14:09:16 -0700
Subject: [PATCH] RAID1: ignore discard error
If a write error occurs, raid1 will try to rewrite the bio in small
chunk size. If the rewrite fails, raid1 will record the error in bad
block. narrow_write_error will always use WRITE for the bio, but
actually it could be a discard. Since discard bio hasn't payload, write
the bio will cause different issues. But discard error isn't fatal, we
can safely ignore it. This is what this patch does.
This issue should exist since discard is added, but only exposed with
recent arbitrary bio size feature.
Reported-and-tested-by: Sitsofe Wheeler <sitsofe@gmail.com>
Cc: stable@vger.kernel.org (v3.6)
Signed-off-by: Shaohua Li <shli@fb.com>
diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index 1961d827dbd1..db536a68b2ee 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -403,11 +403,14 @@ static void raid1_end_write_request(struct bio *bio)
struct bio *to_put = NULL;
int mirror = find_bio_disk(r1_bio, bio);
struct md_rdev *rdev = conf->mirrors[mirror].rdev;
+ bool discard_error;
+
+ discard_error = bio->bi_error && bio_op(bio) == REQ_OP_DISCARD;
/*
* 'one mirror IO has finished' event handler:
*/
- if (bio->bi_error) {
+ if (bio->bi_error && !discard_error) {
set_bit(WriteErrorSeen, &rdev->flags);
if (!test_and_set_bit(WantReplacement, &rdev->flags))
set_bit(MD_RECOVERY_NEEDED, &
@@ -444,7 +447,7 @@ static void raid1_end_write_request(struct bio *bio)
/* Maybe we can clear some bad blocks. */
if (is_badblock(rdev, r1_bio->sector, r1_bio->sectors,
- &first_bad, &bad_sectors)) {
+ &first_bad, &bad_sectors) && !discard_error) {
r1_bio->bios[mirror] = IO_MADE_GOOD;
set_bit(R1BIO_MadeGood, &r1_bio->state);
}
^ permalink raw reply related
* Re: [PATCH] wireless: fix bogus maybe-uninitialized warning
From: Johannes Berg @ 2016-11-09 8:10 UTC (permalink / raw)
To: Kalle Valo, Arnd Bergmann
Cc: Stanislav Yakovlev, Jouni Malinen, David S. Miller,
linux-wireless, netdev, linux-kernel
In-Reply-To: <87mvh9qwhi.fsf@purkki.adurom.net>
> Ideally we prefer that drivers/net/wireless and net/wireless changes
> are
> split into different patches as they get applied to different trees.
> Johannes, is it ok if I take this change through my tree this time?
Sure, please do, thanks.
(I don't particularly care about the lib80211 stuff anyway)
johannes
^ permalink raw reply
* [GIT PULL] Integrator DTS and defconfig changes
From: Linus Walleij @ 2016-11-09 8:10 UTC (permalink / raw)
To: linux-arm-kernel
Hi ARM SoC folks,
this adds DT-based cpufreq to the Integrator family.
The corresponding cpufreq changes are merged by Rafael to the
cpufreq tree, and can go in orthogonally.
However I have included the defconfig change turning on the feature
here as it makes all kind of logic sense to have these three patches
in succession: addin the DTS nodes and then turning on the DT
cpufreq.
If you insist, of course I can send the defconfig patch separately.
I just think it makes more sense like this.
Please pull it in so we get some rotation in linux-next for this!
Yours,
Linus Walleij
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git
tags/armsoc-integrator-dts
for you to fetch changes up to 023c8faf9bbc95b2d00768414f0f73076ca06dc9:
ARM: defconfig: turn on the DT cpufreq for Integrator (2016-11-09
09:02:46 +0100)
----------------------------------------------------------------
This contains the DTS changes enabling DT-only cpufreq
scaling on the Integrator family.
----------------------------------------------------------------
Linus Walleij (3):
ARM: dts: Add Integrator/AP cpus node and operating points
ARM: dts: Add Integrator/CP cpus node and operating points
ARM: defconfig: turn on the DT cpufreq for Integrator
arch/arm/boot/dts/integratorap.dts | 35 +++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/integratorcp.dts | 26 ++++++++++++++++++++++++++
arch/arm/configs/integrator_defconfig | 1 +
3 files changed, 62 insertions(+)
^ permalink raw reply
* [GIT PULL] Integrator DTS and defconfig changes
From: Linus Walleij @ 2016-11-09 8:10 UTC (permalink / raw)
To: arm@kernel.org; +Cc: linux-arm-kernel@lists.infradead.org, cpufreq
Hi ARM SoC folks,
this adds DT-based cpufreq to the Integrator family.
The corresponding cpufreq changes are merged by Rafael to the
cpufreq tree, and can go in orthogonally.
However I have included the defconfig change turning on the feature
here as it makes all kind of logic sense to have these three patches
in succession: addin the DTS nodes and then turning on the DT
cpufreq.
If you insist, of course I can send the defconfig patch separately.
I just think it makes more sense like this.
Please pull it in so we get some rotation in linux-next for this!
Yours,
Linus Walleij
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git
tags/armsoc-integrator-dts
for you to fetch changes up to 023c8faf9bbc95b2d00768414f0f73076ca06dc9:
ARM: defconfig: turn on the DT cpufreq for Integrator (2016-11-09
09:02:46 +0100)
----------------------------------------------------------------
This contains the DTS changes enabling DT-only cpufreq
scaling on the Integrator family.
----------------------------------------------------------------
Linus Walleij (3):
ARM: dts: Add Integrator/AP cpus node and operating points
ARM: dts: Add Integrator/CP cpus node and operating points
ARM: defconfig: turn on the DT cpufreq for Integrator
arch/arm/boot/dts/integratorap.dts | 35 +++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/integratorcp.dts | 26 ++++++++++++++++++++++++++
arch/arm/configs/integrator_defconfig | 1 +
3 files changed, 62 insertions(+)
^ permalink raw reply
* Re: [PATCH 1/6] clk: stm32f4: Add PLL_I2S & PLL_SAI for STM32F429/469 boards
From: Radosław Pietrzyk @ 2016-11-09 8:10 UTC (permalink / raw)
To: Gabriel Fernandez
Cc: Rob Herring, Mark Rutland, Russell King, Maxime Coquelin,
Alexandre Torgue, Michael Turquette, Stephen Boyd, Nicolas Pitre,
Arnd Bergmann, Daniel Thompson, Andrea Merello, devicetree,
amelie.delaunay, kernel, olivier.bideau, linux-kernel, linux-clk,
ludovic.barre, linux-arm-kernel
In-Reply-To: <0368d067-461d-2edb-5561-9717934e0dde@st.com>
I would expect that VCO clock will force recalculation for all its
children if I am not mistaken.
2016-11-08 17:19 GMT+01:00 Gabriel Fernandez <gabriel.fernandez@st.com>:
> On 11/08/2016 09:52 AM, Radosław Pietrzyk wrote:
>>
>> 2016-11-08 9:35 GMT+01:00 Gabriel Fernandez <gabriel.fernandez@st.com>:
>>>
>>> Hi Radosław
>>>
>>> Many thanks for reviewing.
>>>
>>> On 11/07/2016 03:57 PM, Radosław Pietrzyk wrote:
>>>>>
>>>>> +static struct clk_hw *clk_register_pll_div(const char *name,
>>>>> + const char *parent_name, unsigned long flags,
>>>>> + void __iomem *reg, u8 shift, u8 width,
>>>>> + u8 clk_divider_flags, const struct clk_div_table
>>>>> *table,
>>>>> + struct clk_hw *pll_hw, spinlock_t *lock)
>>>>> +{
>>>>> + struct stm32f4_pll_div *pll_div;
>>>>> + struct clk_hw *hw;
>>>>> + struct clk_init_data init;
>>>>> + int ret;
>>>>> +
>>>>> + /* allocate the divider */
>>>>> + pll_div = kzalloc(sizeof(*pll_div), GFP_KERNEL);
>>>>> + if (!pll_div)
>>>>> + return ERR_PTR(-ENOMEM);
>>>>> +
>>>>> + init.name = name;
>>>>> + init.ops = &stm32f4_pll_div_ops;
>>>>> + init.flags = flags;
>>>>
>>>> Maybe it's worth to have CLK_SET_RATE_PARENT here and the VCO clock
>>>> should have CLK_SET_RATE_GATE flag and we can get rid of custom
>>>> divider ops.
>>>
>>> I don't want to offer the possibility to change the vco clock through the
>>> divisor of the pll (only by a boot-loader or by DT).
>>>
>>> e.g. if i make a set rate on lcd-tft clock, i don't want to change the
>>> SAI
>>> frequencies.
>>>
>>> I used same structure for internal divisors of the pll (p, q, r) and for
>>> post divisors (plli2s-q-div, pllsai-q-div & pllsai-r-div).
>>> That why the CLK_SET_RATE_PARENT flag is transmit by parameter.
>>>
>>> These divisors are similar because we have to switch off the pll before
>>> changing the rate.
>>>
>> But changing pll and lcd dividers only may not be enough for getting
>> very specific pixelclocks and that might require changing the VCO
>> frequency itself. The rest of the SAI tree should be recalculated
>> then.
>
> I agree but it seems to be too much complicated to recalculate all PLL
> divisors if we change the vco clock.
> You mean to use Clock notifier callback ?
^ permalink raw reply
* Re: [PATCH 1/6] clk: stm32f4: Add PLL_I2S & PLL_SAI for STM32F429/469 boards
From: Radosław Pietrzyk @ 2016-11-09 8:10 UTC (permalink / raw)
To: Gabriel Fernandez
Cc: Rob Herring, Mark Rutland, Russell King, Maxime Coquelin,
Alexandre Torgue, Michael Turquette, Stephen Boyd, Nicolas Pitre,
Arnd Bergmann, Daniel Thompson, Andrea Merello,
devicetree-u79uwXL29TY76Z2rM5mHXA, amelie.delaunay-qxv4g6HH51o,
kernel-F5mvAk5X5gdBDgjK7y7TUQ, olivier.bideau-qxv4g6HH51o,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA, ludovic.barre-qxv4g6HH51o,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <0368d067-461d-2edb-5561-9717934e0dde-qxv4g6HH51o@public.gmane.org>
I would expect that VCO clock will force recalculation for all its
children if I am not mistaken.
2016-11-08 17:19 GMT+01:00 Gabriel Fernandez <gabriel.fernandez-qxv4g6HH51o@public.gmane.org>:
> On 11/08/2016 09:52 AM, Radosław Pietrzyk wrote:
>>
>> 2016-11-08 9:35 GMT+01:00 Gabriel Fernandez <gabriel.fernandez-qxv4g6HH51o@public.gmane.org>:
>>>
>>> Hi Radosław
>>>
>>> Many thanks for reviewing.
>>>
>>> On 11/07/2016 03:57 PM, Radosław Pietrzyk wrote:
>>>>>
>>>>> +static struct clk_hw *clk_register_pll_div(const char *name,
>>>>> + const char *parent_name, unsigned long flags,
>>>>> + void __iomem *reg, u8 shift, u8 width,
>>>>> + u8 clk_divider_flags, const struct clk_div_table
>>>>> *table,
>>>>> + struct clk_hw *pll_hw, spinlock_t *lock)
>>>>> +{
>>>>> + struct stm32f4_pll_div *pll_div;
>>>>> + struct clk_hw *hw;
>>>>> + struct clk_init_data init;
>>>>> + int ret;
>>>>> +
>>>>> + /* allocate the divider */
>>>>> + pll_div = kzalloc(sizeof(*pll_div), GFP_KERNEL);
>>>>> + if (!pll_div)
>>>>> + return ERR_PTR(-ENOMEM);
>>>>> +
>>>>> + init.name = name;
>>>>> + init.ops = &stm32f4_pll_div_ops;
>>>>> + init.flags = flags;
>>>>
>>>> Maybe it's worth to have CLK_SET_RATE_PARENT here and the VCO clock
>>>> should have CLK_SET_RATE_GATE flag and we can get rid of custom
>>>> divider ops.
>>>
>>> I don't want to offer the possibility to change the vco clock through the
>>> divisor of the pll (only by a boot-loader or by DT).
>>>
>>> e.g. if i make a set rate on lcd-tft clock, i don't want to change the
>>> SAI
>>> frequencies.
>>>
>>> I used same structure for internal divisors of the pll (p, q, r) and for
>>> post divisors (plli2s-q-div, pllsai-q-div & pllsai-r-div).
>>> That why the CLK_SET_RATE_PARENT flag is transmit by parameter.
>>>
>>> These divisors are similar because we have to switch off the pll before
>>> changing the rate.
>>>
>> But changing pll and lcd dividers only may not be enough for getting
>> very specific pixelclocks and that might require changing the VCO
>> frequency itself. The rest of the SAI tree should be recalculated
>> then.
>
> I agree but it seems to be too much complicated to recalculate all PLL
> divisors if we change the vco clock.
> You mean to use Clock notifier callback ?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/6] clk: stm32f4: Add PLL_I2S & PLL_SAI for STM32F429/469 boards
From: Radosław Pietrzyk @ 2016-11-09 8:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0368d067-461d-2edb-5561-9717934e0dde@st.com>
I would expect that VCO clock will force recalculation for all its
children if I am not mistaken.
2016-11-08 17:19 GMT+01:00 Gabriel Fernandez <gabriel.fernandez@st.com>:
> On 11/08/2016 09:52 AM, Rados?aw Pietrzyk wrote:
>>
>> 2016-11-08 9:35 GMT+01:00 Gabriel Fernandez <gabriel.fernandez@st.com>:
>>>
>>> Hi Rados?aw
>>>
>>> Many thanks for reviewing.
>>>
>>> On 11/07/2016 03:57 PM, Rados?aw Pietrzyk wrote:
>>>>>
>>>>> +static struct clk_hw *clk_register_pll_div(const char *name,
>>>>> + const char *parent_name, unsigned long flags,
>>>>> + void __iomem *reg, u8 shift, u8 width,
>>>>> + u8 clk_divider_flags, const struct clk_div_table
>>>>> *table,
>>>>> + struct clk_hw *pll_hw, spinlock_t *lock)
>>>>> +{
>>>>> + struct stm32f4_pll_div *pll_div;
>>>>> + struct clk_hw *hw;
>>>>> + struct clk_init_data init;
>>>>> + int ret;
>>>>> +
>>>>> + /* allocate the divider */
>>>>> + pll_div = kzalloc(sizeof(*pll_div), GFP_KERNEL);
>>>>> + if (!pll_div)
>>>>> + return ERR_PTR(-ENOMEM);
>>>>> +
>>>>> + init.name = name;
>>>>> + init.ops = &stm32f4_pll_div_ops;
>>>>> + init.flags = flags;
>>>>
>>>> Maybe it's worth to have CLK_SET_RATE_PARENT here and the VCO clock
>>>> should have CLK_SET_RATE_GATE flag and we can get rid of custom
>>>> divider ops.
>>>
>>> I don't want to offer the possibility to change the vco clock through the
>>> divisor of the pll (only by a boot-loader or by DT).
>>>
>>> e.g. if i make a set rate on lcd-tft clock, i don't want to change the
>>> SAI
>>> frequencies.
>>>
>>> I used same structure for internal divisors of the pll (p, q, r) and for
>>> post divisors (plli2s-q-div, pllsai-q-div & pllsai-r-div).
>>> That why the CLK_SET_RATE_PARENT flag is transmit by parameter.
>>>
>>> These divisors are similar because we have to switch off the pll before
>>> changing the rate.
>>>
>> But changing pll and lcd dividers only may not be enough for getting
>> very specific pixelclocks and that might require changing the VCO
>> frequency itself. The rest of the SAI tree should be recalculated
>> then.
>
> I agree but it seems to be too much complicated to recalculate all PLL
> divisors if we change the vco clock.
> You mean to use Clock notifier callback ?
^ permalink raw reply
* Re: [PATCH 1/6] clk: stm32f4: Add PLL_I2S & PLL_SAI for STM32F429/469 boards
From: Radosław Pietrzyk @ 2016-11-09 8:10 UTC (permalink / raw)
To: Gabriel Fernandez
Cc: Rob Herring, Mark Rutland, Russell King, Maxime Coquelin,
Alexandre Torgue, Michael Turquette, Stephen Boyd, Nicolas Pitre,
Arnd Bergmann, Daniel Thompson, Andrea Merello, devicetree,
amelie.delaunay, kernel, olivier.bideau, linux-kernel, linux-clk,
ludovic.barre, linux-arm-kernel
In-Reply-To: <0368d067-461d-2edb-5561-9717934e0dde@st.com>
I would expect that VCO clock will force recalculation for all its
children if I am not mistaken.
2016-11-08 17:19 GMT+01:00 Gabriel Fernandez <gabriel.fernandez@st.com>:
> On 11/08/2016 09:52 AM, Rados=C5=82aw Pietrzyk wrote:
>>
>> 2016-11-08 9:35 GMT+01:00 Gabriel Fernandez <gabriel.fernandez@st.com>:
>>>
>>> Hi Rados=C5=82aw
>>>
>>> Many thanks for reviewing.
>>>
>>> On 11/07/2016 03:57 PM, Rados=C5=82aw Pietrzyk wrote:
>>>>>
>>>>> +static struct clk_hw *clk_register_pll_div(const char *name,
>>>>> + const char *parent_name, unsigned long flags,
>>>>> + void __iomem *reg, u8 shift, u8 width,
>>>>> + u8 clk_divider_flags, const struct clk_div_table
>>>>> *table,
>>>>> + struct clk_hw *pll_hw, spinlock_t *lock)
>>>>> +{
>>>>> + struct stm32f4_pll_div *pll_div;
>>>>> + struct clk_hw *hw;
>>>>> + struct clk_init_data init;
>>>>> + int ret;
>>>>> +
>>>>> + /* allocate the divider */
>>>>> + pll_div =3D kzalloc(sizeof(*pll_div), GFP_KERNEL);
>>>>> + if (!pll_div)
>>>>> + return ERR_PTR(-ENOMEM);
>>>>> +
>>>>> + init.name =3D name;
>>>>> + init.ops =3D &stm32f4_pll_div_ops;
>>>>> + init.flags =3D flags;
>>>>
>>>> Maybe it's worth to have CLK_SET_RATE_PARENT here and the VCO clock
>>>> should have CLK_SET_RATE_GATE flag and we can get rid of custom
>>>> divider ops.
>>>
>>> I don't want to offer the possibility to change the vco clock through t=
he
>>> divisor of the pll (only by a boot-loader or by DT).
>>>
>>> e.g. if i make a set rate on lcd-tft clock, i don't want to change the
>>> SAI
>>> frequencies.
>>>
>>> I used same structure for internal divisors of the pll (p, q, r) and fo=
r
>>> post divisors (plli2s-q-div, pllsai-q-div & pllsai-r-div).
>>> That why the CLK_SET_RATE_PARENT flag is transmit by parameter.
>>>
>>> These divisors are similar because we have to switch off the pll before
>>> changing the rate.
>>>
>> But changing pll and lcd dividers only may not be enough for getting
>> very specific pixelclocks and that might require changing the VCO
>> frequency itself. The rest of the SAI tree should be recalculated
>> then.
>
> I agree but it seems to be too much complicated to recalculate all PLL
> divisors if we change the vco clock.
> You mean to use Clock notifier callback ?
^ permalink raw reply
* spinning kworker with space_cache=v2 searching for free space
From: Stefan Priebe - Profihost AG @ 2016-11-09 8:09 UTC (permalink / raw)
To: linux-btrfs@vger.kernel.org
Dear list,
even there's a lot of free space on my disk:
# df -h /vmbackup/
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/stripe0-backup 37T 24T 13T 64% /backup
# btrfs filesystem df /backup/
Data, single: total=23.75TiB, used=22.83TiB
System, DUP: total=8.00MiB, used=3.94MiB
Metadata, DUP: total=283.50GiB, used=105.82GiB
GlobalReserve, single: total=512.00MiB, used=0.00B
I always have a kworker process endless spinning.
# perf top shows:
47,56% [kernel] [k] rb_next
7,71% [kernel] [k] tree_search_offset.isra.25
6,44% [kernel] [k] btrfs_find_space_for_alloc
Mount options:
rw,noatime,compress-force=zlib,nossd,noacl,space_cache=v2,skip_balance
What's wrong here?
Greets,
Stefan
^ permalink raw reply
* Re: [PATCH 8/9] xfs: fuzz every field of every structure
From: Eryu Guan @ 2016-11-09 8:09 UTC (permalink / raw)
To: Darrick J. Wong; +Cc: david, linux-xfs, fstests
In-Reply-To: <147830508036.1919.9626426021774095650.stgit@birch.djwong.org>
On Fri, Nov 04, 2016 at 05:18:00PM -0700, Darrick J. Wong wrote:
> Previously, our XFS fuzzing efforts were limited to using the xfs_db
> blocktrash command to scribble garbage all over a block. This is
> pretty easy to discover; it would be far more interesting if we could
> fuzz individual fields looking for unhandled corner cases. Since we
> now have an online scrub tool, use it to check for our targeted
> corruptions prior to the usual steps of writing to the FS, taking it
> offline, repairing, and re-checking.
>
> These tests use the new xfs_db 'fuzz' command to test corner case
> handling of every field. The 'print' command tells us which fields
> are available, and the fuzz command can write zeroes or ones to the
> field; set the high, middle, or low bit; add or subtract numbers; or
> randomize the field. We loop through all fields and all fuzz verbs to
> see if we can trip up the kernel.
>
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
The first test gave me a kernel crash :) xfs/1300 crashed your kernel
djwong-devel branch. I appended the console log at the end of this mail
if you have interest to see it.
And another xfs/1300 run gave me this failure message:
+/mnt/testarea/scratch: Kernel lacks GETFSMAP; scrub will be less efficient. (xfs.c line 661)
+/mnt/testarea/scratch: Kernel cannot help scrub metadata; scrub will be incomplete. (xfs.c line 661)
+/mnt/testarea/scratch: Kernel cannot help scrub inodes; scrub will be incomplete. (xfs.c line 661)
+/mnt/testarea/scratch: Kernel cannot help scrub extent map; scrub will be less efficient. (xfs.c line 661)
Is this known issue or something should be filtered out in the test?
And ext4/1300 generated large .out.bad file (51M), containing something
like:
+/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101381632/2469888/4096) ends past end of filesystem at 31457280. (generic.c line 272)
+/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101389824/2478080/4096) starts past end of filesystem at 31457280. (generic.c line 264)
+/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101389824/2478080/4096) ends past end of filesystem at 31457280. (generic.c line 272)
+/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101398016/2486272/4096) starts past end of filesystem at 31457280. (generic.c line 264)
+/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101398016/2486272/4096) ends past end of filesystem at 31457280. (generic.c line 272)
+/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101406208/2494464/4096) starts past end of filesystem at 31457280. (generic.c line 264)
+/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101406208/2494464/4096) ends past end of filesystem at 31457280. (generic.c line 272)
+/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101414400/2502656/4096) starts past end of filesystem at 31457280. (generic.c line 264)
+/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101414400/2502656/4096) ends past end of filesystem at 31457280. (generic.c line 272)
Seems like scrub found something wrong (real problems) and became very
noisy?
More comments inline below.
> ---
> common/fuzzy | 49 ++++++++++++++++++++++++++++++------
> common/populate | 10 ++++---
> common/rc | 15 +++++++++++
> tests/ext4/1300 | 60 ++++++++++++++++++++++++++++++++++++++++++++
[snip]
>
> diff --git a/common/fuzzy b/common/fuzzy
> index 6af47f1..dbff744 100644
> --- a/common/fuzzy
> +++ b/common/fuzzy
> @@ -85,32 +85,47 @@ _scratch_scrub() {
> # Filter the xfs_db print command's field debug information
> # into field name and type.
> __filter_xfs_db_print_fields() {
> + filter="$1"
> + if [ -z "${filter}" ] || [ "${filter}" = "nofilter" ]; then
> + filter='^'
> + fi
> grep ' = ' | while read key equals value; do
> - fuzzkey="$(echo "${key}" | sed -e 's/\([a-zA-Z0-9_]*\)\[\([0-9]*\)-[0-9]*\]/\1[\2]/g')"
> - if [[ "${value}" == "["* ]]; then
> + # Filter out any keys with an array index >= 10, and
> + # collapse any array range ("[1-195]") to the first item.
> + fuzzkey="$(echo "${key}" | sed -e '/\([a-z]*\)\[\([0-9][0-9]\+\)\].*/d' -e 's/\([a-zA-Z0-9_]*\)\[\([0-9]*\)-[0-9]*\]/\1[\2]/g')"
> + if [ -z "${fuzzkey}" ]; then
> + continue
> + elif [[ "${value}" == "["* ]]; then
> echo "${value}" | sed -e 's/^.//g' -e 's/.$//g' -e 's/,/\n/g' | while read subfield; do
> echo "${fuzzkey}.${subfield}"
> done
> else
> echo "${fuzzkey}"
> fi
> - done
> + done | egrep "${filter}"
> }
>
> # Navigate to some part of the filesystem and print the field info.
> +# The first argument is an egrep filter for the fields
> +# The rest of the arguments are xfs_db commands to locate the metadata.
> _scratch_xfs_list_metadata_fields() {
> + filter="$1"
> + shift
> if [ -n "${SCRATCH_XFS_LIST_METADATA_FIELDS}" ]; then
> - echo "${SCRATCH_XFS_LIST_METADATA_FIELDS}" | sed -e 's/ /\n/g'
> + echo "${SCRATCH_XFS_LIST_METADATA_FIELDS}" | \
> + sed -e 's/ /\n/g' | __filter_xfs_db_print_fields "${filter}"
> return;
> fi
>
> (for arg in "$@"; do
> echo "${arg}"
> done
> - echo "print") | _scratch_xfs_db | __filter_xfs_db_print_fields
> + echo "print") | _scratch_xfs_db | __filter_xfs_db_print_fields "${filter}"
> }
>
> # Get a metadata field
> +# The first arg is the field name
> +# The rest of the arguments are xfs_db commands to find the metadata.
> _scratch_xfs_get_metadata_field() {
> key="$1"
> shift
> @@ -124,6 +139,9 @@ _scratch_xfs_get_metadata_field() {
> }
>
> # Set a metadata field
> +# The first arg is the field name
> +# The second arg is the new value
> +# The rest of the arguments are xfs_db commands to find the metadata.
> _scratch_xfs_set_metadata_field() {
> key="$1"
> value="$2"
> @@ -136,6 +154,9 @@ _scratch_xfs_set_metadata_field() {
> }
>
> # Fuzz a metadata field
> +# The first arg is the field name
> +# The second arg is the xfs_db fuzz verb
> +# The rest of the arguments are xfs_db commands to find the metadata.
> _scratch_xfs_fuzz_metadata_field() {
> key="$1"
> value="$2"
> @@ -263,12 +284,24 @@ _scratch_xfs_list_fuzz_verbs() {
> sed -e 's/[,.]//g' -e 's/Verbs: //g' -e 's/ /\n/g'
> }
>
> -# Fuzz the fields of some piece of metadata
> -_scratch_xfs_fuzz_fields() {
> - _scratch_xfs_list_metadata_fields "$@" | while read field; do
> +# Fuzz some of the fields of some piece of metadata
> +# The first argument is an egrep filter
> +# The rest of the arguments are xfs_db commands to locate the metadata.
> +_scratch_xfs_fuzz_some_fields() {
> + filter="$1"
> + shift
> + echo "Fields we propose to fuzz: $@"
> + _scratch_xfs_list_metadata_fields "${filter}" "$@"
> + _scratch_xfs_list_metadata_fields "${filter}" "$@" | while read field; do
> _scratch_xfs_list_fuzz_verbs | while read fuzzverb; do
> __scratch_xfs_fuzz_mdrestore
> __scratch_xfs_fuzz_field_test "${field}" "${fuzzverb}" "$@"
> done
> done
> }
> +
> +# Fuzz all of the fields of some piece of metadata
> +# All arguments are xfs_db commands to locate the metadata.
> +_scratch_xfs_fuzz_fields() {
> + _scratch_xfs_fuzz_some_fields '' "$@"
> +}
I think all the fuzz update here should be folded to patch 7/9.
> diff --git a/common/populate b/common/populate
> index 15d68fc..7d103f0 100644
> --- a/common/populate
> +++ b/common/populate
> @@ -180,13 +180,13 @@ _scratch_xfs_populate() {
> # FMT_EXTENTS with a remote less-than-a-block value
> echo "+ attr extents with a remote less-than-a-block value"
> touch "${SCRATCH_MNT}/ATTR.FMT_EXTENTS_REMOTE3K"
> - $XFS_IO_PROG -f -c "pwrite -S 0x43 0 3k" "${SCRATCH_MNT}/attrvalfile" > /dev/null
> + $XFS_IO_PROG -f -c "pwrite -S 0x43 0 $((blksz - 300))" "${SCRATCH_MNT}/attrvalfile" > /dev/null
> attr -q -s user.remotebtreeattrname "${SCRATCH_MNT}/ATTR.FMT_EXTENTS_REMOTE3K" < "${SCRATCH_MNT}/attrvalfile"
>
> # FMT_EXTENTS with a remote block-size value
> echo "+ attr extents with a remote one-block value"
> touch "${SCRATCH_MNT}/ATTR.FMT_EXTENTS_REMOTE4K"
> - $XFS_IO_PROG -f -c "pwrite -S 0x44 0 4k" "${SCRATCH_MNT}/attrvalfile" > /dev/null
> + $XFS_IO_PROG -f -c "pwrite -S 0x44 0 ${blksz}" "${SCRATCH_MNT}/attrvalfile" > /dev/null
> attr -q -s user.remotebtreeattrname "${SCRATCH_MNT}/ATTR.FMT_EXTENTS_REMOTE4K" < "${SCRATCH_MNT}/attrvalfile"
> rm -rf "${SCRATCH_MNT}/attrvalfile"
>
> @@ -482,8 +482,8 @@ _scratch_xfs_populate_check() {
> __populate_check_xfs_aformat "${btree_attr}" "btree"
> __populate_check_xfs_agbtree_height "bno"
> __populate_check_xfs_agbtree_height "cnt"
> - test -n $is_rmapbt && __populate_check_xfs_agbtree_height "rmap"
> - test -n $is_reflink && __populate_check_xfs_agbtree_height "refcnt"
> + test $is_rmapbt -ne 0 && __populate_check_xfs_agbtree_height "rmap"
> + test $is_reflink -ne 0 && __populate_check_xfs_agbtree_height "refcnt"
> }
And these folded to patch 1/9?
>
> # Check data fork format of ext4 file
> @@ -609,7 +609,7 @@ _scratch_populate_cached() {
> rm -rf "$(find "${POPULATE_METADUMP}" -mtime +2 2>/dev/null)"
>
> # Throw away cached image if it doesn't match our spec.
> - meta_descr="FSTYP ${FSTYP} MKFS_OPTIONS ${MKFS_OPTIONS} ARGS $@"
> + meta_descr="FSTYP ${FSTYP} MKFS_OPTIONS $(_scratch_mkfs_options) ARGS $@"
> cmp -s "${POPULATE_METADUMP_DESCR}" <(echo "${meta_descr}") || rm -rf "${POPULATE_METADUMP}"
>
> # Do we have a cached image?
This to patch 6/9?
Because we usually don't introduce something in patch 1 and fix them in
patch 2, I think :)
> diff --git a/common/rc b/common/rc
> index d904582..ec1f5de 100644
> --- a/common/rc
> +++ b/common/rc
> @@ -1870,6 +1870,21 @@ _require_xfs_finobt()
> _scratch_unmount
> }
>
> +# Do we have a fre
> +_require_scratch_finobt()
> +{
> + _require_scratch
> +
> + if [ $FSTYP != "xfs" ]; then
> + _notrun "finobt not supported by scratch filesystem type: $FSTYP"
> + return
> + fi
> + _scratch_mkfs > /dev/null
> + _scratch_mount
> + xfs_info $SCRATCH_MNT | grep -q 'finobt=1' || _notrun "finobt not supported by scratch filesystem type: $FSTYP"
> + _scratch_unmount
> +}
> +
> # this test requires xfs sysfs attribute support
> #
> _require_xfs_sysfs()
> diff --git a/tests/ext4/1300 b/tests/ext4/1300
> new file mode 100755
> index 0000000..3f8135e
> --- /dev/null
> +++ b/tests/ext4/1300
[all the tests look fine to me, snip]
> --- a/tests/xfs/group
> +++ b/tests/xfs/group
> @@ -333,3 +333,34 @@
> 345 auto quick clone
> 346 auto quick clone
> 347 auto quick clone
> +1300 dangerous_fuzzers scrub
ext4/1300 is "auto quick scrub", I think xfs/1300 should be in auto
group too?
Thanks,
Eryu
P.S. console log of xfs/1300 crash
[165877.766244] BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
[165877.774197] IP: [<ffffffffa0680c13>] xfs_scrub_get_inode+0xc3/0x1c0 [xfs]
[165877.781162] PGD 179c1b067 [165877.783784] PUD 14d994067
PMD 0 [165877.787130]
[165877.788722] Oops: 0000 [#1] SMP
[165877.791951] Modules linked in: dm_delay dm_zero btrfs xor raid6_pq dm_thin_pool dm_persistent_data dm_bio_prison dm_snapshot dm_bufio loop dm_flakey xfs libcrc32c binfmt_misc ip6t_rpfilter ipt_REJECT nf_reject_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack nf_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_mangle ip6table_security ip6table_raw iptable_mangle iptable_security iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter coretemp kvm_intel kvm irqbypass crc32_pclmul ghash_clmulni_intel aesni_intel lrw iTCO_wdt gf128mul glue_helper ipmi_devintf cdc_ether iTCO_vendor_support ablk_helper cryptd usbnet i2c_i801 lpc_ich mii pcspkr i2c_smbus sg i7core_edac mfd_core ipmi_si edac_core ipmi_msghandler shpchp ioatdma dca acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables ext4 jbd2 mbcache sr_mod sd_mod cdrom mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm ata_generic pata_acpi drm ata_piix libata crc32c_intel megaraid_sas serio_raw i2c_core bnx2 dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_debug]
[165877.898708] CPU: 5 PID: 26242 Comm: xfs_scrub Tainted: G W 4.9.0-rc3.djwong+ #16
[165877.907308] Hardware name: IBM System x3550 M3 -[7944OEJ]-/90Y4784 , BIOS -[D6E150CUS-1.11]- 02/08/2011
[165877.917124] task: ffff88017a286a40 task.stack: ffffc9000cca0000
[165877.923126] RIP: 0010:[<ffffffffa0680c13>] [<ffffffffa0680c13>] xfs_scrub_get_inode+0xc3/0x1c0 [xfs]
[165877.932503] RSP: 0018:ffffc9000cca3ad0 EFLAGS: 00010246
[165877.937898] RAX: 0000000000000000 RBX: fffffffffffffffe RCX: 0000000000000017
[165877.945111] RDX: 0000000000000000 RSI: ffffc9000cca3ce8 RDI: 0000000000001123
[165877.952328] RBP: ffffc9000cca3b20 R08: 0000000000000003 R09: 0000000000000014
[165877.959544] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880278f59680
[165877.966759] R13: ffffc9000cca3ba8 R14: ffffc9000cca3ce8 R15: 0000000000000000
[165877.973976] FS: 00007f3d099f9700(0000) GS:ffff88017bb00000(0000) knlGS:0000000000000000
[165877.982143] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[165877.987969] CR2: 0000000000000038 CR3: 000000016ad2d000 CR4: 00000000000006e0
[165877.995185] Stack:
[165877.997286] ffff880278f59680 0000000000000000 ffff880220cc5c00 ffff880265190780
[165878.004840] ffff880101a67800 ffffc9000cca3ba8 ffff880278f59680 ffff88025a9e6000
[165878.012396] ffffc9000cca3ce8 0000000000000000 ffffc9000cca3b58 ffffffffa0681a61
[165878.019950] Call Trace:
[165878.022551] [<ffffffffa0681a61>] __xfs_scrub_setup_inode.isra.63+0x81/0x280 [xfs]
[165878.030236] [<ffffffffa0681c70>] xfs_scrub_setup_inode+0x10/0x20 [xfs]
[165878.036963] [<ffffffffa068f57f>] xfs_scrub_metadata+0x2ff/0x450 [xfs]
[165878.043607] [<ffffffffa066aa1d>] xfs_ioc_scrub_metadata+0x4d/0x80 [xfs]
[165878.050424] [<ffffffffa066d029>] xfs_file_ioctl+0x9c9/0xb10 [xfs]
[165878.056689] [<ffffffff8110692f>] ? get_futex_key+0x1df/0x360
[165878.062516] [<ffffffff81106b31>] ? futex_wake+0x81/0x150
[165878.068003] [<ffffffff812189c6>] do_vfs_ioctl+0x96/0x5b0
[165878.073482] [<ffffffff81218f59>] SyS_ioctl+0x79/0x90
[165878.078621] [<ffffffff81003997>] do_syscall_64+0x67/0x180
[165878.084191] [<ffffffff816a6c2b>] entry_SYSCALL64_slow_path+0x25/0x25
[165878.090714] Code: 8b 14 24 49 8b 75 00 85 c0 41 89 c7 44 0f b6 82 93 00 00 00 44 0f b6 8a 94 00 00 00 0f b6 8a 53 02 00 00 49 8b 55 08 48 8b 7e 08 <4c> 8b 62 38 75 38 48 8b 7d d0 8b 46 10 39 87 98 03 00 00 74 21
[165878.110930] RIP [<ffffffffa0680c13>] xfs_scrub_get_inode+0xc3/0x1c0 [xfs]
[165878.117938] RSP <ffffc9000cca3ad0>
[165878.121512] CR2: 0000000000000038
[165878.129219] ---[ end trace d23e56c58f53ccb9 ]---
^ permalink raw reply
* Re: [PATCH 8/9] xfs: fuzz every field of every structure
From: Eryu Guan @ 2016-11-09 8:09 UTC (permalink / raw)
To: Darrick J. Wong; +Cc: david, linux-xfs, fstests
In-Reply-To: <147830508036.1919.9626426021774095650.stgit@birch.djwong.org>
On Fri, Nov 04, 2016 at 05:18:00PM -0700, Darrick J. Wong wrote:
> Previously, our XFS fuzzing efforts were limited to using the xfs_db
> blocktrash command to scribble garbage all over a block. This is
> pretty easy to discover; it would be far more interesting if we could
> fuzz individual fields looking for unhandled corner cases. Since we
> now have an online scrub tool, use it to check for our targeted
> corruptions prior to the usual steps of writing to the FS, taking it
> offline, repairing, and re-checking.
>
> These tests use the new xfs_db 'fuzz' command to test corner case
> handling of every field. The 'print' command tells us which fields
> are available, and the fuzz command can write zeroes or ones to the
> field; set the high, middle, or low bit; add or subtract numbers; or
> randomize the field. We loop through all fields and all fuzz verbs to
> see if we can trip up the kernel.
>
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
The first test gave me a kernel crash :) xfs/1300 crashed your kernel
djwong-devel branch. I appended the console log at the end of this mail
if you have interest to see it.
And another xfs/1300 run gave me this failure message:
+/mnt/testarea/scratch: Kernel lacks GETFSMAP; scrub will be less efficient. (xfs.c line 661)
+/mnt/testarea/scratch: Kernel cannot help scrub metadata; scrub will be incomplete. (xfs.c line 661)
+/mnt/testarea/scratch: Kernel cannot help scrub inodes; scrub will be incomplete. (xfs.c line 661)
+/mnt/testarea/scratch: Kernel cannot help scrub extent map; scrub will be less efficient. (xfs.c line 661)
Is this known issue or something should be filtered out in the test?
And ext4/1300 generated large .out.bad file (51M), containing something
like:
+/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101381632/2469888/4096) ends past end of filesystem at 31457280. (generic.c line 272)
+/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101389824/2478080/4096) starts past end of filesystem at 31457280. (generic.c line 264)
+/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101389824/2478080/4096) ends past end of filesystem at 31457280. (generic.c line 272)
+/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101398016/2486272/4096) starts past end of filesystem at 31457280. (generic.c line 264)
+/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101398016/2486272/4096) ends past end of filesystem at 31457280. (generic.c line 272)
+/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101406208/2494464/4096) starts past end of filesystem at 31457280. (generic.c line 264)
+/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101406208/2494464/4096) ends past end of filesystem at 31457280. (generic.c line 272)
+/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101414400/2502656/4096) starts past end of filesystem at 31457280. (generic.c line 264)
+/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101414400/2502656/4096) ends past end of filesystem at 31457280. (generic.c line 272)
Seems like scrub found something wrong (real problems) and became very
noisy?
More comments inline below.
> ---
> common/fuzzy | 49 ++++++++++++++++++++++++++++++------
> common/populate | 10 ++++---
> common/rc | 15 +++++++++++
> tests/ext4/1300 | 60 ++++++++++++++++++++++++++++++++++++++++++++
[snip]
>
> diff --git a/common/fuzzy b/common/fuzzy
> index 6af47f1..dbff744 100644
> --- a/common/fuzzy
> +++ b/common/fuzzy
> @@ -85,32 +85,47 @@ _scratch_scrub() {
> # Filter the xfs_db print command's field debug information
> # into field name and type.
> __filter_xfs_db_print_fields() {
> + filter="$1"
> + if [ -z "${filter}" ] || [ "${filter}" = "nofilter" ]; then
> + filter='^'
> + fi
> grep ' = ' | while read key equals value; do
> - fuzzkey="$(echo "${key}" | sed -e 's/\([a-zA-Z0-9_]*\)\[\([0-9]*\)-[0-9]*\]/\1[\2]/g')"
> - if [[ "${value}" == "["* ]]; then
> + # Filter out any keys with an array index >= 10, and
> + # collapse any array range ("[1-195]") to the first item.
> + fuzzkey="$(echo "${key}" | sed -e '/\([a-z]*\)\[\([0-9][0-9]\+\)\].*/d' -e 's/\([a-zA-Z0-9_]*\)\[\([0-9]*\)-[0-9]*\]/\1[\2]/g')"
> + if [ -z "${fuzzkey}" ]; then
> + continue
> + elif [[ "${value}" == "["* ]]; then
> echo "${value}" | sed -e 's/^.//g' -e 's/.$//g' -e 's/,/\n/g' | while read subfield; do
> echo "${fuzzkey}.${subfield}"
> done
> else
> echo "${fuzzkey}"
> fi
> - done
> + done | egrep "${filter}"
> }
>
> # Navigate to some part of the filesystem and print the field info.
> +# The first argument is an egrep filter for the fields
> +# The rest of the arguments are xfs_db commands to locate the metadata.
> _scratch_xfs_list_metadata_fields() {
> + filter="$1"
> + shift
> if [ -n "${SCRATCH_XFS_LIST_METADATA_FIELDS}" ]; then
> - echo "${SCRATCH_XFS_LIST_METADATA_FIELDS}" | sed -e 's/ /\n/g'
> + echo "${SCRATCH_XFS_LIST_METADATA_FIELDS}" | \
> + sed -e 's/ /\n/g' | __filter_xfs_db_print_fields "${filter}"
> return;
> fi
>
> (for arg in "$@"; do
> echo "${arg}"
> done
> - echo "print") | _scratch_xfs_db | __filter_xfs_db_print_fields
> + echo "print") | _scratch_xfs_db | __filter_xfs_db_print_fields "${filter}"
> }
>
> # Get a metadata field
> +# The first arg is the field name
> +# The rest of the arguments are xfs_db commands to find the metadata.
> _scratch_xfs_get_metadata_field() {
> key="$1"
> shift
> @@ -124,6 +139,9 @@ _scratch_xfs_get_metadata_field() {
> }
>
> # Set a metadata field
> +# The first arg is the field name
> +# The second arg is the new value
> +# The rest of the arguments are xfs_db commands to find the metadata.
> _scratch_xfs_set_metadata_field() {
> key="$1"
> value="$2"
> @@ -136,6 +154,9 @@ _scratch_xfs_set_metadata_field() {
> }
>
> # Fuzz a metadata field
> +# The first arg is the field name
> +# The second arg is the xfs_db fuzz verb
> +# The rest of the arguments are xfs_db commands to find the metadata.
> _scratch_xfs_fuzz_metadata_field() {
> key="$1"
> value="$2"
> @@ -263,12 +284,24 @@ _scratch_xfs_list_fuzz_verbs() {
> sed -e 's/[,.]//g' -e 's/Verbs: //g' -e 's/ /\n/g'
> }
>
> -# Fuzz the fields of some piece of metadata
> -_scratch_xfs_fuzz_fields() {
> - _scratch_xfs_list_metadata_fields "$@" | while read field; do
> +# Fuzz some of the fields of some piece of metadata
> +# The first argument is an egrep filter
> +# The rest of the arguments are xfs_db commands to locate the metadata.
> +_scratch_xfs_fuzz_some_fields() {
> + filter="$1"
> + shift
> + echo "Fields we propose to fuzz: $@"
> + _scratch_xfs_list_metadata_fields "${filter}" "$@"
> + _scratch_xfs_list_metadata_fields "${filter}" "$@" | while read field; do
> _scratch_xfs_list_fuzz_verbs | while read fuzzverb; do
> __scratch_xfs_fuzz_mdrestore
> __scratch_xfs_fuzz_field_test "${field}" "${fuzzverb}" "$@"
> done
> done
> }
> +
> +# Fuzz all of the fields of some piece of metadata
> +# All arguments are xfs_db commands to locate the metadata.
> +_scratch_xfs_fuzz_fields() {
> + _scratch_xfs_fuzz_some_fields '' "$@"
> +}
I think all the fuzz update here should be folded to patch 7/9.
> diff --git a/common/populate b/common/populate
> index 15d68fc..7d103f0 100644
> --- a/common/populate
> +++ b/common/populate
> @@ -180,13 +180,13 @@ _scratch_xfs_populate() {
> # FMT_EXTENTS with a remote less-than-a-block value
> echo "+ attr extents with a remote less-than-a-block value"
> touch "${SCRATCH_MNT}/ATTR.FMT_EXTENTS_REMOTE3K"
> - $XFS_IO_PROG -f -c "pwrite -S 0x43 0 3k" "${SCRATCH_MNT}/attrvalfile" > /dev/null
> + $XFS_IO_PROG -f -c "pwrite -S 0x43 0 $((blksz - 300))" "${SCRATCH_MNT}/attrvalfile" > /dev/null
> attr -q -s user.remotebtreeattrname "${SCRATCH_MNT}/ATTR.FMT_EXTENTS_REMOTE3K" < "${SCRATCH_MNT}/attrvalfile"
>
> # FMT_EXTENTS with a remote block-size value
> echo "+ attr extents with a remote one-block value"
> touch "${SCRATCH_MNT}/ATTR.FMT_EXTENTS_REMOTE4K"
> - $XFS_IO_PROG -f -c "pwrite -S 0x44 0 4k" "${SCRATCH_MNT}/attrvalfile" > /dev/null
> + $XFS_IO_PROG -f -c "pwrite -S 0x44 0 ${blksz}" "${SCRATCH_MNT}/attrvalfile" > /dev/null
> attr -q -s user.remotebtreeattrname "${SCRATCH_MNT}/ATTR.FMT_EXTENTS_REMOTE4K" < "${SCRATCH_MNT}/attrvalfile"
> rm -rf "${SCRATCH_MNT}/attrvalfile"
>
> @@ -482,8 +482,8 @@ _scratch_xfs_populate_check() {
> __populate_check_xfs_aformat "${btree_attr}" "btree"
> __populate_check_xfs_agbtree_height "bno"
> __populate_check_xfs_agbtree_height "cnt"
> - test -n $is_rmapbt && __populate_check_xfs_agbtree_height "rmap"
> - test -n $is_reflink && __populate_check_xfs_agbtree_height "refcnt"
> + test $is_rmapbt -ne 0 && __populate_check_xfs_agbtree_height "rmap"
> + test $is_reflink -ne 0 && __populate_check_xfs_agbtree_height "refcnt"
> }
And these folded to patch 1/9?
>
> # Check data fork format of ext4 file
> @@ -609,7 +609,7 @@ _scratch_populate_cached() {
> rm -rf "$(find "${POPULATE_METADUMP}" -mtime +2 2>/dev/null)"
>
> # Throw away cached image if it doesn't match our spec.
> - meta_descr="FSTYP ${FSTYP} MKFS_OPTIONS ${MKFS_OPTIONS} ARGS $@"
> + meta_descr="FSTYP ${FSTYP} MKFS_OPTIONS $(_scratch_mkfs_options) ARGS $@"
> cmp -s "${POPULATE_METADUMP_DESCR}" <(echo "${meta_descr}") || rm -rf "${POPULATE_METADUMP}"
>
> # Do we have a cached image?
This to patch 6/9?
Because we usually don't introduce something in patch 1 and fix them in
patch 2, I think :)
> diff --git a/common/rc b/common/rc
> index d904582..ec1f5de 100644
> --- a/common/rc
> +++ b/common/rc
> @@ -1870,6 +1870,21 @@ _require_xfs_finobt()
> _scratch_unmount
> }
>
> +# Do we have a fre
> +_require_scratch_finobt()
> +{
> + _require_scratch
> +
> + if [ $FSTYP != "xfs" ]; then
> + _notrun "finobt not supported by scratch filesystem type: $FSTYP"
> + return
> + fi
> + _scratch_mkfs > /dev/null
> + _scratch_mount
> + xfs_info $SCRATCH_MNT | grep -q 'finobt=1' || _notrun "finobt not supported by scratch filesystem type: $FSTYP"
> + _scratch_unmount
> +}
> +
> # this test requires xfs sysfs attribute support
> #
> _require_xfs_sysfs()
> diff --git a/tests/ext4/1300 b/tests/ext4/1300
> new file mode 100755
> index 0000000..3f8135e
> --- /dev/null
> +++ b/tests/ext4/1300
[all the tests look fine to me, snip]
> --- a/tests/xfs/group
> +++ b/tests/xfs/group
> @@ -333,3 +333,34 @@
> 345 auto quick clone
> 346 auto quick clone
> 347 auto quick clone
> +1300 dangerous_fuzzers scrub
ext4/1300 is "auto quick scrub", I think xfs/1300 should be in auto
group too?
Thanks,
Eryu
P.S. console log of xfs/1300 crash
[165877.766244] BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
[165877.774197] IP: [<ffffffffa0680c13>] xfs_scrub_get_inode+0xc3/0x1c0 [xfs]
[165877.781162] PGD 179c1b067 [165877.783784] PUD 14d994067
PMD 0 [165877.787130]
[165877.788722] Oops: 0000 [#1] SMP
[165877.791951] Modules linked in: dm_delay dm_zero btrfs xor raid6_pq dm_thin_pool dm_persistent_data dm_bio_prison dm_snapshot dm_bufio loop dm_flakey xfs libcrc32c binfmt_misc ip6t_rpfilter ipt_REJECT nf_reject_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack nf_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_mangle ip6table_security ip6table_raw iptable_mangle iptable_security iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter coretemp kvm_intel kvm irqbypass crc32_pclmul ghash_clmulni_intel aesni_intel lrw iTCO_wdt gf128mul glue_helper ipmi_devintf cdc_ether iTCO_vendor_support ablk_helper cryptd usbnet i2c_i801 lpc_ich mii pcspkr i2c_smbus sg i7core_edac mfd_core ipmi_si edac_core ipmi_msghandler shpchp ioatdma dca acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables ext4 jbd2 mbcache sr_mod sd_mod cdrom mgag200 i2c_algo_bit drm_kms_helpe!
r syscopyarea sysfillrect sysimgblt fb_sys_fops ttm ata_generic pata_acpi drm ata_piix libata crc32c_intel megaraid_sas serio_raw i2c_core bnx2 dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_debug]
[165877.898708] CPU: 5 PID: 26242 Comm: xfs_scrub Tainted: G W 4.9.0-rc3.djwong+ #16
[165877.907308] Hardware name: IBM System x3550 M3 -[7944OEJ]-/90Y4784 , BIOS -[D6E150CUS-1.11]- 02/08/2011
[165877.917124] task: ffff88017a286a40 task.stack: ffffc9000cca0000
[165877.923126] RIP: 0010:[<ffffffffa0680c13>] [<ffffffffa0680c13>] xfs_scrub_get_inode+0xc3/0x1c0 [xfs]
[165877.932503] RSP: 0018:ffffc9000cca3ad0 EFLAGS: 00010246
[165877.937898] RAX: 0000000000000000 RBX: fffffffffffffffe RCX: 0000000000000017
[165877.945111] RDX: 0000000000000000 RSI: ffffc9000cca3ce8 RDI: 0000000000001123
[165877.952328] RBP: ffffc9000cca3b20 R08: 0000000000000003 R09: 0000000000000014
[165877.959544] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880278f59680
[165877.966759] R13: ffffc9000cca3ba8 R14: ffffc9000cca3ce8 R15: 0000000000000000
[165877.973976] FS: 00007f3d099f9700(0000) GS:ffff88017bb00000(0000) knlGS:0000000000000000
[165877.982143] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[165877.987969] CR2: 0000000000000038 CR3: 000000016ad2d000 CR4: 00000000000006e0
[165877.995185] Stack:
[165877.997286] ffff880278f59680 0000000000000000 ffff880220cc5c00 ffff880265190780
[165878.004840] ffff880101a67800 ffffc9000cca3ba8 ffff880278f59680 ffff88025a9e6000
[165878.012396] ffffc9000cca3ce8 0000000000000000 ffffc9000cca3b58 ffffffffa0681a61
[165878.019950] Call Trace:
[165878.022551] [<ffffffffa0681a61>] __xfs_scrub_setup_inode.isra.63+0x81/0x280 [xfs]
[165878.030236] [<ffffffffa0681c70>] xfs_scrub_setup_inode+0x10/0x20 [xfs]
[165878.036963] [<ffffffffa068f57f>] xfs_scrub_metadata+0x2ff/0x450 [xfs]
[165878.043607] [<ffffffffa066aa1d>] xfs_ioc_scrub_metadata+0x4d/0x80 [xfs]
[165878.050424] [<ffffffffa066d029>] xfs_file_ioctl+0x9c9/0xb10 [xfs]
[165878.056689] [<ffffffff8110692f>] ? get_futex_key+0x1df/0x360
[165878.062516] [<ffffffff81106b31>] ? futex_wake+0x81/0x150
[165878.068003] [<ffffffff812189c6>] do_vfs_ioctl+0x96/0x5b0
[165878.073482] [<ffffffff81218f59>] SyS_ioctl+0x79/0x90
[165878.078621] [<ffffffff81003997>] do_syscall_64+0x67/0x180
[165878.084191] [<ffffffff816a6c2b>] entry_SYSCALL64_slow_path+0x25/0x25
[165878.090714] Code: 8b 14 24 49 8b 75 00 85 c0 41 89 c7 44 0f b6 82 93 00 00 00 44 0f b6 8a 94 00 00 00 0f b6 8a 53 02 00 00 49 8b 55 08 48 8b 7e 08 <4c> 8b 62 38 75 38 48 8b 7d d0 8b 46 10 39 87 98 03 00 00 74 21
[165878.110930] RIP [<ffffffffa0680c13>] xfs_scrub_get_inode+0xc3/0x1c0 [xfs]
[165878.117938] RSP <ffffc9000cca3ad0>
[165878.121512] CR2: 0000000000000038
[165878.129219] ---[ end trace d23e56c58f53ccb9 ]---
^ permalink raw reply
* Re: [PATCH 6/9 v2] arm64: dts: m3ulcb: enable SDHI0
From: Vladimir Barinov @ 2016-11-09 8:06 UTC (permalink / raw)
To: Simon Horman
Cc: Magnus Damm, Rob Herring, Mark Rutland, devicetree,
linux-renesas-soc
In-Reply-To: <20161109074418.GC30093@verge.net.au>
Hi Simon,
On 09.11.2016 10:44, Simon Horman wrote:
> On Tue, Nov 08, 2016 at 05:14:21PM +0300, Vladimir Barinov wrote:
>> This supports SDHI0 on M3ULCB board SD card slot
>>
>> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
>> Reviewed-off-by: Simon Horman <horms+renesas@verge.net.au>
> Thanks Vladimir,
>
> I have queued up the following patches:
>
> arm64: dts: h3ulcb: rename SDHI0 pins
> arm64: dts: h3ulcb: enable SDHI2
> arm64: dts: m3ulcb: enable SDHI2
> arm64: dts: m3ulcb: enable SDHI0
>
> For reference I would, however, like to make some comments regarding the
> way you have submitted these:
>
> 1. I did not provide a Reviewed-off-by tag or any other tag as far as I
> recall. So its not appropriate for you to add one when posting patches.
> I have removed it.
>
> 2. Not withstanding the above, Reviewed-off-by is an invalid tag.
> Perhaps you mean Reviewed-by.
>
> 3. When you repost patches I have a slight preference for you to repost
> them in a fresh thread. And if the patchset has more than one patch then
> with a fresh cover letter. This makes it a little easier for me
> to see what is going on. And gives a more natural place for
> me to respond to a patchset.
Thank you for these valuable comments!
I will follow them for further work.
Regards,
Vladimir
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.