[PATCH v3 1/6] i2c: s3c2410: Handle i2c sys_cfg register in i2c driver
From: Pankaj Dubey
Let's handle i2c interrupt re-configuration in i2c driver. This will
help us in removing some soc specific checks from machine files.
Since only Exynos5250, and Exynos5420 need to do this, added syscon
based phandle to i2c device nodes of respective SoC DT files.
Also handle saving and restoring of SYS_I2C_CFG register during
suspend and resume of i2c driver. This will help in removing soc
specific check from mach-exynos/pm.c.
CC: Rob Herring
CC: Randy Dunlap
CC: Wolfram Sang
CC: Russell King
CC: devicet...@vger.kernel.org
CC: linux-...@vger.kernel.org
CC: linux-...@vger.kernel.org
Signed-off-by: Pankaj Dubey
---
.../devicetree/bindings/arm/samsung/sysreg.txt |1 +
arch/arm/boot/dts/exynos5.dtsi |5 +++
arch/arm/boot/dts/exynos5250.dtsi |4 +++
arch/arm/boot/dts/exynos5420.dtsi |4 +++
drivers/i2c/busses/i2c-s3c2410.c | 32
5 files changed, 46 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
b/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
index 0ab3251..fd71581 100644
--- a/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
@@ -3,6 +3,7 @@ SAMSUNG S5P/Exynos SoC series System Registers (SYSREG)
Properties:
- compatible : should contain "samsung,-sysreg", "syscon";
For Exynos4 SoC series it should be "samsung,exynos4-sysreg", "syscon";
+ For Exynos5 SoC series it should be "samsung,exynos5-sysreg", "syscon";
- reg : offset and length of the register set.
Example:
diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index 79d0608..3027e37 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -99,4 +99,9 @@
#size-cells = <0>;
status = "disabled";
};
+
+ sys_reg: syscon@1005 {
+ compatible = "samsung,exynos5-sysreg", "syscon";
+ reg = <0x1005 0x400>;
+ };
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 8d724d5..46f0233 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -285,6 +285,7 @@
clock-names = "i2c";
pinctrl-names = "default";
pinctrl-0 = <&i2c0_bus>;
+ samsung,syscon-phandle = <&sys_reg>;
status = "disabled";
};
@@ -298,6 +299,7 @@
clock-names = "i2c";
pinctrl-names = "default";
pinctrl-0 = <&i2c1_bus>;
+ samsung,syscon-phandle = <&sys_reg>;
status = "disabled";
};
@@ -311,6 +313,7 @@
clock-names = "i2c";
pinctrl-names = "default";
pinctrl-0 = <&i2c2_bus>;
+ samsung,syscon-phandle = <&sys_reg>;
status = "disabled";
};
@@ -324,6 +327,7 @@
clock-names = "i2c";
pinctrl-names = "default";
pinctrl-0 = <&i2c3_bus>;
+ samsung,syscon-phandle = <&sys_reg>;
status = "disabled";
};
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index ff496ad..762128c 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -517,6 +517,7 @@
clock-names = "i2c";
pinctrl-names = "default";
pinctrl-0 = <&i2c0_bus>;
+ samsung,syscon-phandle = <&sys_reg>;
status = "disabled";
};
@@ -530,6 +531,7 @@
clock-names = "i2c";
pinctrl-names = "default";
pinctrl-0 = <&i2c1_bus>;
+ samsung,syscon-phandle = <&sys_reg>;
status = "disabled";
};
@@ -543,6 +545,7 @@
clock-names = "i2c";
pinctrl-names = "default";
pinctrl-0 = <&i2c2_bus>;
+ samsung,syscon-phandle = <&sys_reg>;
status = "disabled";
};
@@ -556,6 +559,7 @@
clock-names = "i2c";
pinctrl-names = "default";
pinctrl-0 = <&i2c3_bus>;
+ samsung,syscon-phandle = <&sys_reg>;
status = "disabled";
};
diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index ae44910..e707062 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -39,6 +39,8 @@
#include
#include
#include
+#include
+#include
#include
@@ -91,6 +93,9 @@
/* Max time to wait for bus to become idle after a xfer (in us) */
#define S3C2410_IDLE_TIMEOUT 5000
+/* Exynos5 Sysreg offset */
+#define EXYNOS5_SYS_I2C_CFG0x0234
+
/* i2c controller state */
enum s3c24xx_i2c_state {
STATE_IDLE,
@@ -127,6 +13
[PATCH v3 5/6] soc: samsung: exynos-chipid: Add Exynos Chipid driver support
From: Pankaj Dubey
Exynos SoCs have Chipid, for identification of product IDs
and SoC revistions. Till now we are using static macros
such as soc_is_exynos and #ifdefs for run time identification
of SoCs and their revisions. This is leading to add new Kconfig,
soc_is_exynos definitions each time new SoC support is getting
added. So this driver intends to provide initialization code
all these functionalites and thus helping in removing macros.
Signed-off-by: Pankaj Dubey
---
drivers/soc/Kconfig |1 +
drivers/soc/Makefile|1 +
drivers/soc/samsung/Kconfig | 10 +++
drivers/soc/samsung/Makefile|1 +
drivers/soc/samsung/exynos-chipid.c | 166 +++
include/linux/exynos-soc.h | 46 ++
6 files changed, 225 insertions(+)
create mode 100644 drivers/soc/samsung/Kconfig
create mode 100644 drivers/soc/samsung/Makefile
create mode 100644 drivers/soc/samsung/exynos-chipid.c
create mode 100644 include/linux/exynos-soc.h
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index 07a11be..86e52b1 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -1,5 +1,6 @@
menu "SOC specific Drivers"
source "drivers/soc/qcom/Kconfig"
+source "drivers/soc/samsung/Kconfig"
endmenu
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 0f7c447..ee890aa 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -3,3 +3,4 @@
#
obj-$(CONFIG_ARCH_QCOM)+= qcom/
+obj-$(CONFIG_ARCH_EXYNOS) += samsung/
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
new file mode 100644
index 000..dacc95d
--- /dev/null
+++ b/drivers/soc/samsung/Kconfig
@@ -0,0 +1,10 @@
+
+# SAMSUNG Soc drivers
+#
+config EXYNOS_CHIPID
+ tristate "Support Exynos CHIPID"
+ default y
+ select SOC_BUS
+ depends on ARCH_EXYNOS || ARM64
+ help
+ If you say Y here you get support for the Exynos CHIP id.
diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile
new file mode 100644
index 000..855ca05
--- /dev/null
+++ b/drivers/soc/samsung/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_EXYNOS_CHIPID)+= exynos-chipid.o
diff --git a/drivers/soc/samsung/exynos-chipid.c
b/drivers/soc/samsung/exynos-chipid.c
new file mode 100644
index 000..b5bccd9
--- /dev/null
+++ b/drivers/soc/samsung/exynos-chipid.c
@@ -0,0 +1,166 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * EXYNOS - CHIP ID support
+ * Author: Pankaj Dubey
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define EXYNOS4_SOC_MASK 0xFFFE0
+#define EXYNOS5_SOC_MASK 0xF
+
+#define PROD_ID_SHIFT (12)
+
+static void __iomem*exynos_chipid_base;
+unsigned int exynos_soc_id = EXYNOS_SOC_UNKNOWN;
+enum exynos_soc_revision exynos_revision;
+
+struct exynos_chipid_data {
+ unsigned int product_id_mask;
+ unsigned int product_id_shift;
+};
+
+static struct exynos_chipid_data exynos4_chipid_data = {
+ .product_id_mask= EXYNOS4_SOC_MASK,
+ .product_id_shift = PROD_ID_SHIFT,
+};
+
+static struct exynos_chipid_data exynos5_chipid_data = {
+ .product_id_mask= EXYNOS5_SOC_MASK,
+ .product_id_shift = PROD_ID_SHIFT,
+};
+
+static struct of_device_id of_exynos_chipid_ids[] = {
+ {
+ .compatible = "samsung,exynos4-chipid",
+ .data = (void *)&exynos4_chipid_data,
+ },
+ {
+ .compatible = "samsung,exynos5-chipid",
+ .data = (void *)&exynos5_chipid_data,
+ },
+ {},
+};
+
+bool is_soc_id_compatible(enum exynos_soc_id soc_id)
+{
+ return soc_id == exynos_soc_id;
+}
+
+bool is_soc_rev_compatible(enum exynos_soc_revision soc_rev)
+{
+ return soc_rev == exynos_revision;
+}
+
+static const char *exynos_soc_id_to_name(enum exynos_soc_id id)
+{
+ const char *soc_name;
+ switch (id) {
+ case EXYNOS4210:
+ soc_name = "EXYNOS4210";
+ break;
+ case EXYNOS4212:
+ soc_name = "EXYNOS4212";
+ break;
+ case EXYNOS4412:
+ soc_name = "EXYNOS4412";
+ break;
+ case EXYNOS5250:
+ soc_name = "EXYNOS5250";
+ break;
+ case EXYNOS5420:
+ soc_name = "EXYNOS5420";
+ break;
+ case EXYNOS5440:
+ soc_name = "EXYNOS5440";
+ break;
+ default:
+ soc_name = "";
+ }
+ return soc_name;
+}
+
+struct device * __init exynos_soc_device_init(void)
+{
+ struct soc_device_attribute *soc_dev_attr;
+ stru
[PATCH v3 4/6] ARM: EXYNOS: Remove unused header inclusion from hotplug.c
From: Pankaj Dubey This patch removed "plat/cpu.h" inclusion from hotplug.c as it is not required. Signed-off-by: Pankaj Dubey --- arch/arm/mach-exynos/hotplug.c |2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c index 0243ef3..5e19601 100644 --- a/arch/arm/mach-exynos/hotplug.c +++ b/arch/arm/mach-exynos/hotplug.c @@ -19,8 +19,6 @@ #include #include -#include - #include "common.h" #include "regs-pmu.h" -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 6/6] ARM: EXYNOS: Refactoring to remove soc_is_exynos macros from exynos
From: Pankaj Dubey
This patch enables chipid driver for ARCH_EXYNOS and refactors
machine code as well as exynos cpufreq driver code for using
chipid driver for identification of SoC ID and SoC rev.
This patch also updates DT binding information in exynos4 and
exynos5 dtsi file. As to differentiate product id bit-mask we need
separate compatible string for exynos4 and exynos5. Hoping this will
be helpful in future as bit-mask and bit-shift bit may differ.
Added binding information as well.
Signed-off-by: Pankaj Dubey
---
.../bindings/arm/samsung/exynos-chipid.txt | 21
arch/arm/Kconfig |1 +
arch/arm/boot/dts/exynos4.dtsi |2 +-
arch/arm/boot/dts/exynos5.dtsi |2 +-
arch/arm/mach-exynos/exynos.c | 47
arch/arm/mach-exynos/platsmp.c | 11 ++--
arch/arm/mach-exynos/pm.c | 26 -
arch/arm/plat-samsung/include/plat/cpu.h | 57
drivers/clk/samsung/clk-exynos4.c |2 +-
drivers/cpufreq/exynos-cpufreq.c |9 ++--
drivers/cpufreq/exynos-cpufreq.h |1 -
drivers/cpufreq/exynos4x12-cpufreq.c |5 +-
12 files changed, 61 insertions(+), 123 deletions(-)
create mode 100644
Documentation/devicetree/bindings/arm/samsung/exynos-chipid.txt
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-chipid.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-chipid.txt
new file mode 100644
index 000..a496459
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-chipid.txt
@@ -0,0 +1,21 @@
+SAMSUNG Exynos4/Exynos5 SoCs Chipid driver.
+
+Required properties:
+- compatible : Should at least contain "samsung,exynos4210-chipid". More
+ specific compatible string specify which SoC version (exynos4 or
+ exynos5) are paired with.
+ Details:
+ samsung,exynos4-chipid: Exynos4 SoCs has Chip ID block that can provide
+ product id, revision number and package information.
+ It has different product-id bit-mask than Exynos5 series SoC.
+ samsung,exynos5-chipid: Exynos5 SoCs has Chip ID block that can provide
+ product id, revision number and package information.
+ It has different product-id bit-mask then Exynos4 series SoC.
+
+- reg: offset and length of the register set
+
+Example:
+ chipid@1000 {
+ compatible = "samsung,exynos4210-chipid",
"samsung,exynos4-chipid";
+ reg = <0x1000 0x100>;
+ };
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a4eac2f..06f14a4 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -856,6 +856,7 @@ config ARCH_EXYNOS
select SRAM
select USE_OF
select MFD_SYSCON
+ select EXYNOS_CHIPID
help
Support for SAMSUNG's EXYNOS SoCs (EXYNOS4/5)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 2f8bcd0..d4c0657 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -46,7 +46,7 @@
};
chipid@1000 {
- compatible = "samsung,exynos4210-chipid";
+ compatible = "samsung,exynos4210-chipid",
"samsung,exynos4-chipid";
reg = <0x1000 0x100>;
};
diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index 3027e37..1d0b569 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -19,7 +19,7 @@
interrupt-parent = <&gic>;
chipid@1000 {
- compatible = "samsung,exynos4210-chipid";
+ compatible = "samsung,exynos4210-chipid",
"samsung,exynos5-chipid";
reg = <0x1000 0x100>;
};
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 9902e52..26f5e8c 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
@@ -28,7 +29,6 @@
#include
#include
-#include
#include
#include "common.h"
@@ -171,29 +171,6 @@ static void __init exynos_init_late(void)
exynos_pm_init();
}
-static int __init exynos_fdt_map_chipid(unsigned long node, const char *uname,
- int depth, void *data)
-{
- struct map_desc iodesc;
- __be32 *reg;
- unsigned long len;
-
- if (!of_flat_dt_is_compatible(node, "samsung,exynos4210-chipid") &&
- !of_flat_dt_is_compatible(node, "samsung,exynos5440-clock"))
- return 0;
-
- reg = of_get_flat_dt_prop(node, "reg", &len);
- if (reg == NULL || len != (sizeof(unsigned long) * 2))
- return 0;
-
- iodesc.pfn = __phys_to_pfn(be32_to_cpu(reg[0]));
- iodesc.length = be32_to_cpu(reg[1]) - 1;
- iodesc.vi
[PATCH v3 3/6] ARM: EXYNOS: Remove soc_is_exynos4/5 from exynos.c
From: Pankaj Dubey
This patch removes usage of soc_is_exynos4/5 from exynos.c.
For this we need to separate machine descriptors for exynos4
and exynos5. While doing this patch does some consolidation also.
CC: Russell King
CC: Thomas Abraham
Signed-off-by: Pankaj Dubey
---
arch/arm/mach-exynos/exynos.c| 52 +++---
arch/arm/plat-samsung/include/plat/cpu.h |3 --
2 files changed, 33 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 09063ee..9902e52 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -202,20 +202,6 @@ static const struct of_device_id exynos_dt_pmu_match[] = {
{},
};
-/*
- * exynos_map_io
- *
- * register the standard cpu IO areas
- */
-static void __init exynos_map_io(void)
-{
- if (soc_is_exynos4())
- iotable_init(exynos4_iodesc, ARRAY_SIZE(exynos4_iodesc));
-
- if (soc_is_exynos5())
- iotable_init(exynos5_iodesc, ARRAY_SIZE(exynos5_iodesc));
-}
-
static void __init exynos_init_io(void)
{
debug_ll_io_init();
@@ -224,8 +210,18 @@ static void __init exynos_init_io(void)
/* detect cpu id and rev. */
s5p_init_cpu(S5P_VA_CHIPID);
+}
+
+static void __init exynos5_init_io(void)
+{
+ exynos_init_io();
+ iotable_init(exynos5_iodesc, ARRAY_SIZE(exynos5_iodesc));
+}
- exynos_map_io();
+static void __init exynos4_init_io(void)
+{
+ exynos_init_io();
+ iotable_init(exynos4_iodesc, ARRAY_SIZE(exynos4_iodesc));
}
struct bus_type exynos_subsys = {
@@ -293,11 +289,15 @@ static void __init exynos_dt_machine_init(void)
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
-static char const *exynos_dt_compat[] __initconst = {
+static char const *exynos4_dt_compat[] __initconst = {
"samsung,exynos4",
"samsung,exynos4210",
"samsung,exynos4212",
"samsung,exynos4412",
+ NULL
+};
+
+static char const *exynos5_dt_compat[] __initconst = {
"samsung,exynos5",
"samsung,exynos5250",
"samsung,exynos5420",
@@ -321,15 +321,29 @@ static void __init exynos_reserve(void)
#endif
}
-DT_MACHINE_START(EXYNOS_DT, "SAMSUNG EXYNOS (Flattened Device Tree)")
+DT_MACHINE_START(EXYNOS5_DT, "SAMSUNG EXYNOS (Flattened Device Tree)")
+ /* Maintainer: Thomas Abraham */
+ /* Maintainer: Kukjin Kim */
+ .smp= smp_ops(exynos_smp_ops),
+ .map_io = exynos5_init_io,
+ .init_early = exynos_firmware_init,
+ .init_machine = exynos_dt_machine_init,
+ .init_late = exynos_init_late,
+ .dt_compat = exynos5_dt_compat,
+ .restart= exynos_restart,
+ .reserve= exynos_reserve,
+MACHINE_END
+
+
+DT_MACHINE_START(EXYNOS4_DT, "SAMSUNG EXYNOS (Flattened Device Tree)")
/* Maintainer: Thomas Abraham */
/* Maintainer: Kukjin Kim */
.smp= smp_ops(exynos_smp_ops),
- .map_io = exynos_init_io,
+ .map_io = exynos4_init_io,
.init_early = exynos_firmware_init,
.init_machine = exynos_dt_machine_init,
.init_late = exynos_init_late,
- .dt_compat = exynos_dt_compat,
+ .dt_compat = exynos4_dt_compat,
.restart= exynos_restart,
.reserve= exynos_reserve,
MACHINE_END
diff --git a/arch/arm/plat-samsung/include/plat/cpu.h
b/arch/arm/plat-samsung/include/plat/cpu.h
index 5992b8d..18a9a00 100644
--- a/arch/arm/plat-samsung/include/plat/cpu.h
+++ b/arch/arm/plat-samsung/include/plat/cpu.h
@@ -166,9 +166,6 @@ IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID,
EXYNOS5_SOC_MASK)
# define soc_is_exynos5440() 0
#endif
-#define soc_is_exynos4() (soc_is_exynos4210() || soc_is_exynos4212() || \
- soc_is_exynos4412())
-#define soc_is_exynos5() (soc_is_exynos5250() || soc_is_exynos5420())
#define IODESC_ENT(x) { (unsigned long)S3C24XX_VA_##x,
__phys_to_pfn(S3C24XX_PA_##x), S3C24XX_SZ_##x, MT_DEVICE }
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/6] Introducing Exynos ChipId driver
From: Pankaj Dubey This patch series attempts to get rid of soc_is_exynos macros and eventually with the help of this series we can probably get rid of CONFIG_SOC_EXYNOS in near future. Each Exynos SoC has ChipID block which can give information about SoC's product Id and revision number. Currently we have single DT binding information for this as "samsung,exynos4210-chipid". But Exynos4 and Exynos5 SoC series have one small difference in chip Id, with resepect to product id bit-masks. So it means we should have separate compatible string for these different series of SoCs. So I have added second compatible string for handling this difference. This patch series is based on Kukjin Kim's for-next (3.14_rc1 tag) and prepared on top of following patch series and it's dependent patch series. [1]: Map SYSRAM through generic SRAM bindings by Sachin Kamat. http://www.spinics.net/lists/arm-kernel/msg327677.html [2]: Exynos PMU cleanup and refactoring. https://lkml.org/lkml/2014/4/30/44 [3]: Introduce drivers/soc and add QCOM GSBI driver. https://lkml.org/lkml/2014/4/24/520 Revision 2 and it's discussion can be found here - https://lkml.org/lkml/2014/5/6/100 Changes since v2: - Reorganized patches as suggested by Tomasz Figa. - Addressed review comments of Tomasz Figa in i2c-s3c2410.c file. Changes since v1: - Added patch to move i2c interrupt re-configuration code from exynos.c to i2c driver, as suggested by Arnd. - After above patch only user of SYS_I2C_CFG register is pm.c so moving save/restore of this register also into i2c driver. - Spiltted up exynos4 and exynos5 machine descriptors to get rid from soc_is_exynos4/exynos5 kind of macros, as suggested by Arnd. - Changed location of chipid driver to "drivers/soc". - Added drivers/base/soc.c provided infrastructure to make SoC specific information avaible to user space via sysfs entry, as suggested by Arnd. Pankaj Dubey (6): i2c: s3c2410: Handle i2c sys_cfg register in i2c driver ARM: EXYNOS: Remove i2c sys configuration related code ARM: EXYNOS: Remove soc_is_exynos4/5 from exynos.c ARM: EXYNOS: Remove unused header inclusion from hotplug.c soc: samsung: exynos-chipid: Add Exynos Chipid driver support ARM: EXYNOS: Refactoring to remove soc_is_exynos macros from exynos .../bindings/arm/samsung/exynos-chipid.txt | 21 +++ .../devicetree/bindings/arm/samsung/sysreg.txt |1 + arch/arm/Kconfig |1 + arch/arm/boot/dts/exynos4.dtsi |2 +- arch/arm/boot/dts/exynos5.dtsi |7 +- arch/arm/boot/dts/exynos5250.dtsi |4 + arch/arm/boot/dts/exynos5420.dtsi |4 + arch/arm/mach-exynos/exynos.c | 119 -- arch/arm/mach-exynos/hotplug.c |2 - arch/arm/mach-exynos/include/mach/map.h|3 - arch/arm/mach-exynos/platsmp.c | 11 +- arch/arm/mach-exynos/pm.c | 36 ++--- arch/arm/mach-exynos/regs-sys.h| 22 --- arch/arm/plat-samsung/include/plat/cpu.h | 60 --- drivers/clk/samsung/clk-exynos4.c |2 +- drivers/cpufreq/exynos-cpufreq.c |9 +- drivers/cpufreq/exynos-cpufreq.h |1 - drivers/cpufreq/exynos4x12-cpufreq.c |5 +- drivers/i2c/busses/i2c-s3c2410.c | 32 drivers/soc/Kconfig|1 + drivers/soc/Makefile |1 + drivers/soc/samsung/Kconfig| 10 ++ drivers/soc/samsung/Makefile |1 + drivers/soc/samsung/exynos-chipid.c| 166 include/linux/exynos-soc.h | 46 ++ 25 files changed, 357 insertions(+), 210 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/samsung/exynos-chipid.txt delete mode 100644 arch/arm/mach-exynos/regs-sys.h create mode 100644 drivers/soc/samsung/Kconfig create mode 100644 drivers/soc/samsung/Makefile create mode 100644 drivers/soc/samsung/exynos-chipid.c create mode 100644 include/linux/exynos-soc.h -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/6] ARM: EXYNOS: Remove i2c sys configuration related code
From: Pankaj Dubey
Since all these code has been moved into i2c driver, now we can
safely remove them from machine files.
CC: Russell King
Signed-off-by: Pankaj Dubey
---
arch/arm/mach-exynos/exynos.c | 38 +--
arch/arm/mach-exynos/include/mach/map.h |3 ---
arch/arm/mach-exynos/pm.c | 10
arch/arm/mach-exynos/regs-sys.h | 22 --
4 files changed, 1 insertion(+), 72 deletions(-)
delete mode 100644 arch/arm/mach-exynos/regs-sys.h
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 59eb1f1..09063ee 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -29,11 +29,11 @@
#include
#include
+#include
#include "common.h"
#include "mfc.h"
#include "regs-pmu.h"
-#include "regs-sys.h"
#define L2_AUX_VAL 0x7C470001
#define L2_AUX_MASK 0xC200
@@ -42,11 +42,6 @@ static struct regmap *exynos_pmu_regmap;
static struct map_desc exynos4_iodesc[] __initdata = {
{
- .virtual= (unsigned long)S3C_VA_SYS,
- .pfn= __phys_to_pfn(EXYNOS4_PA_SYSCON),
- .length = SZ_64K,
- .type = MT_DEVICE,
- }, {
.virtual= (unsigned long)S3C_VA_TIMER,
.pfn= __phys_to_pfn(EXYNOS4_PA_TIMER),
.length = SZ_16K,
@@ -116,11 +111,6 @@ static struct map_desc exynos4_iodesc[] __initdata = {
static struct map_desc exynos5_iodesc[] __initdata = {
{
- .virtual= (unsigned long)S3C_VA_SYS,
- .pfn= __phys_to_pfn(EXYNOS5_PA_SYSCON),
- .length = SZ_64K,
- .type = MT_DEVICE,
- }, {
.virtual= (unsigned long)S3C_VA_TIMER,
.pfn= __phys_to_pfn(EXYNOS5_PA_TIMER),
.length = SZ_16K,
@@ -293,32 +283,6 @@ void __init exynos_map_pmu(void)
static void __init exynos_dt_machine_init(void)
{
- struct device_node *i2c_np;
- const char *i2c_compat = "samsung,s3c2440-i2c";
- unsigned int tmp;
- int id;
-
- /*
-* Exynos5's legacy i2c controller and new high speed i2c
-* controller have muxed interrupt sources. By default the
-* interrupts for 4-channel HS-I2C controller are enabled.
-* If node for first four channels of legacy i2c controller
-* are available then re-configure the interrupts via the
-* system register.
-*/
- if (soc_is_exynos5()) {
- for_each_compatible_node(i2c_np, NULL, i2c_compat) {
- if (of_device_is_available(i2c_np)) {
- id = of_alias_get_id(i2c_np, "i2c");
- if (id < 4) {
- tmp = readl(EXYNOS5_SYS_I2C_CFG);
- writel(tmp & ~(0x1 << id),
- EXYNOS5_SYS_I2C_CFG);
- }
- }
- }
- }
-
exynos_map_pmu();
if (!soc_is_exynos5440())
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index 34eee6e..bd4a320 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -25,9 +25,6 @@
#define EXYNOS_PA_CHIPID 0x1000
-#define EXYNOS4_PA_SYSCON 0x1001
-#define EXYNOS5_PA_SYSCON 0x10050100
-
#define EXYNOS4_PA_CMU 0x1003
#define EXYNOS5_PA_CMU 0x1001
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index a7a1b7f..59e5604 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -37,7 +37,6 @@
#include "common.h"
#include "regs-pmu.h"
-#include "regs-sys.h"
#include "exynos-pmu.h"
static struct regmap *pmu_regmap;
@@ -52,10 +51,6 @@ struct exynos_wkup_irq {
u32 mask;
};
-static struct sleep_save exynos5_sys_save[] = {
- SAVE_ITEM(EXYNOS5_SYS_I2C_CFG),
-};
-
static struct sleep_save exynos_core_save[] = {
/* SROM side */
SAVE_ITEM(S5P_SROM_BW),
@@ -211,7 +206,6 @@ static void exynos_pm_prepare(void)
s3c_pm_do_save(exynos_core_save, ARRAY_SIZE(exynos_core_save));
if (soc_is_exynos5250()) {
- s3c_pm_do_save(exynos5_sys_save, ARRAY_SIZE(exynos5_sys_save));
/* Disable USE_RETENTION of JPEG_MEM_OPTION */
regmap_read(pmu_regmap, EXYNOS5_JPEG_MEM_OPTION, &tmp);
tmp &= ~EXYNOS5_OPTION_USE_RETENTION;
@@ -296,10 +290,6 @@ static void exynos_pm_resume(void)
regmap_write(pmu_regmap, S5P_PAD_RET_EBIA_OPTION, (1 << 28));
regmap_write(pmu_regmap, S5P_PAD_RET_EBIB_OPTION, (1 << 28));
- if (soc_is_
[PATCH v3 4/6] ARM: EXYNOS: Remove unused header inclusion from hotplug.c
This patch removed "plat/cpu.h" inclusion from hotplug.c as it is not required. Signed-off-by: Pankaj Dubey --- arch/arm/mach-exynos/hotplug.c |2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c index 0243ef3..5e19601 100644 --- a/arch/arm/mach-exynos/hotplug.c +++ b/arch/arm/mach-exynos/hotplug.c @@ -19,8 +19,6 @@ #include #include -#include - #include "common.h" #include "regs-pmu.h" -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/6] ARM: EXYNOS: Remove i2c sys configuration related code
Since all these code has been moved into i2c driver, now we can
safely remove them from machine files.
CC: Russell King
Signed-off-by: Pankaj Dubey
---
arch/arm/mach-exynos/exynos.c | 38 +--
arch/arm/mach-exynos/include/mach/map.h |3 ---
arch/arm/mach-exynos/pm.c | 10
arch/arm/mach-exynos/regs-sys.h | 22 --
4 files changed, 1 insertion(+), 72 deletions(-)
delete mode 100644 arch/arm/mach-exynos/regs-sys.h
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 59eb1f1..09063ee 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -29,11 +29,11 @@
#include
#include
+#include
#include "common.h"
#include "mfc.h"
#include "regs-pmu.h"
-#include "regs-sys.h"
#define L2_AUX_VAL 0x7C470001
#define L2_AUX_MASK 0xC200
@@ -42,11 +42,6 @@ static struct regmap *exynos_pmu_regmap;
static struct map_desc exynos4_iodesc[] __initdata = {
{
- .virtual= (unsigned long)S3C_VA_SYS,
- .pfn= __phys_to_pfn(EXYNOS4_PA_SYSCON),
- .length = SZ_64K,
- .type = MT_DEVICE,
- }, {
.virtual= (unsigned long)S3C_VA_TIMER,
.pfn= __phys_to_pfn(EXYNOS4_PA_TIMER),
.length = SZ_16K,
@@ -116,11 +111,6 @@ static struct map_desc exynos4_iodesc[] __initdata = {
static struct map_desc exynos5_iodesc[] __initdata = {
{
- .virtual= (unsigned long)S3C_VA_SYS,
- .pfn= __phys_to_pfn(EXYNOS5_PA_SYSCON),
- .length = SZ_64K,
- .type = MT_DEVICE,
- }, {
.virtual= (unsigned long)S3C_VA_TIMER,
.pfn= __phys_to_pfn(EXYNOS5_PA_TIMER),
.length = SZ_16K,
@@ -293,32 +283,6 @@ void __init exynos_map_pmu(void)
static void __init exynos_dt_machine_init(void)
{
- struct device_node *i2c_np;
- const char *i2c_compat = "samsung,s3c2440-i2c";
- unsigned int tmp;
- int id;
-
- /*
-* Exynos5's legacy i2c controller and new high speed i2c
-* controller have muxed interrupt sources. By default the
-* interrupts for 4-channel HS-I2C controller are enabled.
-* If node for first four channels of legacy i2c controller
-* are available then re-configure the interrupts via the
-* system register.
-*/
- if (soc_is_exynos5()) {
- for_each_compatible_node(i2c_np, NULL, i2c_compat) {
- if (of_device_is_available(i2c_np)) {
- id = of_alias_get_id(i2c_np, "i2c");
- if (id < 4) {
- tmp = readl(EXYNOS5_SYS_I2C_CFG);
- writel(tmp & ~(0x1 << id),
- EXYNOS5_SYS_I2C_CFG);
- }
- }
- }
- }
-
exynos_map_pmu();
if (!soc_is_exynos5440())
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index 34eee6e..bd4a320 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -25,9 +25,6 @@
#define EXYNOS_PA_CHIPID 0x1000
-#define EXYNOS4_PA_SYSCON 0x1001
-#define EXYNOS5_PA_SYSCON 0x10050100
-
#define EXYNOS4_PA_CMU 0x1003
#define EXYNOS5_PA_CMU 0x1001
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index a7a1b7f..59e5604 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -37,7 +37,6 @@
#include "common.h"
#include "regs-pmu.h"
-#include "regs-sys.h"
#include "exynos-pmu.h"
static struct regmap *pmu_regmap;
@@ -52,10 +51,6 @@ struct exynos_wkup_irq {
u32 mask;
};
-static struct sleep_save exynos5_sys_save[] = {
- SAVE_ITEM(EXYNOS5_SYS_I2C_CFG),
-};
-
static struct sleep_save exynos_core_save[] = {
/* SROM side */
SAVE_ITEM(S5P_SROM_BW),
@@ -211,7 +206,6 @@ static void exynos_pm_prepare(void)
s3c_pm_do_save(exynos_core_save, ARRAY_SIZE(exynos_core_save));
if (soc_is_exynos5250()) {
- s3c_pm_do_save(exynos5_sys_save, ARRAY_SIZE(exynos5_sys_save));
/* Disable USE_RETENTION of JPEG_MEM_OPTION */
regmap_read(pmu_regmap, EXYNOS5_JPEG_MEM_OPTION, &tmp);
tmp &= ~EXYNOS5_OPTION_USE_RETENTION;
@@ -296,10 +290,6 @@ static void exynos_pm_resume(void)
regmap_write(pmu_regmap, S5P_PAD_RET_EBIA_OPTION, (1 << 28));
regmap_write(pmu_regmap, S5P_PAD_RET_EBIB_OPTION, (1 << 28));
- if (soc_is_exynos5250())
-
[PATCH v3 3/6] ARM: EXYNOS: Remove soc_is_exynos4/5 from exynos.c
This patch removes usage of soc_is_exynos4/5 from exynos.c.
For this we need to separate machine descriptors for exynos4
and exynos5. While doing this patch does some consolidation also.
CC: Russell King
CC: Thomas Abraham
Signed-off-by: Pankaj Dubey
---
arch/arm/mach-exynos/exynos.c| 52 +++---
arch/arm/plat-samsung/include/plat/cpu.h |3 --
2 files changed, 33 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 09063ee..9902e52 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -202,20 +202,6 @@ static const struct of_device_id exynos_dt_pmu_match[] = {
{},
};
-/*
- * exynos_map_io
- *
- * register the standard cpu IO areas
- */
-static void __init exynos_map_io(void)
-{
- if (soc_is_exynos4())
- iotable_init(exynos4_iodesc, ARRAY_SIZE(exynos4_iodesc));
-
- if (soc_is_exynos5())
- iotable_init(exynos5_iodesc, ARRAY_SIZE(exynos5_iodesc));
-}
-
static void __init exynos_init_io(void)
{
debug_ll_io_init();
@@ -224,8 +210,18 @@ static void __init exynos_init_io(void)
/* detect cpu id and rev. */
s5p_init_cpu(S5P_VA_CHIPID);
+}
+
+static void __init exynos5_init_io(void)
+{
+ exynos_init_io();
+ iotable_init(exynos5_iodesc, ARRAY_SIZE(exynos5_iodesc));
+}
- exynos_map_io();
+static void __init exynos4_init_io(void)
+{
+ exynos_init_io();
+ iotable_init(exynos4_iodesc, ARRAY_SIZE(exynos4_iodesc));
}
struct bus_type exynos_subsys = {
@@ -293,11 +289,15 @@ static void __init exynos_dt_machine_init(void)
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
-static char const *exynos_dt_compat[] __initconst = {
+static char const *exynos4_dt_compat[] __initconst = {
"samsung,exynos4",
"samsung,exynos4210",
"samsung,exynos4212",
"samsung,exynos4412",
+ NULL
+};
+
+static char const *exynos5_dt_compat[] __initconst = {
"samsung,exynos5",
"samsung,exynos5250",
"samsung,exynos5420",
@@ -321,15 +321,29 @@ static void __init exynos_reserve(void)
#endif
}
-DT_MACHINE_START(EXYNOS_DT, "SAMSUNG EXYNOS (Flattened Device Tree)")
+DT_MACHINE_START(EXYNOS5_DT, "SAMSUNG EXYNOS (Flattened Device Tree)")
+ /* Maintainer: Thomas Abraham */
+ /* Maintainer: Kukjin Kim */
+ .smp= smp_ops(exynos_smp_ops),
+ .map_io = exynos5_init_io,
+ .init_early = exynos_firmware_init,
+ .init_machine = exynos_dt_machine_init,
+ .init_late = exynos_init_late,
+ .dt_compat = exynos5_dt_compat,
+ .restart= exynos_restart,
+ .reserve= exynos_reserve,
+MACHINE_END
+
+
+DT_MACHINE_START(EXYNOS4_DT, "SAMSUNG EXYNOS (Flattened Device Tree)")
/* Maintainer: Thomas Abraham */
/* Maintainer: Kukjin Kim */
.smp= smp_ops(exynos_smp_ops),
- .map_io = exynos_init_io,
+ .map_io = exynos4_init_io,
.init_early = exynos_firmware_init,
.init_machine = exynos_dt_machine_init,
.init_late = exynos_init_late,
- .dt_compat = exynos_dt_compat,
+ .dt_compat = exynos4_dt_compat,
.restart= exynos_restart,
.reserve= exynos_reserve,
MACHINE_END
diff --git a/arch/arm/plat-samsung/include/plat/cpu.h
b/arch/arm/plat-samsung/include/plat/cpu.h
index 5992b8d..18a9a00 100644
--- a/arch/arm/plat-samsung/include/plat/cpu.h
+++ b/arch/arm/plat-samsung/include/plat/cpu.h
@@ -166,9 +166,6 @@ IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID,
EXYNOS5_SOC_MASK)
# define soc_is_exynos5440() 0
#endif
-#define soc_is_exynos4() (soc_is_exynos4210() || soc_is_exynos4212() || \
- soc_is_exynos4412())
-#define soc_is_exynos5() (soc_is_exynos5250() || soc_is_exynos5420())
#define IODESC_ENT(x) { (unsigned long)S3C24XX_VA_##x,
__phys_to_pfn(S3C24XX_PA_##x), S3C24XX_SZ_##x, MT_DEVICE }
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 6/6] ARM: EXYNOS: Refactoring to remove soc_is_exynos macros from exynos
This patch enables chipid driver for ARCH_EXYNOS and refactors
machine code as well as exynos cpufreq driver code for using
chipid driver for identification of SoC ID and SoC rev.
This patch also updates DT binding information in exynos4 and
exynos5 dtsi file. As to differentiate product id bit-mask we need
separate compatible string for exynos4 and exynos5. Hoping this will
be helpful in future as bit-mask and bit-shift bit may differ.
Added binding information as well.
Signed-off-by: Pankaj Dubey
---
.../bindings/arm/samsung/exynos-chipid.txt | 21
arch/arm/Kconfig |1 +
arch/arm/boot/dts/exynos4.dtsi |2 +-
arch/arm/boot/dts/exynos5.dtsi |2 +-
arch/arm/mach-exynos/exynos.c | 47
arch/arm/mach-exynos/platsmp.c | 11 ++--
arch/arm/mach-exynos/pm.c | 26 -
arch/arm/plat-samsung/include/plat/cpu.h | 57
drivers/clk/samsung/clk-exynos4.c |2 +-
drivers/cpufreq/exynos-cpufreq.c |9 ++--
drivers/cpufreq/exynos-cpufreq.h |1 -
drivers/cpufreq/exynos4x12-cpufreq.c |5 +-
12 files changed, 61 insertions(+), 123 deletions(-)
create mode 100644
Documentation/devicetree/bindings/arm/samsung/exynos-chipid.txt
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-chipid.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-chipid.txt
new file mode 100644
index 000..a496459
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-chipid.txt
@@ -0,0 +1,21 @@
+SAMSUNG Exynos4/Exynos5 SoCs Chipid driver.
+
+Required properties:
+- compatible : Should at least contain "samsung,exynos4210-chipid". More
+ specific compatible string specify which SoC version (exynos4 or
+ exynos5) are paired with.
+ Details:
+ samsung,exynos4-chipid: Exynos4 SoCs has Chip ID block that can provide
+ product id, revision number and package information.
+ It has different product-id bit-mask than Exynos5 series SoC.
+ samsung,exynos5-chipid: Exynos5 SoCs has Chip ID block that can provide
+ product id, revision number and package information.
+ It has different product-id bit-mask then Exynos4 series SoC.
+
+- reg: offset and length of the register set
+
+Example:
+ chipid@1000 {
+ compatible = "samsung,exynos4210-chipid",
"samsung,exynos4-chipid";
+ reg = <0x1000 0x100>;
+ };
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a4eac2f..06f14a4 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -856,6 +856,7 @@ config ARCH_EXYNOS
select SRAM
select USE_OF
select MFD_SYSCON
+ select EXYNOS_CHIPID
help
Support for SAMSUNG's EXYNOS SoCs (EXYNOS4/5)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 2f8bcd0..d4c0657 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -46,7 +46,7 @@
};
chipid@1000 {
- compatible = "samsung,exynos4210-chipid";
+ compatible = "samsung,exynos4210-chipid",
"samsung,exynos4-chipid";
reg = <0x1000 0x100>;
};
diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index 3027e37..1d0b569 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -19,7 +19,7 @@
interrupt-parent = <&gic>;
chipid@1000 {
- compatible = "samsung,exynos4210-chipid";
+ compatible = "samsung,exynos4210-chipid",
"samsung,exynos5-chipid";
reg = <0x1000 0x100>;
};
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 9902e52..26f5e8c 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
@@ -28,7 +29,6 @@
#include
#include
-#include
#include
#include "common.h"
@@ -171,29 +171,6 @@ static void __init exynos_init_late(void)
exynos_pm_init();
}
-static int __init exynos_fdt_map_chipid(unsigned long node, const char *uname,
- int depth, void *data)
-{
- struct map_desc iodesc;
- __be32 *reg;
- unsigned long len;
-
- if (!of_flat_dt_is_compatible(node, "samsung,exynos4210-chipid") &&
- !of_flat_dt_is_compatible(node, "samsung,exynos5440-clock"))
- return 0;
-
- reg = of_get_flat_dt_prop(node, "reg", &len);
- if (reg == NULL || len != (sizeof(unsigned long) * 2))
- return 0;
-
- iodesc.pfn = __phys_to_pfn(be32_to_cpu(reg[0]));
- iodesc.length = be32_to_cpu(reg[1]) - 1;
- iodesc.virtual = (unsigned lon
[PATCH v3 1/6] i2c: s3c2410: Handle i2c sys_cfg register in i2c driver
Let's handle i2c interrupt re-configuration in i2c driver. This will
help us in removing some soc specific checks from machine files.
Since only Exynos5250, and Exynos5420 need to do this, added syscon
based phandle to i2c device nodes of respective SoC DT files.
Also handle saving and restoring of SYS_I2C_CFG register during
suspend and resume of i2c driver. This will help in removing soc
specific check from mach-exynos/pm.c.
CC: Rob Herring
CC: Randy Dunlap
CC: Wolfram Sang
CC: Russell King
CC: devicet...@vger.kernel.org
CC: linux-...@vger.kernel.org
CC: linux-...@vger.kernel.org
Signed-off-by: Pankaj Dubey
---
.../devicetree/bindings/arm/samsung/sysreg.txt |1 +
arch/arm/boot/dts/exynos5.dtsi |5 +++
arch/arm/boot/dts/exynos5250.dtsi |4 +++
arch/arm/boot/dts/exynos5420.dtsi |4 +++
drivers/i2c/busses/i2c-s3c2410.c | 32
5 files changed, 46 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
b/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
index 0ab3251..fd71581 100644
--- a/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
@@ -3,6 +3,7 @@ SAMSUNG S5P/Exynos SoC series System Registers (SYSREG)
Properties:
- compatible : should contain "samsung,-sysreg", "syscon";
For Exynos4 SoC series it should be "samsung,exynos4-sysreg", "syscon";
+ For Exynos5 SoC series it should be "samsung,exynos5-sysreg", "syscon";
- reg : offset and length of the register set.
Example:
diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index 79d0608..3027e37 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -99,4 +99,9 @@
#size-cells = <0>;
status = "disabled";
};
+
+ sys_reg: syscon@1005 {
+ compatible = "samsung,exynos5-sysreg", "syscon";
+ reg = <0x1005 0x400>;
+ };
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 8d724d5..46f0233 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -285,6 +285,7 @@
clock-names = "i2c";
pinctrl-names = "default";
pinctrl-0 = <&i2c0_bus>;
+ samsung,syscon-phandle = <&sys_reg>;
status = "disabled";
};
@@ -298,6 +299,7 @@
clock-names = "i2c";
pinctrl-names = "default";
pinctrl-0 = <&i2c1_bus>;
+ samsung,syscon-phandle = <&sys_reg>;
status = "disabled";
};
@@ -311,6 +313,7 @@
clock-names = "i2c";
pinctrl-names = "default";
pinctrl-0 = <&i2c2_bus>;
+ samsung,syscon-phandle = <&sys_reg>;
status = "disabled";
};
@@ -324,6 +327,7 @@
clock-names = "i2c";
pinctrl-names = "default";
pinctrl-0 = <&i2c3_bus>;
+ samsung,syscon-phandle = <&sys_reg>;
status = "disabled";
};
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index ff496ad..762128c 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -517,6 +517,7 @@
clock-names = "i2c";
pinctrl-names = "default";
pinctrl-0 = <&i2c0_bus>;
+ samsung,syscon-phandle = <&sys_reg>;
status = "disabled";
};
@@ -530,6 +531,7 @@
clock-names = "i2c";
pinctrl-names = "default";
pinctrl-0 = <&i2c1_bus>;
+ samsung,syscon-phandle = <&sys_reg>;
status = "disabled";
};
@@ -543,6 +545,7 @@
clock-names = "i2c";
pinctrl-names = "default";
pinctrl-0 = <&i2c2_bus>;
+ samsung,syscon-phandle = <&sys_reg>;
status = "disabled";
};
@@ -556,6 +559,7 @@
clock-names = "i2c";
pinctrl-names = "default";
pinctrl-0 = <&i2c3_bus>;
+ samsung,syscon-phandle = <&sys_reg>;
status = "disabled";
};
diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index ae44910..e707062 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -39,6 +39,8 @@
#include
#include
#include
+#include
+#include
#include
@@ -91,6 +93,9 @@
/* Max time to wait for bus to become idle after a xfer (in us) */
#define S3C2410_IDLE_TIMEOUT 5000
+/* Exynos5 Sysreg offset */
+#define EXYNOS5_SYS_I2C_CFG0x0234
+
/* i2c controller state */
enum s3c24xx_i2c_state {
STATE_IDLE,
@@ -127,6 +132,8 @@ struct s3c24xx
[PATCH v3 5/6] soc: samsung: exynos-chipid: Add Exynos Chipid driver support
Exynos SoCs have Chipid, for identification of product IDs
and SoC revistions. Till now we are using static macros
such as soc_is_exynos and #ifdefs for run time identification
of SoCs and their revisions. This is leading to add new Kconfig,
soc_is_exynos definitions each time new SoC support is getting
added. So this driver intends to provide initialization code
all these functionalites and thus helping in removing macros.
Signed-off-by: Pankaj Dubey
---
drivers/soc/Kconfig |1 +
drivers/soc/Makefile|1 +
drivers/soc/samsung/Kconfig | 10 +++
drivers/soc/samsung/Makefile|1 +
drivers/soc/samsung/exynos-chipid.c | 166 +++
include/linux/exynos-soc.h | 46 ++
6 files changed, 225 insertions(+)
create mode 100644 drivers/soc/samsung/Kconfig
create mode 100644 drivers/soc/samsung/Makefile
create mode 100644 drivers/soc/samsung/exynos-chipid.c
create mode 100644 include/linux/exynos-soc.h
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index 07a11be..86e52b1 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -1,5 +1,6 @@
menu "SOC specific Drivers"
source "drivers/soc/qcom/Kconfig"
+source "drivers/soc/samsung/Kconfig"
endmenu
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 0f7c447..ee890aa 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -3,3 +3,4 @@
#
obj-$(CONFIG_ARCH_QCOM)+= qcom/
+obj-$(CONFIG_ARCH_EXYNOS) += samsung/
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
new file mode 100644
index 000..dacc95d
--- /dev/null
+++ b/drivers/soc/samsung/Kconfig
@@ -0,0 +1,10 @@
+
+# SAMSUNG Soc drivers
+#
+config EXYNOS_CHIPID
+ tristate "Support Exynos CHIPID"
+ default y
+ select SOC_BUS
+ depends on ARCH_EXYNOS || ARM64
+ help
+ If you say Y here you get support for the Exynos CHIP id.
diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile
new file mode 100644
index 000..855ca05
--- /dev/null
+++ b/drivers/soc/samsung/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_EXYNOS_CHIPID)+= exynos-chipid.o
diff --git a/drivers/soc/samsung/exynos-chipid.c
b/drivers/soc/samsung/exynos-chipid.c
new file mode 100644
index 000..b5bccd9
--- /dev/null
+++ b/drivers/soc/samsung/exynos-chipid.c
@@ -0,0 +1,166 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * EXYNOS - CHIP ID support
+ * Author: Pankaj Dubey
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define EXYNOS4_SOC_MASK 0xFFFE0
+#define EXYNOS5_SOC_MASK 0xF
+
+#define PROD_ID_SHIFT (12)
+
+static void __iomem*exynos_chipid_base;
+unsigned int exynos_soc_id = EXYNOS_SOC_UNKNOWN;
+enum exynos_soc_revision exynos_revision;
+
+struct exynos_chipid_data {
+ unsigned int product_id_mask;
+ unsigned int product_id_shift;
+};
+
+static struct exynos_chipid_data exynos4_chipid_data = {
+ .product_id_mask= EXYNOS4_SOC_MASK,
+ .product_id_shift = PROD_ID_SHIFT,
+};
+
+static struct exynos_chipid_data exynos5_chipid_data = {
+ .product_id_mask= EXYNOS5_SOC_MASK,
+ .product_id_shift = PROD_ID_SHIFT,
+};
+
+static struct of_device_id of_exynos_chipid_ids[] = {
+ {
+ .compatible = "samsung,exynos4-chipid",
+ .data = (void *)&exynos4_chipid_data,
+ },
+ {
+ .compatible = "samsung,exynos5-chipid",
+ .data = (void *)&exynos5_chipid_data,
+ },
+ {},
+};
+
+bool is_soc_id_compatible(enum exynos_soc_id soc_id)
+{
+ return soc_id == exynos_soc_id;
+}
+
+bool is_soc_rev_compatible(enum exynos_soc_revision soc_rev)
+{
+ return soc_rev == exynos_revision;
+}
+
+static const char *exynos_soc_id_to_name(enum exynos_soc_id id)
+{
+ const char *soc_name;
+ switch (id) {
+ case EXYNOS4210:
+ soc_name = "EXYNOS4210";
+ break;
+ case EXYNOS4212:
+ soc_name = "EXYNOS4212";
+ break;
+ case EXYNOS4412:
+ soc_name = "EXYNOS4412";
+ break;
+ case EXYNOS5250:
+ soc_name = "EXYNOS5250";
+ break;
+ case EXYNOS5420:
+ soc_name = "EXYNOS5420";
+ break;
+ case EXYNOS5440:
+ soc_name = "EXYNOS5440";
+ break;
+ default:
+ soc_name = "";
+ }
+ return soc_name;
+}
+
+struct device * __init exynos_soc_device_init(void)
+{
+ struct soc_device_attribute *soc_dev_attr;
+ struct soc_device *exynos
[PATCH v3 0/6] Introducing Exynos ChipId driver
This patch series attempts to get rid of soc_is_exynos macros and eventually with the help of this series we can probably get rid of CONFIG_SOC_EXYNOS in near future. Each Exynos SoC has ChipID block which can give information about SoC's product Id and revision number. Currently we have single DT binding information for this as "samsung,exynos4210-chipid". But Exynos4 and Exynos5 SoC series have one small difference in chip Id, with resepect to product id bit-masks. So it means we should have separate compatible string for these different series of SoCs. So I have added second compatible string for handling this difference. This patch series is based on Kukjin Kim's for-next (3.14_rc1 tag) and prepared on top of following patch series and it's dependent patch series. [1]: Map SYSRAM through generic SRAM bindings by Sachin Kamat. http://www.spinics.net/lists/arm-kernel/msg327677.html [2]: Exynos PMU cleanup and refactoring. https://lkml.org/lkml/2014/4/30/44 [3]: Introduce drivers/soc and add QCOM GSBI driver. https://lkml.org/lkml/2014/4/24/520 Revision 2 and it's discussion can be found here - https://lkml.org/lkml/2014/5/6/100 Changes since v2: - Reorganized patches as suggested by Tomasz Figa. - Addressed review comments of Tomasz Figa in i2c-s3c2410.c file. Changes since v1: - Added patch to move i2c interrupt re-configuration code from exynos.c to i2c driver, as suggested by Arnd. - After above patch only user of SYS_I2C_CFG register is pm.c so moving save/restore of this register also into i2c driver. - Spiltted up exynos4 and exynos5 machine descriptors to get rid from soc_is_exynos4/exynos5 kind of macros, as suggested by Arnd. - Changed location of chipid driver to "drivers/soc". - Added drivers/base/soc.c provided infrastructure to make SoC specific information avaible to user space via sysfs entry, as suggested by Arnd. Pankaj Dubey (6): i2c: s3c2410: Handle i2c sys_cfg register in i2c driver ARM: EXYNOS: Remove i2c sys configuration related code ARM: EXYNOS: Remove soc_is_exynos4/5 from exynos.c ARM: EXYNOS: Remove unused header inclusion from hotplug.c soc: samsung: exynos-chipid: Add Exynos Chipid driver support ARM: EXYNOS: Refactoring to remove soc_is_exynos macros from exynos .../bindings/arm/samsung/exynos-chipid.txt | 21 +++ .../devicetree/bindings/arm/samsung/sysreg.txt |1 + arch/arm/Kconfig |1 + arch/arm/boot/dts/exynos4.dtsi |2 +- arch/arm/boot/dts/exynos5.dtsi |7 +- arch/arm/boot/dts/exynos5250.dtsi |4 + arch/arm/boot/dts/exynos5420.dtsi |4 + arch/arm/mach-exynos/exynos.c | 119 -- arch/arm/mach-exynos/hotplug.c |2 - arch/arm/mach-exynos/include/mach/map.h|3 - arch/arm/mach-exynos/platsmp.c | 11 +- arch/arm/mach-exynos/pm.c | 36 ++--- arch/arm/mach-exynos/regs-sys.h| 22 --- arch/arm/plat-samsung/include/plat/cpu.h | 60 --- drivers/clk/samsung/clk-exynos4.c |2 +- drivers/cpufreq/exynos-cpufreq.c |9 +- drivers/cpufreq/exynos-cpufreq.h |1 - drivers/cpufreq/exynos4x12-cpufreq.c |5 +- drivers/i2c/busses/i2c-s3c2410.c | 32 drivers/soc/Kconfig|1 + drivers/soc/Makefile |1 + drivers/soc/samsung/Kconfig| 10 ++ drivers/soc/samsung/Makefile |1 + drivers/soc/samsung/exynos-chipid.c| 166 include/linux/exynos-soc.h | 46 ++ 25 files changed, 357 insertions(+), 210 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/samsung/exynos-chipid.txt delete mode 100644 arch/arm/mach-exynos/regs-sys.h create mode 100644 drivers/soc/samsung/Kconfig create mode 100644 drivers/soc/samsung/Makefile create mode 100644 drivers/soc/samsung/exynos-chipid.c create mode 100644 include/linux/exynos-soc.h -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] KVM: x86: Fix CR3 reserved bits
On 2014-04-18 02:35, Nadav Amit wrote:
> According to Intel specifications, PAE and non-PAE does not have any reserved
> bits. In long-mode, regardless to PCIDE, only the high bits (above the
> physical address) are reserved.
>
> Signed-off-by: Nadav Amit
> ---
> :100644 100644 7de069af.. e21aee9... March/x86/include/asm/kvm_host.h
> :100644 100644 205b17e... 1d60374... March/x86/kvm/emulate.c
> :100644 100644 8b8fc0b... f4d9839... March/x86/kvm/x86.c
> arch/x86/include/asm/kvm_host.h |6 +-
> arch/x86/kvm/emulate.c |4
> arch/x86/kvm/x86.c | 25 +
> 3 files changed, 6 insertions(+), 29 deletions(-)
>
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 7de069af..e21aee9 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -50,11 +50,7 @@
> | X86_CR0_ET | X86_CR0_NE | X86_CR0_WP | X86_CR0_AM \
> | X86_CR0_NW | X86_CR0_CD | X86_CR0_PG))
>
> -#define CR3_PAE_RESERVED_BITS ((X86_CR3_PWT | X86_CR3_PCD) - 1)
> -#define CR3_NONPAE_RESERVED_BITS ((PAGE_SIZE-1) & ~(X86_CR3_PWT |
> X86_CR3_PCD))
> -#define CR3_PCID_ENABLED_RESERVED_BITS 0xFF00ULL
> -#define CR3_L_MODE_RESERVED_BITS (CR3_NONPAE_RESERVED_BITS | \
> - 0xFF00ULL)
> +#define CR3_L_MODE_RESERVED_BITS 0xFF00ULL
> #define CR4_RESERVED_BITS \
> (~(unsigned long)(X86_CR4_VME | X86_CR4_PVI | X86_CR4_TSD | X86_CR4_DE\
> | X86_CR4_PSE | X86_CR4_PAE | X86_CR4_MCE \
> diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
> index 205b17e..1d60374 100644
> --- a/arch/x86/kvm/emulate.c
> +++ b/arch/x86/kvm/emulate.c
> @@ -3386,10 +3386,6 @@ static int check_cr_write(struct x86_emulate_ctxt
> *ctxt)
> ctxt->ops->get_msr(ctxt, MSR_EFER, &efer);
> if (efer & EFER_LMA)
> rsvd = CR3_L_MODE_RESERVED_BITS;
> - else if (ctxt->ops->get_cr(ctxt, 4) & X86_CR4_PAE)
> - rsvd = CR3_PAE_RESERVED_BITS;
> - else if (ctxt->ops->get_cr(ctxt, 0) & X86_CR0_PG)
> - rsvd = CR3_NONPAE_RESERVED_BITS;
>
> if (new_val & rsvd)
> return emulate_gp(ctxt, 0);
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 8b8fc0b..f4d9839 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -701,26 +701,11 @@ int kvm_set_cr3(struct kvm_vcpu *vcpu, unsigned long
> cr3)
> return 0;
> }
>
> - if (is_long_mode(vcpu)) {
> - if (kvm_read_cr4_bits(vcpu, X86_CR4_PCIDE)) {
> - if (cr3 & CR3_PCID_ENABLED_RESERVED_BITS)
> - return 1;
> - } else
> - if (cr3 & CR3_L_MODE_RESERVED_BITS)
> - return 1;
> - } else {
> - if (is_pae(vcpu)) {
> - if (cr3 & CR3_PAE_RESERVED_BITS)
> - return 1;
> - if (is_paging(vcpu) &&
> - !load_pdptrs(vcpu, vcpu->arch.walk_mmu, cr3))
> - return 1;
> - }
> - /*
> - * We don't check reserved bits in nonpae mode, because
> - * this isn't enforced, and VMware depends on this.
> - */
> - }
> + if (is_long_mode(vcpu) && (cr3 & CR3_L_MODE_RESERVED_BITS))
> + return 1;
> + if (is_pae(vcpu) && is_paging(vcpu) &&
> + !load_pdptrs(vcpu, vcpu->arch.walk_mmu, cr3))
> + return 1;
This is wrong: is_pae returns true in long mode, but we don't have valid
pdptrs then. Crashes my Jailhouse guest.
I suppose we need a patch on top as this is already in kvm.next, right?
Jan
signature.asc
Description: OpenPGP digital signature
[PATCH 1/3] mm: add comment for __mod_zone_page_stat
__mod_zone_page_stat() is not irq-safe, so it should be used carefully.
And it is not appropirately documented now. This patch adds comment for
it, and also documents for some of its call sites.
Suggested-by: Andrew Morton
Signed-off-by: Jianyu Zhan
---
mm/page_alloc.c | 2 ++
mm/rmap.c | 6 ++
mm/vmstat.c | 16 +++-
3 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 5dba293..9d6f474 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -659,6 +659,8 @@ static inline int free_pages_check(struct page *page)
*
* And clear the zone's pages_scanned counter, to hold off the "all pages are
* pinned" detection logic.
+ *
+ * Note: this function should be used with irq disabled.
*/
static void free_pcppages_bulk(struct zone *zone, int count,
struct per_cpu_pages *pcp)
diff --git a/mm/rmap.c b/mm/rmap.c
index 9c3e773..6078a30 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -979,6 +979,8 @@ void page_add_anon_rmap(struct page *page,
/*
* Special version of the above for do_swap_page, which often runs
* into pages that are exclusively owned by the current process.
+ * So we could use the irq-unsafe version __{inc|mod}_zone_page_stat
+ * here without others racing change it in between.
* Everybody else should continue to use page_add_anon_rmap above.
*/
void do_page_add_anon_rmap(struct page *page,
@@ -1077,6 +1079,10 @@ void page_remove_rmap(struct page *page)
/*
* Hugepages are not counted in NR_ANON_PAGES nor NR_FILE_MAPPED
* and not charged by memcg for now.
+*
+* And we are the last user of this page, so it is safe to use
+* the irq-unsafe version __{mod|dec}_zone_page here, since we
+* have no racer.
*/
if (unlikely(PageHuge(page)))
goto out;
diff --git a/mm/vmstat.c b/mm/vmstat.c
index 302dd07..778f154 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -207,7 +207,21 @@ void set_pgdat_percpu_threshold(pg_data_t *pgdat,
}
/*
- * For use when we know that interrupts are disabled.
+ * Optimized modificatoin function.
+ *
+ * The code basically does the modification in two steps:
+ *
+ * 1. read the current counter based on the processor number
+ * 2. modificate the counter write it back.
+ *
+ * So this function should be used with the guarantee that
+ *
+ * 1. interrupts are disabled, or
+ * 2. interrupts are enabled, but no other sites would race to
+ * modify this counter in between.
+ *
+ * Otherwise, an irq-safe version mod_zone_page_state() should
+ * be used instead.
*/
void __mod_zone_page_state(struct zone *zone, enum zone_stat_item item,
int delta)
--
2.0.0-rc1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/char/mem.c: Add /dev/ioports, supporting 16-bit and 32-bit ports
On Fri, May 09, 2014 at 12:19:16PM -0700, Josh Triplett wrote:
> + if (port > 65535)
> + return 0;
> + switch (count) {
[...]
> + case 4:
> + if (__put_user(inl(port), buf) < 0)
> + return -EFAULT;
What if I attempt a four-byte read at 65535? That would access four
out-of-bounds bytes, right?
signature.asc
Description: Digital signature
[PATCH 2/3] mm: use a light-weight __mod_zone_page_state in mlocked_vma_newpage()
mlocked_vma_newpage() is only called in fault path by
page_add_new_anon_rmap(), which is called on a *new* page.
And such page is initially only visible via the pagetables, and the
pte is locked while calling page_add_new_anon_rmap(), so we need not
use an irq-safe mod_zone_page_state() here, using a light-weight version
__mod_zone_page_state() would be OK.
And as suggested by Andrew, to reduce the risks that new call sites
incorrectly using mlocked_vma_newpage() without knowing they are adding
racing, this patch also moves it from internal.h to right before its only
call site page_add_new_anon_rmap() in rmap.c, with detailed document added.
Suggested-by: Andrew Morton
Signed-off-by: Jianyu Zhan
---
mm/internal.h | 22 ++
mm/rmap.c | 24
2 files changed, 26 insertions(+), 20 deletions(-)
diff --git a/mm/internal.h b/mm/internal.h
index 07b6736..20abafb 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -183,26 +183,8 @@ static inline void munlock_vma_pages_all(struct
vm_area_struct *vma)
munlock_vma_pages_range(vma, vma->vm_start, vma->vm_end);
}
-/*
- * Called only in fault path, to determine if a new page is being
- * mapped into a LOCKED vma. If it is, mark page as mlocked.
- */
-static inline int mlocked_vma_newpage(struct vm_area_struct *vma,
- struct page *page)
-{
- VM_BUG_ON_PAGE(PageLRU(page), page);
-
- if (likely((vma->vm_flags & (VM_LOCKED | VM_SPECIAL)) != VM_LOCKED))
- return 0;
-
- if (!TestSetPageMlocked(page)) {
- mod_zone_page_state(page_zone(page), NR_MLOCK,
- hpage_nr_pages(page));
- count_vm_event(UNEVICTABLE_PGMLOCKED);
- }
- return 1;
-}
-
+extern int mlocked_vma_newpage(struct vm_area_struct *vma,
+ struct page *page);
/*
* must be called with vma's mmap_sem held for read or write, and page locked.
*/
diff --git a/mm/rmap.c b/mm/rmap.c
index 6078a30..a9d02ef 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1005,6 +1005,30 @@ void do_page_add_anon_rmap(struct page *page,
__page_check_anon_rmap(page, vma, address);
}
+/*
+ * Called only in fault path, to determine if a new page is being
+ * mapped into a LOCKED vma. If it is, mark page as mlocked.
+ * This function is only called in fault path by
+ * page_add_new_anon_rmap(), which is called on a *new* page.
+ * And such page is initially only visible via the pagetables, and the
+ * pte is locked while calling page_add_new_anon_rmap(), so using a
+ * light-weight version __mod_zone_page_state() would be OK.
+ */
+int mlocked_vma_newpage(struct vm_area_struct *vma,
+ struct page *page)
+{
+ VM_BUG_ON_PAGE(PageLRU(page), page);
+ if (likely((vma->vm_flags & (VM_LOCKED | VM_SPECIAL)) != VM_LOCKED))
+ return 0;
+
+ if (!TestSetPageMlocked(page)) {
+ __mod_zone_page_state(page_zone(page), NR_MLOCK,
+ hpage_nr_pages(page));
+ count_vm_event(UNEVICTABLE_PGMLOCKED);
+ }
+ return 1;
+}
+
/**
* page_add_new_anon_rmap - add pte mapping to a new anonymous page
* @page: the page to add the mapping to
--
2.0.0-rc1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] mm: rename mlocked_vma_newpage to newpage_in_mlocked_vma
mlocked_vma_newpage is used to determine if a new page is mapped into
a *mlocked* vma. It is poorly named, so rename it to newpage_in_mlocked_vma.
Signed-off-by: Jianyu Zhan
---
mm/internal.h | 4 ++--
mm/rmap.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/mm/internal.h b/mm/internal.h
index 20abafb..35efd79 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -183,7 +183,7 @@ static inline void munlock_vma_pages_all(struct
vm_area_struct *vma)
munlock_vma_pages_range(vma, vma->vm_start, vma->vm_end);
}
-extern int mlocked_vma_newpage(struct vm_area_struct *vma,
+extern int newpage_in_mlocked_vma(struct vm_area_struct *vma,
struct page *page);
/*
* must be called with vma's mmap_sem held for read or write, and page locked.
@@ -227,7 +227,7 @@ extern unsigned long vma_address(struct page *page,
struct vm_area_struct *vma);
#endif
#else /* !CONFIG_MMU */
-static inline int mlocked_vma_newpage(struct vm_area_struct *v, struct page *p)
+static inline int newpage_in_mlocked_vma(struct vm_area_struct *v, struct page
*p)
{
return 0;
}
diff --git a/mm/rmap.c b/mm/rmap.c
index a9d02ef..9ff6915 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1014,7 +1014,7 @@ void do_page_add_anon_rmap(struct page *page,
* pte is locked while calling page_add_new_anon_rmap(), so using a
* light-weight version __mod_zone_page_state() would be OK.
*/
-int mlocked_vma_newpage(struct vm_area_struct *vma,
+int newpage_in_mlocked_vma(struct vm_area_struct *vma,
struct page *page)
{
VM_BUG_ON_PAGE(PageLRU(page), page);
@@ -1050,7 +1050,7 @@ void page_add_new_anon_rmap(struct page *page,
__mod_zone_page_state(page_zone(page), NR_ANON_PAGES,
hpage_nr_pages(page));
__page_set_anon_rmap(page, vma, address, 1);
- if (!mlocked_vma_newpage(vma, page)) {
+ if (!newpage_in_mlocked_vma(vma, page)) {
SetPageActive(page);
lru_cache_add(page);
} else
--
2.0.0-rc1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] KVM: x86: Fix CR3 reserved bits check in long mode
From: Jan Kiszka
Regression of 346874c9: PAE is set in long mode, but that does not mean
we have valid PDPTRs.
Signed-off-by: Jan Kiszka
---
arch/x86/kvm/x86.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c5582c3..198aac8 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -701,10 +701,11 @@ int kvm_set_cr3(struct kvm_vcpu *vcpu, unsigned long cr3)
return 0;
}
- if (is_long_mode(vcpu) && (cr3 & CR3_L_MODE_RESERVED_BITS))
- return 1;
- if (is_pae(vcpu) && is_paging(vcpu) &&
- !load_pdptrs(vcpu, vcpu->arch.walk_mmu, cr3))
+ if (is_long_mode(vcpu)) {
+ if (cr3 & CR3_L_MODE_RESERVED_BITS)
+ return 1;
+ } else if (is_pae(vcpu) && is_paging(vcpu) &&
+ !load_pdptrs(vcpu, vcpu->arch.walk_mmu, cr3))
return 1;
vcpu->arch.cr3 = cr3;
--
1.8.1.1.298.ge7eed54
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 1/2] mfd: pm8x41: add support for Qualcomm 8x41 PMICs
Hi Courtney,
On Fri, 2014-05-09 at 13:30 -0700, Courtney Cavin wrote:
> > > Requiring a specific PMIC listed before a generic one allows us an
> > > escape hatch in the future if for some reason we need to add a quirk for
> > > a specific PMIC.
> >
> > Is there a conclusion on this issue? I am voting for generic name :-)
> > "qcom,pm-qpnp".
>
> Josh and I have discussed this offline, and I think we have come to the
> conclusion that this should be a generic driver with only a generic
> binding. The current proposed name is "spmi-ext", as there is specific
> functional relation to Qualcomm, PMICs or QPNP.
>
> Further, the binding documentation should be specific to pm8[89]41 as
> 'mfd/pm8x41.txt', and should contain the compatibles:
> - "qcom,pm8941", "spmi-ext"
> - "qcom,pm8841", "spmi-ext"
>
> This naming has been discussed to death, so a few more shed color
> suggestions can't possibly hurt.
I am fine with this. Thanks.
>
> > Further complication is that several sub function drivers expect to
> > runtime detect the exact version of the controller ("qcom, qpnp-iadc",
> > "qcom, qpnp-vadc", "qcom, qpnp-linear-charger"). This is realized by the
> > exported function of the driver "qcom, qpnp-revid". Would it be good
> > idea to merge qpnp-revid and "qcom,pm-qpnp" driver?
>
> Each block within the PMICs have--undocumented--version registers, so a
> global version number is not particularly useful. A good example of
> this is the ADC code [1], as you mentioned.
Do you happen to know how to match local subdevices revisions to global
PMIC revision? Earlier mentioned drivers are using global chip revision.
I will not be surprised if local subdevice version is not changed, but
instead global version is changed, when only subdevice functionality is
changed ;-)
Regards,
Ivan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Intel-gfx] [3.14.0-rc4] regression: drm FIFO underruns
2014-05-09 19:03 GMT+02:00 Ville Syrjälä : > On Fri, May 09, 2014 at 05:14:38PM +0100, Damien Lespiau wrote: >> On Fri, May 09, 2014 at 06:11:37PM +0200, Jörg Otte wrote: >> > > Jörg, can you please boot with drm.debug=0xe, reproduce the issue and >> > > then attach the complete dmesg? Please make sure that the dmesg >> > > contains the boot-up stuff too. >> > > >> > > Thanks, Daniel >> > Here it is. I should mention it only happens at boot-up. >> >> [0.374095] [drm] Wrong MCH_SSKPD value: 0x20100406 >> [0.374096] [drm] This can cause pipe underruns and display issues. >> [0.374097] [drm] Please upgrade your BIOS to fix this. > > That can be a factor, but I think we may have some more general issue > in the modeset sequence which causes these to get reported. I'm getting > some on my machine as well where SSKPD looks more sane. Maybe we turn on > the error reporting too early or something. > > But I'm not going to spend time worrying about these before my previous > watermark stuff gets merged. Also the underrun reporting code itself > would need some kind of rewrite to be really useful. > > If the display doesn't blank out during use everything is more or less > fine and you can ignore these errors. It's quite likely that the > errors were always present and you didn't know it. We just made them > more prominent recently. > > -- > Ville Syrjälä > Intel OTC It comes out on the boot-up screen which is normally clean. So it becomes highly visible for anyone. Thanks, Jörg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-discuss] Reminder for kernel summit nominations
On 9 May 2014, at 18:31, j...@joshtriplett.org wrote: > On Fri, May 09, 2014 at 11:23:19AM -0400, Theodore Ts'o wrote: >> Also, if you have time to double check the e-mail addresses that we >> have, the Google Spreadsheet is here: >> >> http://goo.gl/FsVUFX > >> Peter P Waskiewicz Jr > > PJ left Intel and now works for SolidFire, so his @intel.com address > won't work anymore. I don't know his preferred new address. (Hopefully > he plans to switch to something company-independent now.) For Debian and StGit work he switched to pjwaskiew...@gmail.com. Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/2] i2c: sunxi: add P2WI (Push/Pull 2 Wire Interface) controller support
On 10/05/2014 03:16, Maxime Ripard wrote: > On Fri, May 09, 2014 at 06:56:10PM +0200, Boris BREZILLON wrote: >> The P2WI looks like an SMBus controller which only supports byte data >> transfers. But, it differs from standard SMBus protocol on several >> aspects: >> - it supports only one slave device, and thus drop the address field >> - it adds a parity bit every 8bits of data >> - only one read access is required to read a byte (instead of a read >> followed by a write access in standard SMBus protocol) >> - there's no Ack bit after each byte transfer >> >> This means this bus cannot be used to interface with standard SMBus >> devices (the only known device to support this interface is the AXP221 >> PMIC). >> >> Signed-off-by: Boris BREZILLON >> --- >> Changes since v2: >> - drop the initialization (switch from I2C to P2WI mode) part >> - print devm_ioremap_resource err code > You'll also need to update the documentation of the DT bindings. Crap, I forgot about that. I'll send a proper v4 updating the documentation and the code. > >> drivers/i2c/busses/Kconfig | 12 ++ >> drivers/i2c/busses/Makefile | 1 + >> drivers/i2c/busses/i2c-sun6i-p2wi.c | 352 >> >> 3 files changed, 365 insertions(+) >> create mode 100644 drivers/i2c/busses/i2c-sun6i-p2wi.c >> >> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig >> index c94db1c..09bce1c 100644 >> --- a/drivers/i2c/busses/Kconfig >> +++ b/drivers/i2c/busses/Kconfig >> @@ -771,6 +771,18 @@ config I2C_STU300 >>This driver can also be built as a module. If so, the module >>will be called i2c-stu300. >> >> +config I2C_SUN6I_P2WI >> +tristate "Allwinner sun6i internal P2WI controller" >> +depends on ARCH_SUNXI >> +help >> + If you say yes to this option, support will be included for the >> + P2WI (Push/Pull 2 Wire Interface) controller embedded in some sunxi >> + SOCs. >> + The P2WI looks like an SMBus controller (which supports only byte >> + accesses), except that it only supports one slave device. >> + This interface is used to connect to specific PMIC devices (like the >> + AXP221). >> + >> config I2C_TEGRA >> tristate "NVIDIA Tegra internal I2C controller" >> depends on ARCH_TEGRA >> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile >> index 18d18ff..58feeb9 100644 >> --- a/drivers/i2c/busses/Makefile >> +++ b/drivers/i2c/busses/Makefile >> @@ -75,6 +75,7 @@ obj-$(CONFIG_I2C_SIMTEC) += i2c-simtec.o >> obj-$(CONFIG_I2C_SIRF) += i2c-sirf.o >> obj-$(CONFIG_I2C_ST)+= i2c-st.o >> obj-$(CONFIG_I2C_STU300)+= i2c-stu300.o >> +obj-$(CONFIG_I2C_SUN6I_P2WI)+= i2c-sun6i-p2wi.o >> obj-$(CONFIG_I2C_TEGRA) += i2c-tegra.o >> obj-$(CONFIG_I2C_VERSATILE) += i2c-versatile.o >> obj-$(CONFIG_I2C_WMT) += i2c-wmt.o >> diff --git a/drivers/i2c/busses/i2c-sun6i-p2wi.c >> b/drivers/i2c/busses/i2c-sun6i-p2wi.c >> new file mode 100644 >> index 000..7c859ee >> --- /dev/null >> +++ b/drivers/i2c/busses/i2c-sun6i-p2wi.c >> @@ -0,0 +1,352 @@ >> +/* >> + * P2WI (Push-Pull Two Wire Interface) bus driver. >> + * >> + * Author: Boris BREZILLON >> + * >> + * This file is licensed under the terms of the GNU General Public License >> + * version 2. This program is licensed "as is" without any warranty of any >> + * kind, whether express or implied. >> + */ >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> + >> +/* P2WI registers */ >> +#define P2WI_CTRL 0x0 >> +#define P2WI_CCR0x4 >> +#define P2WI_INTE 0x8 >> +#define P2WI_INTS 0xc >> +#define P2WI_DADDR0 0x10 >> +#define P2WI_DADDR1 0x14 >> +#define P2WI_DLEN 0x18 >> +#define P2WI_DATA0 0x1c >> +#define P2WI_DATA1 0x20 >> +#define P2WI_LCR0x24 >> +#define P2WI_PMCR 0x28 >> + >> +/* CTRL fields */ >> +#define P2WI_CTRL_START_TRANS BIT(7) >> +#define P2WI_CTRL_ABORT_TRANS BIT(6) >> +#define P2WI_CTRL_GLOBAL_INT_ENBBIT(1) >> +#define P2WI_CTRL_SOFT_RST BIT(0) >> + >> +/* CLK CTRL fields */ >> +#define P2WI_CCR_SDA_OUT_DELAY(v) (((v) & 0x7) << 8) >> +#define P2WI_CCR_MAX_CLK_DIV0xff >> +#define P2WI_CCR_CLK_DIV(v) ((v) & P2WI_CCR_MAX_CLK_DIV) >> + >> +/* STATUS fields */ >> +#define P2WI_INTS_TRANS_ERR_ID(v) (((v) >> 8) & 0xff) >> +#define P2WI_INTS_LOAD_BSY BIT(2) >> +#define P2WI_INTS_TRANS_ERR BIT(1) >> +#define P2WI_INTS_TRANS_OVERBIT(0) >> + >> +/* DATA LENGTH fields*/ >> +#define P2WI_DLEN_READ BIT(4) >> +#define P2WI_DLEN_DATA_LENGTH(v)((v - 1) & 0x7) >> + >> +/* LINE CTRL field
Re: [PATCH 1/2] ARM: at91: add PWM pinctrl to SAMA5D3
Hi Nicolas,
On 09/05/2014 at 15:44:27 +0200, Nicolas Ferre wrote :
> Signed-off-by: Nicolas Ferre
> ---
> arch/arm/boot/dts/sama5d3.dtsi | 82
> ++
> 1 file changed, 82 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
> index 9caa06b3641e..ed7943745f23 100644
> --- a/arch/arm/boot/dts/sama5d3.dtsi
> +++ b/arch/arm/boot/dts/sama5d3.dtsi
> @@ -583,6 +583,88 @@
> };
> };
>
> + pwm0 {
> + pinctrl_pwm0_pwmh0_0: pwm0_pwmh0-0 {
> + atmel,pins =
> + AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PA20 periph B, conflicts with ISI_D4 and
> LCDDAT20 */
Didn't we decide at some point to stop adding comments for the pinctrl ?
At least, I would say that "PA20 periph B" doesn't add any useful
information.
> + };
> + pinctrl_pwm0_pwmh0_1: pwm0_pwmh0-1 {
> + atmel,pins =
> + AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PB0 periph B, conflicts with GTX0 */
> + };
> +
> + pinctrl_pwm0_pwmh1_0: pwm0_pwmh1-0 {
> + atmel,pins =
> + AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PA22 periph B, conflicts with ISI_D6 and
> LCDDAT22 */
> + };
> + pinctrl_pwm0_pwmh1_1: pwm0_pwmh1-1 {
> + atmel,pins =
> + AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PB4 periph B, conflicts with GRX0 */
> + };
> + pinctrl_pwm0_pwmh1_2: pwm0_pwmh1-2 {
> + atmel,pins =
> + AT91_PERIPH_C AT91_PINCTRL_NONE>; /* PB27 periph C, conflicts with G125CKO
> and RTS1 */
> + };
> +
> + pinctrl_pwm0_pwmh2_0: pwm0_pwmh2-0 {
> + atmel,pins =
> + AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PB8 periph B, conflicts with GTXCK */
> + };
> + pinctrl_pwm0_pwmh2_1: pwm0_pwmh2-1 {
> + atmel,pins =
> + AT91_PERIPH_C AT91_PINCTRL_NONE>; /* PD5 periph C, conflicts with MCI0_DA4
> and TIOA0 */
> + };
> +
> + pinctrl_pwm0_pwmh3_0: pwm0_pwmh3-0 {
> + atmel,pins =
> + AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PB12 periph B, conflicts with GRXDV */
> + };
> + pinctrl_pwm0_pwmh3_1: pwm0_pwmh3-1 {
> + atmel,pins =
> + AT91_PERIPH_C AT91_PINCTRL_NONE>; /* PD7 periph C, conflicts with MCI0_DA6
> and TCLK0 */
> + };
> +
> + pinctrl_pwm0_pwml0_0: pwm0_pwml0-0 {
> + atmel,pins =
> + AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PA21 periph B, conflicts with ISI_D5 and
> LCDDAT21 */
> + };
> + pinctrl_pwm0_pwml0_1: pwm0_pwml0-1 {
> + atmel,pins =
> + AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PB1 periph B, conflicts with GTX1 */
> + };
I would group pwm0_pwmhx and pwm0_pwmlx together.
> +
> + pinctrl_pwm0_pwml1_0: pwm0_pwml1-0 {
> + atmel,pins =
> + AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PA23 periph B, conflicts with ISI_D7 and
> LCDDAT23 */
> + };
> + pinctrl_pwm0_pwml1_1: pwm0_pwml1-1 {
> + atmel,pins =
> + AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PB5 periph B, conflicts with GRX1 */
> + };
> +
Re: [PATCH] staging: rtl8192u: initialize array in C compliant way
On Tue, May 6, 2014 at 1:47 AM, Dan Carpenter wrote:
>> diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
>> b/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
>> index 426f223..c96dbab 100644
>> --- a/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
>> +++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
>> @@ -241,7 +241,7 @@ static PTS_COMMON_INFO SearchAdmitTRStream(struct
>> ieee80211_device *ieee,
>> {
>> //DIRECTION_VALUE dir;
>> u8 dir;
>> - boolsearch_dir[4] = {0, 0, 0, 0};
>> + boolsearch_dir[4] = {0};
>
> That's weird. The original code is valid but it generates a sparse
> warning.
Sorry for the late reply. I see what is going on already. The bits_to_bytes()
function is buggy for bool type. Bool is the only type has bits less than 8.
It truncates the bool byte size to 0. As a result, the array layout function
convert_index() always set the expr->init_offset to 0 for bool type:
"e->init_offset = from * bits_to_bytes(e->ctype->bit_size);"
Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [REGRESSION] alsa PM regression in 3.15*, hda intel, realtek codec
At Sat, 10 May 2014 11:17:45 +0200, Knut Petersen wrote: > > S3 suspend / resume cycle works on kernels up to 3.14.x as expected. > With kernels 3.15.0-rc2 it's necessary to reload the alsa modules as sound > stays silent otherwise. > > Hardware: AOpen i915GMm-hfs mobo, hda intel sound with realtek codec. > > 00:1b.0 Audio device: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) > High Definition Audio Controller (rev 04) > Subsystem: AOPEN Inc. Device 0560 > Flags: bus master, fast devsel, latency 0, IRQ 46 > Memory at d544 (64-bit, non-prefetchable) [size=16K] > Capabilities: [50] Power Management version 2 > Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+ > Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00 > Capabilities: [100] Virtual Channel > Capabilities: [130] Root Complex Link > Kernel driver in use: snd_hda_intel > Kernel modules: snd_hda_intel > > Is this regression known or should I bisect? I don't know of any 3.15 bugs regarding HD-audio PM yet, so please bisect. thanks, Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/2] i2c: sunxi: add P2WI (Push/Pull 2 Wire Interface) controller support
The P2WI looks like an SMBus controller which only supports byte data
transfers. But, it differs from standard SMBus protocol on several
aspects:
- it supports only one slave device, and thus drop the address field
- it adds a parity bit every 8bits of data
- only one read access is required to read a byte (instead of a read
followed by a write access in standard SMBus protocol)
- there's no Ack bit after each byte transfer
This means this bus cannot be used to interface with standard SMBus
devices (the only known device to support this interface is the AXP221
PMIC).
Signed-off-by: Boris BREZILLON
---
drivers/i2c/busses/Kconfig | 12 ++
drivers/i2c/busses/Makefile | 1 +
drivers/i2c/busses/i2c-sun6i-p2wi.c | 349
3 files changed, 362 insertions(+)
create mode 100644 drivers/i2c/busses/i2c-sun6i-p2wi.c
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index c94db1c..09bce1c 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -771,6 +771,18 @@ config I2C_STU300
This driver can also be built as a module. If so, the module
will be called i2c-stu300.
+config I2C_SUN6I_P2WI
+ tristate "Allwinner sun6i internal P2WI controller"
+ depends on ARCH_SUNXI
+ help
+ If you say yes to this option, support will be included for the
+ P2WI (Push/Pull 2 Wire Interface) controller embedded in some sunxi
+ SOCs.
+ The P2WI looks like an SMBus controller (which supports only byte
+ accesses), except that it only supports one slave device.
+ This interface is used to connect to specific PMIC devices (like the
+ AXP221).
+
config I2C_TEGRA
tristate "NVIDIA Tegra internal I2C controller"
depends on ARCH_TEGRA
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 18d18ff..58feeb9 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -75,6 +75,7 @@ obj-$(CONFIG_I2C_SIMTEC) += i2c-simtec.o
obj-$(CONFIG_I2C_SIRF) += i2c-sirf.o
obj-$(CONFIG_I2C_ST) += i2c-st.o
obj-$(CONFIG_I2C_STU300) += i2c-stu300.o
+obj-$(CONFIG_I2C_SUN6I_P2WI) += i2c-sun6i-p2wi.o
obj-$(CONFIG_I2C_TEGRA)+= i2c-tegra.o
obj-$(CONFIG_I2C_VERSATILE)+= i2c-versatile.o
obj-$(CONFIG_I2C_WMT) += i2c-wmt.o
diff --git a/drivers/i2c/busses/i2c-sun6i-p2wi.c
b/drivers/i2c/busses/i2c-sun6i-p2wi.c
new file mode 100644
index 000..10f78d2
--- /dev/null
+++ b/drivers/i2c/busses/i2c-sun6i-p2wi.c
@@ -0,0 +1,349 @@
+/*
+ * P2WI (Push-Pull Two Wire Interface) bus driver.
+ *
+ * Author: Boris BREZILLON
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+/* P2WI registers */
+#define P2WI_CTRL 0x0
+#define P2WI_CCR 0x4
+#define P2WI_INTE 0x8
+#define P2WI_INTS 0xc
+#define P2WI_DADDR00x10
+#define P2WI_DADDR10x14
+#define P2WI_DLEN 0x18
+#define P2WI_DATA0 0x1c
+#define P2WI_DATA1 0x20
+#define P2WI_LCR 0x24
+#define P2WI_PMCR 0x28
+
+/* CTRL fields */
+#define P2WI_CTRL_START_TRANS BIT(7)
+#define P2WI_CTRL_ABORT_TRANS BIT(6)
+#define P2WI_CTRL_GLOBAL_INT_ENB BIT(1)
+#define P2WI_CTRL_SOFT_RST BIT(0)
+
+/* CLK CTRL fields */
+#define P2WI_CCR_SDA_OUT_DELAY(v) (((v) & 0x7) << 8)
+#define P2WI_CCR_MAX_CLK_DIV 0xff
+#define P2WI_CCR_CLK_DIV(v)((v) & P2WI_CCR_MAX_CLK_DIV)
+
+/* STATUS fields */
+#define P2WI_INTS_TRANS_ERR_ID(v) (((v) >> 8) & 0xff)
+#define P2WI_INTS_LOAD_BSY BIT(2)
+#define P2WI_INTS_TRANS_ERRBIT(1)
+#define P2WI_INTS_TRANS_OVER BIT(0)
+
+/* DATA LENGTH fields*/
+#define P2WI_DLEN_READ BIT(4)
+#define P2WI_DLEN_DATA_LENGTH(v) ((v - 1) & 0x7)
+
+/* LINE CTRL fields*/
+#define P2WI_LCR_SCL_STATE BIT(5)
+#define P2WI_LCR_SDA_STATE BIT(4)
+#define P2WI_LCR_SCL_CTL BIT(3)
+#define P2WI_LCR_SCL_CTL_ENBIT(2)
+#define P2WI_LCR_SDA_CTL BIT(1)
+#define P2WI_LCR_SDA_CTL_ENBIT(0)
+
+/* PMU MODE CTRL fields */
+#define P2WI_PMCR_PMU_INIT_SENDBIT(31)
+#define P2WI_PMCR_PMU_INIT_DATA(v) (((v) & 0xff) << 16)
+#define P2WI_PMCR_PMU_MODE_REG(v) (((v) & 0xff) << 8)
+#define P2WI_PMCR_PMU_DEV_ADDR(v) ((v) & 0xff)
+
+#define P2WI_MAX_FREQ 600
+
+struct p2wi {
+ struct i2c_adapter adapter;
+ struct completion complete;
+ unsigned int irq
[PATCH v4 0/2] i2c: sunxi: add P2WI controller support
Hello, This series adds support for the P2WI block used by some Allwinner boards to interface with the AXP221 PMIC. Best Regards, Boris Changes since v3: - update the DT bindings doc - fix a comment that was no longer true Changes since v2: - drop the initialization (switch from I2C to P2WI mode) part - print devm_ioremap_resource err code Changes since v1: - implement P2WI initilization - implement P2WI bus frequency configuration - implement address consistency check - fix devm_request_and_ioremap return check - rework the macro definitions - fix typos [1] http://www.spinics.net/lists/linux-i2c/msg15066.html [2] http://comments.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/8947 Boris BREZILLON (2): i2c: sunxi: add P2WI DT bindings documentation i2c: sunxi: add P2WI (Push/Pull 2 Wire Interface) controller support .../devicetree/bindings/i2c/i2c-sunxi-p2wi.txt | 41 +++ drivers/i2c/busses/Kconfig | 12 + drivers/i2c/busses/Makefile| 1 + drivers/i2c/busses/i2c-sun6i-p2wi.c| 349 + 4 files changed, 403 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/i2c-sunxi-p2wi.txt create mode 100644 drivers/i2c/busses/i2c-sun6i-p2wi.c -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 1/2] i2c: sunxi: add P2WI DT bindings documentation
P2WI (Push/Pull 2 Wire Interface) is an SMBus like bus used to communicate
with some PMICs (like the AXP221).
Document P2WI DT bindings which are pretty much the same as the one defined
for the marvell's mv64xxx controller.
Signed-off-by: Boris BREZILLON
---
.../devicetree/bindings/i2c/i2c-sunxi-p2wi.txt | 41 ++
1 file changed, 41 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-sunxi-p2wi.txt
diff --git a/Documentation/devicetree/bindings/i2c/i2c-sunxi-p2wi.txt
b/Documentation/devicetree/bindings/i2c/i2c-sunxi-p2wi.txt
new file mode 100644
index 000..6b76548
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-sunxi-p2wi.txt
@@ -0,0 +1,41 @@
+
+* Allwinner P2WI (Push/Pull 2 Wire Interface) controller
+
+Required properties :
+
+ - reg : Offset and length of the register set for the device.
+ - compatible : Should one of the following:
+ - "allwinner,sun6i-a31-p2wi"
+ - interrupts : The interrupt line connected to the P2WI peripheral.
+ - clocks : The gate clk connected to the P2WI peripheral.
+ - resets : The reset line connected to the P2WI peripheral.
+
+Optional properties :
+
+ - clock-frequency : Desired P2WI bus clock frequency in Hz. If not set the
+default frequency is 100kHz
+
+A P2WI may contain one child node encoding a P2WI slave device.
+
+Slave device properties:
+ Required properties:
+ - reg : the I2C slave address used during the initialization
+ process to switch from I2C to P2WI mode
+
+Example:
+
+ p2wi@01f03400 {
+ compatible = "allwinner,sun6i-a31-p2wi";
+ reg = <0x01f03400 0x400>;
+ interrupts = <0 39 4>;
+ clocks = <&apb0_gates 3>;
+ clock-frequency = <600>;
+ resets = <&apb0_rst 3>;
+
+ axp221: pmic@68 {
+ compatible = "x-powers,axp221";
+ reg = <0x68>;
+
+ /* ... */
+ };
+ };
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6] usb: host: ehci-tegra: Use devm_ioremap_resource instead of devm_ioremap
Using devm_ioremap_resource() API should actually be preferred over
devm_ioremap(), since the former request the mem region first and then
gives back the ioremap'ed memory pointer.
devm_ioremap_resource() calls request_mem_region(), therby preventing
other drivers to make any overlapping call to the same region.
Signed-off-by: Vivek Gautam
---
drivers/usb/host/ehci-tegra.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
index 572634c..ccc6433 100644
--- a/drivers/usb/host/ehci-tegra.c
+++ b/drivers/usb/host/ehci-tegra.c
@@ -411,9 +411,8 @@ static int tegra_ehci_probe(struct platform_device *pdev)
}
hcd->rsrc_start = res->start;
hcd->rsrc_len = resource_size(res);
- hcd->regs = devm_ioremap(&pdev->dev, res->start, resource_size(res));
+ hcd->regs = devm_ioremap_resource(&pdev->dev, res);
if (!hcd->regs) {
- dev_err(&pdev->dev, "Failed to remap I/O memory\n");
err = -ENOMEM;
goto cleanup_clk_en;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/6] usb: host: ohci-exynos: Use devm_ioremap_resource instead of devm_ioremap
Using devm_ioremap_resource() API should actually be preferred over
devm_ioremap(), since the former request the mem region first and then
gives back the ioremap'ed memory pointer.
devm_ioremap_resource() calls request_mem_region(), therby preventing
other drivers to make any overlapping call to the same region.
Signed-off-by: Vivek Gautam
---
drivers/usb/host/ohci-exynos.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 9cf80cb..aa64fb5 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -120,9 +120,8 @@ skip_phy:
hcd->rsrc_start = res->start;
hcd->rsrc_len = resource_size(res);
- hcd->regs = devm_ioremap(&pdev->dev, res->start, hcd->rsrc_len);
+ hcd->regs = devm_ioremap_resource(&pdev->dev, res);
if (!hcd->regs) {
- dev_err(&pdev->dev, "Failed to remap I/O memory\n");
err = -ENOMEM;
goto fail_io;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/6] usb: host: ehci-exynos: Use devm_ioremap_resource instead of devm_ioremap
Using devm_ioremap_resource() API should actually be preferred over
devm_ioremap(), since the former request the mem region first and then
gives back the ioremap'ed memory pointer.
devm_ioremap_resource() calls request_mem_region(), therby preventing
other drivers to make any overlapping call to the same region.
Signed-off-by: Vivek Gautam
---
drivers/usb/host/ehci-exynos.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 7f425ac..bccb6f1 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -135,9 +135,8 @@ skip_phy:
hcd->rsrc_start = res->start;
hcd->rsrc_len = resource_size(res);
- hcd->regs = devm_ioremap(&pdev->dev, res->start, hcd->rsrc_len);
+ hcd->regs = devm_ioremap_resource(&pdev->dev, res);
if (!hcd->regs) {
- dev_err(&pdev->dev, "Failed to remap I/O memory\n");
err = -ENOMEM;
goto fail_io;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/6] usb: host: Cleanup for ioremap'ing hcd memory
Based on 'usb-next' branch of Greg's usb tree. devm_ioremap_resource() API is advantageous over devm_ioremap() and should therefore be preferred to request any ioremap'ed address for hcd. Vivek Gautam (6): usb: host: ehci-exynos: Use devm_ioremap_resource instead of devm_ioremap usb: host: ehci-msm: Use devm_ioremap_resource instead of devm_ioremap usb: host: ehci-mv: Use devm_ioremap_resource instead of devm_ioremap usb: host: ehci-spear: Use devm_ioremap_resource instead of devm_ioremap usb: host: ehci-tegra: Use devm_ioremap_resource instead of devm_ioremap usb: host: ohci-exynos: Use devm_ioremap_resource instead of devm_ioremap drivers/usb/host/ehci-exynos.c |3 +-- drivers/usb/host/ehci-msm.c|3 +-- drivers/usb/host/ehci-mv.c |8 ++-- drivers/usb/host/ehci-spear.c |9 + drivers/usb/host/ehci-tegra.c |3 +-- drivers/usb/host/ohci-exynos.c |3 +-- 6 files changed, 7 insertions(+), 22 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/6] usb: host: ehci-spear: Use devm_ioremap_resource instead of devm_ioremap
Using devm_ioremap_resource() API should actually be preferred over
devm_ioremap(), since the former request the mem region first and then
gives back the ioremap'ed memory pointer.
devm_ioremap_resource() calls request_mem_region(), therby preventing
other drivers to make any overlapping call to the same region.
Signed-off-by: Vivek Gautam
---
drivers/usb/host/ehci-spear.c |9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/usb/host/ehci-spear.c b/drivers/usb/host/ehci-spear.c
index 8bd915b..6d84cf2 100644
--- a/drivers/usb/host/ehci-spear.c
+++ b/drivers/usb/host/ehci-spear.c
@@ -106,15 +106,8 @@ static int spear_ehci_hcd_drv_probe(struct platform_device
*pdev)
hcd->rsrc_start = res->start;
hcd->rsrc_len = resource_size(res);
- if (!devm_request_mem_region(&pdev->dev, hcd->rsrc_start, hcd->rsrc_len,
- driver->description)) {
- retval = -EBUSY;
- goto err_put_hcd;
- }
-
- hcd->regs = devm_ioremap(&pdev->dev, hcd->rsrc_start, hcd->rsrc_len);
+ hcd->regs = devm_ioremap_resource(&pdev->dev, res);
if (hcd->regs == NULL) {
- dev_dbg(&pdev->dev, "error mapping memory\n");
retval = -ENOMEM;
goto err_put_hcd;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/6] usb: host: ehci-mv: Use devm_ioremap_resource instead of devm_ioremap
Using devm_ioremap_resource() API should actually be preferred over
devm_ioremap(), since the former request the mem region first and then
gives back the ioremap'ed memory pointer.
devm_ioremap_resource() calls request_mem_region(), therby preventing
other drivers to make any overlapping call to the same region.
Signed-off-by: Vivek Gautam
---
drivers/usb/host/ehci-mv.c |8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/host/ehci-mv.c b/drivers/usb/host/ehci-mv.c
index bd61612..5d03787 100644
--- a/drivers/usb/host/ehci-mv.c
+++ b/drivers/usb/host/ehci-mv.c
@@ -176,10 +176,8 @@ static int mv_ehci_probe(struct platform_device *pdev)
goto err_put_hcd;
}
- ehci_mv->phy_regs = devm_ioremap(&pdev->dev, r->start,
-resource_size(r));
+ ehci_mv->phy_regs = devm_ioremap_resource(&pdev->dev, r);
if (!ehci_mv->phy_regs) {
- dev_err(&pdev->dev, "failed to map phy I/O memory\n");
retval = -EFAULT;
goto err_put_hcd;
}
@@ -191,10 +189,8 @@ static int mv_ehci_probe(struct platform_device *pdev)
goto err_put_hcd;
}
- ehci_mv->cap_regs = devm_ioremap(&pdev->dev, r->start,
-resource_size(r));
+ ehci_mv->cap_regs = devm_ioremap_resource(&pdev->dev, r);
if (ehci_mv->cap_regs == NULL) {
- dev_err(&pdev->dev, "failed to map I/O memory\n");
retval = -EFAULT;
goto err_put_hcd;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/6] usb: host: ehci-msm: Use devm_ioremap_resource instead of devm_ioremap
Using devm_ioremap_resource() API should actually be preferred over
devm_ioremap(), since the former request the mem region first and then
gives back the ioremap'ed memory pointer.
devm_ioremap_resource() calls request_mem_region(), therby preventing
other drivers to make any overlapping call to the same region.
Signed-off-by: Vivek Gautam
---
drivers/usb/host/ehci-msm.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/host/ehci-msm.c b/drivers/usb/host/ehci-msm.c
index f341651..99989aa 100644
--- a/drivers/usb/host/ehci-msm.c
+++ b/drivers/usb/host/ehci-msm.c
@@ -96,9 +96,8 @@ static int ehci_msm_probe(struct platform_device *pdev)
hcd->rsrc_start = res->start;
hcd->rsrc_len = resource_size(res);
- hcd->regs = devm_ioremap(&pdev->dev, hcd->rsrc_start, hcd->rsrc_len);
+ hcd->regs = devm_ioremap_resource(&pdev->dev, res);
if (!hcd->regs) {
- dev_err(&pdev->dev, "ioremap failed\n");
ret = -ENOMEM;
goto put_hcd;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/6] ipc/sem.c: further whitespace cleanups
Somehow $ was overlooked in the last round of whitespace
cleanups.
Do that now, before making further changes.
Signed-off-by: Manfred Spraul
---
ipc/sem.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/ipc/sem.c b/ipc/sem.c
index bee5554..5749b9c 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -160,7 +160,7 @@ static int sysvipc_sem_proc_show(struct seq_file *s, void
*it);
* sem_array.pending{_alter,_cont},
* sem_array.sem_undo: global sem_lock() for read/write
* sem_undo.proc_next: only "current" is allowed to read/write that field.
- *
+ *
* sem_array.sem_base[i].pending_{const,alter}:
* global or semaphore sem_lock() for read/write
*/
@@ -1161,7 +1161,7 @@ static int semctl_nolock(struct ipc_namespace *ns, int
semid,
err = security_sem_semctl(NULL, cmd);
if (err)
return err;
-
+
memset(&seminfo, 0, sizeof(seminfo));
seminfo.semmni = ns->sc_semmni;
seminfo.semmns = ns->sc_semmns;
@@ -1883,7 +1883,7 @@ SYSCALL_DEFINE4(semtimedop, int, semid, struct sembuf
__user *, tsops,
/* We need to sleep on this operation, so we put the current
* task into the pending queue and go to sleep.
*/
-
+
queue.sops = sops;
queue.nsops = nsops;
queue.undo = un;
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/6] ipc/sem.c: make semctl(,,{GETNCNT,GETZCNT}) standard compliant
Per definition, a task waits on exactly one semaphore:
The semaphore from the first operation in the sop array that cannot proceed.
The Linux implementation never followed the standard, it tried to count all
semaphores that might be the reason why a task sleeps.
This patch fixes that.
Note:
The implementation assumes that GETNCNT and GETZCNT are rare operations,
therefore the code counts them only on demand.
(If they wouldn't be rare, then the non-compliance would have
been found earlier)
Signed-off-by: Manfred Spraul
---
ipc/sem.c | 37 -
1 file changed, 16 insertions(+), 21 deletions(-)
diff --git a/ipc/sem.c b/ipc/sem.c
index 22a4c12..5e8bcde 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -993,38 +993,33 @@ static void do_smart_update(struct sem_array *sma, struct
sembuf *sops, int nsop
}
/*
- * check_qop: Test how often a queued operation sleeps on the semaphore semnum
+ * check_qop: Test if a queued operation sleeps on the semaphore semnum
*/
static int check_qop(struct sem_array *sma, int semnum, struct sem_queue *q,
bool count_zero)
{
- struct sembuf *sops = q->sops;
- int nsops = q->nsops;
- int i, semcnt;
+ struct sembuf *sop = q->blocking;
- semcnt = 0;
+ BUG_ON(sop->sem_flg & IPC_NOWAIT);
+ BUG_ON(sop->sem_op > 0);
- for (i = 0; i < nsops; i++) {
- if (sops[i].sem_num != semnum)
- continue;
- if (sops[i].sem_flg & IPC_NOWAIT)
- continue;
- if (count_zero && sops[i].sem_op == 0)
- semcnt++;
- if (!count_zero && sops[i].sem_op < 0)
- semcnt++;
- }
- return semcnt;
+ if (sop->sem_num != semnum)
+ return 0;
+
+ if (count_zero && sop->sem_op == 0)
+ return 1;
+ if (!count_zero && sop->sem_op < 0)
+ return 1;
+
+ return 0;
}
/* The following counts are associated to each semaphore:
* semncntnumber of tasks waiting on semval being nonzero
* semzcntnumber of tasks waiting on semval being zero
- * This model assumes that a task waits on exactly one semaphore.
- * Since semaphore operations are to be performed atomically, tasks actually
- * wait on a whole sequence of semaphores simultaneously.
- * The counts we return here are a rough approximation, but still
- * warrant that semncnt+semzcnt>0 if the task is on the pending queue.
+ *
+ * Per definition, a task waits only on the semaphore of the first semop
+ * that cannot proceed, even if additional operation would block, too.
*/
static int count_semcnt(struct sem_array *sma, ushort semnum,
bool count_zero)
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/6] ipc/sem.c: Change perform_atomic_semop parameters
Right now, perform_atomic_semop gets the content of sem_queue as individual
fields.
Changes that, instead pass a pointer to sem_queue.
This is a preparation for the next patch: it uses
sem_queue to store the reason why a task must sleep.
Signed-off-by: Manfred Spraul
---
ipc/sem.c | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/ipc/sem.c b/ipc/sem.c
index 821aba7..3962cca 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -585,21 +585,23 @@ SYSCALL_DEFINE3(semget, key_t, key, int, nsems, int,
semflg)
/**
* perform_atomic_semop - Perform (if possible) a semaphore operation
* @sma: semaphore array
- * @sops: array with operations that should be checked
- * @nsops: number of operations
- * @un: undo array
- * @pid: pid that did the change
+ * @q: struct sem_queue that describes the operation
*
* Returns 0 if the operation was possible.
* Returns 1 if the operation is impossible, the caller must sleep.
* Negative values are error codes.
*/
-static int perform_atomic_semop(struct sem_array *sma, struct sembuf *sops,
-int nsops, struct sem_undo *un, int pid)
+static int perform_atomic_semop(struct sem_array *sma, struct sem_queue *q)
{
- int result, sem_op;
+ int result, sem_op, nsops, pid;
struct sembuf *sop;
struct sem *curr;
+ struct sembuf *sops;
+ struct sem_undo *un;
+
+ sops = q->sops;
+ nsops = q->nsops;
+ un = q->undo;
for (sop = sops; sop < sops + nsops; sop++) {
curr = sma->sem_base + sop->sem_num;
@@ -627,6 +629,7 @@ static int perform_atomic_semop(struct sem_array *sma,
struct sembuf *sops,
}
sop--;
+ pid = q->pid;
while (sop >= sops) {
sma->sem_base[sop->sem_num].sempid = pid;
sop--;
@@ -779,8 +782,7 @@ static int wake_const_ops(struct sem_array *sma, int semnum,
q = container_of(walk, struct sem_queue, list);
walk = walk->next;
- error = perform_atomic_semop(sma, q->sops, q->nsops,
-q->undo, q->pid);
+ error = perform_atomic_semop(sma, q);
if (error <= 0) {
/* operation completed, remove from queue & wakeup */
@@ -892,8 +894,7 @@ again:
if (semnum != -1 && sma->sem_base[semnum].semval == 0)
break;
- error = perform_atomic_semop(sma, q->sops, q->nsops,
-q->undo, q->pid);
+ error = perform_atomic_semop(sma, q);
/* Does q->sleeper still need to sleep? */
if (error > 0)
@@ -1873,8 +1874,13 @@ SYSCALL_DEFINE4(semtimedop, int, semid, struct sembuf
__user *, tsops,
if (un && un->semid == -1)
goto out_unlock_free;
- error = perform_atomic_semop(sma, sops, nsops, un,
- task_tgid_vnr(current));
+ queue.sops = sops;
+ queue.nsops = nsops;
+ queue.undo = un;
+ queue.pid = task_tgid_vnr(current);
+ queue.alter = alter;
+
+ error = perform_atomic_semop(sma, &queue);
if (error == 0) {
/* If the operation was successful, then do
* the required updates.
@@ -1891,12 +1897,6 @@ SYSCALL_DEFINE4(semtimedop, int, semid, struct sembuf
__user *, tsops,
* task into the pending queue and go to sleep.
*/
- queue.sops = sops;
- queue.nsops = nsops;
- queue.undo = un;
- queue.pid = task_tgid_vnr(current);
- queue.alter = alter;
-
if (nsops == 1) {
struct sem *curr;
curr = &sma->sem_base[sops->sem_num];
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6] ipc/sem.c: Store which operation blocks in perform_atomic_semop()
Preparation for the next patch:
In the slow-path of perform_atomic_semop(), store a pointer to the operation
that caused the operation to block.
Signed-off-by: Manfred Spraul
---
ipc/sem.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/ipc/sem.c b/ipc/sem.c
index 3962cca..22a4c12 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -109,6 +109,7 @@ struct sem_queue {
int pid; /* process id of requesting process */
int status; /* completion status of operation */
struct sembuf *sops; /* array of pending operations */
+ struct sembuf *blocking; /* the operation that blocked */
int nsops; /* number of operations */
int alter; /* does *sops alter the array? */
};
@@ -642,6 +643,8 @@ out_of_range:
goto undo;
would_block:
+ q->blocking = sop;
+
if (sop->sem_flg & IPC_NOWAIT)
result = -EAGAIN;
else
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/6] ipc/sem.c: Fix semctl(,,{GETNCNT,GETZCNT})
Hi all, According to the man page of semop(), semzcnt or semncnt are increased exactly for the operation that couldn't proceed. The Linux implementation always tried to be clever and to increase the counters for all operations that might be the reason why a task sleeps. The following patches fix that and make the code conform to the documentation. The series got fairly long, because I also noticed that semzcnt was calculated incorrectly. What do you think? I ran a few test cases, and the semncnt and semzcnt counts now match the expectation. Is anyone aware of an application that uses GETNCNT or GETZCNT? -- Manfred -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/6] ipc/sem.c: remove code duplication
count_semzcnt and count_semncnt are more of less identical.
The patch creates a single function that either counts the number of tasks
waiting for zero or waiting due to a decrease operation.
Signed-off-by: Manfred Spraul
---
ipc/sem.c | 103 ++
1 file changed, 50 insertions(+), 53 deletions(-)
diff --git a/ipc/sem.c b/ipc/sem.c
index dc648f8..821aba7 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -47,8 +47,7 @@
* Thus: Perfect SMP scaling between independent semaphore arrays.
* If multiple semaphores in one array are used, then cache line
* trashing on the semaphore array spinlock will limit the scaling.
- * - semncnt and semzcnt are calculated on demand in count_semncnt() and
- * count_semzcnt()
+ * - semncnt and semzcnt are calculated on demand in count_semcnt()
* - the task that performs a successful semop() scans the list of all
* sleeping tasks and completes any pending operations that can be fulfilled.
* Semaphores are actively given to waiting tasks (necessary for FIFO).
@@ -989,6 +988,31 @@ static void do_smart_update(struct sem_array *sma, struct
sembuf *sops, int nsop
set_semotime(sma, sops);
}
+/*
+ * check_qop: Test how often a queued operation sleeps on the semaphore semnum
+ */
+static int check_qop(struct sem_array *sma, int semnum, struct sem_queue *q,
+ bool count_zero)
+{
+ struct sembuf *sops = q->sops;
+ int nsops = q->nsops;
+ int i, semcnt;
+
+ semcnt = 0;
+
+ for (i = 0; i < nsops; i++) {
+ if (sops[i].sem_num != semnum)
+ continue;
+ if (sops[i].sem_flg & IPC_NOWAIT)
+ continue;
+ if (count_zero && sops[i].sem_op == 0)
+ semcnt++;
+ if (!count_zero && sops[i].sem_op < 0)
+ semcnt++;
+ }
+ return semcnt;
+}
+
/* The following counts are associated to each semaphore:
* semncntnumber of tasks waiting on semval being nonzero
* semzcntnumber of tasks waiting on semval being zero
@@ -998,66 +1022,39 @@ static void do_smart_update(struct sem_array *sma,
struct sembuf *sops, int nsop
* The counts we return here are a rough approximation, but still
* warrant that semncnt+semzcnt>0 if the task is on the pending queue.
*/
-static int count_semncnt(struct sem_array *sma, ushort semnum)
+static int count_semcnt(struct sem_array *sma, ushort semnum,
+ bool count_zero)
{
- int semncnt;
+ struct list_head *l;
struct sem_queue *q;
+ int semcnt;
- semncnt = 0;
- list_for_each_entry(q, &sma->sem_base[semnum].pending_alter, list) {
- struct sembuf *sops = q->sops;
- BUG_ON(sops->sem_num != semnum);
- if ((sops->sem_op < 0) && !(sops->sem_flg & IPC_NOWAIT))
- semncnt++;
- }
+ semcnt = 0;
+ /* First: check the simple operations. They are easy to evaluate */
+ if (count_zero)
+ l = &sma->sem_base[semnum].pending_const;
+ else
+ l = &sma->sem_base[semnum].pending_alter;
- list_for_each_entry(q, &sma->pending_alter, list) {
+ list_for_each_entry(q, l, list) {
struct sembuf *sops = q->sops;
- int nsops = q->nsops;
- int i;
- for (i = 0; i < nsops; i++)
- if (sops[i].sem_num == semnum
- && (sops[i].sem_op < 0)
- && !(sops[i].sem_flg & IPC_NOWAIT))
- semncnt++;
- }
- return semncnt;
-}
-static int count_semzcnt(struct sem_array *sma, ushort semnum)
-{
- int semzcnt;
- struct sem_queue *q;
-
- semzcnt = 0;
- list_for_each_entry(q, &sma->sem_base[semnum].pending_const, list) {
- struct sembuf *sops = q->sops;
BUG_ON(sops->sem_num != semnum);
- if ((sops->sem_op == 0) && !(sops->sem_flg & IPC_NOWAIT))
- semzcnt++;
+ BUG_ON(sops->sem_flg & IPC_NOWAIT);
+ BUG_ON(sops->sem_op > 0);
+ semcnt++;
}
- list_for_each_entry(q, &sma->pending_const, list) {
- struct sembuf *sops = q->sops;
- int nsops = q->nsops;
- int i;
- for (i = 0; i < nsops; i++)
- if (sops[i].sem_num == semnum
- && (sops[i].sem_op == 0)
- && !(sops[i].sem_flg & IPC_NOWAIT))
- semzcnt++;
- }
+ /* Then: check the complex operations. */
list_for_each_entry(q, &sma->pending_alter, list) {
- struct sembuf *sops = q->sops;
- int nsops = q->nsops;
- int i;
- for (i
[PATCH 2/6] ipc/sem.c: Bugfix for semctl(,,GETZCNT)
GETZCNT is supposed to return the number of threads that wait until
a semaphore value becomes 0.
The current implementation overlooks complex operations that contain
both wait-for-zero operation and operations that alter at least one semaphore.
The patch fixes that.
It's intentionally copy&paste, this will be cleaned up in the next patch.
Signed-off-by: Manfred Spraul
---
ipc/sem.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/ipc/sem.c b/ipc/sem.c
index 5749b9c..dc648f8 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -1047,6 +1047,16 @@ static int count_semzcnt(struct sem_array *sma, ushort
semnum)
&& !(sops[i].sem_flg & IPC_NOWAIT))
semzcnt++;
}
+ list_for_each_entry(q, &sma->pending_alter, list) {
+ struct sembuf *sops = q->sops;
+ int nsops = q->nsops;
+ int i;
+ for (i = 0; i < nsops; i++)
+ if (sops[i].sem_num == semnum
+ && (sops[i].sem_op == 0)
+ && !(sops[i].sem_flg & IPC_NOWAIT))
+ semzcnt++;
+ }
return semzcnt;
}
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] usb: host: ehci-exynos: Use devm_ioremap_resource instead of devm_ioremap
Sat, 10 May 2014 15:26:58 +0530 от Vivek Gautam :
> Using devm_ioremap_resource() API should actually be preferred over
> devm_ioremap(), since the former request the mem region first and then
> gives back the ioremap'ed memory pointer.
> devm_ioremap_resource() calls request_mem_region(), therby preventing
> other drivers to make any overlapping call to the same region.
>
> Signed-off-by: Vivek Gautam
> ---
> drivers/usb/host/ehci-exynos.c |3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
> index 7f425ac..bccb6f1 100644
> --- a/drivers/usb/host/ehci-exynos.c
> +++ b/drivers/usb/host/ehci-exynos.c
> @@ -135,9 +135,8 @@ skip_phy:
>
> hcd->rsrc_start = res->start;
> hcd->rsrc_len = resource_size(res);
> - hcd->regs = devm_ioremap(&pdev->dev, res->start, hcd->rsrc_len);
> + hcd->regs = devm_ioremap_resource(&pdev->dev, res);
> if (!hcd->regs) {
> - dev_err(&pdev->dev, "Failed to remap I/O memory\n");
> err = -ENOMEM;
> goto fail_io;
> }
You should check this as:
if (IS_ERR(hcd->regs)) {
err = PTR_ERR(hcd->regs);
...
Same in other patches in this series.
---
Re: [PATCH 1/1] KERNEL: add __attribute__ in c file
On Wed, 7 May 2014 15:25:57 -0700
Andrew Morton wrote:
> On Wed, 7 May 2014 22:33:39 +0200 Fabian Frederick wrote:
>
> > This patch fixes a sparse warning about noreturn attribute only
> > featuring in module.h
> >
> > kernel/module.c:212:6: error: symbol '__module_put_and_exit' redeclared with
> > different type (originally declared at include/linux/module.h:449)-
> > different modifiers
> >
> > ...
> >
> > --- a/include/linux/module.h
> > +++ b/include/linux/module.h
> > @@ -446,8 +446,8 @@ int module_kallsyms_on_each_symbol(int (*fn)(void *,
> > const char *,
> > struct module *, unsigned long),
> >void *data);
> >
> > -extern void __module_put_and_exit(struct module *mod, long code)
> > - __attribute__((noreturn));
> > +extern void __attribute__((noreturn)) __module_put_and_exit(struct module
> > *mod,
> > + long code);
> > #define module_put_and_exit(code) __module_put_and_exit(THIS_MODULE, code)
> >
> > #ifdef CONFIG_MODULE_UNLOAD
> > diff --git a/kernel/module.c b/kernel/module.c
> > index 079c461..7d78872 100644
> > --- a/kernel/module.c
> > +++ b/kernel/module.c
> > @@ -209,7 +209,8 @@ static inline void add_taint_module(struct module *mod,
> > unsigned flag,
> > * A thread that wants to hold a reference to a module only while it
> > * is running can call this to safely exit. nfsd and lockd use this.
> > */
> > -void __module_put_and_exit(struct module *mod, long code)
> > +void __attribute__((noreturn)) __module_put_and_exit(struct module *mod,
> > +long code)
> > {
>
> Can we use __noreturn here?
Well it works(compilation/no more sparse warning) but after looking at some
documentation, it looks more like some sparse false positive.
Fabian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] iio: add support of the max1027
On 10/05/14 01:43, Hartmut Knaack wrote:
Philippe Reynes schrieb:
This driver add partial support of the
maxim 1027/1029/1031. Differential mode is not
supported.
It was tested on armadeus apf27 board.
Signed-off-by: Philippe Reynes
I've added a few additional comments to Hartmut's thorough review.
Mostly cases where the driver could be simplified a bit.
Nice to see these spi parts finally getting support (I have one
in a box somewhere I was meaning to solder up a good 4 years
ago ;(
---
.../devicetree/bindings/iio/adc/max1027-adc.txt| 19 +
drivers/staging/iio/adc/Kconfig| 10 +
drivers/staging/iio/adc/Makefile |1 +
drivers/staging/iio/adc/max1027.c | 647
4 files changed, 677 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/iio/adc/max1027-adc.txt
create mode 100644 drivers/staging/iio/adc/max1027.c
diff --git a/Documentation/devicetree/bindings/iio/adc/max1027-adc.txt
b/Documentation/devicetree/bindings/iio/adc/max1027-adc.txt
new file mode 100644
index 000..8daafe4
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/max1027-adc.txt
@@ -0,0 +1,19 @@
+* Maxim 1027/1029/1031 Analog to Digital Converter (ADC)
+
+Required properties:
+ - compatible: Should be "maxim,max1027" or "maxim,max1029" or "maxim,max1031"
+ - reg: Should contain the ADC SPI address
+ - gpios: gpio for end of conversion
+
+Example:
+adc@0 {
+ compatible = "maxim,max1027";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_max1027>;
+ /* SPI mode = 0 */
+ spi-cpol = <0>;
+ spi-cpha = <0>;
+ spi-max-frequency = <100>;
+ reg = <0>;
+ gpios = <&gpio5 15 0>;
+};
diff --git a/drivers/staging/iio/adc/Kconfig b/drivers/staging/iio/adc/Kconfig
index 3633298..472504b 100644
--- a/drivers/staging/iio/adc/Kconfig
+++ b/drivers/staging/iio/adc/Kconfig
@@ -112,6 +112,16 @@ config LPC32XX_ADC
activate only one via device tree selection. Provides direct access
via sysfs.
+config MAX1027
+ tristate "Maxim max1027 ADC driver"
+ depends on SPI
+ select IIO_BUFFER
+ select IIO_TRIGGERED_BUFFER
+ help
+ Say yes here to build support for many Maxim spi analog to digital
+ converters (ADC). (max1027, max1029, max2031) Provides
Something went wrong here with the models in parenthesis. Also, we are in the ADC
submenu, so whoever gets to this point should know what ADC stands for. Maybe better
write something like "... build support for Maxim SPI ADC models max1027, max1029
and max1031."
+ direct access via sysfs and buffered data via the iio dev interface.
+
config MXS_LRADC
tristate "Freescale i.MX23/i.MX28 LRADC"
depends on ARCH_MXS || COMPILE_TEST
diff --git a/drivers/staging/iio/adc/Makefile b/drivers/staging/iio/adc/Makefile
index 3e9fb14..22fbd0c 100644
--- a/drivers/staging/iio/adc/Makefile
+++ b/drivers/staging/iio/adc/Makefile
@@ -18,5 +18,6 @@ obj-$(CONFIG_AD7816) += ad7816.o
obj-$(CONFIG_AD7192) += ad7192.o
obj-$(CONFIG_AD7280) += ad7280a.o
obj-$(CONFIG_LPC32XX_ADC) += lpc32xx_adc.o
+obj-$(CONFIG_MAX1027) += max1027.o
obj-$(CONFIG_MXS_LRADC) += mxs-lradc.o
obj-$(CONFIG_SPEAR_ADC) += spear_adc.o
diff --git a/drivers/staging/iio/adc/max1027.c
b/drivers/staging/iio/adc/max1027.c
new file mode 100644
index 000..a50978f
--- /dev/null
+++ b/drivers/staging/iio/adc/max1027.c
@@ -0,0 +1,647 @@
+ /*
+ * iio/adc/max1027.c
+ * Copyright (C) 2014 Philippe Reynes
+ *
+ * based on linux/drivers/iio/ad7923.c
+ * Copyright 2011 Analog Devices Inc (from AD7923 Driver)
+ * Copyright 2012 CS Systemes d'Information
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * max1027.c
+ *
+ * Partial support for max1027 and similar chips.
+ *
+ */
Better remove the blank comment line and add a blank line after the comment
block.
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+enum max1027_id {
+ max1027,
+ max1029,
+ max1031,
+};
+
You could be brave and take a look at the other similar Maxim devices.
For example based on a really quick look, the max1026, max1028 and max1030 are
very nearly the same, but just running on 3V rather than 5V.
There are also max12xx parts that are probably much the same but 12bit.
(I'm being lazy today and haven't actually compared datasheets - going
on the basis of maxims usual part numbering.
If there spi parts are anything like their i2c ones there will be dozens
of very similar parts!
+static const struct spi_device_id max1027_id[] = {
+ {"max1027", max1027},
+ {"max1029", max1029},
+ {"max
[PATCH V2 RESEND] ARCH/M68K/AMIGA: convert printk(foo to pr_foo()
-no level printk converted to pr_warn/pr_info
-fixed a small identation problem
This is untested
Cc: Geert Uytterhoeven
Cc: Andrew Morton
Signed-off-by: Fabian Frederick
---
v2: use pr_cont after pr_ without newline (suggested by Geert Uytterhoeven)
arch/m68k/amiga/amisound.c | 2 +-
arch/m68k/amiga/config.c | 20 ++--
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/m68k/amiga/amisound.c b/arch/m68k/amiga/amisound.c
index 2559eef..90a60d7 100644
--- a/arch/m68k/amiga/amisound.c
+++ b/arch/m68k/amiga/amisound.c
@@ -51,7 +51,7 @@ void __init amiga_init_sound(void)
snd_data = amiga_chip_alloc_res(sizeof(sine_data), &beep_res);
if (!snd_data) {
- printk (KERN_CRIT "amiga init_sound: failed to allocate
chipmem\n");
+ pr_crit("amiga init_sound: failed to allocate chipmem\n");
return;
}
memcpy (snd_data, sine_data, sizeof(sine_data));
diff --git a/arch/m68k/amiga/config.c b/arch/m68k/amiga/config.c
index 9625b71..01693df 100644
--- a/arch/m68k/amiga/config.c
+++ b/arch/m68k/amiga/config.c
@@ -183,7 +183,7 @@ int __init amiga_parse_bootinfo(const struct bi_record
*record)
dev->boardaddr = be32_to_cpu(cd->cd_BoardAddr);
dev->boardsize = be32_to_cpu(cd->cd_BoardSize);
} else
- printk("amiga_parse_bootinfo: too many AutoConfig
devices\n");
+ pr_warn("amiga_parse_bootinfo: too many AutoConfig
devices\n");
#endif /* CONFIG_ZORRO */
break;
@@ -209,9 +209,9 @@ static void __init amiga_identify(void)
memset(&amiga_hw_present, 0, sizeof(amiga_hw_present));
- printk("Amiga hardware found: ");
+ pr_info("Amiga hardware found: ");
if (amiga_model >= AMI_500 && amiga_model <= AMI_DRACO) {
- printk("[%s] ", amiga_models[amiga_model-AMI_500]);
+ pr_cont("[%s] ", amiga_models[amiga_model-AMI_500]);
strcat(amiga_model_name, amiga_models[amiga_model-AMI_500]);
}
@@ -322,7 +322,7 @@ static void __init amiga_identify(void)
#define AMIGAHW_ANNOUNCE(name, str)\
if (AMIGAHW_PRESENT(name)) \
- printk(str)
+ pr_cont(str)
AMIGAHW_ANNOUNCE(AMI_VIDEO, "VIDEO ");
AMIGAHW_ANNOUNCE(AMI_BLITTER, "BLITTER ");
@@ -354,8 +354,8 @@ static void __init amiga_identify(void)
AMIGAHW_ANNOUNCE(MAGIC_REKICK, "MAGIC_REKICK ");
AMIGAHW_ANNOUNCE(PCMCIA, "PCMCIA ");
if (AMIGAHW_PRESENT(ZORRO))
- printk("ZORRO%s ", AMIGAHW_PRESENT(ZORRO3) ? "3" : "");
- printk("\n");
+ pr_cont("ZORRO%s ", AMIGAHW_PRESENT(ZORRO3) ? "3" : "");
+ pr_cont("\n");
#undef AMIGAHW_ANNOUNCE
}
@@ -424,7 +424,7 @@ void __init config_amiga(void)
if (m68k_memory[i].addr < 16*1024*1024) {
if (i == 0) {
/* don't cut off the branch we're
sitting on */
- printk("Warning: kernel runs in Zorro
II memory\n");
+ pr_warn("Warning: kernel runs in Zorro
II memory\n");
continue;
}
disabled_z2mem += m68k_memory[i].size;
@@ -435,8 +435,8 @@ void __init config_amiga(void)
}
}
if (disabled_z2mem)
- printk("%dK of Zorro II memory will not be used as system
memory\n",
- disabled_z2mem>>10);
+ pr_info("%dK of Zorro II memory will not be used as
system memory\n",
+ disabled_z2mem>>10);
}
/* request all RAM */
@@ -475,7 +475,7 @@ static void __init amiga_sched_init(irq_handler_t
timer_routine)
jiffy_ticks = DIV_ROUND_CLOSEST(amiga_eclock, HZ);
if (request_resource(&mb_resources._ciab, &sched_res))
- printk("Cannot allocate ciab.ta{lo,hi}\n");
+ pr_warn("Cannot allocate ciab.ta{lo,hi}\n");
ciab.cra &= 0xC0; /* turn off timer A, continuous mode, from Eclk */
ciab.talo = jiffy_ticks % 256;
ciab.tahi = jiffy_ticks / 256;
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] iio: always select ANON_INODES
On 08/05/14 15:56, Arnd Bergmann wrote: Without ANON_INODES, we get this build error: drivers/built-in.o: In function `iio_event_getfd': :(.text+0x14bf18): undefined reference to `anon_inode_getfd' All other users explicitly select this symbol, so we should do the same thing here. Signed-off-by: Arnd Bergmann Cc: Jonathan Cameron Cc: linux-...@vger.kernel.org Applied to the togreg branch of iio.git. Thanks, --- drivers/iio/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig index 743485e..345395e 100644 --- a/drivers/iio/Kconfig +++ b/drivers/iio/Kconfig @@ -4,6 +4,7 @@ menuconfig IIO tristate "Industrial I/O support" + select ANON_INODES help The industrial I/O subsystem provides a unified framework for drivers for many different types of embedded sensors using a -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] net:Add basic DWC Ethernet QoS Driver
small suggestions regarding interrupt registration ( request_irq()) call:
1. instead of request_irq() call in probe function , i think interrupt
can be registered in dwceqos_open() call . since packet only come when
we make interface up( ifconfig up) .
2. in request_irq() thier is flag parameter can either be zero or flag as :
IRQF_DISABLED
IRQF_SHARED
...
normally if we have to share the irq line with other device we use IRQF_SHARED .
On Fri, May 9, 2014 at 8:49 PM, Tobias Klauser wrote:
> On 2014-05-08 at 14:50:14 +0200, Andreas Irestal
> wrote:
>> This is an early version of a driver for the Synopsys DWC Ethernet QoS IP
>> version 4. Unfortunately, version 4.00a and onwards of this IP is totally
>> different from earlier versions used in the STMicroelectronics drivers. Both
>> functionality and registers are different. As this is my first network driver
>> I am submitting an RFC to catch design flaws and bad coding standards at an
>> early stage. Also, others looking at this IP could hopefully be helped by
>> this
>> early code.
>>
>> The driver is quite inefficient, yet still functional (Gbit only) and uses a
>> polling-driven TX-approach. For the RX side NAPI and interrupts are used.
>> There are still quite a lot of work to do. Link handling, more robust
>> error-handling, HW Checksumming, scatter-gather and TCP Segmentation and
>> checksum offloading to name a few.
>>
>> All code has been developed and tested using an FPGA implementation of the
>> IP,
>> with an ARM Cortex A9 as the main CPU, running Linux 3.13.
>>
>> Signed-off-by: Andreas Irestaal
>> ---
>> drivers/net/ethernet/Kconfig|1 +
>> drivers/net/ethernet/Makefile |1 +
>> drivers/net/ethernet/synopsys/Kconfig | 24 +
>> drivers/net/ethernet/synopsys/Makefile |5 +
>> drivers/net/ethernet/synopsys/dwc_eth_qos.c | 706
>> +++
>> drivers/net/ethernet/synopsys/dwc_eth_qos.h | 308
>> 6 files changed, 1045 insertions(+), 0 deletions(-)
>> create mode 100644 drivers/net/ethernet/synopsys/Kconfig
>> create mode 100644 drivers/net/ethernet/synopsys/Makefile
>> create mode 100644 drivers/net/ethernet/synopsys/dwc_eth_qos.c
>> create mode 100644 drivers/net/ethernet/synopsys/dwc_eth_qos.h
>
> [...]
>
>> diff --git a/drivers/net/ethernet/synopsys/dwc_eth_qos.c
>> b/drivers/net/ethernet/synopsys/dwc_eth_qos.c
>> new file mode 100644
>> index 000..20b1a9e
>> --- /dev/null
>> +++ b/drivers/net/ethernet/synopsys/dwc_eth_qos.c
>> @@ -0,0 +1,706 @@
>
> [...]
>
>> +struct net_local {
>> + void __iomem *baseaddr;
>> + struct clk *phy_ref_clk;
>> + struct clk *apb_pclk;
>> +
>> + struct net_device *ndev;
>> + struct platform_device *pdev;
>> +
>> + volatile struct dwc_eth_qos_txdesc *tx_descs;
>> + volatile struct dwc_eth_qos_rxdesc *rx_descs;
>> +
>> + void *tx_buf;
>> +
>> + struct ring_info *rx_skb;
>> +
>> + dma_addr_t tx_descs_addr;
>> + dma_addr_t rx_descs_addr;
>> +
>> + u32 next_tx;
>> + u32 next_rx;
>> +
>> + struct napi_struct napi;
>> +
>> + struct net_device_stats stats;
>
> You don't need a private copy of struct net_device_stats, just use the
> one from struct net_device. It looks like the driver is not returning
> these stats currently anyway. If you use ndev->stats, they will be
> picked up by dev_get_stats() and i.e. show up in ifconfig output.
>
>> + spinlock_t rx_lock;
>> +};
>> +
>> +/* Allocate DMA helper structure at position given by index */
>> +static void dwceqos_alloc_rxring_desc(struct net_local *lp, int index)
>> +{
>> + struct sk_buff *new_skb;
>> + u32 new_skb_baddr = 0;
>> + new_skb = netdev_alloc_skb(lp->ndev, DWCEQOS_RX_BUF_SIZE);
>> + if (!new_skb) {
>> + dev_err(&lp->ndev->dev, "alloc_skb error for desc %d\n",
>> index);
>> + goto out;
>> + }
>> +
>> + /* Get dma handle of skb->data */
>> + new_skb_baddr = (u32)dma_map_single(lp->ndev->dev.parent,
>> + new_skb->data, DWCEQOS_RX_BUF_SIZE, DMA_FROM_DEVICE);
>> + if (dma_mapping_error(lp->ndev->dev.parent, new_skb_baddr)) {
>> + dev_err(&lp->pdev->dev, "DMA map error\n");
>> + dev_kfree_skb(new_skb);
>> + new_skb = NULL;
>> + }
>> +out:
>> + lp->rx_skb[index].skb = new_skb;
>> + lp->rx_skb[index].mapping = new_skb_baddr;
>> + lp->rx_skb[index].len = DWCEQOS_RX_BUF_SIZE;
>> +
>> + return;
>> +}
>> +
>> +static void dwceqos_mtl_init(struct net_local *lp)
>> +{
>> + dwceqos_write(lp->baseaddr, DWCEQOS_MTL_OP_MODE, 0x0060);
>> +}
>> +
>> +static void dwceqos_mtl_tx_init(struct net_local *lp)
>> +{
>> + dwceqos_write(lp->baseaddr, DWCEQOS_MTL_TXQ0_OP_MODE,
>> + DWCEQOS_MTL_TXQ_EN);
>> +}
>> +
>> +static void dwceqos_mtl_rx_init(struct net_local *lp)
>> +{
>> + dwceqos_writ
[PATCH 1/1 RESEND] arch/m68k/apollo/config.c: convert printk to pr_foo()
no level printk converted to pr_info
This is untested
Cc: Geert Uytterhoeven
Cc: Andrew Morton
Signed-off-by: Fabian Frederick
---
arch/m68k/apollo/config.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/m68k/apollo/config.c b/arch/m68k/apollo/config.c
index 9268c0f..42d393f 100644
--- a/arch/m68k/apollo/config.c
+++ b/arch/m68k/apollo/config.c
@@ -65,8 +65,8 @@ int __init apollo_parse_bootinfo(const struct bi_record
*record)
static void __init dn_setup_model(void)
{
- printk("Apollo hardware found: ");
- printk("[%s]\n", apollo_models[apollo_model - APOLLO_DN3000]);
+ pr_info("Apollo hardware found: ");
+ pr_cont("[%s]\n", apollo_models[apollo_model - APOLLO_DN3000]);
switch(apollo_model) {
case APOLLO_UNKNOWN:
@@ -197,8 +197,10 @@ void dn_sched_init(irq_handler_t timer_routine)
*(volatile unsigned char *)(pica+1)&=(~8);
#if 0
- printk("*(0x10803) %02x\n",*(volatile unsigned char *)(apollo_timer +
0x3));
- printk("*(0x10803) %02x\n",*(volatile unsigned char *)(apollo_timer +
0x3));
+ pr_info("*(0x10803) %02x\n",
+ *(volatile unsigned char *)(apollo_timer + 0x3));
+ pr_info("*(0x10803) %02x\n",
+ *(volatile unsigned char *)(apollo_timer + 0x3));
#endif
if (request_irq(IRQ_APOLLO, dn_timer_int, 0, "time", timer_routine))
@@ -236,12 +238,10 @@ int dn_dummy_hwclk(int op, struct rtc_time *t) {
}
-int dn_dummy_set_clock_mmss(unsigned long nowtime) {
-
- printk("set_clock_mmss\n");
-
- return 0;
-
+int dn_dummy_set_clock_mmss(unsigned long nowtime)
+{
+ pr_info("set_clock_mmss\n");
+ return 0;
}
void dn_dummy_reset(void) {
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] iio:adc: at91 requires the input subsystem
On 09/05/14 13:57, Nicolas Ferre wrote: On 09/05/2014 13:43, Arnd Bergmann : On Friday 09 May 2014 12:01:48 Nicolas Ferre wrote: On 08/05/2014 16:56, Arnd Bergmann : Building the at91 adc driver with CONFIG_INPUT disabled results in this build error: ERROR: "input_event" [drivers/iio/adc/at91_adc.ko] undefined! ERROR: "input_unregister_device" [drivers/iio/adc/at91_adc.ko] undefined! ERROR: "input_free_device" [drivers/iio/adc/at91_adc.ko] undefined! ERROR: "input_register_device" [drivers/iio/adc/at91_adc.ko] undefined! ERROR: "input_set_abs_params" [drivers/iio/adc/at91_adc.ko] undefined! ERROR: "input_allocate_device" [drivers/iio/adc/at91_adc.ko] undefined! To make sure we can build random configurations, this turns on CONFIG_INPUT whenever CONFIG_AT91_ADC is enabled. Isn't it a "select" instead of "depends" that is required then? It seems I fixed the patch at some point but didn't update the message. In general, we should not mix 'depends on' and 'select' for the same symbol, since that causes extra confusion. In case of CONFIG_INPUT, almost all the users do 'depends on INPUT', with a few exceptions that seem to be done in error. Ok, that makes sense. Updated patch below. Thanks Arnd. Arnd 8< >From 4679d63b24a681d9c6afcfdde266bae0f940e90b Mon Sep 17 00:00:00 2001 From: Arnd Bergmann Date: Wed, 9 Apr 2014 17:18:10 +0200 Subject: [PATCH] [SUBMITTED] iio:adc: at91 requires the input subsystem Building the at91 adc driver with CONFIG_INPUT disabled results in this build error: ERROR: "input_event" [drivers/iio/adc/at91_adc.ko] undefined! ERROR: "input_unregister_device" [drivers/iio/adc/at91_adc.ko] undefined! ERROR: "input_free_device" [drivers/iio/adc/at91_adc.ko] undefined! ERROR: "input_register_device" [drivers/iio/adc/at91_adc.ko] undefined! ERROR: "input_set_abs_params" [drivers/iio/adc/at91_adc.ko] undefined! ERROR: "input_allocate_device" [drivers/iio/adc/at91_adc.ko] undefined! To make sure we can build random configurations, this adds a Kconfig dependency on CONFIG_INPUT, as we do for other similar drivers. Signed-off-by: Arnd Bergmann Cc: linux-...@vger.kernel.org Cc: Josh Wu Cc: Jonathan Cameron Cc: Maxime Ripard Acked-by: Nicolas Ferre Applied to the togreg branch of iio.git. Thanks, Jonathan Bye, diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index 90f596d..a80d236 100644 --- a/drivers/iio/adc/Kconfig +++ b/drivers/iio/adc/Kconfig @@ -110,6 +110,7 @@ config AD799X config AT91_ADC tristate "Atmel AT91 ADC" depends on ARCH_AT91 + depends on INPUT select IIO_BUFFER select IIO_TRIGGERED_BUFFER select SYSFS -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1 RESEND] arch/m68k/hp300/config.c: convert printk to pr_foo()
This patch also fixes some checkpatch warnings
This is untested
Cc: Geert Uytterhoeven
Cc: Andrew Morton
Signed-off-by: Fabian Frederick
---
arch/m68k/hp300/config.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/m68k/hp300/config.c b/arch/m68k/hp300/config.c
index 2e5a787..a9befe6 100644
--- a/arch/m68k/hp300/config.c
+++ b/arch/m68k/hp300/config.c
@@ -87,7 +87,7 @@ int __init hp300_parse_bootinfo(const struct bi_record
*record)
/* serial port address: ignored here */
break;
-default:
+ default:
unknown = 1;
}
@@ -262,11 +262,12 @@ void __init config_hp300(void)
#endif
mach_max_dma_address = 0x;
- if (hp300_model >= HP_330 && hp300_model <= HP_433S && hp300_model !=
HP_350) {
- printk(KERN_INFO "Detected HP9000 model %s\n",
hp300_models[hp300_model-HP_320]);
+ if (hp300_model >= HP_330 && hp300_model <= HP_433S &&
+ hp300_model != HP_350) {
+ pr_info("Detected HP9000 model %s\n",
+ hp300_models[hp300_model-HP_320]);
strcat(hp300_model_name, hp300_models[hp300_model-HP_320]);
- }
- else {
+ } else {
panic("Unknown HP9000 Model");
}
#ifdef CONFIG_SERIAL_8250_CONSOLE
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1 RESEND] drivers/pnp/resource.c: remove positive test on unsigned values
irq and dma are both resource_size_t (derived from phys_addr_t <-> unsigned) Cc: "Rafael J. Wysocki" Cc: Andrew Morton Signed-off-by: Fabian Frederick --- drivers/pnp/resource.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/pnp/resource.c b/drivers/pnp/resource.c index 01712cb..782e822 100644 --- a/drivers/pnp/resource.c +++ b/drivers/pnp/resource.c @@ -360,7 +360,7 @@ int pnp_check_irq(struct pnp_dev *dev, struct resource *res) return 1; /* check if the resource is valid */ - if (*irq < 0 || *irq > 15) + if (*irq > 15) return 0; /* check if the resource is reserved */ @@ -424,7 +424,7 @@ int pnp_check_dma(struct pnp_dev *dev, struct resource *res) return 1; /* check if the resource is valid */ - if (*dma < 0 || *dma == 4 || *dma > 7) + if (*dma == 4 || *dma > 7) return 0; /* check if the resource is reserved */ -- 1.8.4.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1 RESEND] drivers/scsi/sd.c: remove positive test on unsigned value
val is unsigned. Cc: "James E.J. Bottomley" Cc: Andrew Morton Signed-off-by: Fabian Frederick --- drivers/scsi/sd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index efcbcd1..b54d4f8 100644 --- a/drivers/scsi/sd.c +++ b/drivers/scsi/sd.c @@ -296,7 +296,7 @@ protection_type_store(struct device *dev, struct device_attribute *attr, if (err) return err; - if (val >= 0 && val <= SD_DIF_TYPE3_PROTECTION) + if (val <= SD_DIF_TYPE3_PROTECTION) sdkp->protection_type = val; return count; -- 1.8.4.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] tick: SHUTDOWN event-dev if no events are required for KTIME_MAX
On Fri, 9 May 2014, Thomas Gleixner wrote:
> On Fri, 9 May 2014, Viresh Kumar wrote:
> So the right thing to do this is:
>
> 1A) Change the prototype of the set_mode callback to return int and
> fixup all users. Either add the missing default clause or remove
> the existing BUG()/ pr_err()/whatever handling in the existing
> default clause and return a UNIQUE error code.
>
> I know I should have done that from the very beginning, but in
> hindsight one could have done everything better.
>
> coccinelle is your friend (if you need help ask me or Julia
> Lawall). But it's going to be quite some manual work on top.
There is even a better way to do that:
1) Create a new callback set_state() which has an
int return value.
2) Make the callsites do
if (dev->set_state) {
ret = dev->set_state();
handle_return_value();
} else
dev->set_mode();
3) Convert implementations one by one to use the new callback
4) Remove the set_mode callback
5) Implement new features.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] perf/events/core: Drop unused variable after cleanup
From: Borislav Petkov
... in 3a497f48637 ("perf: Simplify perf_event_exit_task_context()")
Cc: Peter Zijlstra
Signed-off-by: Borislav Petkov
---
kernel/events/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 7ab734fbaeeb..ed50b0943213 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -7431,7 +7431,7 @@ __perf_event_exit_task(struct perf_event *child_event,
static void perf_event_exit_task_context(struct task_struct *child, int ctxn)
{
- struct perf_event *child_event, *tmp;
+ struct perf_event *child_event;
struct perf_event_context *child_ctx;
unsigned long flags;
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Question: hwmon: Adding addtitional sysfs entries
Hi, i am currently working on an implemenation of my Board Management Controller (BMC). This Controller is a MCR assembled on almost all of our Compact PCI or Compact PCI Serial Cards as well as on some other CPU Boards. The BMC includes LED´s, Watchdog, Voltage Monitoring and some other features. I have already implemented an MFD driver, LED and Watchdog driver. Currently i am working on the hwmon implemenation. This includes for the first step the voltage monitoring. The BMC has some other feature which are not supported by any of the subsystem. - Errorcounter (Board status) - Power Failure status - Operating ours - Do software reset, do cold reset - Set power modes - Backplate Geographical Address These are all informations related to the Board where the BMC is assembled to. I think all those features could be part of the hwmon implementation. Is it possible to add "custom" sysfs entries in my hwmon driver to support all these features? Does lm-sensor ingore those custom features or is it a problem for lm-sensors? What is the normal way to add those features? Regards Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] usb: host: ehci-exynos: Use devm_ioremap_resource instead of devm_ioremap
Hi,
On Sat, May 10, 2014 at 3:36 PM, Alexander Shiyan wrote:
> Sat, 10 May 2014 15:26:58 +0530 от Vivek Gautam :
>> Using devm_ioremap_resource() API should actually be preferred over
>> devm_ioremap(), since the former request the mem region first and then
>> gives back the ioremap'ed memory pointer.
>> devm_ioremap_resource() calls request_mem_region(), therby preventing
>> other drivers to make any overlapping call to the same region.
>>
>> Signed-off-by: Vivek Gautam
>> ---
>> drivers/usb/host/ehci-exynos.c |3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
>> index 7f425ac..bccb6f1 100644
>> --- a/drivers/usb/host/ehci-exynos.c
>> +++ b/drivers/usb/host/ehci-exynos.c
>> @@ -135,9 +135,8 @@ skip_phy:
>>
>> hcd->rsrc_start = res->start;
>> hcd->rsrc_len = resource_size(res);
>> - hcd->regs = devm_ioremap(&pdev->dev, res->start, hcd->rsrc_len);
>> + hcd->regs = devm_ioremap_resource(&pdev->dev, res);
>> if (!hcd->regs) {
>> - dev_err(&pdev->dev, "Failed to remap I/O memory\n");
>> err = -ENOMEM;
>> goto fail_io;
>> }
>
> You should check this as:
>
> if (IS_ERR(hcd->regs)) {
> err = PTR_ERR(hcd->regs);
> ...
Thanks for pointing out. Will change this.
>
> Same in other patches in this series.
>
> ---
>
--
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: rtl8821ae: fix pointer coding style
Found by checkpatch. Signed-off-by: Levente Kurusa --- drivers/staging/rtl8821ae/pci.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8821ae/pci.c b/drivers/staging/rtl8821ae/pci.c index a562aa6..7bbaef7 100644 --- a/drivers/staging/rtl8821ae/pci.c +++ b/drivers/staging/rtl8821ae/pci.c @@ -392,7 +392,7 @@ static u8 _rtl_pci_get_pciehdr_offset(struct ieee80211_hw *hw) pcicfg_addr_port + (num4bytes << 2)); rtl_pci_raw_read_port_ushort(PCI_CONF_DATA, -(u16*)&capability_hdr); +(u16 *)&capability_hdr); /* Found the PCI express capability. */ if (capability_hdr.capability_id == PCI_CAPABILITY_ID_PCI_EXPRESS) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 5/6] usb: host: ehci-tegra: Use devm_ioremap_resource instead of devm_ioremap
Using devm_ioremap_resource() API should actually be preferred over
devm_ioremap(), since the former request the mem region first and then
gives back the ioremap'ed memory pointer.
devm_ioremap_resource() calls request_mem_region(), therby preventing
other drivers to make any overlapping call to the same region.
Signed-off-by: Vivek Gautam
---
drivers/usb/host/ehci-tegra.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
index 572634c..6fdcb8a 100644
--- a/drivers/usb/host/ehci-tegra.c
+++ b/drivers/usb/host/ehci-tegra.c
@@ -411,10 +411,9 @@ static int tegra_ehci_probe(struct platform_device *pdev)
}
hcd->rsrc_start = res->start;
hcd->rsrc_len = resource_size(res);
- hcd->regs = devm_ioremap(&pdev->dev, res->start, resource_size(res));
- if (!hcd->regs) {
- dev_err(&pdev->dev, "Failed to remap I/O memory\n");
- err = -ENOMEM;
+ hcd->regs = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(hcd->regs)) {
+ err = PTR_ERR(hcd->regs);
goto cleanup_clk_en;
}
ehci->caps = hcd->regs + 0x100;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/6] usb: host: ehci-mv: Use devm_ioremap_resource instead of devm_ioremap
Using devm_ioremap_resource() API should actually be preferred over
devm_ioremap(), since the former request the mem region first and then
gives back the ioremap'ed memory pointer.
devm_ioremap_resource() calls request_mem_region(), therby preventing
other drivers to make any overlapping call to the same region.
Signed-off-by: Vivek Gautam
---
drivers/usb/host/ehci-mv.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/host/ehci-mv.c b/drivers/usb/host/ehci-mv.c
index bd61612..08147c3 100644
--- a/drivers/usb/host/ehci-mv.c
+++ b/drivers/usb/host/ehci-mv.c
@@ -176,11 +176,9 @@ static int mv_ehci_probe(struct platform_device *pdev)
goto err_put_hcd;
}
- ehci_mv->phy_regs = devm_ioremap(&pdev->dev, r->start,
-resource_size(r));
- if (!ehci_mv->phy_regs) {
- dev_err(&pdev->dev, "failed to map phy I/O memory\n");
- retval = -EFAULT;
+ ehci_mv->phy_regs = devm_ioremap_resource(&pdev->dev, r);
+ if (IS_ERR(ehci_mv->phy_regs)) {
+ retval = PTR_ERR(ehci_mv->phy_regs);
goto err_put_hcd;
}
@@ -191,11 +189,9 @@ static int mv_ehci_probe(struct platform_device *pdev)
goto err_put_hcd;
}
- ehci_mv->cap_regs = devm_ioremap(&pdev->dev, r->start,
-resource_size(r));
- if (ehci_mv->cap_regs == NULL) {
- dev_err(&pdev->dev, "failed to map I/O memory\n");
- retval = -EFAULT;
+ ehci_mv->cap_regs = devm_ioremap_resource(&pdev->dev, r);
+ if (IS_ERR(ehci_mv->cap_regs)) {
+ retval = PTR_ERR(ehci_mv->cap_regs);
goto err_put_hcd;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/6] usb: host: ehci-msm: Use devm_ioremap_resource instead of devm_ioremap
Using devm_ioremap_resource() API should actually be preferred over
devm_ioremap(), since the former request the mem region first and then
gives back the ioremap'ed memory pointer.
devm_ioremap_resource() calls request_mem_region(), therby preventing
other drivers to make any overlapping call to the same region.
Signed-off-by: Vivek Gautam
---
drivers/usb/host/ehci-msm.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/ehci-msm.c b/drivers/usb/host/ehci-msm.c
index f341651..982c09b 100644
--- a/drivers/usb/host/ehci-msm.c
+++ b/drivers/usb/host/ehci-msm.c
@@ -96,10 +96,9 @@ static int ehci_msm_probe(struct platform_device *pdev)
hcd->rsrc_start = res->start;
hcd->rsrc_len = resource_size(res);
- hcd->regs = devm_ioremap(&pdev->dev, hcd->rsrc_start, hcd->rsrc_len);
- if (!hcd->regs) {
- dev_err(&pdev->dev, "ioremap failed\n");
- ret = -ENOMEM;
+ hcd->regs = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(hcd->regs)) {
+ ret = PTR_ERR(hcd->regs);
goto put_hcd;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/6] usb: host: ehci-exynos: Use devm_ioremap_resource instead of devm_ioremap
Using devm_ioremap_resource() API should actually be preferred over
devm_ioremap(), since the former request the mem region first and then
gives back the ioremap'ed memory pointer.
devm_ioremap_resource() calls request_mem_region(), therby preventing
other drivers to make any overlapping call to the same region.
Signed-off-by: Vivek Gautam
---
drivers/usb/host/ehci-exynos.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 7f425ac..c23a6d9 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -135,10 +135,9 @@ skip_phy:
hcd->rsrc_start = res->start;
hcd->rsrc_len = resource_size(res);
- hcd->regs = devm_ioremap(&pdev->dev, res->start, hcd->rsrc_len);
- if (!hcd->regs) {
- dev_err(&pdev->dev, "Failed to remap I/O memory\n");
- err = -ENOMEM;
+ hcd->regs = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(hcd->regs)) {
+ err = PTR_ERR(hcd->regs);
goto fail_io;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/6] usb: host: Cleanup for ioremap'ing hcd memory
Based on 'usb-next' branch of Greg's usb tree. devm_ioremap_resource() API is advantageous over devm_ioremap() and should therefore be preferred to request any ioremap'ed address for hcd. Changes from v1: - Changed the way returned pointer is checked for error value as pointed out in the review comment in the mailing list. Vivek Gautam (6): usb: host: ehci-exynos: Use devm_ioremap_resource instead of devm_ioremap usb: host: ehci-msm: Use devm_ioremap_resource instead of devm_ioremap usb: host: ehci-mv: Use devm_ioremap_resource instead of devm_ioremap usb: host: ehci-spear: Use devm_ioremap_resource instead of devm_ioremap usb: host: ehci-tegra: Use devm_ioremap_resource instead of devm_ioremap usb: host: ohci-exynos: Use devm_ioremap_resource instead of devm_ioremap drivers/usb/host/ehci-exynos.c |7 +++ drivers/usb/host/ehci-msm.c|7 +++ drivers/usb/host/ehci-mv.c | 16 ++-- drivers/usb/host/ehci-spear.c | 13 +++-- drivers/usb/host/ehci-tegra.c |7 +++ drivers/usb/host/ohci-exynos.c |7 +++ 6 files changed, 21 insertions(+), 36 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 6/6] usb: host: ohci-exynos: Use devm_ioremap_resource instead of devm_ioremap
Using devm_ioremap_resource() API should actually be preferred over
devm_ioremap(), since the former request the mem region first and then
gives back the ioremap'ed memory pointer.
devm_ioremap_resource() calls request_mem_region(), therby preventing
other drivers to make any overlapping call to the same region.
Signed-off-by: Vivek Gautam
---
drivers/usb/host/ohci-exynos.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 9cf80cb..dec691d 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -120,10 +120,9 @@ skip_phy:
hcd->rsrc_start = res->start;
hcd->rsrc_len = resource_size(res);
- hcd->regs = devm_ioremap(&pdev->dev, res->start, hcd->rsrc_len);
- if (!hcd->regs) {
- dev_err(&pdev->dev, "Failed to remap I/O memory\n");
- err = -ENOMEM;
+ hcd->regs = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(hcd->regs)) {
+ err = PTR_ERR(hcd->regs);
goto fail_io;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/6] usb: host: ehci-spear: Use devm_ioremap_resource instead of devm_ioremap
Using devm_ioremap_resource() API should actually be preferred over
devm_ioremap(), since the former request the mem region first and then
gives back the ioremap'ed memory pointer.
devm_ioremap_resource() calls request_mem_region(), therby preventing
other drivers to make any overlapping call to the same region.
Signed-off-by: Vivek Gautam
---
drivers/usb/host/ehci-spear.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/host/ehci-spear.c b/drivers/usb/host/ehci-spear.c
index 8bd915b..1d59958 100644
--- a/drivers/usb/host/ehci-spear.c
+++ b/drivers/usb/host/ehci-spear.c
@@ -106,16 +106,9 @@ static int spear_ehci_hcd_drv_probe(struct platform_device
*pdev)
hcd->rsrc_start = res->start;
hcd->rsrc_len = resource_size(res);
- if (!devm_request_mem_region(&pdev->dev, hcd->rsrc_start, hcd->rsrc_len,
- driver->description)) {
- retval = -EBUSY;
- goto err_put_hcd;
- }
-
- hcd->regs = devm_ioremap(&pdev->dev, hcd->rsrc_start, hcd->rsrc_len);
- if (hcd->regs == NULL) {
- dev_dbg(&pdev->dev, "error mapping memory\n");
- retval = -ENOMEM;
+ hcd->regs = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(hcd->regs)) {
+ retval = PTR_ERR(hcd->regs);
goto err_put_hcd;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mfd: abx500-core: Fix compiler warning larger stack frame
From 95f6ac368dbe352af0dfa2097b7d58b416447be5 Mon Sep 17 00:00:00 2001
From: Aurabindo J
Date: Sat, 10 May 2014 15:16:58 +0530
Subject: [PATCH] mfd: abx500-core: Fix compiler warning larger stack frame
On systems with CONFIG_FRAME_WARN=1024, compiler warns the allocation of
an object of struct device on stack. Make the allocation dynamically to
fix the warning.
drivers/mfd/abx500-core.c: In function ‘abx500_dump_all_banks’:
drivers/mfd/abx500-core.c:167:1: warning: the frame size of 1032 bytes
is larger than 1024 bytes [-Wframe-larger-than=]
Signed-off-by: Aurabindo J
---
drivers/mfd/abx500-core.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/abx500-core.c b/drivers/mfd/abx500-core.c
index f3a15aa..87d80c3 100644
--- a/drivers/mfd/abx500-core.c
+++ b/drivers/mfd/abx500-core.c
@@ -154,16 +154,19 @@ EXPORT_SYMBOL(abx500_startup_irq_enabled);
void abx500_dump_all_banks(void)
{
struct abx500_ops *ops;
- struct device dummy_child = {NULL};
+ struct device *dummy_child;
struct abx500_device_entry *dev_entry;
+ dummy_child = kzalloc(sizeof(struct device), GFP_KERNEL);
+
list_for_each_entry(dev_entry, &abx500_list, list) {
- dummy_child.parent = dev_entry->dev;
+ dummy_child->parent = dev_entry->dev;
ops = &dev_entry->ops;
if ((ops != NULL) && (ops->dump_all_banks != NULL))
- ops->dump_all_banks(&dummy_child);
+ ops->dump_all_banks(dummy_child);
}
+ kfree(dummy_child);
}
EXPORT_SYMBOL(abx500_dump_all_banks);
--
1.9.1
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 1/1 RESEND] drivers/pnp/resource.c: remove positive test on unsigned values
On Saturday, May 10, 2014 12:47:15 PM Fabian Frederick wrote: > irq and dma are both resource_size_t (derived from phys_addr_t <-> unsigned) > > Cc: "Rafael J. Wysocki" > Cc: Andrew Morton > Signed-off-by: Fabian Frederick Queued up for 3.16, thanks! > --- > drivers/pnp/resource.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/pnp/resource.c b/drivers/pnp/resource.c > index 01712cb..782e822 100644 > --- a/drivers/pnp/resource.c > +++ b/drivers/pnp/resource.c > @@ -360,7 +360,7 @@ int pnp_check_irq(struct pnp_dev *dev, struct resource > *res) > return 1; > > /* check if the resource is valid */ > - if (*irq < 0 || *irq > 15) > + if (*irq > 15) > return 0; > > /* check if the resource is reserved */ > @@ -424,7 +424,7 @@ int pnp_check_dma(struct pnp_dev *dev, struct resource > *res) > return 1; > > /* check if the resource is valid */ > - if (*dma < 0 || *dma == 4 || *dma > 7) > + if (*dma == 4 || *dma > 7) > return 0; > > /* check if the resource is reserved */ > -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vmstat: On demand vmstat workers V4
On Fri, 9 May 2014, Paul E. McKenney wrote: > On Sat, May 10, 2014 at 12:57:15AM +0200, Thomas Gleixner wrote: > > On Fri, 9 May 2014, Christoph Lameter wrote: > > > On Fri, 9 May 2014, Thomas Gleixner wrote: > > > > I understand why you want to get this done by a housekeeper, I just > > > > did not understand why we need this whole move it around business is > > > > required. > > > > > > This came about because of another objection against having it simply > > > fixed to a processor. After all that processor may be disabled etc etc. > > > > I really regret that I did not pay more attention (though my cycle > > constraints simply do not allow it). > > As far as I can see, the NO_HZ_FULL timekeeping CPU is always zero. If it > can change in NO_HZ_FULL kernels, RCU will do some very strange things! Good. I seriously hope it stays that way. > One possible issue here is that Christoph's patch is unconditional. > It takes effect for both NO_HZ_FULL and !NO_HZ_FULL. If I recall > correctly, the timekeeping CPU -can- change in !NO_HZ_FULL kernels, > which might be what Christoph was trying to take into account. Ok. Sorry, I was just in a lousy mood after wasting half a day in reviewing even lousier patches related to that NO_HZ* muck. So, right with NO_HZ_IDLE the time keeper can move around and housekeeping stuff might want to move around as well. But it's not necessary a good idea to bundle that with the timekeeper, as under certain conditions the timekeeper duty can move around fast and left unassigned again when the system is fully idle. And we really do not want a gazillion of sites which implement a metric ton of different ways to connect some random housekeeping jobs with the timekeeper. So the proper solution to this is to have either a thread or a dedicated housekeeping worker, which is placed by the scheduler depending on the system configuration and workload. That way it can be kept at cpu0 for the nohz=off and the nohz_full case. In the nohz_idle case we can have different placement algorithms. On a big/little ARM machine you probably want to keep it on the first cpu of one or the other cluster. And there might be other constraints on servers. So we are way better of with a generic facility, where the various housekeeping jobs can be queued. Does that make sense? Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Add lib/glob.c
Hello,
On Fri, May 09, 2014 at 11:13:56PM -0400, George Spelvin wrote:
> +config GLOB
> + tristate
> +#(Prompt disabled to reduce kbuild clutter until someone needs it.)
> +#prompt "glob_match() function"
> + help
> + This option provides a glob_match function for performing simple
> + text pattern matching. It is primarily used by the ATA code
> + to blacklist particular drive models, but other device drivers
> + may need similar functionality.
> +
> + All in-kernel drivers that require this function automatically
> + select this option. Say N unless you are compiling an out-of
> + tree driver which tells you it depend on it.
Just adding glob.o to lib-y should be enough. It will be excluded
from linking if unused.
> +#ifdef UNITTEST
> +/* To do a basic sanity test, "cc -DUNITTEST glob.c" and run a.out. */
> +
> +#include
> +#define __pure __attribute__((pure))
> +#define NOP(x)
> +#define EXPORT_SYMBOL NOP/* Two stages to avoid checkpatch complaints */
These things tend to bitrot. Let's please keep testing harness out of
tree.
> +#else
> +
> +#include
> +#include
> +
> +MODULE_DESCRIPTION("glob(7) matching");
> +MODULE_LICENSE("Dual MIT/GPL");
Do we make library routines separate modules usually?
...
> +bool __pure
> +glob_match(char const *pat, char const *str)
The whole thing fits in a single 80 column line, right?
bool __pure glob_match(char const *pat, char const *str)
> +{
> + /*
> + * Backtrack to previous * on mismatch and retry starting one
> + * character later in the string. Because * matches all characters
> + * (no exception for /), it can be easily proved that there's
> + * never a need to backtrack multiple levels.
> + */
> + char const *back_pat = 0, *back_str = back_str;
Blank line here.
I haven't delved into the actual implementation. Looks sane on the
first glance.
> +#ifdef UNITTEST
> +
> +/* Test code */
> +#include
> +#include
> +struct glob_test {
> + char const *pat, *str;
> + bool expected;
> +};
> +
> +static void
> +test(struct glob_test const *g)
> +{
> + bool match = glob_match(g->pat, g->str);
> +
> + printf("\"%s\" vs. \"%s\": %s %s\n", g->pat, g->str,
> + match ? "match" : "mismatch",
> + match == g->expected ? "OK" : "*** ERROR ***");
> + if (match != g->expected)
> + exit(1);
> +}
> +
> +static struct glob_test const tests[] = {
> + { "a", "a", true },
...
> + { "*ab*cd*", "abcabcabcabcefg", false }
> +};
> +
> +int
> +main(void)
> +{
> + size_t i;
> +
> + for (i = 0; i < sizeof(tests)/sizeof(*tests); i++)
> + test(tests + i);
> +
> + return 0;
> +}
> +
> +#endif /* UNITTEST */
Again, I don't really think the userland testing code belongs here.
If you wanna keep them, please make it in-kernel selftesting. We
don't really wanna keep code which can't get built and tested in
kernel tree proper.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: vmstat: On demand vmstat workers V4
On Sat, 10 May 2014, Frederic Weisbecker wrote: > Anyway I agree that was overengineering at this stage. > > Fortunately nothing has been applied. I was too busy with cleanups and > workqueues > affinity. Good. > So the "only" damage is on bad directions given to Christoph. But you know > how I use GPS... Yeah, especially when it's switched to 'Frederic universe' mode :) Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Add lib/glob.c
Ooh, one more nitpick. On Fri, May 09, 2014 at 11:13:56PM -0400, George Spelvin wrote: > +/** > + * glob_match - Shell-style pattern matching, like !fnmatch(pat, str, 0) > + * @pat: Pattern to match. Metacharacters are ?, *, [ and \. > + * (And, inside character classes, !, - and ].) @ARG lines should be contained in a single line. Just "Pattern to match." should do. With detailed description in the body. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vmstat: On demand vmstat workers V4
On Sat, 10 May 2014, Frederic Weisbecker wrote: > But I still have the plan to make the timekeeper use the full sysidle > facility in order to adaptively get to dynticks idle. > > Reminder for others: in NO_HZ_FULL, the timekeeper (always CPU 0) stays > completely periodic. It can't enter in dynticks idle mode because it > must maintain timekeeping on behalf of full dynticks CPUs. So that's > a power issue. > > But Paul has a feature in RCU that lets us know when all CPUs are idle > and the timekeeper can finally sleep. Then when a full nohz CPU wakes > up from idle, it sends an IPI to the timekeeper if needed so the latter > restarts timekeeping maintainance. > > It's not complicated to add to the timer code. > Most of the code is already there, in RCU, for a while already. > > Are we keeping that direction? So the idea is that the timekeeper stays on cpu0, but if everything is idle it is allowed to take a long nap as well. So if some other cpu wakes up it updates timekeeping without taking over the time keeper duty and if it has work to do, it kicks cpu0 into gear. If it just goes back to sleep, then nothing to do. No objections from my side. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question: hwmon: Adding addtitional sysfs entries
On 05/10/2014 06:22 AM, Andreas Werner wrote: Hi, i am currently working on an implemenation of my Board Management Controller (BMC). This Controller is a MCR assembled on almost all of our Compact PCI or Compact PCI Serial Cards as well as on some other CPU Boards. The BMC includes LED´s, Watchdog, Voltage Monitoring and some other features. I have already implemented an MFD driver, LED and Watchdog driver. Currently i am working on the hwmon implemenation. This includes for the first step the voltage monitoring. The BMC has some other feature which are not supported by any of the subsystem. - Errorcounter (Board status) - Power Failure status - Operating ours Guess you mean hours here. - Do software reset, do cold reset - Set power modes - Backplate Geographical Address These are all informations related to the Board where the BMC is assembled to. I think all those features could be part of the hwmon implementation. Why ? Is it possible to add "custom" sysfs entries in my hwmon driver to support all these features? Does lm-sensor ingore those custom features or is it a problem for lm-sensors? What is the normal way to add those features? The hwmon subsystem isn't really the correct location for this functionality. Power management should be done with a regulator driver (possibly power). The other attributes and functionality would better fit into the mfd core driver. You might want to tie the reset functions into the system reset functionality. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/2] i2c: sunxi: add P2WI controller support
On Sat, May 10, 2014 at 11:46:01AM +0200, Boris BREZILLON wrote: > Hello, > > This series adds support for the P2WI block used by some Allwinner > boards to interface with the AXP221 PMIC. > > Best Regards, It looks fine now. Thanks for your work. You have, for the two patches, my Acked-by: Maxime Ripard Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[PATCH v2 2/7] ARM: sun6i: Add the USB clocks to the DTSI.
The USB clocks of the A31 seems to be parented to the 24MHz oscillator, and
handle the clocks for the USB phys and OHCI devices.
Signed-off-by: Maxime Ripard
Reviewed-by: Hans de Goede
---
arch/arm/boot/dts/sun6i-a31.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index eec1afa257a5..13aa56ed5858 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -269,6 +269,17 @@
clocks = <&osc24M>, <&pll6>;
clock-output-names = "spi3";
};
+
+ usb_clk: clk@01c200cc {
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ compatible = "allwinner,sun6i-a31-usb-clk";
+ reg = <0x01c200cc 0x4>;
+ clocks = <&osc24M>;
+ clock-output-names = "usb_phy0", "usb_phy1", "usb_phy2",
+"usb_ohci0", "usb_ohci1",
+"usb_ohci2";
+ };
};
soc@01c0 {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/7] clk: sunxi: Implement A31 USB clock
The A31 USB clock slightly differ from its older counterparts, mostly because
it has a different gate for each PHY, while the older one had a single gate for
all the phy.
Signed-off-by: Maxime Ripard
Reviewed-by: Hans de Goede
---
drivers/clk/sunxi/clk-sunxi.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index bd7dc733c1ca..d9bab75f128b 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -972,6 +972,11 @@ static const struct gates_data sun5i_a13_usb_gates_data
__initconst = {
.reset_mask = 0x03,
};
+static const struct gates_data sun6i_a31_usb_gates_data __initconst = {
+ .mask = { BIT(18) | BIT(17) | BIT(16) | BIT(10) | BIT(9) | BIT(8) },
+ .reset_mask = BIT(2) | BIT(1) | BIT(0),
+};
+
static void __init sunxi_gates_clk_setup(struct device_node *node,
struct gates_data *data)
{
@@ -1267,6 +1272,7 @@ static const struct of_device_id clk_gates_match[]
__initconst = {
{.compatible = "allwinner,sun6i-a31-apb2-gates-clk", .data =
&sun6i_a31_apb2_gates_data,},
{.compatible = "allwinner,sun4i-a10-usb-clk", .data =
&sun4i_a10_usb_gates_data,},
{.compatible = "allwinner,sun5i-a13-usb-clk", .data =
&sun5i_a13_usb_gates_data,},
+ {.compatible = "allwinner,sun6i-a31-usb-clk", .data =
&sun6i_a31_usb_gates_data,},
{}
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/7] usb: ehci-platform: add optional reset controller retrieval
From: Boris BREZILLON
On the Allwinner's A31 SoC the reset line connected to the EHCI IP has to
be deasserted for the EHCI block to be usable.
Add support for an optional reset controller that will be deasserted on
power off and asserted on power on.
Signed-off-by: Boris BREZILLON
Signed-off-by: Maxime Ripard
Reviewed-by: Hans de Goede
---
Documentation/devicetree/bindings/usb/usb-ehci.txt | 1 +
drivers/usb/host/ehci-platform.c | 18 ++
2 files changed, 19 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt
b/Documentation/devicetree/bindings/usb/usb-ehci.txt
index ff151ec084c4..43c1a4e06767 100644
--- a/Documentation/devicetree/bindings/usb/usb-ehci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt
@@ -15,6 +15,7 @@ Optional properties:
- clocks : a list of phandle + clock specifier pairs
- phys : phandle + phy specifier pair
- phy-names : "usb"
+ - resets : phandle + reset specifier pair
Example (Sequoia 440EPx):
ehci@e300 {
diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index c7dd93aad20c..da89f274aa76 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -41,6 +42,7 @@
struct ehci_platform_priv {
struct clk *clks[EHCI_MAX_CLKS];
+ struct reset_control *rst;
struct phy *phy;
};
@@ -206,6 +208,19 @@ static int ehci_platform_probe(struct platform_device *dev)
break;
}
}
+
+ priv->rst = devm_reset_control_get_optional(&dev->dev,
+ NULL);
+ if (IS_ERR(priv->rst)) {
+ err = PTR_ERR(priv->rst);
+ if (err == -EPROBE_DEFER)
+ goto err_put_clks;
+ priv->rst = NULL;
+ } else {
+ err = reset_control_deassert(priv->rst);
+ if (err)
+ goto err_put_clks;
+ }
}
if (pdata->big_endian_desc)
@@ -280,6 +295,9 @@ static int ehci_platform_remove(struct platform_device *dev)
if (pdata->power_off)
pdata->power_off(dev);
+ if (priv->rst)
+ reset_control_assert(priv->rst);
+
for (clk = 0; clk < EHCI_MAX_CLKS && priv->clks[clk]; clk++)
clk_put(priv->clks[clk]);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 7/7] ARM: sunxi: dt: add APP4-EVB1 board support
From: Boris BREZILLON
The APP4 EVB1 development boards embeds an A31, together with some NAND, one SD
card slot, and one SDIO + UART WiFi and Bluetooth chip, a few I2C buses, USB,
and a LCD display.
Signed-off-by: Boris BREZILLON
Signed-off-by: Maxime Ripard
Reviewed-by: Hans de Goede
---
arch/arm/boot/dts/Makefile| 1 +
arch/arm/boot/dts/sun6i-a31-app4-evb1.dts | 57 +++
2 files changed, 58 insertions(+)
create mode 100644 arch/arm/boot/dts/sun6i-a31-app4-evb1.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index ffa3f5ef27d3..d50c0895a9d5 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -343,6 +343,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += \
sun5i-a10s-olinuxino-micro.dtb \
sun5i-a13-olinuxino.dtb \
sun5i-a13-olinuxino-micro.dtb \
+ sun6i-a31-app4-evb1.dtb \
sun6i-a31-colombus.dtb \
sun6i-a31-m9.dtb \
sun7i-a20-cubieboard2.dtb \
diff --git a/arch/arm/boot/dts/sun6i-a31-app4-evb1.dts
b/arch/arm/boot/dts/sun6i-a31-app4-evb1.dts
new file mode 100644
index ..2bbf8867362b
--- /dev/null
+++ b/arch/arm/boot/dts/sun6i-a31-app4-evb1.dts
@@ -0,0 +1,57 @@
+/*
+ * Copyright 2014 Boris Brezillon
+ *
+ * Boris Brezillon
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+/include/ "sun6i-a31.dtsi"
+/include/ "sunxi-common-regulators.dtsi"
+
+/ {
+ model = "Allwinner A31 APP4 EVB1 Evaluation Board";
+ compatible = "allwinner,app4-evb1", "allwinner,sun6i-a31";
+
+ chosen {
+ bootargs = "earlyprintk console=ttyS0,115200";
+ };
+
+ soc@01c0 {
+ pio: pinctrl@01c20800 {
+ usb1_vbus_pin_a: usb1_vbus_pin@0 {
+ allwinner,pins = "PH27";
+ allwinner,function = "gpio_out";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
+ };
+
+ usbphy: phy@01c19400 {
+ usb1_vbus-supply = <®_usb1_vbus>;
+ status = "okay";
+ };
+
+ ehci0: usb@01c1a000 {
+ status = "okay";
+ };
+
+ uart0: serial@01c28000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins_a>;
+ status = "okay";
+ };
+ };
+
+ reg_usb1_vbus: usb1-vbus {
+ pinctrl-0 = <&usb1_vbus_pin_a>;
+ gpio = <&pio 7 27 0>;
+ status = "okay";
+ };
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/7] Add Allwinner A31 USB support
Hi everyone, This patchset adds support for the USB controllers found in the Allwinner A31. While the design is similar to the earlier Allwinner SoCs that are already supported, a few details here and there change, like the fact that the PHYs now have one clock per phy, while it used to be only one for all the PHYs. Thanks, Maxime Changes from v1: - Moved the reset assertion/deassertion to probe/remove - Moved the dedicated_clocks to the probe function instead of the private structure since it was the only user Boris BREZILLON (2): usb: ehci-platform: add optional reset controller retrieval ARM: sunxi: dt: add APP4-EVB1 board support Maxime Ripard (5): clk: sunxi: Implement A31 USB clock ARM: sun6i: Add the USB clocks to the DTSI. phy: usb: sunxi: Introduce Allwinner A31 USB PHY support usb: ohci-platform: Enable optional use of reset controller ARM: sun6i: dt: Add support for the USB controllers Documentation/devicetree/bindings/usb/usb-ehci.txt | 1 + Documentation/devicetree/bindings/usb/usb-ohci.txt | 1 + arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/sun6i-a31-app4-evb1.dts | 57 ++ arch/arm/boot/dts/sun6i-a31.dtsi | 88 ++ drivers/clk/sunxi/clk-sunxi.c | 6 ++ drivers/phy/phy-sun4i-usb.c| 35 ++--- drivers/usb/host/ehci-platform.c | 18 + drivers/usb/host/ohci-platform.c | 18 + 9 files changed, 216 insertions(+), 9 deletions(-) create mode 100644 arch/arm/boot/dts/sun6i-a31-app4-evb1.dts -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 5/7] usb: ohci-platform: Enable optional use of reset controller
The OHCI controllers used in the Allwinner A31 are asserted in reset using a
global reset controller.
Add optional support for such a controller in the OHCI platform driver.
Signed-off-by: Maxime Ripard
Reviewed-by: Hans de Goede
---
Documentation/devicetree/bindings/usb/usb-ohci.txt | 1 +
drivers/usb/host/ohci-platform.c | 18 ++
2 files changed, 19 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/usb-ohci.txt
b/Documentation/devicetree/bindings/usb/usb-ohci.txt
index 45f67d91e888..b968a1aea995 100644
--- a/Documentation/devicetree/bindings/usb/usb-ohci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-ohci.txt
@@ -12,6 +12,7 @@ Optional properties:
- clocks : a list of phandle + clock specifier pairs
- phys : phandle + phy specifier pair
- phy-names : "usb"
+- resets : phandle + reset specifier pair
Example:
diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index b6002c951c5c..25073112abea 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -36,6 +37,7 @@
struct ohci_platform_priv {
struct clk *clks[OHCI_MAX_CLKS];
+ struct reset_control *rst;
struct phy *phy;
};
@@ -191,6 +193,19 @@ static int ohci_platform_probe(struct platform_device *dev)
break;
}
}
+
+ priv->rst = devm_reset_control_get_optional(&dev->dev,
+ NULL);
+ if (IS_ERR(priv->rst)) {
+ err = PTR_ERR(priv->rst);
+ if (err == -EPROBE_DEFER)
+ goto err_put_clks;
+ priv->rst = NULL;
+ } else {
+ err = reset_control_deassert(priv->rst);
+ if (err)
+ goto err_put_clks;
+ }
}
if (pdata->big_endian_desc)
@@ -266,6 +281,9 @@ static int ohci_platform_remove(struct platform_device *dev)
if (pdata->power_off)
pdata->power_off(dev);
+ if (priv->rst)
+ reset_control_assert(priv->rst);
+
for (clk = 0; clk < OHCI_MAX_CLKS && priv->clks[clk]; clk++)
clk_put(priv->clks[clk]);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 6/7] ARM: sun6i: dt: Add support for the USB controllers
The A31 has two ECHI/OHCI controllers, and one OHCI-only phy-less controller.
Signed-off-by: Maxime Ripard
Reviewed-by: Hans de Goede
---
arch/arm/boot/dts/sun6i-a31.dtsi | 77
1 file changed, 77 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 13aa56ed5858..5e9f01af6d99 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -341,6 +341,83 @@
status = "disabled";
};
+ usbphy: phy@01c19400 {
+ compatible = "allwinner,sun6i-a31-usb-phy";
+ reg = <0x01c19400 0x10>,
+ <0x01c1a800 0x4>,
+ <0x01c1b800 0x4>;
+ reg-names = "phy_ctrl",
+ "pmu1",
+ "pmu2";
+ clocks = <&usb_clk 8>,
+<&usb_clk 9>,
+<&usb_clk 10>;
+ clock-names = "usb0_phy",
+ "usb1_phy",
+ "usb2_phy";
+ resets = <&usb_clk 0>,
+<&usb_clk 1>,
+<&usb_clk 2>;
+ reset-names = "usb0_reset",
+ "usb1_reset",
+ "usb2_reset";
+ status = "disabled";
+ #phy-cells = <1>;
+ };
+
+ ehci0: usb@01c1a000 {
+ compatible = "allwinner,sun6i-a31-ehci", "generic-ehci";
+ reg = <0x01c1a000 0x100>;
+ interrupts = <0 72 4>;
+ clocks = <&ahb1_gates 26>;
+ resets = <&ahb1_rst 26>;
+ phys = <&usbphy 1>;
+ phy-names = "usb";
+ status = "disabled";
+ };
+
+ ohci0: usb@01c1a400 {
+ compatible = "allwinner,sun6i-a31-ohci", "generic-ohci";
+ reg = <0x01c1a400 0x100>;
+ interrupts = <0 73 4>;
+ clocks = <&ahb1_gates 29>, <&usb_clk 16>;
+ resets = <&ahb1_rst 29>;
+ phys = <&usbphy 1>;
+ phy-names = "usb";
+ status = "disabled";
+ };
+
+ ehci1: usb@01c1b000 {
+ compatible = "allwinner,sun6i-a31-ehci", "generic-ehci";
+ reg = <0x01c1b000 0x100>;
+ interrupts = <0 74 4>;
+ clocks = <&ahb1_gates 27>;
+ resets = <&ahb1_rst 27>;
+ phys = <&usbphy 2>;
+ phy-names = "usb";
+ status = "disabled";
+ };
+
+ ohci1: usb@01c1b400 {
+ compatible = "allwinner,sun6i-a31-ohci", "generic-ohci";
+ reg = <0x01c1b400 0x100>;
+ interrupts = <0 75 4>;
+ clocks = <&ahb1_gates 30>, <&usb_clk 17>;
+ resets = <&ahb1_rst 30>;
+ phys = <&usbphy 2>;
+ phy-names = "usb";
+ status = "disabled";
+ };
+
+ ohci2: usb@01c1c000 {
+ compatible = "allwinner,sun6i-a31-ohci", "generic-ohci";
+ reg = <0x01c1c400 0x100>;
+ interrupts = <0 77 4>;
+ clocks = <&ahb1_gates 31>, <&usb_clk 18>;
+ resets = <&ahb1_rst 31>;
+ status = "disabled";
+ };
+
pio: pinctrl@01c20800 {
compatible = "allwinner,sun6i-a31-pinctrl";
reg = <0x01c20800 0x400>;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/7] phy: usb: sunxi: Introduce Allwinner A31 USB PHY support
The USB phy controller in the A31 differs mostly from the older controllers
because it has a clock dedicated for each phy, while the older ones were having
a single clock for all the phys.
Signed-off-by: Maxime Ripard
Reviewed-by: Hans de Goede
---
drivers/phy/phy-sun4i-usb.c | 35 ++-
1 file changed, 26 insertions(+), 9 deletions(-)
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index e6e6c4ba7145..8bd89430d945 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -61,7 +61,6 @@
#define MAX_PHYS 3
struct sun4i_usb_phy_data {
- struct clk *clk;
void __iomem *base;
struct mutex mutex;
int num_phys;
@@ -71,6 +70,7 @@ struct sun4i_usb_phy_data {
void __iomem *pmu;
struct regulator *vbus;
struct reset_control *reset;
+ struct clk *clk;
int index;
} phys[MAX_PHYS];
};
@@ -146,13 +146,13 @@ static int sun4i_usb_phy_init(struct phy *_phy)
struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
int ret;
- ret = clk_prepare_enable(data->clk);
+ ret = clk_prepare_enable(phy->clk);
if (ret)
return ret;
ret = reset_control_deassert(phy->reset);
if (ret) {
- clk_disable_unprepare(data->clk);
+ clk_disable_unprepare(phy->clk);
return ret;
}
@@ -170,11 +170,10 @@ static int sun4i_usb_phy_init(struct phy *_phy)
static int sun4i_usb_phy_exit(struct phy *_phy)
{
struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
- struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
sun4i_usb_phy_passby(phy, 0);
reset_control_assert(phy->reset);
- clk_disable_unprepare(data->clk);
+ clk_disable_unprepare(phy->clk);
return 0;
}
@@ -228,8 +227,10 @@ static int sun4i_usb_phy_probe(struct platform_device
*pdev)
struct phy_provider *phy_provider;
struct reset_control *reset;
struct regulator *vbus;
+ bool dedicated_clocks;
struct resource *res;
struct phy *phy;
+ struct clk *clk;
char name[16];
int i;
@@ -249,15 +250,20 @@ static int sun4i_usb_phy_probe(struct platform_device
*pdev)
else
data->disc_thresh = 2;
+ if (of_device_is_compatible(np, "allwinner,sun6i-a31-usb-phy"))
+ dedicated_clocks = true;
+
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "phy_ctrl");
data->base = devm_ioremap_resource(dev, res);
if (IS_ERR(data->base))
return PTR_ERR(data->base);
- data->clk = devm_clk_get(dev, "usb_phy");
- if (IS_ERR(data->clk)) {
- dev_err(dev, "could not get usb_phy clock\n");
- return PTR_ERR(data->clk);
+ if (!dedicated_clocks) {
+ clk = devm_clk_get(dev, "usb_phy");
+ if (IS_ERR(clk)) {
+ dev_err(dev, "could not get usb_phy clock\n");
+ return PTR_ERR(clk);
+ }
}
/* Skip 0, 0 is the phy for otg which is not yet supported. */
@@ -270,6 +276,15 @@ static int sun4i_usb_phy_probe(struct platform_device
*pdev)
vbus = NULL;
}
+ if (dedicated_clocks) {
+ snprintf(name, sizeof(name), "usb%d_phy", i);
+ clk = devm_clk_get(dev, name);
+ if (IS_ERR(clk)) {
+ dev_err(dev, "failed to get clock %s\n", name);
+ return PTR_ERR(clk);
+ }
+ }
+
snprintf(name, sizeof(name), "usb%d_reset", i);
reset = devm_reset_control_get(dev, name);
if (IS_ERR(reset)) {
@@ -296,6 +311,7 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev)
data->phys[i].pmu = pmu;
data->phys[i].vbus = vbus;
data->phys[i].reset = reset;
+ data->phys[i].clk = clk;
data->phys[i].index = i;
phy_set_drvdata(phy, &data->phys[i]);
}
@@ -311,6 +327,7 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev)
static const struct of_device_id sun4i_usb_phy_of_match[] = {
{ .compatible = "allwinner,sun4i-a10-usb-phy" },
{ .compatible = "allwinner,sun5i-a13-usb-phy" },
+ { .compatible = "allwinner,sun6i-a31-usb-phy" },
{ .compatible = "allwinner,sun7i-a20-usb-phy" },
{ },
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: vmstat: On demand vmstat workers V4
On Sat, May 10, 2014 at 02:31:28PM +0200, Thomas Gleixner wrote: > On Sat, 10 May 2014, Frederic Weisbecker wrote: > > But I still have the plan to make the timekeeper use the full sysidle > > facility in order to adaptively get to dynticks idle. > > > > Reminder for others: in NO_HZ_FULL, the timekeeper (always CPU 0) stays > > completely periodic. It can't enter in dynticks idle mode because it > > must maintain timekeeping on behalf of full dynticks CPUs. So that's > > a power issue. > > > > But Paul has a feature in RCU that lets us know when all CPUs are idle > > and the timekeeper can finally sleep. Then when a full nohz CPU wakes > > up from idle, it sends an IPI to the timekeeper if needed so the latter > > restarts timekeeping maintainance. > > > > It's not complicated to add to the timer code. > > Most of the code is already there, in RCU, for a while already. > > > > Are we keeping that direction? > > So the idea is that the timekeeper stays on cpu0, but if everything is > idle it is allowed to take a long nap as well. So if some other cpu > wakes up it updates timekeeping without taking over the time keeper > duty and if it has work to do, it kicks cpu0 into gear. If it just > goes back to sleep, then nothing to do. Exactly! Except perhaps the last sentence "If it just goes back to sleep, then nothing to do.", I didn't think about that although this special case is quite frequent indeed when an interrupt fires on idle but no task is woken up. Maybe I should move the code that fires the IPI to cpu0, if it is sleeping, on irq exit (the plan was to do it right away on irq enter) and fire it only if need_resched(). > > No objections from my side. Great! Thanks for checking that! > > Thanks, > > tglx > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 06/19] qspinlock: prolong the stay in the pending bit path
On Fri, May 09, 2014 at 08:58:47PM -0400, Waiman Long wrote:
> On 05/08/2014 02:58 PM, Peter Zijlstra wrote:
> >On Wed, May 07, 2014 at 11:01:34AM -0400, Waiman Long wrote:
> >>@@ -221,11 +222,37 @@ static inline int trylock_pending(struct qspinlock
> >>*lock, u32 *pval)
> >> */
> >>for (;;) {
> >>/*
> >>-* If we observe any contention; queue.
> >>+* If we observe that the queue is not empty,
> >>+* return and be queued.
> >> */
> >>- if (val& ~_Q_LOCKED_MASK)
> >>+ if (val& _Q_TAIL_MASK)
> >>return 0;
> >>
> >>+ if (val == (_Q_LOCKED_VAL|_Q_PENDING_VAL)) {
> >>+ /*
> >>+* If both the lock and pending bits are set, we wait
> >>+* a while to see if that either bit will be cleared.
> >>+* If that is no change, we return and be queued.
> >>+*/
> >>+ if (!retry)
> >>+ return 0;
> >>+ retry--;
> >>+ cpu_relax();
> >>+ cpu_relax();
> >>+ *pval = val = atomic_read(&lock->val);
> >>+ continue;
> >>+ } else if (val == _Q_PENDING_VAL) {
> >>+ /*
> >>+* Pending bit is set, but not the lock bit.
> >>+* Assuming that the pending bit holder is going to
> >>+* set the lock bit and clear the pending bit soon,
> >>+* it is better to wait than to exit at this point.
> >>+*/
> >>+ cpu_relax();
> >>+ *pval = val = atomic_read(&lock->val);
> >>+ continue;
> >>+ }
> >Didn't I give a much saner alternative to this mess last time?
>
> I don't recall you have any suggestion last time. Anyway, if you think the
> code is too messy, I think I can give up the first if statement which is
> more an optimistic spinning kind of code for short critical section. The 2nd
> if statement is still need to improve chance of using this code path due to
> timing reason. I will rerun my performance test to make sure it won't have
> too much performance impact.
lkml.kernel.org/r/20140417163640.gt11...@twins.programming.kicks-ass.net
pgpB9A7nPwpN3.pgp
Description: PGP signature
Re: Question: hwmon: Adding addtitional sysfs entries
On Sat, May 10, 2014 at 05:32:13AM -0700, Guenter Roeck wrote: > On 05/10/2014 06:22 AM, Andreas Werner wrote: > >Hi, > >i am currently working on an implemenation of my Board Management Controller > >(BMC). > > > >This Controller is a MCR assembled on almost all of our Compact PCI or > >Compact PCI Serial > >Cards as well as on some other CPU Boards. > > > >The BMC includes LED´s, Watchdog, Voltage Monitoring and some other features. > >I have already implemented an MFD driver, LED and Watchdog driver. > > > >Currently i am working on the hwmon implemenation. This includes for the > >first step the > >voltage monitoring. > > > >The BMC has some other feature which are not supported by any of the > >subsystem. > > - Errorcounter (Board status) > > - Power Failure status > > - Operating ours > > Guess you mean hours here. Yes sorry my mistake. > > > - Do software reset, do cold reset > > - Set power modes > > - Backplate Geographical Address > > > >These are all informations related to the Board where the BMC is assembled > >to. > >I think all those features could be part of the hwmon implementation. > > > Why ? As all of the settings are CPU board related i thought it will be an good idea to put as much settings as possible to a group to one subsystem. This would be easier for the User Application. > > >Is it possible to add "custom" sysfs entries in my hwmon driver to support > >all these features? > >Does lm-sensor ingore those custom features or is it a problem for > >lm-sensors? > > > >What is the normal way to add those features? > > > > The hwmon subsystem isn't really the correct location for this functionality. > Power management should be done with a regulator driver (possibly power). > The other attributes and functionality would better fit into the mfd core > driver. > MFD Core sounds good. That is also perfect for the User App. > You might want to tie the reset functions into the system reset functionality. I do not understand this. Is there another subsystem or something like that were I can put the Reset stuff to? > > Guenter > I guess the hwmon subsys is the right place for the voltage monitoring (3,3V, 5V etc) isn´t it? Regards Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Add lib/glob.c
Thanks a lot for the feedback!
> On Fri, May 09, 2014 at 11:13:56PM -0400, George Spelvin wrote:
>> +/**
>> + * glob_match - Shell-style pattern matching, like !fnmatch(pat, str, 0)
>> + * @pat: Pattern to match. Metacharacters are ?, *, [ and \.
>> + * (And, inside character classes, !, - and ].)
> @ARG lines should be contained in a single line. Just "Pattern to
> match." should do. With detailed description in the body.
Huh, Documentation/kernel-doc-nano-HOWTO.txt (lines 57-59, to be precise)
implies otherwise pretty strongly. But I can certainly change it.
> Just adding glob.o to lib-y should be enough. It will be excluded
> from linking if unused.
Will that work right if the caller is a module? What will it get linked
into, the main kernel binary or the module?
A significant and very helpful simplification; I just want to be sure
it works right.
>> +#ifdef UNITTEST
>> +/* To do a basic sanity test, "cc -DUNITTEST glob.c" and run a.out. */
>> +
>> +#include
>> +#define __pure __attribute__((pure))
>> +#define NOP(x)
>> +#define EXPORT_SYMBOL NOP /* Two stages to avoid checkpatch complaints */
> These things tend to bitrot. Let's please keep testing harness out of
> tree.
Damn, when separated it bitrots a lot faster. That's *is* my testing
harness, and I wanted to keep it close so it has a chance on hell of
being used by someone who updates it.
Especially given that the function's interface is quite rigidly defined,
do you really think there will be a lot of rot?
> Do we make library routines separate modules usually?
A large number of files in lib/ are implemented that way (lib/crc-ccitt.c,
just for one example), and that's what I copied. But if I just do the
obj-y thing, all that goes away
>> +bool __pure
>> +glob_match(char const *pat, char const *str)
>
> The whole thing fits in a single 80 column line, right?
>
> bool __pure glob_match(char const *pat, char const *str)
Whoops, a residue of my personal code style. (I like to left-align
function names in definitions so they're easy to search for with ^func.)
But it's not kernel style. Will fix.
>> +{
>> +/*
>> + * Backtrack to previous * on mismatch and retry starting one
>> + * character later in the string. Because * matches all characters
>> + * (no exception for /), it can be easily proved that there's
>> + * never a need to backtrack multiple levels.
>> + */
>> +char const *back_pat = 0, *back_str = back_str;
> Blank line here.
I had considered the "/*" start of the following block comment as visually
enough separation between variable declarations and statements, but sure,
I can add one.
> I haven't delved into the actual implementation. Looks sane on the
> first glance.
That's the part I'm least worried about, actually.
> Again, I don't really think the userland testing code belongs here.
> If you want to keep them, please make it in-kernel selftesting. We
> don't really want to keep code which can't get built and tested in
> kernel tree proper.
I'll see if I can figure out how to do that. Simple as it is, I hate to
throw away regression tests.
Thank you very much.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 09/19] qspinlock: Prepare for unfair lock support
On Fri, May 09, 2014 at 09:19:32PM -0400, Waiman Long wrote: > On 05/08/2014 03:06 PM, Peter Zijlstra wrote: > >On Wed, May 07, 2014 at 11:01:37AM -0400, Waiman Long wrote: > >>If unfair lock is supported, the lock acquisition loop at the end of > >>the queue_spin_lock_slowpath() function may need to detect the fact > >>the lock can be stolen. Code are added for the stolen lock detection. > >> > >>A new qhead macro is also defined as a shorthand for mcs.locked. > >NAK, unfair should be a pure test-and-set lock. > > I have performance data showing that a simple test-and-set lock does not > scale well. That is the primary reason of ditching the test-and-set lock and > use a more complicated scheme which scales better. Nobody should give a fuck about scalability in this case anyway. Also, as I explained/asked earlier: lkml.kernel.org/r/20140314083001.gn27...@twins.programming.kicks-ass.net Lock holder preemption is _way_ worse with any kind of queueing. You've not explained how the simple 3 cpu example in that email gets better performance than a test-and-set lock. > Also, it will be hard to > make the unfair test-and-set lock code to coexist nicely with PV spinlock > code. That's just complete crap as the test-and-set lock is like 3 lines of code. pgpgcDUtIdmd0.pgp Description: PGP signature
Re: [PATCH v10 08/19] qspinlock: Make a new qnode structure to support virtualization
On Fri, May 09, 2014 at 09:08:56PM -0400, Waiman Long wrote:
> On 05/08/2014 03:04 PM, Peter Zijlstra wrote:
> >On Wed, May 07, 2014 at 11:01:36AM -0400, Waiman Long wrote:
> >> /*
> >>+ * To have additional features for better virtualization support, it is
> >>+ * necessary to store additional data in the queue node structure. So
> >>+ * a new queue node structure will have to be defined and used here.
> >>+ */
> >>+struct qnode {
> >>+ struct mcs_spinlock mcs;
> >>+};
> >You can ditch this entire patch; its pointless, just add a new
> >DEFINE_PER_CPU for the para-virt muck.
>
> Yes, I can certainly merge it to the next one in the series. I break it out
> to make each individual patch smaller, more single-purpose and easier to
> review.
No, don't merge it, _drop_ it. Wrapping things in a struct generates a
ton of pointless change.
Put the new data in a new DEFINE_PER_CPU and leave the existing code as
is.
pgplnqXGbsIPK.pgp
Description: PGP signature
Re: [PATCH v2 00/15] PCI/iommu: Fix DMA alias problems
On Sat, 2014-05-10 at 10:08 -0400, George Spelvin wrote: > > What's the device ID of these devices? > > Oops! It's > > 05:00.0 SATA controller [0106]: Marvell Technology Group Ltd. 88SE9172 SATA > 6Gb/s Controller [1b4b:9172] (rev 11) > 06:00.0 SATA controller [0106]: Marvell Technology Group Ltd. 88SE9172 SATA > 6Gb/s Controller [1b4b:9172] (rev 11) > 07:00.0 SATA controller [0106]: Marvell Technology Group Ltd. 88SE9172 SATA > 6Gb/s Controller [1b4b:9172] (rev 11) > > > The dma-alias branch only has the v1 patchset. There are several more > > Marvell devices included in the quirks in the v2 set. Please re-test > > with this code. Thanks, > > Oh, okay! I got the patches from github because it was a lot easier > to get the whole set that way. (I don't actually have an SMTP LKML > subscription, so I have to copy them all from a web archive, then > manually edit the headers into something RFC822-like enough for "git am" > to accept.) > > Mea culpa for forgetting to check the version. And thank you for the > response! Hi George, I'll post a v3 soon, I think we figured out the problem Andrew was having, a couple typos on my part. I'll push out a new branch for that so you don't need to piece it together yourself. Thanks, Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/6] usb: host: Cleanup for ioremap'ing hcd memory
Sat, 10 May 2014 17:30:04 +0530 от Vivek Gautam : > Based on 'usb-next' branch of Greg's usb tree. > > devm_ioremap_resource() API is advantageous over devm_ioremap() > and should therefore be preferred to request any ioremap'ed address > for hcd. > > Changes from v1: > - Changed the way returned pointer is checked for error value >as pointed out in the review comment in the mailing list. hcd->rsrc_len field can be removed entirely, since I cannot find any reason how this filed can be used in the drivers now. This is of course should be in an another series. This one looks good. ---
Re: [PATCH v2 4/7] usb: ehci-platform: add optional reset controller retrieval
On Sat, 10 May 2014, Maxime Ripard wrote:
> From: Boris BREZILLON
>
> On the Allwinner's A31 SoC the reset line connected to the EHCI IP has to
> be deasserted for the EHCI block to be usable.
>
> Add support for an optional reset controller that will be deasserted on
> power off and asserted on power on.
>
> Signed-off-by: Boris BREZILLON
> Signed-off-by: Maxime Ripard
> Reviewed-by: Hans de Goede
This basically is good. fine. I have only two comments, and one of
them is a matter of taste rather than substance.
> @@ -206,6 +208,19 @@ static int ehci_platform_probe(struct platform_device
> *dev)
> break;
> }
> }
> +
> + priv->rst = devm_reset_control_get_optional(&dev->dev,
> + NULL);
I hate the style that matches arguments on a continuation line with the
opening paren of the function call, for a couple of reasons. Instead I
simply indent continuation lines by two or more tab stops. But some
people seem to be incurably attached to it.
> + if (IS_ERR(priv->rst)) {
> + err = PTR_ERR(priv->rst);
> + if (err == -EPROBE_DEFER)
> + goto err_put_clks;
> + priv->rst = NULL;
> + } else {
> + err = reset_control_deassert(priv->rst);
> + if (err)
> + goto err_put_clks;
> + }
> }
>
> if (pdata->big_endian_desc)
The new code was added inside an "if" statement, which will cause it to
apply only to OF devices. Is there any reason not to put the new code
outside the "if" statement, so it applies to all devices?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix missing a blank line after declaration for usbip
Hi,
Please find attached patch which fixes most of
"Missing blank line after declaration" in drivers/staging/usbip
directory.
There are still two WARNINGS reported which refers to the struct
declaration, and it seems to be a problem with the checkpatck.pl script.
Regards
Pawel Lebioda
>From 6fba281794ce0466e88c785123f906b7d3654bc2 Mon Sep 17 00:00:00 2001
From: Pawel Lebioda
Date: Sat, 10 May 2014 16:35:50 +0200
Subject: [PATCH] Fix missing a blank line after declaration for usbip
---
drivers/staging/usbip/stub_dev.c | 1 +
drivers/staging/usbip/stub_tx.c | 1 +
drivers/staging/usbip/usbip_common.h | 2 ++
drivers/staging/usbip/userspace/libsrc/usbip_common.c | 2 +-
drivers/staging/usbip/userspace/src/usbip_attach.c| 1 +
drivers/staging/usbip/userspace/src/usbipd.c | 6 +-
drivers/staging/usbip/vhci_hcd.c | 2 ++
7 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/usbip/stub_dev.c b/drivers/staging/usbip/stub_dev.c
index de692d7..51d0c71 100644
--- a/drivers/staging/usbip/stub_dev.c
+++ b/drivers/staging/usbip/stub_dev.c
@@ -99,6 +99,7 @@ static ssize_t store_sockfd(struct device *dev, struct device_attribute *attr,
if (sockfd != -1) {
int err;
+
dev_info(dev, "stub up\n");
spin_lock_irq(&sdev->ud.lock);
diff --git a/drivers/staging/usbip/stub_tx.c b/drivers/staging/usbip/stub_tx.c
index 1622563..38fe551 100644
--- a/drivers/staging/usbip/stub_tx.c
+++ b/drivers/staging/usbip/stub_tx.c
@@ -218,6 +218,7 @@ static int stub_send_ret_submit(struct stub_device *sdev)
*/
int i;
+
for (i = 0; i < urb->number_of_packets; i++) {
iov[iovnum].iov_base = urb->transfer_buffer +
urb->iso_frame_desc[i].offset;
diff --git a/drivers/staging/usbip/usbip_common.h b/drivers/staging/usbip/usbip_common.h
index f555d83..4da3866 100644
--- a/drivers/staging/usbip/usbip_common.h
+++ b/drivers/staging/usbip/usbip_common.h
@@ -321,12 +321,14 @@ int usbip_event_happened(struct usbip_device *ud);
static inline int interface_to_busnum(struct usb_interface *interface)
{
struct usb_device *udev = interface_to_usbdev(interface);
+
return udev->bus->busnum;
}
static inline int interface_to_devnum(struct usb_interface *interface)
{
struct usb_device *udev = interface_to_usbdev(interface);
+
return udev->devnum;
}
diff --git a/drivers/staging/usbip/userspace/libsrc/usbip_common.c b/drivers/staging/usbip/userspace/libsrc/usbip_common.c
index 238bf5b..05a7443 100644
--- a/drivers/staging/usbip/userspace/libsrc/usbip_common.c
+++ b/drivers/staging/usbip/userspace/libsrc/usbip_common.c
@@ -75,6 +75,7 @@ const char *usbip_speed_string(int num)
void dump_usb_interface(struct usbip_usb_interface *uinf)
{
char buff[100];
+
usbip_names_get_class(buff, sizeof(buff),
uinf->bInterfaceClass,
uinf->bInterfaceSubClass,
@@ -86,7 +87,6 @@ void dump_usb_device(struct usbip_usb_device *udev)
{
char buff[100];
-
dbg("%-20s = %s", "path", udev->path);
dbg("%-20s = %s", "busid", udev->busid);
diff --git a/drivers/staging/usbip/userspace/src/usbip_attach.c b/drivers/staging/usbip/userspace/src/usbip_attach.c
index 716a79e..d58a14d 100644
--- a/drivers/staging/usbip/userspace/src/usbip_attach.c
+++ b/drivers/staging/usbip/userspace/src/usbip_attach.c
@@ -56,6 +56,7 @@ static int record_connection(char *host, char *port, char *busid, int rhport)
/* if VHCI_STATE_PATH exists, then it better be a directory */
if (errno == EEXIST) {
struct stat s;
+
ret = stat(VHCI_STATE_PATH, &s);
if (ret < 0)
return -1;
diff --git a/drivers/staging/usbip/userspace/src/usbipd.c b/drivers/staging/usbip/userspace/src/usbipd.c
index 2cae4ce..b32047a 100644
--- a/drivers/staging/usbip/userspace/src/usbipd.c
+++ b/drivers/staging/usbip/userspace/src/usbipd.c
@@ -372,6 +372,7 @@ static int listen_all_addrinfo(struct addrinfo *ai_head, int sockfdlist[],
for (ai = ai_head; ai && nsockfd < maxsockfd; ai = ai->ai_next) {
int sock;
+
addrinfo_to_text(ai, ai_buf, ai_buf_size);
dbg("opening %s", ai_buf);
sock = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol);
@@ -461,7 +462,9 @@ static void write_pid_file()
{
if (pid_file) {
dbg("creating pid file %s", pid_file);
- FILE *fp = fopen(pid_file, "w");
+ FILE *fp;
+
+ fp = fopen(pid_file, "w");
if (!fp) {
err("pid_file: %s: %d (%s)",
pid_file, errno, strerror(errno));
@@ -602,6 +605,7 @@ int main(int argc, char *argv[])
int daemonize = 0;
int ipv4 = 0, ipv6 = 0;
int opt, rc = -1;
+
pid_file = NULL;
usbip_use_stderr = 1;
diff --git a/drivers/staging/usbip/vhci_hcd.c b/drivers/staging/usbip/vhci_hcd.c
index 70e1755..0007d30 100644
--- a/drivers/staging/usbip/vhci_hcd.c
+++ b/drivers/staging/usbip/vhci_hcd.c
@@ -635,6 +635,7 @@ static int vhci_urb_dequeue(struct usb_hcd *hcd, struct urb *urb, int status)
{
int ret = 0;
+
ret = usb_hcd_check_unlink_
Re: [PATCH V2 1/6] namespaces: assign each namespace instance a serial number
On Fri, 2014-05-09 at 20:27 -0400, Richard Guy Briggs wrote:
> Generate and assign a serial number per namespace instance since boot.
>
> Use a serial number per namespace (unique across one boot of one kernel)
> instead of the inode number (which is claimed to have had the right to change
> reserved and is not necessarily unique if there is more than one proc fs) to
> uniquely identify it per kernel boot.
>
> Signed-off-by: Richard Guy Briggs
> ---
> +/**
> + * ns_serial - compute a serial number for the namespace
> + *
> + * Compute a serial number for the namespace to uniquely identify it in
> + * audit records.
> + */
> +unsigned long long ns_serial(void)
> +{
> + static DEFINE_SPINLOCK(serial_lock);
> + static unsigned long long serial = 4; /* reserved for IPC, UTS, user,
> PID */
> + unsigned long flags;
> +
> + spin_lock_irqsave(&serial_lock, flags);
> + ++serial;
> + spin_unlock_irqrestore(&serial_lock, flags);
> + BUG_ON(!serial);
> +
> + return serial;
> +}
> +
> static inline struct nsproxy *create_nsproxy(void)
> {
> struct nsproxy *nsproxy;
atomic64_t instead of doing it yourself?
and why _irqsave() ? Can we seriously create new namespaces in irq
context? If you use the atomic though, you don't have to worry about
it...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 03/15] PCI: quirk dma_func_alias for Ricoh devices
The existing quirk for these devices doesn't really solve the problem,
re-implement it using the DMA alias iterator. We'll come back later
and remove the existing quirk and dma_source interface. Note that
device ID 0xe822 is typically function 0 and 0xe230 has been tested
to not need the quirk and are therefore removed versus the equivalent
dma_source quirk. If the exist in other configurations we can re-add
them.
Signed-off-by: Alex Williamson
---
drivers/pci/quirks.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index e729206..ea2cb9f 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -,6 +,20 @@ int pci_dev_specific_reset(struct pci_dev *dev, int
probe)
return -ENOTTY;
}
+static void quirk_dma_func0_alias(struct pci_dev *dev)
+{
+ if (PCI_FUNC(dev->devfn) != 0)
+ dev->dma_func_alias |= (1 << 0);
+}
+
+/*
+ * https://bugzilla.redhat.com/show_bug.cgi?id=605888
+ *
+ * Some Ricoh devices use function 0 as the PCIe requester ID for DMA.
+ */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_RICOH, 0xe832, quirk_dma_func0_alias);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_RICOH, 0xe476, quirk_dma_func0_alias);
+
static struct pci_dev *pci_func_0_dma_source(struct pci_dev *dev)
{
if (!PCI_FUNC(dev->devfn))
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 00/15] PCI/iommu: Fix DMA alias problems
This version can be found in my git tree: git://github.com/awilliam/linux-vfio.git dma-alias-v3 Please report any issues. v3: - Found several instances where I had PCI_SLOT when I meant PCI_FUNC. Thanks to Andrew for spotting this. This should fix the problem he was having with Ricoh quirks. We also pruned down the func0 quirks to only those that we know are needed. We can always add them back later. - Found a case in intel-iommu of using dev_is_pci() where I really wanted !dev_is_pci(). Fixed. v2: - Several new Marvell controllers added to quirks. There's been a lot of success reported with this series in https://bugzilla.kernel.org/show_bug.cgi?id=42679 - Add quirk for ASMedia and Tundra PCIe-to-PCI bridges that do not expose a PCIe capability. These have been shown to use the standard PCIe-to-PCI bridge requester ID. - Fix copy/paste duplicate Ricoh quirk ID - Fixed AMD IOMMU for the "ghost" function case where the DMA alias is for an absent device. The iommu rlookup table and data fields need to be initializes. - Fixed Intel interrupt remapping, I wasn't passing the target bus number, only the alias bus number. These patches are split across PCI and IOMMU, but I've front-loaded all of the PCI infrastructure so that the first 7 patches can be applied to PCI-core, the IOMMU maintainers can pickup their patches, then we can finish with dead code removal. Bjorn might also be willing to carry the IOMMU changes if the maintainers want to ack them. Original description: This series attempts to fix a couple issues we've had outstanding in the PCI/IOMMU code for a while. The first issue is with devices that use the wrong requester ID for DMA transactions. We already have a sort of half-baked attempt to fix this for several Ricoh devices, but the fix only helps them be useful through IOMMU groups, not the general DMA case. There are also several Marvell devices which use use a different wrong requester ID and don't even fit into the DMA source idea. This series creates a DMA alias iterator that will step through each possible alias of a device, allowing IOMMUs to insert mappings for both the device and its aliases. Hand-in-hand with this is our broken pci_find_upstream_pcie_bridge() function, which is known to blowup when it finds itself suddenly at a PCIe device without crossing a PCIe-to-PCI bridge (as identified by the PCIe capability). It also likes to make the invalid assumption that a PCIe device never has its requester ID masked by any usptream bus. We can fix this using the above new DMA alias iterator, since that's effectively what this function was meant to do. Finally, with all these helpers, it makes sense to consolidate code for determining IOMMU groups. The first step in finding the root of a group is finding the final upstream DMA alias for the device, then applying additional ACS rules and incorporating device specific aliases. As this is all common to PCI, create a single implementation and remove piles of code from the individual IOMMU drivers. This series allows devices like the Marvell 88SE9123 to finally work on Linux with either AMD-Vi or VT-d enabled on the box. I've collected device IDs from various bugs to support as many SKUs of these devices as possible, but I'm sure there are others that I've missed. This should also enable motherboards with an onboard ASmedia ASM1083/1085 PCIe-to-PCI bridge to work with VT-d enabled. I've acquired an adapter board with this chip, but it actually exposes a PCIe capability, unlike most of the onboard controllers. Therefore I expect this series will fix the WARN_ON currently hit during boot, but there's a 50/50 chance whether the device behaves like a PCI bridge or a PCIe bridge with regard to the requester ID that it uses to take ownership of the transaction. If it turns out to use the PCIe bridge model, I expect we can quirk it using a dev_flags bit to identify a PCI bridge that takes ownership as if it was a PCIe bridge. Please test and provide feedback. I expect IOMMU group topology should not change from this series, but if a case is found where it does, please share. Also, if there are additional quirks we need to add, please either file new or add to the existing bugs. Thanks, Alex --- Alex Williamson (15): PCI: Add DMA alias iterator PCI: quirk pci_for_each_dma_alias() PCI: quirk dma_func_alias for Ricoh devices PCI: quirk dma_func_alias for Marvell devices PCI: Quirk pci_for_each_dma_alias() for bridges PCI: Add quirks for ASMedia and Tundra bridges PCI: Consolidate isolation domain code iommu/amd: Use pci_find_dma_isolation_root() for IOMMU groups iommu/amd: Update to use PCI DMA aliases iommu/intel: Use pci_find_dma_isolation_root() for IOMMU groups iommu/intel: Update to use PCI DMA aliases iommu/fsl: Use pci_find_dma_isolation_root() for IOMMU groups iommu: Remove pci.h PC
[PATCH v3 04/15] PCI: quirk dma_func_alias for Marvell devices
Several Marvell devices and a JMicron device have a similar DMA
requester ID problem to Ricoh, except they use function 1 as the
PCIe requester ID. Add a quirk for these to populate the DMA
function alias bitmap.
Signed-off-by: Alex Williamson
---
drivers/pci/quirks.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index ea2cb9f..c6ae46f 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3347,6 +3347,40 @@ static void quirk_dma_func0_alias(struct pci_dev *dev)
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_RICOH, 0xe832, quirk_dma_func0_alias);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_RICOH, 0xe476, quirk_dma_func0_alias);
+static void quirk_dma_func1_alias(struct pci_dev *dev)
+{
+ if (PCI_FUNC(dev->devfn) != 1)
+ dev->dma_func_alias |= (1 << 1);
+}
+
+/*
+ * Marvell 88SE9123 uses function 1 as the requester ID for DMA. In some
+ * SKUs function 1 is present and is a legacy IDE controller, in other
+ * SKUs this function is not present, making this a ghost requester.
+ * https://bugzilla.kernel.org/show_bug.cgi?id=42679
+ */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x9123,
+quirk_dma_func1_alias);
+/* https://bugzilla.kernel.org/show_bug.cgi?id=42679#c14 */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x9130,
+quirk_dma_func1_alias);
+/* https://bugzilla.kernel.org/show_bug.cgi?id=42679#c47 + c57 */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x9172,
+quirk_dma_func1_alias);
+/* https://bugzilla.kernel.org/show_bug.cgi?id=42679#c59 */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x917a,
+quirk_dma_func1_alias);
+/* https://bugzilla.kernel.org/show_bug.cgi?id=42679#c46 */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x91a0,
+quirk_dma_func1_alias);
+/* https://bugzilla.kernel.org/show_bug.cgi?id=42679#c49 */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x9230,
+quirk_dma_func1_alias);
+/* https://bugs.gentoo.org/show_bug.cgi?id=497630 */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_JMICRON,
+PCI_DEVICE_ID_JMICRON_JMB388_ESD,
+quirk_dma_func1_alias);
+
static struct pci_dev *pci_func_0_dma_source(struct pci_dev *dev)
{
if (!PCI_FUNC(dev->devfn))
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 05/15] PCI: Quirk pci_for_each_dma_alias() for bridges
Several PCIe-to-PCI bridges fail to provide a PCIe capability, causing
us to handle them as conventional PCI devices. In some cases, this
may be correct, in others it's not. Add a dev_flag bit to identify
devices to be handled as standard PCIe-to-PCI bridges.
Signed-off-by: Alex Williamson
---
drivers/pci/search.c | 10 --
include/linux/pci.h |2 ++
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/search.c b/drivers/pci/search.c
index ad698b2..dab4561 100644
--- a/drivers/pci/search.c
+++ b/drivers/pci/search.c
@@ -98,8 +98,14 @@ int pci_for_each_dma_alias(struct pci_dev *pdev,
continue;
}
} else {
- ret = fn(tmp, PCI_DEVID(tmp->bus->number, tmp->devfn),
-data);
+ if (tmp->dev_flags & PCI_DEV_FLAG_PCIE_BRIDGE_ALIAS)
+ ret = fn(tmp,
+PCI_DEVID(tmp->subordinate->number,
+ PCI_DEVFN(0, 0)), data);
+ else
+ ret = fn(tmp,
+PCI_DEVID(tmp->bus->number,
+ tmp->devfn), data);
if (ret)
return ret;
}
diff --git a/include/linux/pci.h b/include/linux/pci.h
index b4c97d2..31d9a90 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -171,6 +171,8 @@ enum pci_dev_flags {
PCI_DEV_FLAGS_ASSIGNED = (__force pci_dev_flags_t) 4,
/* Flag for quirk use to store if quirk-specific ACS is enabled */
PCI_DEV_FLAGS_ACS_ENABLED_QUIRK = (__force pci_dev_flags_t) 8,
+ /* DMA alias the device as if it was a PCIe-to-PCI bridge */
+ PCI_DEV_FLAG_PCIE_BRIDGE_ALIAS = (__force pci_dev_flags_t) 16,
};
enum pci_irq_reroute_variant {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 02/15] PCI: quirk pci_for_each_dma_alias()
There are a few broken devices that use the requester ID of a different
function in the slot for their DMA. To handle these, add a bitmap to
struct pci_dev (using an alignment gap) that quirks can populate. As
we iterate over the device and bus DMA aliases, also iterate over any
bits in the map.
Signed-off-by: Alex Williamson
---
drivers/pci/search.c | 21 +
include/linux/pci.h |2 ++
2 files changed, 23 insertions(+)
diff --git a/drivers/pci/search.c b/drivers/pci/search.c
index 5601cdb..ad698b2 100644
--- a/drivers/pci/search.c
+++ b/drivers/pci/search.c
@@ -37,6 +37,27 @@ int pci_for_each_dma_alias(struct pci_dev *pdev,
if (ret)
return ret;
+ /*
+* dma_func_alias provides a bitmap of other function numbers on
+* this same PCI slot to use as DMA aliases.
+*/
+ if (unlikely(pdev->dma_func_alias)) {
+ u8 map = pdev->dma_func_alias & ~(1 << PCI_FUNC(pdev->devfn));
+ int func;
+
+ for (func = 0; map && func < 8; func++, map >>= 1) {
+ if (!(map & 1))
+ continue;
+
+ ret = fn(pdev,
+PCI_DEVID(pdev->bus->number,
+ PCI_DEVFN(PCI_SLOT(pdev->devfn),
+ func)), data);
+ if (ret)
+ return ret;
+ }
+ }
+
for (bus = pdev->bus; !pci_is_root_bus(bus); bus = bus->parent) {
struct pci_dev *tmp;
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 14b074b..b4c97d2 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -268,6 +268,8 @@ struct pci_dev {
u8 rom_base_reg; /* which config register controls the
ROM */
u8 pin;/* which interrupt pin this device uses
*/
u16 pcie_flags_reg; /* cached PCIe Capabilities Register */
+ u8 dma_func_alias; /* bitmap of functions used as DMA
+ aliases for this device */
struct pci_driver *driver; /* which driver has allocated this
device */
u64 dma_mask; /* Mask of the bits of bus address this
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
