* [v16, 2/7] dt: bindings: move guts devicetree doc out of powerpc directory
From: Yangbo Lu @ 2016-11-09 3:14 UTC (permalink / raw)
To: linux-mmc, ulf.hansson, Scott Wood, Arnd Bergmann
Cc: linuxppc-dev, devicetree, linux-arm-kernel, linux-kernel,
linux-clk, linux-i2c, iommu, netdev, Greg Kroah-Hartman,
Mark Rutland, Rob Herring, Russell King, Jochen Friedrich,
Joerg Roedel, Claudiu Manoil, Bhupesh Sharma, Qiang Zhao,
Kumar Gala, Leo Li, Xiaobo Xie, Minghuan Lian, Yangbo Lu
In-Reply-To: <1478661252-42439-1-git-send-email-yangbo.lu@nxp.com>
Move guts devicetree doc to Documentation/devicetree/bindings/soc/fsl/
since it's used by not only PowerPC but also ARM. And add a specification
for 'little-endian' property.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Scott Wood <oss@buserror.net>
Acked-by: Arnd Bergmann <arnd@arndb.de>
---
Changes for v4:
- Added this patch
Changes for v5:
- Modified the description for little-endian property
Changes for v6:
- None
Changes for v7:
- None
Changes for v8:
- Added 'Acked-by: Scott Wood'
- Added 'Acked-by: Rob Herring'
Changes for v9:
- None
Changes for v10:
- None
Changes for v11:
- None
Changes for v12:
- None
Changes for v13:
- None
Changes for v14:
- None
Changes for v15:
- None
Changes for v16:
- Added 'Acked-by: Arnd'
---
Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt | 3 +++
1 file changed, 3 insertions(+)
rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt b/Documentation/devicetree/bindings/soc/fsl/guts.txt
similarity index 91%
rename from Documentation/devicetree/bindings/powerpc/fsl/guts.txt
rename to Documentation/devicetree/bindings/soc/fsl/guts.txt
index b71b203..07adca9 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
+++ b/Documentation/devicetree/bindings/soc/fsl/guts.txt
@@ -25,6 +25,9 @@ Recommended properties:
- fsl,liodn-bits : Indicates the number of defined bits in the LIODN
registers, for those SOCs that have a PAMU device.
+ - little-endian : Indicates that the global utilities block is little
+ endian. The default is big endian.
+
Examples:
global-utilities@e0000 { /* global utilities block */
compatible = "fsl,mpc8548-guts";
--
2.1.0.27.g96db324
^ permalink raw reply related
* [v16, 3/7] soc: fsl: add GUTS driver for QorIQ platforms
From: Yangbo Lu @ 2016-11-09 3:14 UTC (permalink / raw)
To: linux-mmc, ulf.hansson, Scott Wood, Arnd Bergmann
Cc: linuxppc-dev, devicetree, linux-arm-kernel, linux-kernel,
linux-clk, linux-i2c, iommu, netdev, Greg Kroah-Hartman,
Mark Rutland, Rob Herring, Russell King, Jochen Friedrich,
Joerg Roedel, Claudiu Manoil, Bhupesh Sharma, Qiang Zhao,
Kumar Gala, Leo Li, Xiaobo Xie, Minghuan Lian, Yangbo Lu
In-Reply-To: <1478661252-42439-1-git-send-email-yangbo.lu@nxp.com>
The global utilities block controls power management, I/O device
enabling, power-onreset(POR) configuration monitoring, alternate
function selection for multiplexed signals,and clock control.
This patch adds a driver to manage and access global utilities block.
Initially only reading SVR and registering soc device are supported.
Other guts accesses, such as reading RCW, should eventually be moved
into this driver as well.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
---
Changes for v4:
- Added this patch
Changes for v5:
- Modified copyright info
- Changed MODULE_LICENSE to GPL
- Changed EXPORT_SYMBOL_GPL to EXPORT_SYMBOL
- Made FSL_GUTS user-invisible
- Added a complete compatible list for GUTS
- Stored guts info in file-scope variable
- Added mfspr() getting SVR
- Redefined GUTS APIs
- Called fsl_guts_init rather than using platform driver
- Removed useless parentheses
- Removed useless 'extern' key words
Changes for v6:
- Made guts thread safe in fsl_guts_init
Changes for v7:
- Removed 'ifdef' for function declaration in guts.h
Changes for v8:
- Fixes lines longer than 80 characters checkpatch issue
- Added 'Acked-by: Scott Wood'
Changes for v9:
- None
Changes for v10:
- None
Changes for v11:
- Changed to platform driver
Changes for v12:
- Removed "signed-off-by: Scott"
- Defined fsl_soc_die_attr struct array instead of
soc_device_attribute
- Re-designed soc_device_attribute for QorIQ SoC
- Other minor fixes
Changes for v13:
- Rebased
- Removed text after 'bool' in Kconfig
- Removed ARCH ifdefs
- Added more bits for ls1021a mask
- Used devm
Changes for v14:
- Used devm_ioremap_resource
Changes for v15:
- Fixed error code for devm_ioremap_resource
Changes for v16:
- Removed header file svr.h and calculated REV_MAJ/MIN in this driver
- Added 'Acked-by: Arnd'
---
drivers/soc/Kconfig | 3 +-
drivers/soc/fsl/Kconfig | 18 ++++
drivers/soc/fsl/Makefile | 1 +
drivers/soc/fsl/guts.c | 236 +++++++++++++++++++++++++++++++++++++++++++++++
include/linux/fsl/guts.h | 125 +++++++++++++++----------
5 files changed, 333 insertions(+), 50 deletions(-)
create mode 100644 drivers/soc/fsl/Kconfig
create mode 100644 drivers/soc/fsl/guts.c
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index e6e90e8..f31bceb 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -1,8 +1,7 @@
menu "SOC (System On Chip) specific Drivers"
source "drivers/soc/bcm/Kconfig"
-source "drivers/soc/fsl/qbman/Kconfig"
-source "drivers/soc/fsl/qe/Kconfig"
+source "drivers/soc/fsl/Kconfig"
source "drivers/soc/mediatek/Kconfig"
source "drivers/soc/qcom/Kconfig"
source "drivers/soc/rockchip/Kconfig"
diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
new file mode 100644
index 0000000..7a9fb9b
--- /dev/null
+++ b/drivers/soc/fsl/Kconfig
@@ -0,0 +1,18 @@
+#
+# Freescale SOC drivers
+#
+
+source "drivers/soc/fsl/qbman/Kconfig"
+source "drivers/soc/fsl/qe/Kconfig"
+
+config FSL_GUTS
+ bool
+ select SOC_BUS
+ help
+ The global utilities block controls power management, I/O device
+ enabling, power-onreset(POR) configuration monitoring, alternate
+ function selection for multiplexed signals,and clock control.
+ This driver is to manage and access global utilities block.
+ Initially only reading SVR and registering soc device are supported.
+ Other guts accesses, such as reading RCW, should eventually be moved
+ into this driver as well.
diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
index 75e1f53..44b3beb 100644
--- a/drivers/soc/fsl/Makefile
+++ b/drivers/soc/fsl/Makefile
@@ -5,3 +5,4 @@
obj-$(CONFIG_FSL_DPAA) += qbman/
obj-$(CONFIG_QUICC_ENGINE) += qe/
obj-$(CONFIG_CPM) += qe/
+obj-$(CONFIG_FSL_GUTS) += guts.o
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
new file mode 100644
index 0000000..0ac8826
--- /dev/null
+++ b/drivers/soc/fsl/guts.c
@@ -0,0 +1,236 @@
+/*
+ * Freescale QorIQ Platforms GUTS Driver
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/io.h>
+#include <linux/slab.h>
+#include <linux/module.h>
+#include <linux/of_fdt.h>
+#include <linux/sys_soc.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/fsl/guts.h>
+
+struct guts {
+ struct ccsr_guts __iomem *regs;
+ bool little_endian;
+};
+
+struct fsl_soc_die_attr {
+ char *die;
+ u32 svr;
+ u32 mask;
+};
+
+static struct guts *guts;
+static struct soc_device_attribute soc_dev_attr;
+static struct soc_device *soc_dev;
+
+
+/* SoC die attribute definition for QorIQ platform */
+static const struct fsl_soc_die_attr fsl_soc_die[] = {
+ /*
+ * Power Architecture-based SoCs T Series
+ */
+
+ /* Die: T4240, SoC: T4240/T4160/T4080 */
+ { .die = "T4240",
+ .svr = 0x82400000,
+ .mask = 0xfff00000,
+ },
+ /* Die: T1040, SoC: T1040/T1020/T1042/T1022 */
+ { .die = "T1040",
+ .svr = 0x85200000,
+ .mask = 0xfff00000,
+ },
+ /* Die: T2080, SoC: T2080/T2081 */
+ { .die = "T2080",
+ .svr = 0x85300000,
+ .mask = 0xfff00000,
+ },
+ /* Die: T1024, SoC: T1024/T1014/T1023/T1013 */
+ { .die = "T1024",
+ .svr = 0x85400000,
+ .mask = 0xfff00000,
+ },
+
+ /*
+ * ARM-based SoCs LS Series
+ */
+
+ /* Die: LS1043A, SoC: LS1043A/LS1023A */
+ { .die = "LS1043A",
+ .svr = 0x87920000,
+ .mask = 0xffff0000,
+ },
+ /* Die: LS2080A, SoC: LS2080A/LS2040A/LS2085A */
+ { .die = "LS2080A",
+ .svr = 0x87010000,
+ .mask = 0xff3f0000,
+ },
+ /* Die: LS1088A, SoC: LS1088A/LS1048A/LS1084A/LS1044A */
+ { .die = "LS1088A",
+ .svr = 0x87030000,
+ .mask = 0xff3f0000,
+ },
+ /* Die: LS1012A, SoC: LS1012A */
+ { .die = "LS1012A",
+ .svr = 0x87040000,
+ .mask = 0xffff0000,
+ },
+ /* Die: LS1046A, SoC: LS1046A/LS1026A */
+ { .die = "LS1046A",
+ .svr = 0x87070000,
+ .mask = 0xffff0000,
+ },
+ /* Die: LS2088A, SoC: LS2088A/LS2048A/LS2084A/LS2044A */
+ { .die = "LS2088A",
+ .svr = 0x87090000,
+ .mask = 0xff3f0000,
+ },
+ /* Die: LS1021A, SoC: LS1021A/LS1020A/LS1022A */
+ { .die = "LS1021A",
+ .svr = 0x87000000,
+ .mask = 0xfff70000,
+ },
+ { },
+};
+
+static const struct fsl_soc_die_attr *fsl_soc_die_match(
+ u32 svr, const struct fsl_soc_die_attr *matches)
+{
+ while (matches->svr) {
+ if (matches->svr == (svr & matches->mask))
+ return matches;
+ matches++;
+ };
+ return NULL;
+}
+
+u32 fsl_guts_get_svr(void)
+{
+ u32 svr = 0;
+
+ if (!guts || !guts->regs)
+ return svr;
+
+ if (guts->little_endian)
+ svr = ioread32(&guts->regs->svr);
+ else
+ svr = ioread32be(&guts->regs->svr);
+
+ return svr;
+}
+EXPORT_SYMBOL(fsl_guts_get_svr);
+
+static int fsl_guts_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct device *dev = &pdev->dev;
+ struct resource *res;
+ const struct fsl_soc_die_attr *soc_die;
+ const char *machine;
+ u32 svr;
+
+ /* Initialize guts */
+ guts = devm_kzalloc(dev, sizeof(*guts), GFP_KERNEL);
+ if (!guts)
+ return -ENOMEM;
+
+ guts->little_endian = of_property_read_bool(np, "little-endian");
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ guts->regs = devm_ioremap_resource(dev, res);
+ if (IS_ERR(guts->regs))
+ return PTR_ERR(guts->regs);
+
+ /* Register soc device */
+ machine = of_flat_dt_get_machine_name();
+ if (machine)
+ soc_dev_attr.machine = devm_kstrdup(dev, machine, GFP_KERNEL);
+
+ svr = fsl_guts_get_svr();
+ soc_die = fsl_soc_die_match(svr, fsl_soc_die);
+ if (soc_die) {
+ soc_dev_attr.family = devm_kasprintf(dev, GFP_KERNEL,
+ "QorIQ %s", soc_die->die);
+ } else {
+ soc_dev_attr.family = devm_kasprintf(dev, GFP_KERNEL, "QorIQ");
+ }
+ soc_dev_attr.soc_id = devm_kasprintf(dev, GFP_KERNEL,
+ "svr:0x%08x", svr);
+ soc_dev_attr.revision = devm_kasprintf(dev, GFP_KERNEL, "%d.%d",
+ (svr >> 4) & 0xf, svr & 0xf);
+
+ soc_dev = soc_device_register(&soc_dev_attr);
+ if (IS_ERR(soc_dev))
+ return PTR_ERR(soc_dev);
+
+ pr_info("Machine: %s\n", soc_dev_attr.machine);
+ pr_info("SoC family: %s\n", soc_dev_attr.family);
+ pr_info("SoC ID: %s, Revision: %s\n",
+ soc_dev_attr.soc_id, soc_dev_attr.revision);
+ return 0;
+}
+
+static int fsl_guts_remove(struct platform_device *dev)
+{
+ soc_device_unregister(soc_dev);
+ return 0;
+}
+
+/*
+ * Table for matching compatible strings, for device tree
+ * guts node, for Freescale QorIQ SOCs.
+ */
+static const struct of_device_id fsl_guts_of_match[] = {
+ { .compatible = "fsl,qoriq-device-config-1.0", },
+ { .compatible = "fsl,qoriq-device-config-2.0", },
+ { .compatible = "fsl,p1010-guts", },
+ { .compatible = "fsl,p1020-guts", },
+ { .compatible = "fsl,p1021-guts", },
+ { .compatible = "fsl,p1022-guts", },
+ { .compatible = "fsl,p1023-guts", },
+ { .compatible = "fsl,p2020-guts", },
+ { .compatible = "fsl,bsc9131-guts", },
+ { .compatible = "fsl,bsc9132-guts", },
+ { .compatible = "fsl,mpc8536-guts", },
+ { .compatible = "fsl,mpc8544-guts", },
+ { .compatible = "fsl,mpc8548-guts", },
+ { .compatible = "fsl,mpc8568-guts", },
+ { .compatible = "fsl,mpc8569-guts", },
+ { .compatible = "fsl,mpc8572-guts", },
+ { .compatible = "fsl,ls1021a-dcfg", },
+ { .compatible = "fsl,ls1043a-dcfg", },
+ { .compatible = "fsl,ls2080a-dcfg", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, fsl_guts_of_match);
+
+static struct platform_driver fsl_guts_driver = {
+ .driver = {
+ .name = "fsl-guts",
+ .of_match_table = fsl_guts_of_match,
+ },
+ .probe = fsl_guts_probe,
+ .remove = fsl_guts_remove,
+};
+
+static int __init fsl_guts_init(void)
+{
+ return platform_driver_register(&fsl_guts_driver);
+}
+core_initcall(fsl_guts_init);
+
+static void __exit fsl_guts_exit(void)
+{
+ platform_driver_unregister(&fsl_guts_driver);
+}
+module_exit(fsl_guts_exit);
diff --git a/include/linux/fsl/guts.h b/include/linux/fsl/guts.h
index 649e917..3efa3b8 100644
--- a/include/linux/fsl/guts.h
+++ b/include/linux/fsl/guts.h
@@ -29,83 +29,112 @@
* #ifdefs.
*/
struct ccsr_guts {
- __be32 porpllsr; /* 0x.0000 - POR PLL Ratio Status Register */
- __be32 porbmsr; /* 0x.0004 - POR Boot Mode Status Register */
- __be32 porimpscr; /* 0x.0008 - POR I/O Impedance Status and Control Register */
- __be32 pordevsr; /* 0x.000c - POR I/O Device Status Register */
- __be32 pordbgmsr; /* 0x.0010 - POR Debug Mode Status Register */
- __be32 pordevsr2; /* 0x.0014 - POR device status register 2 */
+ u32 porpllsr; /* 0x.0000 - POR PLL Ratio Status Register */
+ u32 porbmsr; /* 0x.0004 - POR Boot Mode Status Register */
+ u32 porimpscr; /* 0x.0008 - POR I/O Impedance Status and
+ * Control Register
+ */
+ u32 pordevsr; /* 0x.000c - POR I/O Device Status Register */
+ u32 pordbgmsr; /* 0x.0010 - POR Debug Mode Status Register */
+ u32 pordevsr2; /* 0x.0014 - POR device status register 2 */
u8 res018[0x20 - 0x18];
- __be32 porcir; /* 0x.0020 - POR Configuration Information Register */
+ u32 porcir; /* 0x.0020 - POR Configuration Information
+ * Register
+ */
u8 res024[0x30 - 0x24];
- __be32 gpiocr; /* 0x.0030 - GPIO Control Register */
+ u32 gpiocr; /* 0x.0030 - GPIO Control Register */
u8 res034[0x40 - 0x34];
- __be32 gpoutdr; /* 0x.0040 - General-Purpose Output Data Register */
+ u32 gpoutdr; /* 0x.0040 - General-Purpose Output Data
+ * Register
+ */
u8 res044[0x50 - 0x44];
- __be32 gpindr; /* 0x.0050 - General-Purpose Input Data Register */
+ u32 gpindr; /* 0x.0050 - General-Purpose Input Data
+ * Register
+ */
u8 res054[0x60 - 0x54];
- __be32 pmuxcr; /* 0x.0060 - Alternate Function Signal Multiplex Control */
- __be32 pmuxcr2; /* 0x.0064 - Alternate function signal multiplex control 2 */
- __be32 dmuxcr; /* 0x.0068 - DMA Mux Control Register */
+ u32 pmuxcr; /* 0x.0060 - Alternate Function Signal
+ * Multiplex Control
+ */
+ u32 pmuxcr2; /* 0x.0064 - Alternate function signal
+ * multiplex control 2
+ */
+ u32 dmuxcr; /* 0x.0068 - DMA Mux Control Register */
u8 res06c[0x70 - 0x6c];
- __be32 devdisr; /* 0x.0070 - Device Disable Control */
+ u32 devdisr; /* 0x.0070 - Device Disable Control */
#define CCSR_GUTS_DEVDISR_TB1 0x00001000
#define CCSR_GUTS_DEVDISR_TB0 0x00004000
- __be32 devdisr2; /* 0x.0074 - Device Disable Control 2 */
+ u32 devdisr2; /* 0x.0074 - Device Disable Control 2 */
u8 res078[0x7c - 0x78];
- __be32 pmjcr; /* 0x.007c - 4 Power Management Jog Control Register */
- __be32 powmgtcsr; /* 0x.0080 - Power Management Status and Control Register */
- __be32 pmrccr; /* 0x.0084 - Power Management Reset Counter Configuration Register */
- __be32 pmpdccr; /* 0x.0088 - Power Management Power Down Counter Configuration Register */
- __be32 pmcdr; /* 0x.008c - 4Power management clock disable register */
- __be32 mcpsumr; /* 0x.0090 - Machine Check Summary Register */
- __be32 rstrscr; /* 0x.0094 - Reset Request Status and Control Register */
- __be32 ectrstcr; /* 0x.0098 - Exception reset control register */
- __be32 autorstsr; /* 0x.009c - Automatic reset status register */
- __be32 pvr; /* 0x.00a0 - Processor Version Register */
- __be32 svr; /* 0x.00a4 - System Version Register */
+ u32 pmjcr; /* 0x.007c - 4 Power Management Jog Control
+ * Register
+ */
+ u32 powmgtcsr; /* 0x.0080 - Power Management Status and
+ * Control Register
+ */
+ u32 pmrccr; /* 0x.0084 - Power Management Reset Counter
+ * Configuration Register
+ */
+ u32 pmpdccr; /* 0x.0088 - Power Management Power Down Counter
+ * Configuration Register
+ */
+ u32 pmcdr; /* 0x.008c - 4Power management clock disable
+ * register
+ */
+ u32 mcpsumr; /* 0x.0090 - Machine Check Summary Register */
+ u32 rstrscr; /* 0x.0094 - Reset Request Status and
+ * Control Register
+ */
+ u32 ectrstcr; /* 0x.0098 - Exception reset control register */
+ u32 autorstsr; /* 0x.009c - Automatic reset status register */
+ u32 pvr; /* 0x.00a0 - Processor Version Register */
+ u32 svr; /* 0x.00a4 - System Version Register */
u8 res0a8[0xb0 - 0xa8];
- __be32 rstcr; /* 0x.00b0 - Reset Control Register */
+ u32 rstcr; /* 0x.00b0 - Reset Control Register */
u8 res0b4[0xc0 - 0xb4];
- __be32 iovselsr; /* 0x.00c0 - I/O voltage select status register
+ u32 iovselsr; /* 0x.00c0 - I/O voltage select status register
Called 'elbcvselcr' on 86xx SOCs */
u8 res0c4[0x100 - 0xc4];
- __be32 rcwsr[16]; /* 0x.0100 - Reset Control Word Status registers
+ u32 rcwsr[16]; /* 0x.0100 - Reset Control Word Status registers
There are 16 registers */
u8 res140[0x224 - 0x140];
- __be32 iodelay1; /* 0x.0224 - IO delay control register 1 */
- __be32 iodelay2; /* 0x.0228 - IO delay control register 2 */
+ u32 iodelay1; /* 0x.0224 - IO delay control register 1 */
+ u32 iodelay2; /* 0x.0228 - IO delay control register 2 */
u8 res22c[0x604 - 0x22c];
- __be32 pamubypenr; /* 0x.604 - PAMU bypass enable register */
+ u32 pamubypenr; /* 0x.604 - PAMU bypass enable register */
u8 res608[0x800 - 0x608];
- __be32 clkdvdr; /* 0x.0800 - Clock Divide Register */
+ u32 clkdvdr; /* 0x.0800 - Clock Divide Register */
u8 res804[0x900 - 0x804];
- __be32 ircr; /* 0x.0900 - Infrared Control Register */
+ u32 ircr; /* 0x.0900 - Infrared Control Register */
u8 res904[0x908 - 0x904];
- __be32 dmacr; /* 0x.0908 - DMA Control Register */
+ u32 dmacr; /* 0x.0908 - DMA Control Register */
u8 res90c[0x914 - 0x90c];
- __be32 elbccr; /* 0x.0914 - eLBC Control Register */
+ u32 elbccr; /* 0x.0914 - eLBC Control Register */
u8 res918[0xb20 - 0x918];
- __be32 ddr1clkdr; /* 0x.0b20 - DDR1 Clock Disable Register */
- __be32 ddr2clkdr; /* 0x.0b24 - DDR2 Clock Disable Register */
- __be32 ddrclkdr; /* 0x.0b28 - DDR Clock Disable Register */
+ u32 ddr1clkdr; /* 0x.0b20 - DDR1 Clock Disable Register */
+ u32 ddr2clkdr; /* 0x.0b24 - DDR2 Clock Disable Register */
+ u32 ddrclkdr; /* 0x.0b28 - DDR Clock Disable Register */
u8 resb2c[0xe00 - 0xb2c];
- __be32 clkocr; /* 0x.0e00 - Clock Out Select Register */
+ u32 clkocr; /* 0x.0e00 - Clock Out Select Register */
u8 rese04[0xe10 - 0xe04];
- __be32 ddrdllcr; /* 0x.0e10 - DDR DLL Control Register */
+ u32 ddrdllcr; /* 0x.0e10 - DDR DLL Control Register */
u8 rese14[0xe20 - 0xe14];
- __be32 lbcdllcr; /* 0x.0e20 - LBC DLL Control Register */
- __be32 cpfor; /* 0x.0e24 - L2 charge pump fuse override register */
+ u32 lbcdllcr; /* 0x.0e20 - LBC DLL Control Register */
+ u32 cpfor; /* 0x.0e24 - L2 charge pump fuse override
+ * register
+ */
u8 rese28[0xf04 - 0xe28];
- __be32 srds1cr0; /* 0x.0f04 - SerDes1 Control Register 0 */
- __be32 srds1cr1; /* 0x.0f08 - SerDes1 Control Register 0 */
+ u32 srds1cr0; /* 0x.0f04 - SerDes1 Control Register 0 */
+ u32 srds1cr1; /* 0x.0f08 - SerDes1 Control Register 0 */
u8 resf0c[0xf2c - 0xf0c];
- __be32 itcr; /* 0x.0f2c - Internal transaction control register */
+ u32 itcr; /* 0x.0f2c - Internal transaction control
+ * register
+ */
u8 resf30[0xf40 - 0xf30];
- __be32 srds2cr0; /* 0x.0f40 - SerDes2 Control Register 0 */
- __be32 srds2cr1; /* 0x.0f44 - SerDes2 Control Register 0 */
+ u32 srds2cr0; /* 0x.0f40 - SerDes2 Control Register 0 */
+ u32 srds2cr1; /* 0x.0f44 - SerDes2 Control Register 0 */
} __attribute__ ((packed));
+u32 fsl_guts_get_svr(void);
/* Alternate function signal multiplex control */
#define MPC85xx_PMUXCR_QE(x) (0x8000 >> (x))
--
2.1.0.27.g96db324
^ permalink raw reply related
* [v16, 4/7] MAINTAINERS: add entry for Freescale SoC drivers
From: Yangbo Lu @ 2016-11-09 3:14 UTC (permalink / raw)
To: linux-mmc, ulf.hansson, Scott Wood, Arnd Bergmann
Cc: linuxppc-dev, devicetree, linux-arm-kernel, linux-kernel,
linux-clk, linux-i2c, iommu, netdev, Greg Kroah-Hartman,
Mark Rutland, Rob Herring, Russell King, Jochen Friedrich,
Joerg Roedel, Claudiu Manoil, Bhupesh Sharma, Qiang Zhao,
Kumar Gala, Leo Li, Xiaobo Xie, Minghuan Lian, Yangbo Lu
In-Reply-To: <1478661252-42439-1-git-send-email-yangbo.lu@nxp.com>
Add maintainer entry for Freescale SoC drivers including
the QE library and the GUTS driver now. Also add maintainer
for QE library.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Acked-by: Scott Wood <oss@buserror.net>
Acked-by: Qiang Zhao <qiang.zhao@nxp.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
---
Changes for v8:
- Added this patch
Changes for v9:
- Added linux-arm mail list
- Removed GUTS driver entry
Changes for v10:
- Changed 'DRIVER' to 'DRIVERS'
- Added 'Acked-by' of Scott and Qiang
Changes for v11:
- None
Changes for v12:
- None
Changes for v13:
- None
Changes for v14:
- None
Changes for v15:
- None
Changes for v16:
- Added 'Acked-by: Arnd'
---
MAINTAINERS | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9be761f..e1a8835 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5045,9 +5045,18 @@ S: Maintained
F: drivers/net/ethernet/freescale/fman
F: Documentation/devicetree/bindings/powerpc/fsl/fman.txt
+FREESCALE SOC DRIVERS
+M: Scott Wood <oss@buserror.net>
+L: linuxppc-dev@lists.ozlabs.org
+L: linux-arm-kernel@lists.infradead.org
+S: Maintained
+F: drivers/soc/fsl/
+F: include/linux/fsl/
+
FREESCALE QUICC ENGINE LIBRARY
+M: Qiang Zhao <qiang.zhao@nxp.com>
L: linuxppc-dev@lists.ozlabs.org
-S: Orphan
+S: Maintained
F: drivers/soc/fsl/qe/
F: include/soc/fsl/*qe*.h
F: include/soc/fsl/*ucc*.h
--
2.1.0.27.g96db324
^ permalink raw reply related
* [v16, 5/7] base: soc: introduce soc_device_match() interface
From: Yangbo Lu @ 2016-11-09 3:14 UTC (permalink / raw)
To: linux-mmc, ulf.hansson, Scott Wood, Arnd Bergmann
Cc: linuxppc-dev, devicetree, linux-arm-kernel, linux-kernel,
linux-clk, linux-i2c, iommu, netdev, Greg Kroah-Hartman,
Mark Rutland, Rob Herring, Russell King, Jochen Friedrich,
Joerg Roedel, Claudiu Manoil, Bhupesh Sharma, Qiang Zhao,
Kumar Gala, Leo Li, Xiaobo Xie, Minghuan Lian, Yangbo Lu
In-Reply-To: <1478661252-42439-1-git-send-email-yangbo.lu@nxp.com>
From: Arnd Bergmann <arnd@arndb.de>
We keep running into cases where device drivers want to know the exact
version of the a SoC they are currently running on. In the past, this has
usually been done through a vendor specific API that can be called by a
driver, or by directly accessing some kind of version register that is
not part of the device itself but that belongs to a global register area
of the chip.
Common reasons for doing this include:
- A machine is not using devicetree or similar for passing data about
on-chip devices, but just announces their presence using boot-time
platform devices, and the machine code itself does not care about the
revision.
- There is existing firmware or boot loaders with existing DT binaries
with generic compatible strings that do not identify the particular
revision of each device, but the driver knows which SoC revisions
include which part.
- A prerelease version of a chip has some quirks and we are using the same
version of the bootloader and the DT blob on both the prerelease and the
final version. An update of the DT binding seems inappropriate because
that would involve maintaining multiple copies of the dts and/or
bootloader.
This patch introduces the soc_device_match() interface that is meant to
work like of_match_node() but instead of identifying the version of a
device, it identifies the SoC itself using a vendor-agnostic interface.
Unlike of_match_node(), we do not do an exact string compare but instead
use glob_match() to allow wildcards in strings.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Changes for v11:
- Added this patch for soc match
Changes for v12:
- Corrected the author
- Rewrited soc_device_match with while loop
Changes for v13:
- Added ack from Greg
Changes for v14:
- None
Changes for v15:
- None
Changes for v16:
- None
---
drivers/base/Kconfig | 1 +
drivers/base/soc.c | 66 +++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/sys_soc.h | 3 +++
3 files changed, 70 insertions(+)
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index d02e7c0..2abea87 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -237,6 +237,7 @@ config GENERIC_CPU_AUTOPROBE
config SOC_BUS
bool
+ select GLOB
source "drivers/base/regmap/Kconfig"
diff --git a/drivers/base/soc.c b/drivers/base/soc.c
index b63f23e..0c5cf87 100644
--- a/drivers/base/soc.c
+++ b/drivers/base/soc.c
@@ -13,6 +13,7 @@
#include <linux/spinlock.h>
#include <linux/sys_soc.h>
#include <linux/err.h>
+#include <linux/glob.h>
static DEFINE_IDA(soc_ida);
@@ -159,3 +160,68 @@ static int __init soc_bus_register(void)
return bus_register(&soc_bus_type);
}
core_initcall(soc_bus_register);
+
+static int soc_device_match_one(struct device *dev, void *arg)
+{
+ struct soc_device *soc_dev = container_of(dev, struct soc_device, dev);
+ const struct soc_device_attribute *match = arg;
+
+ if (match->machine &&
+ !glob_match(match->machine, soc_dev->attr->machine))
+ return 0;
+
+ if (match->family &&
+ !glob_match(match->family, soc_dev->attr->family))
+ return 0;
+
+ if (match->revision &&
+ !glob_match(match->revision, soc_dev->attr->revision))
+ return 0;
+
+ if (match->soc_id &&
+ !glob_match(match->soc_id, soc_dev->attr->soc_id))
+ return 0;
+
+ return 1;
+}
+
+/*
+ * soc_device_match - identify the SoC in the machine
+ * @matches: zero-terminated array of possible matches
+ *
+ * returns the first matching entry of the argument array, or NULL
+ * if none of them match.
+ *
+ * This function is meant as a helper in place of of_match_node()
+ * in cases where either no device tree is available or the information
+ * in a device node is insufficient to identify a particular variant
+ * by its compatible strings or other properties. For new devices,
+ * the DT binding should always provide unique compatible strings
+ * that allow the use of of_match_node() instead.
+ *
+ * The calling function can use the .data entry of the
+ * soc_device_attribute to pass a structure or function pointer for
+ * each entry.
+ */
+const struct soc_device_attribute *soc_device_match(
+ const struct soc_device_attribute *matches)
+{
+ int ret = 0;
+
+ if (!matches)
+ return NULL;
+
+ while (!ret) {
+ if (!(matches->machine || matches->family ||
+ matches->revision || matches->soc_id))
+ break;
+ ret = bus_for_each_dev(&soc_bus_type, NULL, (void *)matches,
+ soc_device_match_one);
+ if (!ret)
+ matches++;
+ else
+ return matches;
+ }
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(soc_device_match);
diff --git a/include/linux/sys_soc.h b/include/linux/sys_soc.h
index 2739ccb..9f5eb06 100644
--- a/include/linux/sys_soc.h
+++ b/include/linux/sys_soc.h
@@ -13,6 +13,7 @@ struct soc_device_attribute {
const char *family;
const char *revision;
const char *soc_id;
+ const void *data;
};
/**
@@ -34,4 +35,6 @@ void soc_device_unregister(struct soc_device *soc_dev);
*/
struct device *soc_device_to_device(struct soc_device *soc);
+const struct soc_device_attribute *soc_device_match(
+ const struct soc_device_attribute *matches);
#endif /* __SOC_BUS_H */
--
2.1.0.27.g96db324
^ permalink raw reply related
* [v16, 6/7] base: soc: Check for NULL SoC device attributes
From: Yangbo Lu @ 2016-11-09 3:14 UTC (permalink / raw)
To: linux-mmc, ulf.hansson, Scott Wood, Arnd Bergmann
Cc: linuxppc-dev, devicetree, linux-arm-kernel, linux-kernel,
linux-clk, linux-i2c, iommu, netdev, Greg Kroah-Hartman,
Mark Rutland, Rob Herring, Russell King, Jochen Friedrich,
Joerg Roedel, Claudiu Manoil, Bhupesh Sharma, Qiang Zhao,
Kumar Gala, Leo Li, Xiaobo Xie, Minghuan Lian, Geert Uytterhoeven
In-Reply-To: <1478661252-42439-1-git-send-email-yangbo.lu@nxp.com>
From: Geert Uytterhoeven <geert+renesas@glider.be>
If soc_device_match() is used to check the value of a specific
attribute that is not present for the current SoC, the kernel crashes
with a NULL pointer dereference.
Fix this by explicitly checking for the absence of a needed property,
and considering this a non-match.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Arnd Bergmann <arnd@arndb.de>
---
Changes for v16:
- Added this patch
---
drivers/base/soc.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/base/soc.c b/drivers/base/soc.c
index 0c5cf87..0e701e2 100644
--- a/drivers/base/soc.c
+++ b/drivers/base/soc.c
@@ -167,19 +167,23 @@ static int soc_device_match_one(struct device *dev, void *arg)
const struct soc_device_attribute *match = arg;
if (match->machine &&
- !glob_match(match->machine, soc_dev->attr->machine))
+ (!soc_dev->attr->machine ||
+ !glob_match(match->machine, soc_dev->attr->machine)))
return 0;
if (match->family &&
- !glob_match(match->family, soc_dev->attr->family))
+ (!soc_dev->attr->family ||
+ !glob_match(match->family, soc_dev->attr->family)))
return 0;
if (match->revision &&
- !glob_match(match->revision, soc_dev->attr->revision))
+ (!soc_dev->attr->revision ||
+ !glob_match(match->revision, soc_dev->attr->revision)))
return 0;
if (match->soc_id &&
- !glob_match(match->soc_id, soc_dev->attr->soc_id))
+ (!soc_dev->attr->soc_id ||
+ !glob_match(match->soc_id, soc_dev->attr->soc_id)))
return 0;
return 1;
--
2.1.0.27.g96db324
^ permalink raw reply related
* [v16, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
From: Yangbo Lu @ 2016-11-09 3:14 UTC (permalink / raw)
To: linux-mmc, ulf.hansson, Scott Wood, Arnd Bergmann
Cc: linuxppc-dev, devicetree, linux-arm-kernel, linux-kernel,
linux-clk, linux-i2c, iommu, netdev, Greg Kroah-Hartman,
Mark Rutland, Rob Herring, Russell King, Jochen Friedrich,
Joerg Roedel, Claudiu Manoil, Bhupesh Sharma, Qiang Zhao,
Kumar Gala, Leo Li, Xiaobo Xie, Minghuan Lian, Yangbo Lu
In-Reply-To: <1478661252-42439-1-git-send-email-yangbo.lu@nxp.com>
The eSDHC of T4240-R1.0-R2.0 has incorrect vender version and spec version.
Acturally the right version numbers should be VVN=0x13 and SVN = 0x1.
This patch adds the GUTS driver support for eSDHC driver to match SoC.
And fix host version to avoid that incorrect version numbers break down
the ADMA data transfer.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Scott Wood <oss@buserror.net>
Acked-by: Arnd Bergmann <arnd@arndb.de>
---
Changes for v2:
- Got SVR through iomap instead of dts
Changes for v3:
- Managed GUTS through syscon instead of iomap in eSDHC driver
Changes for v4:
- Got SVR by GUTS driver instead of SYSCON
Changes for v5:
- Changed to get SVR through API fsl_guts_get_svr()
- Combined patch 4, patch 5 and patch 6 into one
Changes for v6:
- Added 'Acked-by: Ulf Hansson'
Changes for v7:
- None
Changes for v8:
- Added 'Acked-by: Scott Wood'
Changes for v9:
- None
Changes for v10:
- None
Changes for v11:
- Changed to use soc_device_match
Changes for v12:
- Matched soc through .family field instead of .soc_id
Changes for v13:
- None
Changes for v14:
- None
Changes for v15:
- None
Changes for v16:
- Added 'Acked-by: Arnd'
---
drivers/mmc/host/Kconfig | 1 +
drivers/mmc/host/sdhci-of-esdhc.c | 20 ++++++++++++++++++++
2 files changed, 21 insertions(+)
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 5cf7eba..4128a3c 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -144,6 +144,7 @@ config MMC_SDHCI_OF_ESDHC
depends on MMC_SDHCI_PLTFM
depends on PPC || ARCH_MXC || ARCH_LAYERSCAPE
select MMC_SDHCI_IO_ACCESSORS
+ select FSL_GUTS
help
This selects the Freescale eSDHC controller support.
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
index fb71c86..57bdb9e 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -18,6 +18,7 @@
#include <linux/of.h>
#include <linux/delay.h>
#include <linux/module.h>
+#include <linux/sys_soc.h>
#include <linux/mmc/host.h>
#include "sdhci-pltfm.h"
#include "sdhci-esdhc.h"
@@ -28,6 +29,7 @@
struct sdhci_esdhc {
u8 vendor_ver;
u8 spec_ver;
+ bool quirk_incorrect_hostver;
};
/**
@@ -73,6 +75,8 @@ static u32 esdhc_readl_fixup(struct sdhci_host *host,
static u16 esdhc_readw_fixup(struct sdhci_host *host,
int spec_reg, u32 value)
{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_esdhc *esdhc = sdhci_pltfm_priv(pltfm_host);
u16 ret;
int shift = (spec_reg & 0x2) * 8;
@@ -80,6 +84,12 @@ static u16 esdhc_readw_fixup(struct sdhci_host *host,
ret = value & 0xffff;
else
ret = (value >> shift) & 0xffff;
+ /* Workaround for T4240-R1.0-R2.0 eSDHC which has incorrect
+ * vendor version and spec version information.
+ */
+ if ((spec_reg == SDHCI_HOST_VERSION) &&
+ (esdhc->quirk_incorrect_hostver))
+ ret = (VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) | SDHCI_SPEC_200;
return ret;
}
@@ -558,6 +568,12 @@ static const struct sdhci_pltfm_data sdhci_esdhc_le_pdata = {
.ops = &sdhci_esdhc_le_ops,
};
+static struct soc_device_attribute soc_incorrect_hostver[] = {
+ { .family = "QorIQ T4240", .revision = "1.0", },
+ { .family = "QorIQ T4240", .revision = "2.0", },
+ { },
+};
+
static void esdhc_init(struct platform_device *pdev, struct sdhci_host *host)
{
struct sdhci_pltfm_host *pltfm_host;
@@ -571,6 +587,10 @@ static void esdhc_init(struct platform_device *pdev, struct sdhci_host *host)
esdhc->vendor_ver = (host_ver & SDHCI_VENDOR_VER_MASK) >>
SDHCI_VENDOR_VER_SHIFT;
esdhc->spec_ver = host_ver & SDHCI_SPEC_VER_MASK;
+ if (soc_device_match(soc_incorrect_hostver))
+ esdhc->quirk_incorrect_hostver = true;
+ else
+ esdhc->quirk_incorrect_hostver = false;
}
static int sdhci_esdhc_probe(struct platform_device *pdev)
--
2.1.0.27.g96db324
^ permalink raw reply related
* Re: [PATCH 7/9] populate: discover XFS structure fields and fuzz verbs, and use them to fuzz fields
From: Eryu Guan @ 2016-11-09 3:32 UTC (permalink / raw)
To: Darrick J. Wong; +Cc: david, linux-xfs, fstests
In-Reply-To: <147830507411.1919.17534443838350465519.stgit@birch.djwong.org>
On Fri, Nov 04, 2016 at 05:17:54PM -0700, Darrick J. Wong wrote:
> Create some routines to help us perform targeted fuzzing of individual
> fields in various XFS structures. Specifically, we want the caller to
> drop the xfs_db iocursor on the victim field; from there, the scripts
> should discover all available fields and fuzzing verbs, and try each
> fuzz verb on every available field.
>
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> ---
> common/fuzzy | 191 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 191 insertions(+)
>
>
> diff --git a/common/fuzzy b/common/fuzzy
> index 20f1d29..6af47f1 100644
> --- a/common/fuzzy
> +++ b/common/fuzzy
> @@ -81,3 +81,194 @@ _scratch_scrub() {
> ;;
> esac
> }
> +
> +# Filter the xfs_db print command's field debug information
> +# into field name and type.
> +__filter_xfs_db_print_fields() {
> + 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
> + 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
> +}
> +
> +# Navigate to some part of the filesystem and print the field info.
> +_scratch_xfs_list_metadata_fields() {
> + if [ -n "${SCRATCH_XFS_LIST_METADATA_FIELDS}" ]; then
> + echo "${SCRATCH_XFS_LIST_METADATA_FIELDS}" | sed -e 's/ /\n/g'
> + return;
> + fi
> +
> + (for arg in "$@"; do
> + echo "${arg}"
> + done
> + echo "print") | _scratch_xfs_db | __filter_xfs_db_print_fields
> +}
> +
> +# Get a metadata field
> +_scratch_xfs_get_metadata_field() {
> + key="$1"
> + shift
> +
> + grep_key="$(echo "${key}" | tr '[]()' '....')"
> + (for arg in "$@"; do
> + echo "${arg}"
> + done
> + echo "print ${key}") | _scratch_xfs_db | grep "^${grep_key}" | \
> + sed -e 's/^.* = //g'
> +}
> +
> +# Set a metadata field
> +_scratch_xfs_set_metadata_field() {
> + key="$1"
> + value="$2"
> + shift; shift
> + (for arg in "$@"; do
> + echo "${arg}"
> + done
> + echo "write -d ${key} ${value}") | _scratch_xfs_db -x
> + echo
> +}
> +
> +# Fuzz a metadata field
> +_scratch_xfs_fuzz_metadata_field() {
> + key="$1"
> + value="$2"
> + shift; shift
> +
> + if [ "${key}" = "crc" ]; then
> + fuzz_arg="-c"
> + else
> + fuzz_arg="-d"
> + fi
> + oldval="$(_scratch_xfs_get_metadata_field "${key}" "$@")"
> + (for arg in "$@"; do
> + echo "${arg}"
> + done
> + echo "fuzz ${fuzz_arg} ${key} ${value}") | _scratch_xfs_db -x
> + echo
> + newval="$(_scratch_xfs_get_metadata_field "${key}" "$@" 2> /dev/null)"
> + if [ "${oldval}" = "${newval}" ]; then
> + echo "Field ${key} already set to ${oldval}, skipping test."
> + return 1
> + fi
> + return 0
> +}
> +
> +# Try to forcibly unmount the scratch fs
> +__scratch_xfs_fuzz_unmount()
> +{
> + while _scratch_unmount 2>/dev/null; do sleep 0.2; done
Shouldn't this be
while ! _scratch_unmount 2>/dev/null; do sleep 0.2; done
so it only sleeps and try again if umount failed?
Thanks,
Eryu
> +}
> +
> +# Restore metadata to scratch device prior to field-fuzzing.
> +__scratch_xfs_fuzz_mdrestore()
> +{
> + test -e "${POPULATE_METADUMP}" || _fail "Need to set POPULATE_METADUMP"
> +
> + __scratch_xfs_fuzz_unmount
> + xfs_mdrestore "${POPULATE_METADUMP}" "${SCRATCH_DEV}"
> +}
> +
> +__fuzz_notify() {
> + echo "$@"
> + test -w /dev/ttyprintk && echo "$@" >> /dev/ttyprintk
> +}
> +
> +# Fuzz one field of some piece of metadata
> +__scratch_xfs_fuzz_field_test() {
> + field="$1"
> + fuzzverb="$2"
> + shift; shift
> +
> + # Set the new field value
> + __fuzz_notify "+ Fuzz ${field} = ${fuzzverb}"
> + echo "========================"
> + _scratch_xfs_fuzz_metadata_field "${field}" ${fuzzverb} "$@"
> + res=$?
> + test $res -ne 0 && return
> +
> + # Try to catch the error with scrub
> + echo "+ Try to catch the error"
> + _scratch_mount 2>&1
> + res=$?
> + if [ $res -eq 0 ]; then
> + _scratch_scrub -a 1 -e continue 2>&1
> + res=$?
> + test $res -eq 0 && \
> + (>&2 echo "scrub didn't fail with ${field} = ${fuzzverb}.")
> +
> + # Try modifying the filesystem!
> + __fuzz_notify "++ Try to write filesystem"
> + #_scratch_fuzz_modify 100 2>&1
> + __scratch_xfs_fuzz_unmount
> + fi
> +
> + # Repair the filesystem
> + echo "+ Fix the error"
> + _repair_scratch_fs 2>&1
> + res=$?
> + test $res -ne 0 && \
> + (>&2 echo "repair failed ($res) with ${field} = ${fuzzverb}.")
> +
> + # See if scrub finds a clean fs
> + echo "+ Make sure error is gone"
> + _scratch_mount 2>&1
> + res=$?
> + if [ $res -eq 0 ]; then
> + _scratch_scrub -e continue 2>&1
> + res=$?
> + test $res -ne 0 && \
> + (>&2 echo "re-scrub ($res) with ${field} = ${fuzzverb}.")
> +
> + # Try modifying the filesystem again!
> + __fuzz_notify "++ Try to write filesystem again"
> + _scratch_fuzz_modify 100 2>&1
> + __scratch_xfs_fuzz_unmount
> + else
> + (>&2 echo "re-mount failed ($res) with ${field} = ${fuzzverb}.")
> + fi
> +
> + # See if repair finds a clean fs
> + _scratch_xfs_repair -n 2>&1
> + res=$?
> + test $res -ne 0 && \
> + (>&2 echo "re-repair failed ($res) with ${field} = ${fuzzverb}.")
> +}
> +
> +# Make sure we have all the pieces we need for field fuzzing
> +_require_scratch_xfs_fuzz_fields()
> +{
> + _require_scratch
> + _require_scrub
> + _require_populate_commands
> + _require_command "$XFS_DB_PROG" "xfs_db"
> + _scratch_mkfs_xfs >/dev/null 2>&1
> + _scratch_xfs_db -x -c 'fuzz' 2>&1 | grep -q 'not found' && \
> + _notrun "xfs_db does not have fuzz command"
> +}
> +
> +# Grab the list of available fuzzing verbs
> +_scratch_xfs_list_fuzz_verbs() {
> + if [ -n "${SCRATCH_XFS_LIST_FUZZ_VERBS}" ]; then
> + echo "${SCRATCH_XFS_LIST_FUZZ_VERBS}" | sed -e 's/ /\n/g'
> + return;
> + fi
> + _scratch_xfs_db -x -c 'sb 0' -c 'fuzz' | grep '^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
> + _scratch_xfs_list_fuzz_verbs | while read fuzzverb; do
> + __scratch_xfs_fuzz_mdrestore
> + __scratch_xfs_fuzz_field_test "${field}" "${fuzzverb}" "$@"
> + done
> + done
> +}
>
^ permalink raw reply
* Re: net/sctp: null-ptr-deref in sctp_inet_listen
From: Xin Long @ 2016-11-09 3:32 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Vlad Yasevich, Neil Horman, David S. Miller, linux-sctp, netdev,
LKML, Dmitry Vyukov, Alexander Potapenko, Kostya Serebryany,
Eric Dumazet, syzkaller, Marcelo Ricardo Leitner
In-Reply-To: <CAAeHK+yW+5qqPtiXt+5+HsDPj=czh2ppfcUi0qO0fEjGsaqFnQ@mail.gmail.com>
On Wed, Nov 9, 2016 at 2:46 AM, Andrey Konovalov <andreyknvl@google.com> wrote:
> Hi Xin,
>
> Your patch seems to be fixing the issue.
>
> Tested-by: Andrey Konovalov <andreyknvl@google.com>
>
> Thanks!
>
> On Tue, Nov 8, 2016 at 11:06 AM, Xin Long <lucien.xin@gmail.com> wrote:
>> On Tue, Nov 8, 2016 at 5:44 AM, Andrey Konovalov <andreyknvl@google.com> wrote:
>>> Hi,
>>>
>>> I've got the following error report while running the syzkaller fuzzer:
>>>
>>> kasan: CONFIG_KASAN_INLINE enabled
>>> kasan: GPF could be caused by NULL-ptr deref or user memory access
>>> general protection fault: 0000 [#1] SMP KASAN
>>> Modules linked in:
>>> CPU: 1 PID: 3851 Comm: a.out Not tainted 4.9.0-rc4+ #354
>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>>> task: ffff880065f1d800 task.stack: ffff880063840000
>>> RIP: 0010:[<ffffffff8394151b>] [<ffffffff8394151b>]
>>> sctp_inet_listen+0x29b/0x790 net/sctp/socket.c:6870
>>> RSP: 0018:ffff880063847dd0 EFLAGS: 00010202
>>> RAX: dffffc0000000000 RBX: 1ffff1000c708fbd RCX: 0000000000000000
>>> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002
>>> RBP: ffff880063847e70 R08: dffffc0000000000 R09: dffffc0000000000
>>> R10: 0000000000000002 R11: 0000000000000002 R12: ffff88006b350800
>>> R13: 0000000000000000 R14: 1ffff1000d66a1a5 R15: 0000000000000000
>>> FS: 00007fd1f0f3d7c0(0000) GS:ffff88006cd00000(0000) knlGS:0000000000000000
>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> CR2: 0000000020000000 CR3: 0000000064af9000 CR4: 00000000000006e0
>>> Stack:
>>> ffff880063847de0 ffff880066165900 ffff88006b350d20 0000000041b58ab3
>>> ffffffff847ff589 ffffffff83941280 dffffc0000000000 0000000000000000
>>> ffff880069b9f740 0000000000000000 ffff880063847e38 ffffffff819f04ef
>>> Call Trace:
>>> [< inline >] SYSC_listen net/socket.c:1396
>>> [<ffffffff82b73cf6>] SyS_listen+0x206/0x250 net/socket.c:1382
>>> [<ffffffff83fc1501>] entry_SYSCALL_64_fastpath+0x1f/0xc2
>>> arch/x86/entry/entry_64.S:209
>>> Code: 00 0f 85 f4 04 00 00 4d 8b ac 24 28 05 00 00 49 b8 00 00 00 00
>>> 00 fc ff df 49 8d 7d 02 48 89 fe 49 89 fa 48 c1 ee 03 41 83 e2 07 <46>
>>> 0f b6 0c 06 41 83 c2 01 45 38 ca 7c 09 45 84 c9 0f 85 87 04
>>> RIP [<ffffffff8394151b>] sctp_inet_listen+0x29b/0x790 net/sctp/socket.c:6870
>>> RSP <ffff880063847dd0>
>>> ---[ end trace f2b501fc22999b37 ]---
>>>
>>> A reproducer is attached.
>>>
>>> On commit bc33b0ca11e3df467777a4fa7639ba488c9d4911 (Nov 5).
>>>
>> This is a shutdown injection issue.
>> sctp_shutdown need a sk->state check, just like tcp_shutdown:
>>
>> --- a/net/sctp/socket.c
>> +++ b/net/sctp/socket.c
>> @@ -4287,7 +4287,8 @@ static void sctp_shutdown(struct sock *sk, int how)
>> if (!sctp_style(sk, TCP))
>> return;
>>
>> - if (how & SEND_SHUTDOWN) {
>> + if (how & SEND_SHUTDOWN &&
>> + (1 << sk->sk_state) & (SCTP_SS_ESTABLISHED | SCTP_SS_CLOSING)) {
>> sk->sk_state = SCTP_SS_CLOSING;
>> ep = sctp_sk(sk)->ep;
>> if (!list_empty(&ep->asocs)) {
this fix may break TYPE_SCTP_PRIMITIVE_SHUTDOWN statetable,
could you give the following one a try ? thanks.
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -4288,9 +4288,9 @@ static void sctp_shutdown(struct sock *sk, int how)
return;
if (how & SEND_SHUTDOWN) {
- sk->sk_state = SCTP_SS_CLOSING;
ep = sctp_sk(sk)->ep;
if (!list_empty(&ep->asocs)) {
+ sk->sk_state = SCTP_SS_CLOSING;
asoc = list_entry(ep->asocs.next,
struct sctp_association, asocs);
sctp_primitive_SHUTDOWN(net, asoc, NULL);
^ permalink raw reply
* Re: net/sctp: null-ptr-deref in sctp_inet_listen
From: Xin Long @ 2016-11-09 3:32 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Vlad Yasevich, Neil Horman, David S. Miller, linux-sctp, netdev,
LKML, Dmitry Vyukov, Alexander Potapenko, Kostya Serebryany,
Eric Dumazet, syzkaller, Marcelo Ricardo Leitner
In-Reply-To: <CAAeHK+yW+5qqPtiXt+5+HsDPj=czh2ppfcUi0qO0fEjGsaqFnQ@mail.gmail.com>
On Wed, Nov 9, 2016 at 2:46 AM, Andrey Konovalov <andreyknvl@google.com> wrote:
> Hi Xin,
>
> Your patch seems to be fixing the issue.
>
> Tested-by: Andrey Konovalov <andreyknvl@google.com>
>
> Thanks!
>
> On Tue, Nov 8, 2016 at 11:06 AM, Xin Long <lucien.xin@gmail.com> wrote:
>> On Tue, Nov 8, 2016 at 5:44 AM, Andrey Konovalov <andreyknvl@google.com> wrote:
>>> Hi,
>>>
>>> I've got the following error report while running the syzkaller fuzzer:
>>>
>>> kasan: CONFIG_KASAN_INLINE enabled
>>> kasan: GPF could be caused by NULL-ptr deref or user memory access
>>> general protection fault: 0000 [#1] SMP KASAN
>>> Modules linked in:
>>> CPU: 1 PID: 3851 Comm: a.out Not tainted 4.9.0-rc4+ #354
>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>>> task: ffff880065f1d800 task.stack: ffff880063840000
>>> RIP: 0010:[<ffffffff8394151b>] [<ffffffff8394151b>]
>>> sctp_inet_listen+0x29b/0x790 net/sctp/socket.c:6870
>>> RSP: 0018:ffff880063847dd0 EFLAGS: 00010202
>>> RAX: dffffc0000000000 RBX: 1ffff1000c708fbd RCX: 0000000000000000
>>> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002
>>> RBP: ffff880063847e70 R08: dffffc0000000000 R09: dffffc0000000000
>>> R10: 0000000000000002 R11: 0000000000000002 R12: ffff88006b350800
>>> R13: 0000000000000000 R14: 1ffff1000d66a1a5 R15: 0000000000000000
>>> FS: 00007fd1f0f3d7c0(0000) GS:ffff88006cd00000(0000) knlGS:0000000000000000
>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> CR2: 0000000020000000 CR3: 0000000064af9000 CR4: 00000000000006e0
>>> Stack:
>>> ffff880063847de0 ffff880066165900 ffff88006b350d20 0000000041b58ab3
>>> ffffffff847ff589 ffffffff83941280 dffffc0000000000 0000000000000000
>>> ffff880069b9f740 0000000000000000 ffff880063847e38 ffffffff819f04ef
>>> Call Trace:
>>> [< inline >] SYSC_listen net/socket.c:1396
>>> [<ffffffff82b73cf6>] SyS_listen+0x206/0x250 net/socket.c:1382
>>> [<ffffffff83fc1501>] entry_SYSCALL_64_fastpath+0x1f/0xc2
>>> arch/x86/entry/entry_64.S:209
>>> Code: 00 0f 85 f4 04 00 00 4d 8b ac 24 28 05 00 00 49 b8 00 00 00 00
>>> 00 fc ff df 49 8d 7d 02 48 89 fe 49 89 fa 48 c1 ee 03 41 83 e2 07 <46>
>>> 0f b6 0c 06 41 83 c2 01 45 38 ca 7c 09 45 84 c9 0f 85 87 04
>>> RIP [<ffffffff8394151b>] sctp_inet_listen+0x29b/0x790 net/sctp/socket.c:6870
>>> RSP <ffff880063847dd0>
>>> ---[ end trace f2b501fc22999b37 ]---
>>>
>>> A reproducer is attached.
>>>
>>> On commit bc33b0ca11e3df467777a4fa7639ba488c9d4911 (Nov 5).
>>>
>> This is a shutdown injection issue.
>> sctp_shutdown need a sk->state check, just like tcp_shutdown:
>>
>> --- a/net/sctp/socket.c
>> +++ b/net/sctp/socket.c
>> @@ -4287,7 +4287,8 @@ static void sctp_shutdown(struct sock *sk, int how)
>> if (!sctp_style(sk, TCP))
>> return;
>>
>> - if (how & SEND_SHUTDOWN) {
>> + if (how & SEND_SHUTDOWN &&
>> + (1 << sk->sk_state) & (SCTP_SS_ESTABLISHED | SCTP_SS_CLOSING)) {
>> sk->sk_state = SCTP_SS_CLOSING;
>> ep = sctp_sk(sk)->ep;
>> if (!list_empty(&ep->asocs)) {
this fix may break TYPE_SCTP_PRIMITIVE_SHUTDOWN statetable,
could you give the following one a try ? thanks.
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -4288,9 +4288,9 @@ static void sctp_shutdown(struct sock *sk, int how)
return;
if (how & SEND_SHUTDOWN) {
- sk->sk_state = SCTP_SS_CLOSING;
ep = sctp_sk(sk)->ep;
if (!list_empty(&ep->asocs)) {
+ sk->sk_state = SCTP_SS_CLOSING;
asoc = list_entry(ep->asocs.next,
struct sctp_association, asocs);
sctp_primitive_SHUTDOWN(net, asoc, NULL);
^ permalink raw reply
* RE: [PATCH] HID:i2c-hid: add a simple quirk to fix device defects
From: Hn Chen @ 2016-11-09 3:32 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: jkosina@suse.cz, dmitry.torokhov@gmail.com,
linux-input@vger.kernel.org
In-Reply-To: <20161108093803.GD6689@mail.corp.redhat.com>
Hi Benjamin,
Ok, I will add a static quirk table and lookup for the quirks in i2c_hid_probe().
About the return value after send the PWR_ON command, it should be failed in weida's case.
The oscillator of the controller will be gated in the deep sleep mode and
the controller will be active after the first command but there is no any feedback.
So should I check the failed return value here ? Or I should check if it is ok and then just return ?
Hn.chen
-----Original Message-----
From: Benjamin Tissoires [mailto:benjamin.tissoires@redhat.com]
Sent: Tuesday, November 08, 2016 5:38 PM
To: Hn Chen
Cc: jkosina@suse.cz; dmitry.torokhov@gmail.com; linux-input@vger.kernel.org
Subject: Re: [PATCH] HID:i2c-hid: add a simple quirk to fix device defects
On Nov 08 2016 or thereabouts, hn.chen@weidahitech.com wrote:
> From: HungNien Chen <hn.chen@weidahitech.com>
>
> Weida's device can get a quirk value by the quirk function.
> Base on the quirk value, set_power function will send a command to
> wake up the device before send the PWR_ON command.
>
> Signed-off-by: HungNien Chen <hn.chen@weidahitech.com>
> ---
> drivers/hid/hid-ids.h | 5 +++++
> drivers/hid/i2c-hid/i2c-hid.c | 32 ++++++++++++++++++++++++++++++++
> 2 files changed, 37 insertions(+)
>
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h index
> 6cfb5ca..787afdf 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -1033,6 +1033,11 @@
> #define USB_DEVICE_ID_WALTOP_MEDIA_TABLET_14_1_INCH 0x0500
> #define USB_DEVICE_ID_WALTOP_SIRIUS_BATTERY_FREE_TABLET 0x0502
>
> +#define USB_VENDOR_ID_WEIDA 0x2575
> +#define USB_DEVICE_ID_WEIDA_8756 0x8756
> +#define USB_DEVICE_ID_WEIDA_8752 0xC300
> +#define USB_DEVICE_ID_WEIDA_8755 0xC301
> +
> #define USB_VENDOR_ID_WISEGROUP 0x0925
> #define USB_DEVICE_ID_SMARTJOY_PLUS 0x0005
> #define USB_DEVICE_ID_SUPER_JOY_BOX_3 0x8888
> diff --git a/drivers/hid/i2c-hid/i2c-hid.c
> b/drivers/hid/i2c-hid/i2c-hid.c index b3ec4f2..7a9b100 100644
> --- a/drivers/hid/i2c-hid/i2c-hid.c
> +++ b/drivers/hid/i2c-hid/i2c-hid.c
> @@ -41,6 +41,11 @@
>
> #include <linux/i2c/i2c-hid.h>
>
> +#include "../hid-ids.h"
> +
> +/* quirks to control the device */
> +#define I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV (1 << 0)
> +
> /* flags */
> #define I2C_HID_STARTED 0
> #define I2C_HID_RESET_PENDING 1
> @@ -143,6 +148,7 @@ struct i2c_hid {
> char *argsbuf; /* Command arguments buffer */
>
> unsigned long flags; /* device flags */
> + unsigned long quirks; /* Various quirks */
>
> wait_queue_head_t wait; /* For waiting the interrupt */
> struct gpio_desc *desc;
> @@ -154,6 +160,25 @@ struct i2c_hid {
> struct mutex reset_lock;
> };
>
> +/*
> + * i2c_hid_lookup_quirk: return any quirks associated with a I2C HID
> +device
> + * @idVendor: the 16-bit vendor ID
> + * @idProduct: the 16-bit product ID
> + *
> + * Returns: a u32 quirks value.
> + */
> +static u32 i2c_hid_lookup_quirk(const u16 idVendor, const u16
> +idProduct) {
> + u32 quirks = 0;
> +
> + /* Weida devices check here */
> + if (idVendor == USB_VENDOR_ID_WEIDA &&
> + idProduct >= USB_DEVICE_ID_WEIDA_8752)
Wouldn't it make more sense to have a static table of the affected products, instead of this test?
> + return I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV;
> +
> + return quirks;
> +}
> +
> static int __i2c_hid_command(struct i2c_client *client,
> const struct i2c_hid_cmd *command, u8 reportID,
> u8 reportType, u8 *args, int args_len, @@ -346,6 +371,11 @@ static
> int i2c_hid_set_power(struct i2c_client *client, int power_state)
>
> i2c_hid_dbg(ihid, "%s\n", __func__);
>
> + /* Some devices require to send a command to wakeup first */
> + if (power_state == I2C_HID_PWR_ON &&
> + ihid->quirks & I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV)
> + i2c_hid_command(client, &hid_set_power_cmd, NULL, 0);
Isn't there a need to check the return value here?
> +
> ret = __i2c_hid_command(client, &hid_set_power_cmd, power_state,
> 0, NULL, 0, NULL, 0);
> if (ret)
> @@ -661,6 +691,8 @@ static int i2c_hid_parse(struct hid_device *hid)
>
> i2c_hid_dbg(ihid, "entering %s\n", __func__);
>
> + ihid->quirks = i2c_hid_lookup_quirk(hid->vendor, hid->product);
Please lookup for the quirks in i2c_hid_probe(), right after we set version, vendor and product
> +
> rsize = le16_to_cpu(hdesc->wReportDescLength);
> if (!rsize || rsize > HID_MAX_DESCRIPTOR_SIZE) {
> dbg_hid("weird size of report descriptor (%u)\n", rsize);
> --
> 1.9.1
>
Cheers,
Benjamin
^ permalink raw reply
* Re: [meta-python][PATCH v3] python-cassandra-driver: add recipe for version 3.7.1
From: Paul Eggleton @ 2016-11-09 3:32 UTC (permalink / raw)
To: Ruben De Smet; +Cc: openembedded-devel
In-Reply-To: <20161104193553.1493-1-ruben.de.smet@rubdos.be>
Hi Ruben,
On Fri, 04 Nov 2016 20:35:53 Ruben De Smet wrote:
> A Python library for Apache Cassandra
>
> Signed-off-by: Ruben De Smet <ruben.de.smet@rubdos.be>
> ---
> .../python/python-cassandra-driver.inc | 33
> ++++++++++++++++++++++ .../python/python3-cassandra-driver_3.7.1.bb |
> 2 ++
> 2 files changed, 35 insertions(+)
> create mode 100644
> meta-python/recipes-devtools/python/python-cassandra-driver.inc create mode
> 100644
> meta-python/recipes-devtools/python/python3-cassandra-driver_3.7.1.bb
>
> diff --git a/meta-python/recipes-devtools/python/python-cassandra-driver.inc
> b/meta-python/recipes-devtools/python/python-cassandra-driver.inc new file
> mode 100644
> index 0000000..bc83592
> --- /dev/null
> +++ b/meta-python/recipes-devtools/python/python-cassandra-driver.inc
> @@ -0,0 +1,33 @@
> +SUMMARY = "DataStax Python Driver for Apache Cassandra"
> +DESCRIPTION = "A modern, feature-rich and highly-tunable Python client \
> +library for Apache Cassandra (1.2+) and DataStax Enterprise (3.1+) using \
> +exclusively Cassandra's binary protocol and Cassandra Query Language v3."
> +HOMEPAGE = "https://github.com/datastax/python-driver"
> +SECTION = "devel/python"
> +LICENSE = "Apache-2.0"
> +LIC_FILES_CHKSUM = "file://LICENSE;md5=2ee41112a44fe7014dce33e26468ba93"
> +SRCNAME = "cassandra-driver"
> +
> +SRC_URI[md5sum] = "e01822b1e08940f300c0013765e070be"
> +SRC_URI[sha256sum] =
> "cd76355a6bf30b9cb9f1dd12327b6db2f4b883d5521eb6cac5e6b905000d688e" +
> +DISTUTILS_BUILD_ARGS += " \
> + --no-libev \
> +"
> +DISTUTILS_INSTALL_ARGS += " \
> + --no-libev \
> +"
> +
> +inherit pypi
> +
> +RDEPENDS_${PN} += "\
> + ${PYTHON_PN}-cython \
> + ${PYTHON_PN}-multiprocessing \
> + ${PYTHON_PN}-six \
> + ${PYTHON_PN}-json \
> + libevent \
> +"
> +
> +DEPENDS_${PN} += "\
> + ${PYTHON_PN}-cython \
> +"
What Khem meant by "don't use PN here" was that DEPENDS_${PN} is not valid.
You only use such an override when you are dealing with a variable that is
specific to one of the packages in PACKAGES (${PN} being the main package) -
typically that is only variables that deal with packaging. DEPENDS (as, for
example, SRC_URI) is recipe-wide and thus not only do you not need such an
override, adding one will in fact prevent your additions from having any
effect.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
^ permalink raw reply
* Re: 25G RDMA networking thoughts???
From: Haomai Wang @ 2016-11-09 3:33 UTC (permalink / raw)
To: LIU, Fei; +Cc: Sage Weil, ceph-devel
In-Reply-To: <35adaeb1-25ff-4f16-be56-0589e483f054.james.liu@alibaba-inc.com>
On Wed, Nov 9, 2016 at 5:51 AM, LIU, Fei <james.liu@alibaba-inc.com> wrote:
> Hi Sage，
> thanks，Sorry for confusing you. What i am trying to say is async with
> RDMA over ethernet. I understand that async messenger support TCP based
> ethernet well.
> Secondly, would be possible to have data traffice among osds categorized
> into different service level to better provide QoS for the whole Ceph
> cluster service if we can within the 25G RDMA faclitiis?
> Thirdly, would be possible to provide unified network for both storage and
> compute within QoS control? We don't expect the replication/recovery/refill
> to have bad impact to the latency of application.
Currently I only use rdma over ib to test. I don't have eth over ib
nic by hand. I don't know what need to do for eth rdma nic...
>
>
> Regards,
> James
>
> ------------------------------------------------------------------
> From:Sage Weil <sweil@redhat.com>
> Time:2016 Nov 8 (Tue) 13:45
> To:James <james.liu@alibaba-inc.com>
> Cc:Haomai Wang <haomai@xsky.com>; ceph-devel <ceph-devel@vger.kernel.org>
> Subject:Re: 25G RDMA networking thoughts???
>
> On Wed, 9 Nov 2016, LIU, Fei wrote:
>> Hi Sage，
>> Yes, Totally understood. 25G RDMA network for Ceph cluster is built
>> for
>> interal test. Xio messenger and Async messenger(But it can only support
>> infiniband,right) are going to be two options. We are carefully evaluate
>> both of these two options. But the most important goal in the end is to
>> see
>> how bluestore works with rdma to bring down the total latency for workload
>> like OLTP.
>>
>> Hi Haomai,
>> Would you mind let us know when the async messenger is going to support
>> ethernet if not support yet?
>
> The default async backend is PosixStack which is all TCP-based. (And
> async is now the default messenger in kraken.)
>
> sage
>
>>
>> Regards,
>> James
>> ------------------------------------------------------------------
>> From:Sage Weil <sweil@redhat.com>
>> Time:2016 Nov 8 (Tue) 13:19
>> To:James <james.liu@alibaba-inc.com>
>> Subject:Re: 25G RDMA networking thoughts???
>>
>> [adding ceph-devel]
>>
>> On Wed, 9 Nov 2016, LIU, Fei wrote:
>> > Hi Sage,
>> > I was wondering do you have any thoughts of 25G RDMA networking
>> > construction besides of xio-messenger/async? Is there any guidance to
>> > bu
>> ild
>> > 25G RDMA netowrk to better control the whole Ceph cluster latency?
>>
>> The only RDMA options right now are XioMessenger and AsyncMessenger's new
>> RDMA backend. Both are experimental, but we'd be very interested in
>> hearing about your experience.
>>
>> I wouldn't assume that latency is network-related, though. More often
>> than not we're finding it's the OSD backend or the OSD request internals
>> (e.g., request scheduling or peering) that's the culprit...
>>
>> sage
>>
>>
>>
>>
>
>
^ permalink raw reply
* Re: For playback method of stopping after the execution aplay command
From: 高井和也 @ 2016-11-09 3:34 UTC (permalink / raw)
To: Takashi Sakamoto; +Cc: alsa-devel
In-Reply-To: <15be5f38-2710-5531-33c4-a1c1cd1a4179@sakamocchi.jp>
Thank you. i will try.
2016-11-09 12:23 GMT+09:00 Takashi Sakamoto <o-takashi@sakamocchi.jp>:
> On Nov 9 2016 11:52, 高井和也 wrote:
>
>> After I was playing at aplay command, we are looking for a way to
>> terminate by the other process.
>>
>
> The aplay is quite simple program and it has no implementation for modern
> IPC (inter process communication) mechanism. So we need to use a
> traditional fashion, sending UNIX signals to aplay process to terminate the
> process.
>
> In detail, please see 'signal_handler()' and related codes in aplay.c:
> http://git.alsa-project.org/?p=alsa-utils.git;a=blob;f=aplay
> /aplay.c;h=2da7ddac1c81d24d20988d2719e4e66833277177;hb=HEAD#l385
>
>
> Regards
>
> Takashi Sakamoto
>
--
//--------------------------------------
// サン電子株式会社
// 技術開発部 開発２課
// 高井 和也
// 〒483-8555
// 愛知県江南市古知野町朝日250
// Tel:0587-55-2204, Fax:0587-53-8185
// E-Mail:ktakai@sun-denshi.co.jp
//--------------------------------------
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply
* Re: Bug: git config does not respect read-only .gitconfig file
From: Jeff King @ 2016-11-09 3:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Word, Markus Hitter, git, jword
In-Reply-To: <xmqqk2cdbg5v.fsf@gitster.mtv.corp.google.com>
On Tue, Nov 08, 2016 at 05:22:52PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > Probably converting "rename(from, to)" to first check "access(to,
> > W_OK)". That's racy, but it's the best we could do.
>
> Hmph, if these (possibly problematic) callers are all following the
> usual "lock, write to temp, rename" pattern, perhaps the lock_file()
> function can have access(path, W_OK) check before it returns a
> tempfile that has been successfully opened?
Yeah, that is a lot friendlier, as it prevents the caller from doing
work (which may even involve the user typing things!) when it is clear
that we would fail the final step anyway.
-Peff
^ permalink raw reply
* Re: [PATCH v11 15/22] vfio: Introduce vfio_set_irqs_validate_and_prepare()
From: Alex Williamson @ 2016-11-09 3:35 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: Kirti Wankhede, pbonzini, kraxel, cjia, qemu-devel, kvm,
kevin.tian, jike.song, bjsdjshi, linux-kernel
In-Reply-To: <26a4171a-e68f-c8e5-af39-b5af2c1645fe@ozlabs.ru>
On Wed, 9 Nov 2016 14:07:58 +1100
Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> On 09/11/16 07:22, Kirti Wankhede wrote:
> > On 11/8/2016 2:16 PM, Alexey Kardashevskiy wrote:
> >> On 05/11/16 08:10, Kirti Wankhede wrote:
> >>> Vendor driver using mediated device framework would use same mechnism to
> >>> validate and prepare IRQs. Introducing this function to reduce code
> >>> replication in multiple drivers.
> >>>
> >>> Signed-off-by: Kirti Wankhede <kwankhede@nvidia.com>
> >>> Signed-off-by: Neo Jia <cjia@nvidia.com>
> >>> Change-Id: Ie201f269dda0713ca18a07dc4852500bd8b48309
> >>> ---
> >>> drivers/vfio/vfio.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
> >>> include/linux/vfio.h | 4 ++++
> >>> 2 files changed, 52 insertions(+)
> >>>
> >>> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> >>> index 9a03be0942a1..ed2361e4b904 100644
> >>> --- a/drivers/vfio/vfio.c
> >>> +++ b/drivers/vfio/vfio.c
> >>> @@ -1858,6 +1858,54 @@ int vfio_info_add_capability(struct vfio_info_cap *caps, int cap_type_id,
> >>> }
> >>> EXPORT_SYMBOL(vfio_info_add_capability);
> >>>
> >>> +int vfio_set_irqs_validate_and_prepare(struct vfio_irq_set *hdr, int num_irqs,
> >>> + int max_irq_type, size_t *data_size)
> >>> +{
> >>> + unsigned long minsz;
> >>> + size_t size;
> >>> +
> >>> + minsz = offsetofend(struct vfio_irq_set, count);
> >>> +
> >>> + if ((hdr->argsz < minsz) || (hdr->index >= max_irq_type) ||
> >>> + (hdr->count >= (U32_MAX - hdr->start)) ||
> >>> + (hdr->flags & ~(VFIO_IRQ_SET_DATA_TYPE_MASK |
> >>> + VFIO_IRQ_SET_ACTION_TYPE_MASK)))
> >>> + return -EINVAL;
> >>> +
> >>> + if (data_size)
> >>
> >> Pointless check, the callers will pass non null pointer with value
> >> initialized to 0 anyway.
> >>
> >
> > Not always, When VFIO_IRQ_SET_DATA_NONE flag is set, caller can pass
> > data_size = NULL.
>
>
> Today data_size is not NULL in all cases and the way it is used now (ioctl
> VFIO_DEVICE_SET_IRQS) gives me an idea that this is not going to change.
>
> >
> >>
> >>> + *data_size = 0;
> >>> +
> >>> + if (hdr->start >= num_irqs || hdr->start + hdr->count > num_irqs)
> >>> + return -EINVAL;
> >>> +
> >>> + switch (hdr->flags & VFIO_IRQ_SET_DATA_TYPE_MASK) {
> >>> + case VFIO_IRQ_SET_DATA_NONE:
> >>> + size = 0;
> >>> + break;
> >>> + case VFIO_IRQ_SET_DATA_BOOL:
> >>> + size = sizeof(uint8_t);
> >>> + break;
> >>> + case VFIO_IRQ_SET_DATA_EVENTFD:
> >>> + size = sizeof(int32_t);
> >>> + break;
> >>> + default:
> >>> + return -EINVAL;
> >>> + }
> >>> +
> >>> + if (size) {
> >>
> >> The whole branch would even work for size == 0.
> >>
> >
> > In that case below check (!data_size) might result in error if data_size
> > == NULL, whereas its not error case when size == 0, i.e.
> > VFIO_IRQ_SET_DATA_NONE flag set.
> >
> >>> + if (hdr->argsz - minsz < hdr->count * size)
> >>> + return -EINVAL;
> >>> +
> >>> + if (!data_size)
> >>> + return -EINVAL;
> >>
> >> Redundant check as well.
> >>
> >
> > This is not redundant. If you see above check, it sets its init value to
> > 0 but doesn't fail.
> >
> >>> +
> >>> + *data_size = hdr->count * size;
> >>> + }
> >>> +
> >>> + return 0;
> >>> +}
> >>
> >> It does not really prepare anything as the name suggests. It looks like
> >> this is 2 different helpers actually:
> >>
> >> int vfio_set_irqs_validate()
> >> and
> >> size_t vfio_set_irqs_hdr_to_data_size()
> >>
> >
> > Later one is the prepare.
>
>
> Does not like it prepares anything, just a simple converter.
>
>
> >> And it would make it easier to review/bisect if 16/22 and 17/22 were merged
> >> into this one as this patch alone adds new code which it does not use and
> >> all 3 patches are fairly small.
> >>
> >
> > I do had all 3 patch merged in one in earlier version of patchset. This
> > is split as per Alex's suggestion.
>
> I got this from another mail from Alex. Which I find strange but whatever,
> this is his realm anyway :)
Maybe you haven't noticed, but your patch series are often difficult to
deal with, they almost always split across functional areas and
maintainers. Splitting out code to common functions and _then_
updating the callers to make use of it is a common way to deal with
that. We're in the same functional area here, but it's still
good practice. Thanks,
Alex
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v11 15/22] vfio: Introduce vfio_set_irqs_validate_and_prepare()
From: Alex Williamson @ 2016-11-09 3:35 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: Kirti Wankhede, pbonzini, kraxel, cjia, qemu-devel, kvm,
kevin.tian, jike.song, bjsdjshi, linux-kernel
In-Reply-To: <26a4171a-e68f-c8e5-af39-b5af2c1645fe@ozlabs.ru>
On Wed, 9 Nov 2016 14:07:58 +1100
Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> On 09/11/16 07:22, Kirti Wankhede wrote:
> > On 11/8/2016 2:16 PM, Alexey Kardashevskiy wrote:
> >> On 05/11/16 08:10, Kirti Wankhede wrote:
> >>> Vendor driver using mediated device framework would use same mechnism to
> >>> validate and prepare IRQs. Introducing this function to reduce code
> >>> replication in multiple drivers.
> >>>
> >>> Signed-off-by: Kirti Wankhede <kwankhede@nvidia.com>
> >>> Signed-off-by: Neo Jia <cjia@nvidia.com>
> >>> Change-Id: Ie201f269dda0713ca18a07dc4852500bd8b48309
> >>> ---
> >>> drivers/vfio/vfio.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
> >>> include/linux/vfio.h | 4 ++++
> >>> 2 files changed, 52 insertions(+)
> >>>
> >>> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> >>> index 9a03be0942a1..ed2361e4b904 100644
> >>> --- a/drivers/vfio/vfio.c
> >>> +++ b/drivers/vfio/vfio.c
> >>> @@ -1858,6 +1858,54 @@ int vfio_info_add_capability(struct vfio_info_cap *caps, int cap_type_id,
> >>> }
> >>> EXPORT_SYMBOL(vfio_info_add_capability);
> >>>
> >>> +int vfio_set_irqs_validate_and_prepare(struct vfio_irq_set *hdr, int num_irqs,
> >>> + int max_irq_type, size_t *data_size)
> >>> +{
> >>> + unsigned long minsz;
> >>> + size_t size;
> >>> +
> >>> + minsz = offsetofend(struct vfio_irq_set, count);
> >>> +
> >>> + if ((hdr->argsz < minsz) || (hdr->index >= max_irq_type) ||
> >>> + (hdr->count >= (U32_MAX - hdr->start)) ||
> >>> + (hdr->flags & ~(VFIO_IRQ_SET_DATA_TYPE_MASK |
> >>> + VFIO_IRQ_SET_ACTION_TYPE_MASK)))
> >>> + return -EINVAL;
> >>> +
> >>> + if (data_size)
> >>
> >> Pointless check, the callers will pass non null pointer with value
> >> initialized to 0 anyway.
> >>
> >
> > Not always, When VFIO_IRQ_SET_DATA_NONE flag is set, caller can pass
> > data_size = NULL.
>
>
> Today data_size is not NULL in all cases and the way it is used now (ioctl
> VFIO_DEVICE_SET_IRQS) gives me an idea that this is not going to change.
>
> >
> >>
> >>> + *data_size = 0;
> >>> +
> >>> + if (hdr->start >= num_irqs || hdr->start + hdr->count > num_irqs)
> >>> + return -EINVAL;
> >>> +
> >>> + switch (hdr->flags & VFIO_IRQ_SET_DATA_TYPE_MASK) {
> >>> + case VFIO_IRQ_SET_DATA_NONE:
> >>> + size = 0;
> >>> + break;
> >>> + case VFIO_IRQ_SET_DATA_BOOL:
> >>> + size = sizeof(uint8_t);
> >>> + break;
> >>> + case VFIO_IRQ_SET_DATA_EVENTFD:
> >>> + size = sizeof(int32_t);
> >>> + break;
> >>> + default:
> >>> + return -EINVAL;
> >>> + }
> >>> +
> >>> + if (size) {
> >>
> >> The whole branch would even work for size == 0.
> >>
> >
> > In that case below check (!data_size) might result in error if data_size
> > == NULL, whereas its not error case when size == 0, i.e.
> > VFIO_IRQ_SET_DATA_NONE flag set.
> >
> >>> + if (hdr->argsz - minsz < hdr->count * size)
> >>> + return -EINVAL;
> >>> +
> >>> + if (!data_size)
> >>> + return -EINVAL;
> >>
> >> Redundant check as well.
> >>
> >
> > This is not redundant. If you see above check, it sets its init value to
> > 0 but doesn't fail.
> >
> >>> +
> >>> + *data_size = hdr->count * size;
> >>> + }
> >>> +
> >>> + return 0;
> >>> +}
> >>
> >> It does not really prepare anything as the name suggests. It looks like
> >> this is 2 different helpers actually:
> >>
> >> int vfio_set_irqs_validate()
> >> and
> >> size_t vfio_set_irqs_hdr_to_data_size()
> >>
> >
> > Later one is the prepare.
>
>
> Does not like it prepares anything, just a simple converter.
>
>
> >> And it would make it easier to review/bisect if 16/22 and 17/22 were merged
> >> into this one as this patch alone adds new code which it does not use and
> >> all 3 patches are fairly small.
> >>
> >
> > I do had all 3 patch merged in one in earlier version of patchset. This
> > is split as per Alex's suggestion.
>
> I got this from another mail from Alex. Which I find strange but whatever,
> this is his realm anyway :)
Maybe you haven't noticed, but your patch series are often difficult to
deal with, they almost always split across functional areas and
maintainers. Splitting out code to common functions and _then_
updating the callers to make use of it is a common way to deal with
that. We're in the same functional area here, but it's still
good practice. Thanks,
Alex
^ permalink raw reply
* [PATCH] mwifiex: fix memory leak in mwifiex_save_hidden_ssid_channels()
From: Ricky Liang @ 2016-11-09 3:37 UTC (permalink / raw)
Cc: Ricky Liang, Amitkumar Karwar, Nishant Sarmukadam, Kalle Valo,
open list:MARVELL MWIFIEX WIRELESS DRIVER,
open list:NETWORKING DRIVERS, open list
kmemleak reports memory leak in mwifiex_save_hidden_ssid_channels():
unreferenced object 0xffffffc0a2914780 (size 192):
comm "ksdioirqd/mmc2", pid 2004, jiffies 4307182506 (age 820.684s)
hex dump (first 32 bytes):
00 06 47 49 4e 2d 32 67 01 03 c8 60 6c 03 01 40 ..GIN-2g...`l..@
07 10 54 57 20 34 04 1e 64 05 24 84 03 24 95 04 ..TW 4..d.$..$..
backtrace:
[<ffffffc0003375f4>] create_object+0x164/0x2b4
[<ffffffc0008e3530>] kmemleak_alloc+0x50/0x88
[<ffffffc000335120>] __kmalloc_track_caller+0x1bc/0x264
[<ffffffc00030899c>] kmemdup+0x38/0x64
[<ffffffbffc2311cc>] mwifiex_fill_new_bss_desc+0x3c/0x130 [mwifiex]
[<ffffffbffc22ee9c>] mwifiex_save_curr_bcn+0x4ec/0x640 [mwifiex]
[<ffffffbffc22f45c>] mwifiex_handle_event_ext_scan_report+0x1d4/0x268 [mwifiex]
[<ffffffbffc2375d0>] mwifiex_process_sta_event+0x378/0x898 [mwifiex]
[<ffffffbffc224dc8>] mwifiex_process_event+0x1a8/0x1e8 [mwifiex]
[<ffffffbffc2228f0>] mwifiex_main_process+0x258/0x534 [mwifiex]
[<ffffffbffc258858>] 0xffffffbffc258858
[<ffffffc00071ee90>] process_sdio_pending_irqs+0xf8/0x160
[<ffffffc00071efdc>] sdio_irq_thread+0x9c/0x1a4
[<ffffffc000240d08>] kthread+0xf4/0x100
[<ffffffc0002043fc>] ret_from_fork+0xc/0x50
[<ffffffffffffffff>] 0xffffffffffffffff
Signed-off-by: Ricky Liang <jcliang-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
drivers/net/wireless/marvell/mwifiex/scan.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c b/drivers/net/wireless/marvell/mwifiex/scan.c
index 97c9765..98ce072 100644
--- a/drivers/net/wireless/marvell/mwifiex/scan.c
+++ b/drivers/net/wireless/marvell/mwifiex/scan.c
@@ -1671,6 +1671,10 @@ static int mwifiex_save_hidden_ssid_channels(struct mwifiex_private *priv,
}
done:
+ /* beacon_ie buffer was allocated in function
+ * mwifiex_fill_new_bss_desc(). Free it now.
+ */
+ kfree(bss_desc->beacon_buf);
kfree(bss_desc);
return 0;
}
--
2.6.6
^ permalink raw reply related
* [PATCH] mwifiex: fix memory leak in mwifiex_save_hidden_ssid_channels()
From: Ricky Liang @ 2016-11-09 3:37 UTC (permalink / raw)
Cc: Ricky Liang, Amitkumar Karwar, Nishant Sarmukadam, Kalle Valo,
open list:MARVELL MWIFIEX WIRELESS DRIVER,
open list:NETWORKING DRIVERS, open list
kmemleak reports memory leak in mwifiex_save_hidden_ssid_channels():
unreferenced object 0xffffffc0a2914780 (size 192):
comm "ksdioirqd/mmc2", pid 2004, jiffies 4307182506 (age 820.684s)
hex dump (first 32 bytes):
00 06 47 49 4e 2d 32 67 01 03 c8 60 6c 03 01 40 ..GIN-2g...`l..@
07 10 54 57 20 34 04 1e 64 05 24 84 03 24 95 04 ..TW 4..d.$..$..
backtrace:
[<ffffffc0003375f4>] create_object+0x164/0x2b4
[<ffffffc0008e3530>] kmemleak_alloc+0x50/0x88
[<ffffffc000335120>] __kmalloc_track_caller+0x1bc/0x264
[<ffffffc00030899c>] kmemdup+0x38/0x64
[<ffffffbffc2311cc>] mwifiex_fill_new_bss_desc+0x3c/0x130 [mwifiex]
[<ffffffbffc22ee9c>] mwifiex_save_curr_bcn+0x4ec/0x640 [mwifiex]
[<ffffffbffc22f45c>] mwifiex_handle_event_ext_scan_report+0x1d4/0x268 [mwifiex]
[<ffffffbffc2375d0>] mwifiex_process_sta_event+0x378/0x898 [mwifiex]
[<ffffffbffc224dc8>] mwifiex_process_event+0x1a8/0x1e8 [mwifiex]
[<ffffffbffc2228f0>] mwifiex_main_process+0x258/0x534 [mwifiex]
[<ffffffbffc258858>] 0xffffffbffc258858
[<ffffffc00071ee90>] process_sdio_pending_irqs+0xf8/0x160
[<ffffffc00071efdc>] sdio_irq_thread+0x9c/0x1a4
[<ffffffc000240d08>] kthread+0xf4/0x100
[<ffffffc0002043fc>] ret_from_fork+0xc/0x50
[<ffffffffffffffff>] 0xffffffffffffffff
Signed-off-by: Ricky Liang <jcliang@chromium.org>
---
drivers/net/wireless/marvell/mwifiex/scan.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c b/drivers/net/wireless/marvell/mwifiex/scan.c
index 97c9765..98ce072 100644
--- a/drivers/net/wireless/marvell/mwifiex/scan.c
+++ b/drivers/net/wireless/marvell/mwifiex/scan.c
@@ -1671,6 +1671,10 @@ static int mwifiex_save_hidden_ssid_channels(struct mwifiex_private *priv,
}
done:
+ /* beacon_ie buffer was allocated in function
+ * mwifiex_fill_new_bss_desc(). Free it now.
+ */
+ kfree(bss_desc->beacon_buf);
kfree(bss_desc);
return 0;
}
--
2.6.6
^ permalink raw reply related
* [PATCH v6] PM/devfreq: add suspend frequency support
From: Lin Huang @ 2016-11-09 3:37 UTC (permalink / raw)
To: myungjoo.ham
Cc: cw00.choi, dianders, linux-rockchip, linux-pm, dbasehore,
linux-arm-kernel, linux-kernel, Lin Huang
Add suspend frequency support and if needed set it to
the frequency obtained from the suspend opp (can be defined
using opp-v2 bindings and is optional).
Signed-off-by: Lin Huang <hl@rock-chips.com>
---
Changes in v2:
- use update_devfreq() instead devfreq_update_status()
Changes in v3:
- fix build error
Changes in v4:
- move dev_pm_opp_get_suspend_opp() to devfreq_add_device()
Changes in v5:
- delete devfreq_opp_get_suspend_opp() in devfreq.h
Changes in v6:
- return to use stop_polling check suspend status
drivers/devfreq/devfreq.c | 14 +++++++++++---
drivers/devfreq/governor_simpleondemand.c | 9 +++++++++
include/linux/devfreq.h | 1 +
3 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index da72d97..cfa64a0 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -359,9 +359,11 @@ void devfreq_monitor_suspend(struct devfreq *devfreq)
mutex_unlock(&devfreq->lock);
return;
}
-
- devfreq_update_status(devfreq, devfreq->previous_freq);
devfreq->stop_polling = true;
+ if (devfreq->suspend_freq)
+ update_devfreq(devfreq);
+ else
+ devfreq_update_status(devfreq, devfreq->previous_freq);
mutex_unlock(&devfreq->lock);
cancel_delayed_work_sync(&devfreq->work);
}
@@ -390,7 +392,6 @@ void devfreq_monitor_resume(struct devfreq *devfreq)
devfreq->last_stat_updated = jiffies;
devfreq->stop_polling = false;
-
if (devfreq->profile->get_cur_freq &&
!devfreq->profile->get_cur_freq(devfreq->dev.parent, &freq))
devfreq->previous_freq = freq;
@@ -524,6 +525,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
struct devfreq *devfreq;
struct devfreq_governor *governor;
int err = 0;
+ struct dev_pm_opp *suspend_opp;
if (!dev || !profile || !governor_name) {
dev_err(dev, "%s: Invalid parameters.\n", __func__);
@@ -558,6 +560,12 @@ struct devfreq *devfreq_add_device(struct device *dev,
devfreq->data = data;
devfreq->nb.notifier_call = devfreq_notifier_call;
+ rcu_read_lock();
+ suspend_opp = dev_pm_opp_get_suspend_opp(dev);
+ if (suspend_opp)
+ devfreq->suspend_freq = dev_pm_opp_get_freq(suspend_opp);
+ rcu_read_unlock();
+
if (!devfreq->profile->max_state && !devfreq->profile->freq_table) {
mutex_unlock(&devfreq->lock);
devfreq_set_freq_table(devfreq);
diff --git a/drivers/devfreq/governor_simpleondemand.c b/drivers/devfreq/governor_simpleondemand.c
index ae72ba5..b82f089 100644
--- a/drivers/devfreq/governor_simpleondemand.c
+++ b/drivers/devfreq/governor_simpleondemand.c
@@ -29,6 +29,15 @@ static int devfreq_simple_ondemand_func(struct devfreq *df,
struct devfreq_simple_ondemand_data *data = df->data;
unsigned long max = (df->max_freq) ? df->max_freq : UINT_MAX;
+ /*
+ * if devfreq in suspend status and have suspend_freq,
+ * the frequency need to set to suspend_freq
+ */
+ if (df->stop_polling) {
+ *freq = df->suspend_freq;
+ return 0;
+ }
+
err = devfreq_update_stats(df);
if (err)
return err;
diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
index 98c6993..517e394 100644
--- a/include/linux/devfreq.h
+++ b/include/linux/devfreq.h
@@ -172,6 +172,7 @@ struct devfreq {
struct delayed_work work;
unsigned long previous_freq;
+ unsigned long suspend_freq;
struct devfreq_dev_status last_status;
void *data; /* private data for governors */
--
2.6.6
^ permalink raw reply related
* [PATCH v6] PM/devfreq: add suspend frequency support
From: Lin Huang @ 2016-11-09 3:37 UTC (permalink / raw)
To: linux-arm-kernel
Add suspend frequency support and if needed set it to
the frequency obtained from the suspend opp (can be defined
using opp-v2 bindings and is optional).
Signed-off-by: Lin Huang <hl@rock-chips.com>
---
Changes in v2:
- use update_devfreq() instead devfreq_update_status()
Changes in v3:
- fix build error
Changes in v4:
- move dev_pm_opp_get_suspend_opp() to devfreq_add_device()
Changes in v5:
- delete devfreq_opp_get_suspend_opp() in devfreq.h
Changes in v6:
- return to use stop_polling check suspend status
drivers/devfreq/devfreq.c | 14 +++++++++++---
drivers/devfreq/governor_simpleondemand.c | 9 +++++++++
include/linux/devfreq.h | 1 +
3 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index da72d97..cfa64a0 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -359,9 +359,11 @@ void devfreq_monitor_suspend(struct devfreq *devfreq)
mutex_unlock(&devfreq->lock);
return;
}
-
- devfreq_update_status(devfreq, devfreq->previous_freq);
devfreq->stop_polling = true;
+ if (devfreq->suspend_freq)
+ update_devfreq(devfreq);
+ else
+ devfreq_update_status(devfreq, devfreq->previous_freq);
mutex_unlock(&devfreq->lock);
cancel_delayed_work_sync(&devfreq->work);
}
@@ -390,7 +392,6 @@ void devfreq_monitor_resume(struct devfreq *devfreq)
devfreq->last_stat_updated = jiffies;
devfreq->stop_polling = false;
-
if (devfreq->profile->get_cur_freq &&
!devfreq->profile->get_cur_freq(devfreq->dev.parent, &freq))
devfreq->previous_freq = freq;
@@ -524,6 +525,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
struct devfreq *devfreq;
struct devfreq_governor *governor;
int err = 0;
+ struct dev_pm_opp *suspend_opp;
if (!dev || !profile || !governor_name) {
dev_err(dev, "%s: Invalid parameters.\n", __func__);
@@ -558,6 +560,12 @@ struct devfreq *devfreq_add_device(struct device *dev,
devfreq->data = data;
devfreq->nb.notifier_call = devfreq_notifier_call;
+ rcu_read_lock();
+ suspend_opp = dev_pm_opp_get_suspend_opp(dev);
+ if (suspend_opp)
+ devfreq->suspend_freq = dev_pm_opp_get_freq(suspend_opp);
+ rcu_read_unlock();
+
if (!devfreq->profile->max_state && !devfreq->profile->freq_table) {
mutex_unlock(&devfreq->lock);
devfreq_set_freq_table(devfreq);
diff --git a/drivers/devfreq/governor_simpleondemand.c b/drivers/devfreq/governor_simpleondemand.c
index ae72ba5..b82f089 100644
--- a/drivers/devfreq/governor_simpleondemand.c
+++ b/drivers/devfreq/governor_simpleondemand.c
@@ -29,6 +29,15 @@ static int devfreq_simple_ondemand_func(struct devfreq *df,
struct devfreq_simple_ondemand_data *data = df->data;
unsigned long max = (df->max_freq) ? df->max_freq : UINT_MAX;
+ /*
+ * if devfreq in suspend status and have suspend_freq,
+ * the frequency need to set to suspend_freq
+ */
+ if (df->stop_polling) {
+ *freq = df->suspend_freq;
+ return 0;
+ }
+
err = devfreq_update_stats(df);
if (err)
return err;
diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
index 98c6993..517e394 100644
--- a/include/linux/devfreq.h
+++ b/include/linux/devfreq.h
@@ -172,6 +172,7 @@ struct devfreq {
struct delayed_work work;
unsigned long previous_freq;
+ unsigned long suspend_freq;
struct devfreq_dev_status last_status;
void *data; /* private data for governors */
--
2.6.6
^ permalink raw reply related
* Re: [PATCH 0/2] Support compiling out the prctl syscall
From: Josh Triplett @ 2016-11-09 3:42 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Andrew Morton, Kees Cook, Johannes Weiner, Ingo Molnar,
Andy Lutomirski, Petr Mladek, Thomas Garnier, Ard Biesheuvel,
Nicolas Pitre, Zefan Li, Li Bin, Eric W. Biederman, Dmitry Vyukov,
Ralf Baechle, Alex Thorlton, Michal Hocko, Mateusz Guzik,
Cyrill Gorcunov, John Stultz, Al Viro, Zach
In-Reply-To: <3032452.SC5nD8WpIB@wuerfel>
On Wed, Nov 09, 2016 at 01:26:53AM +0100, Arnd Bergmann wrote:
> On Tuesday, November 8, 2016 4:17:47 PM CET Josh Triplett wrote:
> > Some embedded systems can do without the prctl syscall, saving some space.
> >
> > This also avoids regular increases in tinyconfig size as people add more
> > non-optional functionality to prctl (observed via the 0-day kernel
> > infrastructure).
> >
> > The first patch moves prctl and all its helpers into a separate source file,
> > kernel/prctl.c, to allow making it optional via the Makefile without any
> > ifdefs. The second patch adds the Kconfig option to make prctl optional.
> >
> > Josh Triplett (2):
> > kernel: Move prctl and helpers from kernel/sys.c to new kernel/prctl.c
> > kernel: Support compiling out the prctl syscall
> >
>
> Both of these look really nice to me. Another syscall that comes to
> mind as a candidate to be made optional is ptrace, and I've added
> Nicolas Pitre to Cc here, as he has looked into this before.
I've looked at that as well; it's a rather more complex patch, as
several other bits of the kernel hook into ptrace or otherwise depend on
ptrace. (And ptrace_may_access will need to stick around even when
ptrace doesn't.)
- Josh Triplett
^ permalink raw reply
* Re: [PATCH 0/2] Support compiling out the prctl syscall
From: Josh Triplett @ 2016-11-09 3:42 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Andrew Morton, Kees Cook, Johannes Weiner, Ingo Molnar,
Andy Lutomirski, Petr Mladek, Thomas Garnier, Ard Biesheuvel,
Nicolas Pitre, Zefan Li, Li Bin, Eric W. Biederman, Dmitry Vyukov,
Ralf Baechle, Alex Thorlton, Michal Hocko, Mateusz Guzik,
Cyrill Gorcunov, John Stultz, Al Viro, Zach Brown, Anna Schumaker,
Dave Hansen, linux-kernel, linux-api, Nicolas Pitre
In-Reply-To: <3032452.SC5nD8WpIB@wuerfel>
On Wed, Nov 09, 2016 at 01:26:53AM +0100, Arnd Bergmann wrote:
> On Tuesday, November 8, 2016 4:17:47 PM CET Josh Triplett wrote:
> > Some embedded systems can do without the prctl syscall, saving some space.
> >
> > This also avoids regular increases in tinyconfig size as people add more
> > non-optional functionality to prctl (observed via the 0-day kernel
> > infrastructure).
> >
> > The first patch moves prctl and all its helpers into a separate source file,
> > kernel/prctl.c, to allow making it optional via the Makefile without any
> > ifdefs. The second patch adds the Kconfig option to make prctl optional.
> >
> > Josh Triplett (2):
> > kernel: Move prctl and helpers from kernel/sys.c to new kernel/prctl.c
> > kernel: Support compiling out the prctl syscall
> >
>
> Both of these look really nice to me. Another syscall that comes to
> mind as a candidate to be made optional is ptrace, and I've added
> Nicolas Pitre to Cc here, as he has looked into this before.
I've looked at that as well; it's a rather more complex patch, as
several other bits of the kernel hook into ptrace or otherwise depend on
ptrace. (And ptrace_may_access will need to stick around even when
ptrace doesn't.)
- Josh Triplett
^ permalink raw reply
* Re: Need some pointers to debug a target hang
From: Zhu Lingshan @ 2016-11-09 3:42 UTC (permalink / raw)
To: Nicholas A. Bellinger
Cc: Johannes Thumshirn, linux-scsi, target-devel@vger.kernel.org
In-Reply-To: <1478242353.5611.57.camel@haakon3.risingtidesystems.com>
On 11/04/2016 02:52 PM, Nicholas A. Bellinger wrote:
> Hi Zhu & Co,
>
> Thanks for the detailed logs. Comments below.
>
> On Mon, 2016-10-31 at 16:51 +0800, Zhu Lingshan wrote:
>> Hi Nicholas,
>>
>> (sorry it would be a long mail)
>>
>> Sorry for the delay, I spent some test and debug work. I find the patch
>> http://www.spinics.net/lists/target-devel/msg13530.html can solve two
>> issues:
>> (a). iscsit_stop_session() on the top of iscsi_np stack.
>> (b).iscsi_check_for_session_reinstatement() on the top of iscsi_np
>> stack, it is a must to reboot to recover.
>>
> Great, thanks for confirming the patch above.
>
> The key wrt this scenario, and other scenarios below is once target-core
> ABORT_TASK logic locates a se_cmd descriptor for IBLOCK backend I/O
> still outstanding, both iscsi session reinstatement in iscsi_np context
> and iscsi session shutdown in iscsi_t[t,r]x context are blocked until
> the specific outstanding se_cmd I/Os are completed, back to target-core
> backend driver.
>
> Note this is expected behavior during target-core ABORT_TASK and
> iscsi-target session reinstatement + session shutdown.
>
>> But I also find two more issues.
>> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>> Please let me explain my setup:
>> I have a target server, kernel version 4.4.21, it has a SATA HDD as a
>> LUN, only one LUN.
>> I have two initiators, both login to the target.
>> Create two partitions on the LUN, each initiator mount a certain
>> partition. Like initiator1 mount /dev/sdc1, initiator2 mount /dev/sdc2.
>> looks like this:
>> lszhu_DEV:~ # lsscsi
>> [0:0:0:0] cd/dvd HL-DT-ST DVD+-RW GHB0N A1C0 /dev/sr0
>> [4:0:0:0] disk ATA TOSHIBA DT01ACA2 MX4O /dev/sda
>> [9:0:0:0] disk LIO-ORG IBLOCK 4.0 /dev/sdc
>> lszhu_DEV:~ # lsblk
>> NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
>> sda 8:0 0 1.8T 0 disk
>> ├─sda1 8:1 0 16G 0 part [SWAP]
>> ├─sda2 8:2 0 200G 0 part /
>> └─sda3 8:3 0 1.6T 0 part /home
>> sdc 8:32 0 465.8G 0 disk
>> ├─sdc1 8:33 0 200G 0 part
>> └─sdc2 8:34 0 265.8G 0 part /mnt
>> sr0 11:0 1 1024M 0 rom
>>
>> bj-ha-5:~ # lsblk
>> NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
>> sda 8:0 0 465.8G 0 disk
>> ├─sda1 8:1 0 8G 0 part [SWAP]
>> ├─sda2 8:2 0 100G 0 part /
>> └─sda3 8:3 0 357.8G 0 part /home
>> sdb 8:16 0 465.8G 0 disk
>> sdc 8:32 0 465.8G 0 disk
>> ├─sdc1 8:33 0 200G 0 part /mnt
>> └─sdc2 8:34 0 265.8G 0 part
>> sr0 11:0 1 1024M 0 rom
>>
>> so you can see each initiator will read / write on their own partition
>> from the LUN.
>>
>> mount the partition like this:
>> mount -o dioread_nolock /dev/sdc1 /mnt, option dioread_nolock can help
>> we reproduce this bug a little quicker.
>>
>> Then run fio on both initiators like this:
>> fio -filename=/mnt/file1 -direct=1 -rw=randread -iodepth=64
>> -ioengin=libaio -bs=64K -size=5G -numjobs=24 -runtime=60000 -time_based
>> -group_reporting -name=init1
>> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>
>> Here are the three more issues I found, kernel version 4.4.21
>> (1) The first one looks like this, it is quite rare, only once, I failed
>> to get stack information for iscsi_trx and hard to reproduce, call stack
>> of iscsi_np is here:
>>
>> bj-ha-3:~ # ps -aux | grep iscsi
>> root 10501 0.0 0.0 0 0 ? D 16:45 0:00 [iscsi_np]
>> root 10519 0.4 0.0 0 0 ? S 16:49 0:02 [iscsi_ttx]
>> root 10520 2.2 0.0 0 0 ? S 16:49 0:14 [iscsi_trx]
>> root 10533 0.9 0.0 0 0 ? D 16:54 0:03 [iscsi_trx]
>> root 10547 0.0 0.0 10508 1552 pts/0 S+ 16:59 0:00 grep
>> --color=auto iscsi
>> bj-ha-3:~ # cat /proc/10501/stack
>> [<ffffffff815334c9>] inet_csk_accept+0x269/0x2e0
>> [<ffffffff8155f4aa>] inet_accept+0x2a/0x100
>> [<ffffffff814d2a88>] kernel_accept+0x48/0xa0
>> [<ffffffffa06fe871>] iscsit_accept_np+0x31/0x230 [iscsi_target_mod]
>> [<ffffffffa06fefab>] iscsi_target_login_thread+0xeb/0xfd0 [iscsi_target_mod]
>> [<ffffffff810996bd>] kthread+0xbd/0xe0
>> [<ffffffff815e15bf>] ret_from_fork+0x3f/0x70
>> [<ffffffff81099600>] kthread+0x0/0xe0
>> [<ffffffffffffffff>] 0xffffffffffffffff
> The iscsi_np here is looks like it's doing normal Linux/NET accept.
>
> Is the uninterruptible sleep for PID=10533 waiting for outstanding I/O
> to complete during iscsit_close_connection() shutdown after
> ABORT_TASK..?
sorry I have been trying to reproduce this case for a week, but can not
reproduce this case anymore, it is quite rare.
>
>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>> (2) The second issue I found has iscsi_check_for_session_reinstatement()
>> on the top of iscsi_np call stack, but different from case (b) we
>> mentioned before. In case (b), we must reboot the target to recover, but
>> in this case, it will auto recover, here is the details:
>> dmesg:
>> [ 100.487421] iSCSI/iqn.1996-04.de.suse:01:faad5846cde9: Unsupported
>> SCSI Opcode 0xa3, sending CHECK_CONDITION.
>> [ 182.582323] ABORT_TASK: Found referenced iSCSI task_tag: 15
>> [ 197.616800] Unexpected ret: -32 send data 48
>> [ 197.712278] ABORT_TASK: Sending TMR_FUNCTION_COMPLETE for ref_tag: 15
>> [ 263.603305] ABORT_TASK: Found referenced iSCSI task_tag: 268435537
>> [ 278.640172] Unexpected ret: -32 send data 48
>> [ 278.671299] ABORT_TASK: Sending TMR_FUNCTION_COMPLETE for ref_tag:
>> 268435537
>> [ 341.584329] ABORT_TASK: Found referenced iSCSI task_tag: 536871038
>> [ 357.423710] Unexpected ret: -32 send data 48
>> [ 373.660476] iSCSI Login timeout on Network Portal 192.168.100.233:3260
>>
> Great, recovering from uninterruptible sleep once the backend (finally)
> completes outstanding I/O here confirms the earlier SCF_ACK_KREF patch.
>
> So the backend device in question looks like it's repeatably taking
> extended time to complete I/O. At least 15 seconds plus the host
> initiator side ABORT_TASK timeout.
>
> Is the device failing..?
I tried many times (more than 50), I_T nexus always alive, after killed
the survival node( we have two initiator nodes, one fail one keep
running), I see the former D threads on the target side back to S
status, and I can read or write the LUN, the mount point is still
active. The target is fully functional! Thanks for the patch!!!!
But I still see such message "[ 887.448142] sd 8:0:0:0: rejecting I/O
to offline device" on the failed initiator dmesg, I guess maybe target
can not response to the failed initiator during that time because the
target is fully occupied by the other initiator, I guess maybe HDD
performance is the bottle neck.
But I think maybe there should not be an "offline device", yes IO
traffic at the failed initiator is stuck there, but we still have much
free network resources (FIO shows IO traffic < 20MB/s), also CPU and RAM
resources, so I think it is still possible to ping in the protocol
layer, should not be an "offline device".
Is it possible to investigate more(I will do that)? Maybe on the
initiator side, any suggestions?
>
>> call stacks:
>> bj-ha-3:~ # ps -aux | grep iscsi
>> root 3063 0.0 0.0 0 0 ? D 15:36 0:00 [iscsi_np]
>> root 3073 0.3 0.0 0 0 ? S 15:36 0:01 [iscsi_ttx]
>> root 3074 0.4 0.0 0 0 ? S 15:36 0:01 [iscsi_trx]
>> root 3094 0.3 0.0 0 0 ? D 15:39 0:00 [iscsi_trx]
>> root 3116 0.0 0.0 10508 1616 pts/0 S+ 15:42 0:00 grep
>> --color=auto iscsi
>> bj-ha-3:~ # cat /proc/3063/stack
>> [<ffffffffa03fcd97>] iscsi_check_for_session_reinstatement+0x1d7/0x270
>> [iscsi_target_mod]
>> [<ffffffffa03ff971>] iscsi_target_do_login+0x111/0x5f0 [iscsi_target_mod]
>> [<ffffffffa0400b17>] iscsi_target_start_negotiation+0x17/0xa0
>> [iscsi_target_mod]
>> [<ffffffffa03fe932>] iscsi_target_login_thread+0xa72/0xfd0
>> [iscsi_target_mod]
>> [<ffffffff810997cd>] kthread+0xbd/0xe0
>> [<ffffffff815e177f>] ret_from_fork+0x3f/0x70
>> [<ffffffff81099710>] kthread+0x0/0xe0
>> [<ffffffffffffffff>] 0xffffffffffffffff
>> bj-ha-3:~ # cat /proc/3094/stack
>> [<ffffffffa03adcc6>] transport_generic_free_cmd+0x76/0x110 [target_core_mod]
>> [<ffffffffa0404917>] iscsit_free_cmd+0x67/0x130 [iscsi_target_mod]
>> [<ffffffffa040b929>] iscsit_close_connection+0x4a9/0x860 [iscsi_target_mod]
>> [<ffffffffa040b0b3>] iscsi_target_rx_thread+0x93/0xa0 [iscsi_target_mod]
>> [<ffffffff810997cd>] kthread+0xbd/0xe0
>> [<ffffffff815e177f>] ret_from_fork+0x3f/0x70
>> [<ffffffff81099710>] kthread+0x0/0xe0
>> [<ffffffffffffffff>] 0xffffffffffffffff
>>
>> At this moment, we can see IO errors at one initiator side, the other
>> will survive. Once we killed the survival side FIO processes or wait a
>> moment, the target would auto recover, looks like this:
>>
>> bj-ha-3:~ # ps -aux | grep iscsi
>> root 3063 0.0 0.0 0 0 ? S 15:36 0:00 [iscsi_np]
>> root 3142 0.0 0.0 0 0 ? S 15:43 0:00 [iscsi_ttx]
>> root 3143 0.0 0.0 0 0 ? S 15:43 0:00 [iscsi_trx]
>> root 3146 0.6 0.0 0 0 ? S 15:43 0:00 [iscsi_ttx]
>> root 3147 0.8 0.0 0 0 ? S 15:43 0:00 [iscsi_trx]
>> root 3149 0.0 0.0 10508 1636 pts/0 S+ 15:43 0:00 grep
>> --color=auto iscsi
>>
>> dmesg at this moment:
>> [ 90.507364] iSCSI/iqn.1996-04.de.suse:01:4039926d2313: Unsupported
>> SCSI Opcode 0xa3, sending CHECK_CONDITION.
>> [ 100.487421] iSCSI/iqn.1996-04.de.suse:01:faad5846cde9: Unsupported
>> SCSI Opcode 0xa3, sending CHECK_CONDITION.
>> [ 182.582323] ABORT_TASK: Found referenced iSCSI task_tag: 15
>> [ 197.616800] Unexpected ret: -32 send data 48
>> [ 197.712278] ABORT_TASK: Sending TMR_FUNCTION_COMPLETE for ref_tag: 15
>> [ 263.603305] ABORT_TASK: Found referenced iSCSI task_tag: 268435537
>> [ 278.640172] Unexpected ret: -32 send data 48
>> [ 278.671299] ABORT_TASK: Sending TMR_FUNCTION_COMPLETE for ref_tag:
>> 268435537
>> [ 341.584329] ABORT_TASK: Found referenced iSCSI task_tag: 536871038
>> [ 357.423710] Unexpected ret: -32 send data 48
>> [ 373.660476] iSCSI Login timeout on Network Portal 192.168.100.233:3260
>> [ 535.852903] Unexpected ret: -32 send data 48
>> [ 535.923803] ABORT_TASK: Sending TMR_FUNCTION_COMPLETE for ref_tag:
>> 536871038
>> [ 535.923811] ABORT_TASK: Found referenced iSCSI task_tag: 76
>> [ 535.923815] ABORT_TASK: Sending TMR_TASK_DOES_NOT_EXIST for ref_tag: 76
>> [ 535.924325] Unexpected ret: -104 send data 360
>> [ 535.924329] tx_data returned -32, expecting 360.
>> [ 535.924489] iSCSI Login negotiation failed.
>> [ 535.924916] Unexpected ret: -104 send data 360
>> [ 535.924918] tx_data returned -32, expecting 360.
>> [ 535.924943] iSCSI Login negotiation failed.
>> [ 535.925424] Unexpected ret: -104 send data 360
>> [ 535.925428] tx_data returned -32, expecting 360.
>> [ 535.925650] iSCSI Login negotiation failed.
>> [ 535.926095] Unexpected ret: -104 send data 360
>> [ 535.926097] tx_data returned -32, expecting 360.
>> [ 535.926132] iSCSI Login negotiation failed.
>> [ 535.926349] Unexpected ret: -104 send data 360
>> [ 535.926351] tx_data returned -32, expecting 360.
>> [ 535.926369] iSCSI Login negotiation failed.
>> [ 535.926576] Unexpected ret: -104 send data 360
>> [ 535.926577] tx_data returned -32, expecting 360.
>> [ 535.926593] iSCSI Login negotiation failed.
>> [ 535.926750] Unexpected ret: -104 send data 360
>> [ 535.926752] tx_data returned -32, expecting 360.
>> [ 535.926768] iSCSI Login negotiation failed.
>> [ 535.926905] Unexpected ret: -104 send data 360
>> [ 535.926906] tx_data returned -32, expecting 360.
>> [ 535.926925] iSCSI Login negotiation failed.
>> [ 535.927064] Unexpected ret: -104 send data 360
>> [ 535.927065] tx_data returned -32, expecting 360.
>> [ 535.927082] iSCSI Login negotiation failed.
>> [ 535.927219] Unexpected ret: -104 send data 360
>> [ 535.927220] tx_data returned -32, expecting 360.
>> [ 535.927237] iSCSI Login negotiation failed.
>>
>> I am still debugging on this case, I have core dumps, I think the dump
>> files are too big for a mail list, I can send it off the list if needed.
> AFAICT, this is all expected behavior from target-core + iscsi-target
> when the backend device is not completing I/O for extended periods of
> time.
>
>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>> (3) In this case, dmesg and call stack looks like this:
>> bj-ha-3:~ # dmesg
>> [ 803.570868] ABORT_TASK: Found referenced iSCSI task_tag: 96
>> [ 818.584038] Unexpected ret: -32 send data 48
>> [ 818.620210] ABORT_TASK: Sending TMR_FUNCTION_COMPLETE for ref_tag: 96
>> [ 882.555923] ABORT_TASK: Found referenced iSCSI task_tag: 268435496
>> [ 897.587925] Unexpected ret: -32 send data 48
>> [ 898.845646] Unexpected ret: -32 send data 48
>> [ 898.916090] ABORT_TASK: Sending TMR_FUNCTION_COMPLETE for ref_tag:
>> 268435496
>> [ 898.916095] ABORT_TASK: Found referenced iSCSI task_tag: 45
>> [ 898.916377] ABORT_TASK: Sending TMR_FUNCTION_COMPLETE for ref_tag: 45
>> [ 962.785419] ABORT_TASK: Found referenced iSCSI task_tag: 268435489
>>
>> bj-ha-3:~ # ps -aux | grep iscsi
>> root 3063 0.0 0.0 0 0 ? D 15:36 0:00 [iscsi_np]
>> root 3296 1.9 0.0 0 0 ? S 15:49 0:01 [iscsi_ttx]
>> root 3297 1.9 0.0 0 0 ? R 15:49 0:01 [iscsi_trx]
>> root 3299 0.0 0.0 0 0 ? D 15:49 0:00 [iscsi_trx]
>> root 3506 0.0 0.0 10508 1516 pts/0 S+ 15:51 0:00 grep
>> --color=auto iscsi
>>
>>
>> bj-ha-3:~ # cat /proc/3063/stack
>> [<ffffffffa03fcd97>] iscsi_check_for_session_reinstatement+0x1d7/0x270
>> [iscsi_target_mod]
>> [<ffffffffa03ff971>] iscsi_target_do_login+0x111/0x5f0 [iscsi_target_mod]
>> [<ffffffffa0400b17>] iscsi_target_start_negotiation+0x17/0xa0
>> [iscsi_target_mod]
>> [<ffffffffa03fe932>] iscsi_target_login_thread+0xa72/0xfd0
>> [iscsi_target_mod]
>> [<ffffffff810997cd>] kthread+0xbd/0xe0
>> [<ffffffff815e177f>] ret_from_fork+0x3f/0x70
>> [<ffffffff81099710>] kthread+0x0/0xe0
>> [<ffffffffffffffff>] 0xffffffffffffffff
>> bj-ha-3:~ # cat /proc/3099/stack
>> [<ffffffffa03ac784>] __transport_wait_for_tasks+0xb4/0x190 [target_core_mod]
>> [<ffffffffa03ac905>] transport_wait_for_tasks+0x45/0x60 [target_core_mod]
>> [<ffffffffa03aa034>] core_tmr_abort_task+0xf4/0x160 [target_core_mod]
>> [<ffffffffa03aca43>] target_tmr_work+0x123/0x140 [target_core_mod]
>> [<ffffffff81093ace>] process_one_work+0x14e/0x410
>> [<ffffffff81094326>] worker_thread+0x116/0x490
>> [<ffffffff810997cd>] kthread+0xbd/0xe0
>> [<ffffffff815e177f>] ret_from_fork+0x3f/0x70
>> [<ffffffff81099710>] kthread+0x0/0xe0
>> [<ffffffffffffffff>] 0xffffffffffffffff
>>
>> This case is also rare, only once, but I got the core dump files.
> Looks the same as #2.
>
>> -------------------------------------------------------------------------------------------------------------------------------------------------
>> Sorry again for the delay and send such a long mail, I am still working
>> on there cases, I will keep the list update once I find anything new.
> Thanks again for confirming the earlier patch.
>
>
Thanks a lot for your help!
BR
Zhu Lingshan
^ permalink raw reply
* [Fuego] Fuego 1.0.0 release
From: Bird, Timothy @ 2016-11-09 3:43 UTC (permalink / raw)
To: fuego@lists.linuxfoundation.org
I am pleased to announce the release of Fuego version 1.0.0.
It is available now in the following git repositories:
* https://bitbucket.org/tbird20d/fuego.git
* https://bitbucket.org/tbird20d/fuego-core.git
Here is the Changelog for this release:
== [1.0.0] - 2016-11-08 ==
* Add support for building the docker container behind a proxy
* Add support for creating a container that can see USB changes
* Change reboot test to only report boot time (not other stats)
* Fix some other issues with the reboot test
* Change name of nologger function and distribution file to 'nologread'
* WARNING: this will break the Jenkins configuration for targets
that referenced nologger.dist
* the DISTRIB environment variable should be changed from
'distribs/nologger.dist' to 'distribs/nologread.dist' in the target
configuration for these boards
* Add .gitignore files to make repository management easier
* Add code to create the FUEGO_HOME directory if not already present
* Change bzip2 test to support busybox version of bzip2
* Add VERSION and CHANGELOG files
* status:
* This version of Fuego uses Jenkins 1.509.2
* This verison of Fuego includes ftc version 0.3.0
-----------
It should be noted that the use of version 1.0.0 was somewhat arbitrary.
Fuego can be used to test some things today, but there are many features that
are not quite complete, and lots of work to improve certain aspects of it.
However, this is my first official release of Fuego. This took longer than expected
due to having to work out my release process. Having two repositories is a real pain.
Note that you can update fuego-core independently from the container/Jenkins
pieces, by just cd-ing to /home/jenkins/fuego inside your current docker container
and doing a 'git pull' (assuming you're using the tbird20d repositories, and not the
cogentembedded ones).
Let me know if you see any problems. I've foregone going through an RC release
series for this release, but I may add that if it looks like I need help from outside
parties stabilizing releases in the future.
Finally - I know there are pending patches on the mailing list (thanks Daniel).
I wanted to get this release out before going through those, as this release was
already complicated enough. Just by way of information, my upcoming to-do list is:
* figure out why there are two tests.info files, and hopefully get rid of one
* evaluate Daniel's latest set of patches (from the last 2 weeks), and provide
feedback and/or integrate them into 'next'.
* start work on standards for test pre check functionality (compare with 0day
and any other systems that do test pre check
* write a target scan and health_check test
* write the contract for the serial console transport feature
I know that Toshiba is working on (or plans to work on) supporting another
Jenkins version besides 1.509.2. I plan to help with that if needed. If we
can get Fuego to be independent of Jenkins version, that would be good.
That's hard at the moment, but we should see how much dependencies
can be reduced.
With regard to forks, I need to review where Cogent Embedded is with their stuff.
I noticed that the AGL-JTA CIAT project has made a few changes, but I believe
the script engine (which has changed in Fuego but not in AGL-JTA, I believe)
is still compatible with their tests. This is also something that needs review.
Finally, I hope that with each release I'll be able to extend the test automation
for the release itself.
Regards,
-- Tim
^ permalink raw reply
* Re: [PATCH 7/9] populate: discover XFS structure fields and fuzz verbs, and use them to fuzz fields
From: Eryu Guan @ 2016-11-09 3:44 UTC (permalink / raw)
To: Darrick J. Wong; +Cc: david, linux-xfs, fstests
In-Reply-To: <147830507411.1919.17534443838350465519.stgit@birch.djwong.org>
[sorry, more comments on this patch]
On Fri, Nov 04, 2016 at 05:17:54PM -0700, Darrick J. Wong wrote:
> Create some routines to help us perform targeted fuzzing of individual
> fields in various XFS structures. Specifically, we want the caller to
> drop the xfs_db iocursor on the victim field; from there, the scripts
> should discover all available fields and fuzzing verbs, and try each
> fuzz verb on every available field.
>
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> ---
> common/fuzzy | 191 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 191 insertions(+)
>
>
[snip]
> +
> +# Make sure we have all the pieces we need for field fuzzing
> +_require_scratch_xfs_fuzz_fields()
> +{
> + _require_scratch
> + _require_scrub
> + _require_populate_commands
> + _require_command "$XFS_DB_PROG" "xfs_db"
This is included in _require_populate_commands, not needed here.
> + _scratch_mkfs_xfs >/dev/null 2>&1
> + _scratch_xfs_db -x -c 'fuzz' 2>&1 | grep -q 'not found' && \
> + _notrun "xfs_db does not have fuzz command"
Does _require_xfs_db_command work here?
Thanks,
Eryu
> +}
> +
> +# Grab the list of available fuzzing verbs
> +_scratch_xfs_list_fuzz_verbs() {
> + if [ -n "${SCRATCH_XFS_LIST_FUZZ_VERBS}" ]; then
> + echo "${SCRATCH_XFS_LIST_FUZZ_VERBS}" | sed -e 's/ /\n/g'
> + return;
> + fi
> + _scratch_xfs_db -x -c 'sb 0' -c 'fuzz' | grep '^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
> + _scratch_xfs_list_fuzz_verbs | while read fuzzverb; do
> + __scratch_xfs_fuzz_mdrestore
> + __scratch_xfs_fuzz_field_test "${field}" "${fuzzverb}" "$@"
> + done
> + done
> +}
>
^ 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.