[PATCH 6/9] clk: samsung: exynos5433: Add clocks for CMU_ISP domain
This patch adds the mux/divider/gate clocks for CMU_ISP domain which
generates the clocks for FIMC-ISP/DRC/SCLC/DIS/3DNR IPs.
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Cc: Tomasz Figa tomasz.f...@gmail.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Inki Dae inki@samsung.com
---
.../devicetree/bindings/clock/exynos5433-clock.txt | 8 +
drivers/clk/samsung/clk-exynos5433.c | 267 +
include/dt-bindings/clock/exynos5433.h | 89 ++-
3 files changed, 363 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
index 10908d2..ae97a77 100644
--- a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
@@ -43,6 +43,8 @@ Required Properties:
which generates clocks for MFC(Multi-Format Codec) IP.
- samsung,exynos5433-cmu-hevc - clock controller compatible for CMU_HEVC
which generates clocks for HEVC(High Efficiency Video Codec) decoder IP.
+ - samsung,exynos5433-cmu-isp - clock controller compatible for CMU_ISP
+which generates clocks for FIMC-ISP/DRC/SCLC/DIS/3DNR IPs.
- reg: physical base address of the controller and length of memory mapped
region.
@@ -172,6 +174,12 @@ Example 1: Examples of clock controller nodes are listed
below.
#clock-cells = 1;
};
+ cmu_isp: clock-controller@146d {
+ compatible = samsung,exynos5433-cmu-isp;
+ reg = 0x146d 0x0b0c;
+ #clock-cells = 1;
+ };
+
Example 2: UART controller node that consumes the clock generated by the clock
controller.
diff --git a/drivers/clk/samsung/clk-exynos5433.c
b/drivers/clk/samsung/clk-exynos5433.c
index 1c2e5c8..04a6089 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -404,6 +404,12 @@ static struct samsung_mux_clock top_mux_clks[] __initdata
= {
};
static struct samsung_div_clock top_div_clks[] __initdata = {
+ /* DIV_TOP0 */
+ DIV(CLK_DIV_ACLK_ISP_DIS_400, div_aclk_isp_dis_400,
+ mout_aclk_isp_dis_400, DIV_TOP0, 4, 4),
+ DIV(CLK_DIV_ACLK_ISP_400, div_aclk_isp_400,
+ mout_aclk_isp_400, DIV_TOP0, 0, 4),
+
/* DIV_TOP1 */
DIV(CLK_DIV_ACLK_GSCL_111, div_aclk_gscl_111, mout_aclk_gscl_333,
DIV_TOP1, 28, 3),
@@ -560,6 +566,12 @@ static struct samsung_gate_clock top_gate_clks[]
__initdata = {
GATE(CLK_ACLK_GSCL_333, aclk_gscl_333, div_aclk_gscl_333,
ENABLE_ACLK_TOP, 14,
CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_ACLK_ISP_DIS_400, aclk_isp_dis_400, div_aclk_isp_dis_400,
+ ENABLE_ACLK_TOP, 7,
+ CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_ACLK_ISP_400, aclk_isp_400, div_aclk_isp_400,
+ ENABLE_ACLK_TOP, 6,
+ CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
GATE(CLK_ACLK_HEVC_400, aclk_hevc_400, div_aclk_hevc_400,
ENABLE_ACLK_TOP, 5,
CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
@@ -4218,3 +4230,258 @@ static void __init exynos5433_cmu_hevc_init(struct
device_node *np)
}
CLK_OF_DECLARE(exynos5433_cmu_hevc, samsung,exynos5433-cmu-hevc,
exynos5433_cmu_hevc_init);
+
+/*
+ * Register offset definitions for CMU_ISP
+ */
+#define MUX_SEL_ISP0x0200
+#define MUX_ENABLE_ISP 0x0300
+#define MUX_STAT_ISP 0x0400
+#define DIV_ISP0x0600
+#define DIV_STAT_ISP 0x0700
+#define ENABLE_ACLK_ISP0 0x0800
+#define ENABLE_ACLK_ISP1 0x0804
+#define ENABLE_ACLK_ISP2 0x0808
+#define ENABLE_PCLK_ISP0x0900
+#define ENABLE_SCLK_ISP0x0a00
+#define ENABLE_IP_ISP0 0x0b00
+#define ENABLE_IP_ISP1 0x0b04
+#define ENABLE_IP_ISP2 0x0b08
+#define ENABLE_IP_ISP3 0x0b0c
+
+static unsigned long isp_clk_regs[] __initdata = {
+ MUX_SEL_ISP,
+ MUX_ENABLE_ISP,
+ MUX_STAT_ISP,
+ DIV_ISP,
+ DIV_STAT_ISP,
+ ENABLE_ACLK_ISP0,
+ ENABLE_ACLK_ISP1,
+ ENABLE_ACLK_ISP2,
+ ENABLE_PCLK_ISP,
+ ENABLE_SCLK_ISP,
+ ENABLE_IP_ISP0,
+ ENABLE_IP_ISP1,
+ ENABLE_IP_ISP2,
+ ENABLE_IP_ISP3,
+};
+
+PNAME(mout_aclk_isp_dis_400_user_p)= { fin_pll, aclk_isp_dis_400, };
+PNAME(mout_aclk_isp_400_user_p)= { fin_pll, aclk_isp_400,
};
+
+static struct samsung_mux_clock isp_mux_clks[] __initdata = {
+ /* MUX_SEL_ISP */
+ MUX(CLK_MOUT_ACLK_ISP_DIS_400_USER, mout_aclk_isp_dis_400_user,
+
[PATCH 5/9] clk: samsung: exynos5433: Add clocks for CMU_HEVC domain
This patch adds the mux/divider/gate clocks for CMU_HEVC domain which
generates the clocks for HEVC(High Efficiency Video Codec) decoder IP.
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Cc: Tomasz Figa tomasz.f...@gmail.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Inki Dae inki@samsung.com
---
.../devicetree/bindings/clock/exynos5433-clock.txt | 8 ++
drivers/clk/samsung/clk-exynos5433.c | 115 +
include/dt-bindings/clock/exynos5433.h | 27 -
3 files changed, 149 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
index d3deaaf..10908d2 100644
--- a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
@@ -41,6 +41,8 @@ Required Properties:
which generates clocks for M2M (Memory to Memory) scaler and JPEG IPs.
- samsung,exynos5433-cmu-mfc - clock controller compatible for CMU_MFC
which generates clocks for MFC(Multi-Format Codec) IP.
+ - samsung,exynos5433-cmu-hevc - clock controller compatible for CMU_HEVC
+which generates clocks for HEVC(High Efficiency Video Codec) decoder IP.
- reg: physical base address of the controller and length of memory mapped
region.
@@ -164,6 +166,12 @@ Example 1: Examples of clock controller nodes are listed
below.
#clock-cells = 1;
};
+ cmu_hevc: clock-controller@14f8 {
+ compatible = samsung,exynos5433-cmu-hevc;
+ reg = 0x14f8 0x0b08;
+ #clock-cells = 1;
+ };
+
Example 2: UART controller node that consumes the clock generated by the clock
controller.
diff --git a/drivers/clk/samsung/clk-exynos5433.c
b/drivers/clk/samsung/clk-exynos5433.c
index b64f703..1c2e5c8 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -560,6 +560,9 @@ static struct samsung_gate_clock top_gate_clks[] __initdata
= {
GATE(CLK_ACLK_GSCL_333, aclk_gscl_333, div_aclk_gscl_333,
ENABLE_ACLK_TOP, 14,
CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_ACLK_HEVC_400, aclk_hevc_400, div_aclk_hevc_400,
+ ENABLE_ACLK_TOP, 5,
+ CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
GATE(CLK_ACLK_MFC_400, aclk_mfc_400, div_aclk_mfc_400,
ENABLE_ACLK_TOP, 3,
CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
@@ -4103,3 +4106,115 @@ static void __init exynos5433_cmu_mfc_init(struct
device_node *np)
}
CLK_OF_DECLARE(exynos5433_cmu_mfc, samsung,exynos5433-cmu-mfc,
exynos5433_cmu_mfc_init);
+
+/*
+ * Register offset definitions for CMU_HEVC
+ */
+#define MUX_SEL_HEVC 0x0200
+#define MUX_ENABLE_HEVC0x0300
+#define MUX_STAT_HEVC 0x0400
+#define DIV_HEVC 0x0600
+#define DIV_STAT_HEVC 0x0700
+#define ENABLE_ACLK_HEVC 0x0800
+#define ENABLE_ACLK_HEVC_SECURE_SMMU_HEVC 0x0804
+#define ENABLE_PCLK_HEVC 0x0900
+#define ENABLE_PCLK_HEVC_SECURE_SMMU_HEVC 0x0904
+#define ENABLE_IP_HEVC00x0b00
+#define ENABLE_IP_HEVC10x0b04
+#define ENABLE_IP_HEVC_SECURE_SMMU_HEVC0x0b08
+
+static unsigned long hevc_clk_regs[] __initdata = {
+ MUX_SEL_HEVC,
+ MUX_ENABLE_HEVC,
+ MUX_STAT_HEVC,
+ DIV_HEVC,
+ DIV_STAT_HEVC,
+ ENABLE_ACLK_HEVC,
+ ENABLE_ACLK_HEVC_SECURE_SMMU_HEVC,
+ ENABLE_PCLK_HEVC,
+ ENABLE_PCLK_HEVC_SECURE_SMMU_HEVC,
+ ENABLE_IP_HEVC0,
+ ENABLE_IP_HEVC1,
+ ENABLE_IP_HEVC_SECURE_SMMU_HEVC,
+};
+
+PNAME(mout_aclk_hevc_400_user_p) = { fin_pll, aclk_hevc_400, };
+
+static struct samsung_mux_clock hevc_mux_clks[] __initdata = {
+ /* MUX_SEL_HEVC */
+ MUX(CLK_MOUT_ACLK_HEVC_400_USER, mout_aclk_hevc_400_user,
+ mout_aclk_hevc_400_user_p, MUX_SEL_HEVC, 0, 0),
+};
+
+static struct samsung_div_clock hevc_div_clks[] __initdata = {
+ /* DIV_HEVC */
+ DIV(CLK_DIV_PCLK_HEVC, div_pclk_hevc, mout_aclk_hevc_400_user,
+ DIV_HEVC, 0, 2),
+};
+
+static struct samsung_gate_clock hevc_gate_clks[] __initdata = {
+ /* ENABLE_ACLK_HEVC */
+ GATE(CLK_ACLK_BTS_HEVC_1, aclk_bts_hevc_1, mout_aclk_hevc_400_user,
+ ENABLE_ACLK_HEVC, 6, 0, 0),
+ GATE(CLK_ACLK_BTS_HEVC_0, aclk_bts_hevc_0, mout_aclk_hevc_400_user,
+ ENABLE_ACLK_HEVC, 5, 0, 0),
+ GATE(CLK_ACLK_AHB2APB_HEVCP, aclk_ahb2apb_hevcp, div_pclk_hevc,
+ ENABLE_ACLK_HEVC, 4, CLK_IGNORE_UNUSED, 0),
+
[PATCH v3 0/2] power: rt5033: Add Richtek RT533 drivers
This patchset adds driver for Richtek rt5033 chip The chip contains switching charge mode Li-Ion/Li-Polymer battery charger, fuelgauge. Additionally, This includes document for device tree of RT5033 device. RT5033 core driver is applied by Lee Jones. RT5033 regulator driver is applied by Mark Brown. RT5033 fuelgauge driver is applied by Sebastian Reichel. Changes in v3: - Applied one of patchset. - Add acked-by. Changes in v2: - Revise binding documentation.. Beomho Seo (2): power: rt5033_charger: Add RT5033 charger device driver Documentation: Add documentation for rt5033 multifunction device Documentation/devicetree/bindings/mfd/rt5033.txt | 101 .../devicetree/bindings/vendor-prefixes.txt|1 + drivers/power/Kconfig |8 + drivers/power/Makefile |1 + drivers/power/rt5033_charger.c | 485 5 files changed, 596 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/rt5033.txt create mode 100644 drivers/power/rt5033_charger.c -- 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 v3 1/2] power: rt5033_charger: Add RT5033 charger device driver
This patch add device driver of Richtek RT5033 PMIC. The driver support
switching charger. rt5033 charger provide three charging mode.
Three charging mode are pre charge mode, fast cahrge mode and constant voltage
mode. They are have vary charge rate, charge parameters. The charge parameters
can be controlled by i2c interface.
Cc: Sebastian Reichel s...@kernel.org
Cc: Dmitry Eremin-Solenikov dbarysh...@gmail.com
Cc: David Woodhouse dw...@infradead.org
Signed-off-by: Beomho Seo beomho@samsung.com
Acked-by: Chanwoo Choi cw00.c...@samsung.com
---
Changes in v3
Changes in v2
- none
---
drivers/power/Kconfig |8 +
drivers/power/Makefile |1 +
drivers/power/rt5033_charger.c | 485
3 files changed, 494 insertions(+)
create mode 100644 drivers/power/rt5033_charger.c
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index da6981f..629b101 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -405,6 +405,14 @@ config BATTERY_RT5033
The fuelgauge calculates and determines the battery state of charge
according to battery open circuit voltage.
+config CHARGER_RT5033
+ tristate RT5033 battery charger support
+ depends on MFD_RT5033
+ help
+ This adds support for battery charger in Richtek RT5033 PMIC.
+ The device supports pre-charge mode, fast charge mode and
+ constant voltage mode.
+
source drivers/power/reset/Kconfig
endif # POWER_SUPPLY
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index b83a0c7..bb8cce3 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -57,6 +57,7 @@ obj-$(CONFIG_CHARGER_BQ2415X) += bq2415x_charger.o
obj-$(CONFIG_CHARGER_BQ24190) += bq24190_charger.o
obj-$(CONFIG_CHARGER_BQ24735) += bq24735-charger.o
obj-$(CONFIG_POWER_AVS)+= avs/
+obj-$(CONFIG_POWER_RT5033) += rt5033_charger.o
obj-$(CONFIG_CHARGER_SMB347) += smb347-charger.o
obj-$(CONFIG_CHARGER_TPS65090) += tps65090-charger.o
obj-$(CONFIG_POWER_RESET) += reset/
diff --git a/drivers/power/rt5033_charger.c b/drivers/power/rt5033_charger.c
new file mode 100644
index 000..9dcaef4
--- /dev/null
+++ b/drivers/power/rt5033_charger.c
@@ -0,0 +1,485 @@
+/*
+ * Battery charger driver for RT5033
+ *
+ * Copyright (C) 2014 Samsung Electronics, Co., Ltd.
+ * Author: Beomho Seo beomho@samsung.com
+ *
+ * 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 bythe Free Software Foundation.
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/power_supply.h
+#include linux/mfd/rt5033-private.h
+#include linux/mfd/rt5033.h
+
+static int rt5033_get_charger_state(struct rt5033_charger *charger)
+{
+ struct regmap *regmap = charger-rt5033-regmap;
+ int state = POWER_SUPPLY_STATUS_UNKNOWN;
+ u32 reg_data;
+
+ if (!regmap)
+ return state;
+
+ regmap_read(regmap, RT5033_REG_CHG_STAT, reg_data);
+
+ switch (reg_data RT5033_CHG_STAT_MASK) {
+ case RT5033_CHG_STAT_DISCHARGING:
+ state = POWER_SUPPLY_STATUS_DISCHARGING;
+ break;
+ case RT5033_CHG_STAT_CHARGING:
+ state = POWER_SUPPLY_STATUS_CHARGING;
+ break;
+ case RT5033_CHG_STAT_FULL:
+ state = POWER_SUPPLY_STATUS_FULL;
+ break;
+ case RT5033_CHG_STAT_NOT_CHARGING:
+ state = POWER_SUPPLY_STATUS_NOT_CHARGING;
+ break;
+ }
+
+ return state;
+}
+
+static int rt5033_get_charger_type(struct rt5033_charger *charger)
+{
+ struct regmap *regmap = charger-rt5033-regmap;
+ int state = POWER_SUPPLY_CHARGE_TYPE_UNKNOWN;
+ u32 reg_data;
+
+ regmap_read(regmap, RT5033_REG_CHG_STAT, reg_data);
+
+ switch (reg_data RT5033_CHG_STAT_TYPE_MASK) {
+ case RT5033_CHG_STAT_TYPE_FAST:
+ state = POWER_SUPPLY_CHARGE_TYPE_FAST;
+ break;
+ case RT5033_CHG_STAT_TYPE_PRE:
+ state = POWER_SUPPLY_CHARGE_TYPE_TRICKLE;
+ break;
+ }
+
+ return state;
+}
+
+static int rt5033_get_charger_current(struct rt5033_charger *charger,
+ enum power_supply_property psp)
+{
+ struct regmap *regmap = charger-rt5033-regmap;
+ unsigned int state, reg_data, data;
+
+ if (psp == POWER_SUPPLY_PROP_CURRENT_MAX)
+ return RT5033_CHG_MAX_CURRENT;
+
+ regmap_read(regmap, RT5033_REG_CHG_CTRL5, reg_data);
+
+ state = (reg_data RT5033_CHGCTRL5_ICHG_SHIFT) 0xf;
+
+ if (state RT5033_CHG_MAX_CURRENT)
+ state = RT5033_CHG_MAX_CURRENT;
+
+ data = state * 100 + 700;
+
+ return data;
+}
+
+static int rt5033_get_charge_voltage(struct rt5033_charger *charger,
+ enum power_supply_property psp)
+{
+ struct regmap
[PATCH v3 2/2] Documentation: Add documentation for rt5033 multifunction device
This patch device tree binding documentation for rt5033 multifunction device.
Cc: Sebastian Reichel s...@kernel.org
Cc: Lee Jones lee.jo...@linaro.org
Cc: Mark Brown broo...@kernel.org
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
Signed-off-by: Beomho Seo beomho@samsung.com
Acked-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Lee Jones lee.jo...@linaro.org
---
Changes in v3
- Add Acked-by
Changes in v2
- Fix incorrect typo.
- Align -uamp and -uvolt names with regulator binding suffixes.
- Drop incorrect phandle.
- Fix incorrect example.
---
Documentation/devicetree/bindings/mfd/rt5033.txt | 101
.../devicetree/bindings/vendor-prefixes.txt|1 +
2 files changed, 102 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/rt5033.txt
diff --git a/Documentation/devicetree/bindings/mfd/rt5033.txt
b/Documentation/devicetree/bindings/mfd/rt5033.txt
new file mode 100644
index 000..64b23e8
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/rt5033.txt
@@ -0,0 +1,101 @@
+Richtek RT5033 Power management Integrated Circuit
+
+RT5033 is a Multifunction device which includes battery charger, fuel gauge,
+flash LED current source, LDO and synchronous Buck converter for portable
+applications. It is interfaced to host controller using i2c interface.
+
+Required properties:
+- compatible : Must be richtek,rt5033
+- reg : Specifies the i2c slave address of general part.
+- interrupts : This i2c devices has an IRQ line connected to the main SoC.
+- interrupt-parent : The parent interrupt controller.
+
+Optional node:
+Regulators: The regulators of RT5033 have to be instantiated under sub-node
+named regulators using the following format.
+
+ regulators {
+ regulator-name {
+ regulator-name = LDO/BUCK
+ regulator subnodes called X, Y and Z
+ };
+ };
+ refer Documentation/devicetree/bindings/regulator/regulator.txt
+
+
+Battery charger: There battery charger of RT5033 have to be instantiated under
+sub-node named charger using the following format.
+
+Required properties:
+- compatible : Must be richtek,rt5033-charger.
+- richtek,pre-uamp : Current of pre-charge mode. The pre-charge current levels
+ are 350 mA to 650 mA programmed by I2C per 100 mA.
+- richtek,fast-uamp : Current of fast-charge mode. The fast-charge current
+ levels are 700 mA to 2000 mA programmed by I2C per 100 mA.
+- richtek,eoc-uamp : This property is end of charge current. Its level 150 mA
+ to 200 mA.
+- richtek,pre-threshold-uvolt : Voltage of threshold pre-charge mode. Battery
+ voltage is below pre-charge threshold voltage, the charger is in pre-charge
+ mode with pre-charge current. Its levels are 2.3 V to 3.8 V programmed
+ by I2C per 0.1 V.
+- richtek,const-uvolt : Battery regulation voltage of constant voltage mode.
+ This voltage level 3.65 V to 4.4 V bye I2C per 0.025 V.
+
+ charger {
+ compatible = richtek,rt5033-charger;
+ richtek,pre-uamp = 35;
+ richtek,fast-uamp = 200;
+ richtek,eoc-uamp = 25;
+ richtek,pre-threshold-uvolt = 340;
+ richtek,const-uvolt = 435;
+
+ };
+
+
+Fuelgauge: There fuelgauge of RT5033 to be instantiated node named fuelgauge
+using the following format.
+
+Required properties:
+- compatible = Must be richtek,rt5033-battery.
+
+ rt5033@35 {
+ compatible = richtek,rt5033-battery;
+ interrupt-parent = gpx2;
+ interrupts = 3 0;
+ reg = 0x35;
+ };
+
+Example:
+
+ rt5033@34 {
+ compatible = richtek,rt5033;
+ reg = 0x34;
+ interrupt-parent = gpx1;
+ interrupts = 5 0;
+
+ regulators {
+ buck_reg: BUCK {
+ regulator-name = BUCK;
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 120;
+ regulator-always-on;
+ };
+ };
+
+ charger {
+ compatible = richtek,rt5033-charger;
+ richtek,pre-uamp = 35;
+ richtek,fast-uamp = 200;
+ richtek,eoc-uamp = 25;
+ richtek,pre-threshold-uvolt = 340;
+ richtek,const-uvolt = 435;
+ };
+
+ };
+
+ rt5033@35 {
+ compatible = richtek,rt5033-battery;
Re: [PATCH net-next v13 5/5] openvswitch: Add support for unique flow IDs.
On 21 January 2015 at 15:41, Pravin Shelar pshe...@nicira.com wrote: On Wed, Jan 21, 2015 at 11:29 AM, Joe Stringer joestrin...@nicira.com wrote: On 21 January 2015 at 10:31, Pravin Shelar pshe...@nicira.com wrote: On Tue, Jan 20, 2015 at 10:32 AM, Joe Stringer joestrin...@nicira.com wrote: Previously, flows were manipulated by userspace specifying a full, unmasked flow key. This adds significant burden onto flow serialization/deserialization, particularly when dumping flows. This patch adds an alternative way to refer to flows using a variable-length unique flow identifier (UFID). At flow setup time, userspace may specify a UFID for a flow, which is stored with the flow and inserted into a separate table for lookup, in addition to the standard flow table. Flows created using a UFID must be fetched or deleted using the UFID. All flow dump operations may now be made more terse with OVS_UFID_F_* flags. For example, the OVS_UFID_F_OMIT_KEY flag allows responses to omit the flow key from a datapath operation if the flow has a corresponding UFID. This significantly reduces the time spent assembling and transacting netlink messages. With all OVS_UFID_F_OMIT_* flags enabled, the datapath only returns the UFID and statistics for each flow during flow dump, increasing ovs-vswitchd revalidator performance by 40% or more. Signed-off-by: Joe Stringer joestrin...@nicira.com Its almost ready. But I saw minor issues, few checkpatch.pl failures. in ovs_flow_cmd_new() we should use unmasked key to lookup in flow table for legacy case. Thanks for review, I can send out a fresh version soon. Should I resend the whole series or is just a new version of this patch sufficient? I think you have to send entire series. Dave will not apply series patches from different versions. Thanks. I also realized there were checkpatch issues in the first patch, so I resent the whole series anyway. -- 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/1] NVMe: Do not take nsid while a passthrough IO command is being issued via a block device file descriptor
On Wed, 21 Jan 2015, Yan Liu wrote: When a passthrough IO command is issued with a specific block device file descriptor. It should be applied at the namespace which is associated with that block device file descriptor. This patch makes such passthrough command ingore nsid in nvme_passthru_cmd structure. Instead it takes the namespace ID asscoiated with the block device descriptor. Signed-off-by: Yan Liu y...@purestorage.com Oh it doesn't look like you tested this through the character handle. You've got it set to use the admin queue's request_queue for IO passthrough commands, so that can't be right. The IOCTL's purpose was to let someone submit completely arbitrary commands on IO queues. This technically shouldn't even need a namespace handle, but we don't have a request_queue associated to IO queues without one like the admin queue has. In fact, we ought to fix that so we can issue IO commands without namespaces. Anyway, namespaces may be hidden or some vendor special NSID trickery, who knows. Point is we don't want to tie the passthrough command's NSID down to the namespace providing the request_queue. If it is your intention to use that NSID, you can get the NSID using the NVME_IOCTL_ID prior to setting up the passthrough command. -- 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] perf symbols: debuglink should take symfs option into account
On 1/21/15 5:34 PM, Victor Kamensky wrote:
diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index 45be944..ca8d8d5 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -45,13 +45,13 @@ int dso__read_binary_type_filename(const struct dso *dso,
case DSO_BINARY_TYPE__DEBUGLINK: {
char *debuglink;
-strncpy(filename, dso-long_name, size);
-debuglink = filename + dso-long_name_len;
+len = __symbol__join_symfs(filename, size, dso-long_name);
+debuglink = filename + len;
while (debuglink != filename *debuglink != '/')
debuglink--;
if (*debuglink == '/')
debuglink++;
-ret = filename__read_debuglink(dso-long_name, debuglink,
+ret = filename__read_debuglink(filename, debuglink,
size - (debuglink - filename));
}
break;
I do not see any reason this will not work. Essentially after
filename__read_debuglink filename contains symfs + dso path + debuglink
read from .gnu_debuglink section which is what is wanted.
Thanks for the example. I used it with both a symfs and non-symfs
example and both times this change worked properly -- the correct
hang.debug file is read.
Arnaldo?
David
--
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] x86, e820: clean up around sanitize_e820_map()
On Wed, 7 Jan 2015, WANG Chao wrote: The argument 3 of sanitize_e820_map() will only update upon a successful sanitization. Some of the callers may not be aware of this in the past. Now clean up these callers. Signed-off-by: WANG Chao chaow...@redhat.com Nice, but it's incomplete: it should also cleanup default_machine_specific_memory_setup(). After that's fixed, feel free to add my Acked-by: David Rientjes rient...@google.com -- 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/
linux-next: strange commit in the mfd tree
Hi Lee, I noticed this commit in the mfd tree: f11b9265e6ca [FIX/HACK] Disable DRM Is that really appropriate here? Especially given it has no explanation. I guess it will make my builds slightly faster :-) -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpJYAPVrOnUE.pgp Description: OpenPGP digital signature
[PATCH 2/2] watchdog: dw_wdt: Try to get a 30 second watchdog by default
The dw_wdt_set_top() function takes in a value in seconds. In
dw_wdt_open() we were calling it with a value that's supposed to
represent the maximum value programmed into the top register with a
comment saying that we were trying to set the watchdog to its maximum
value. Instead we ended up setting the watchdog to ~15 seconds.
Let's fix this. However, setting things to the max gives me an 86
second watchdog in the system I'm looking at. 86 seconds feels a
little too long. We'll explicitly choose 30 seconds as a more
reasonable value.
NOTE: Ideally this driver should be transitioned to be a real watchdog
driver. Then we could use watchdog_init_timeout and let the timeout
be specified in a number of ways (device tree, module parameter, etc).
This patch should be considered a bit of a stopgap solution.
Signed-off-by: Doug Anderson diand...@chromium.org
---
drivers/watchdog/dw_wdt.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/watchdog/dw_wdt.c b/drivers/watchdog/dw_wdt.c
index fc92bea..cc2805d 100644
--- a/drivers/watchdog/dw_wdt.c
+++ b/drivers/watchdog/dw_wdt.c
@@ -51,6 +51,8 @@
/* The maximum TOP (timeout period) value that can be set in the watchdog. */
#define DW_WDT_MAX_TOP 15
+#define DW_WDT_DEFAULT_SECONDS 30
+
static bool nowayout = WATCHDOG_NOWAYOUT;
module_param(nowayout, bool, 0);
MODULE_PARM_DESC(nowayout, Watchdog cannot be stopped once started
@@ -167,9 +169,9 @@ static int dw_wdt_open(struct inode *inode, struct file
*filp)
if (!dw_wdt_is_enabled()) {
/*
* The watchdog is not currently enabled. Set the timeout to
-* the maximum and then start it.
+* something reasonable and then start it.
*/
- dw_wdt_set_top(DW_WDT_MAX_TOP);
+ dw_wdt_set_top(DW_WDT_DEFAULT_SECONDS);
dw_wdt_keepalive();
writel(WDOG_CONTROL_REG_WDT_EN_MASK,
dw_wdt.regs + WDOG_CONTROL_REG_OFFSET);
--
2.2.0.rc0.207.ga3a616c
--
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/2] watchdog: dw_wdt: pat the watchdog before enabling it
On some dw_wdt implementations the top register may be initted to 0 at bootup. In such a case, each pat of the watchdog will reset the timer to 0x. That's pretty short. The input clock of the wdt can be any of a wide range of values. On an rk3288 system, I've seen the wdt clock be 24.75 MHz. That means each tick is ~40ns and we'll count to 0x in ~2.6ms. Because of the above two facts, it's a really good idea to pat the watchdog after initting the top register properly and before enabling the watchdog. If you don't then there's no way we'll get the next heartbeat in time. Signed-off-by: Doug Anderson diand...@chromium.org --- drivers/watchdog/dw_wdt.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/watchdog/dw_wdt.c b/drivers/watchdog/dw_wdt.c index b34a2e4..fc92bea 100644 --- a/drivers/watchdog/dw_wdt.c +++ b/drivers/watchdog/dw_wdt.c @@ -170,6 +170,7 @@ static int dw_wdt_open(struct inode *inode, struct file *filp) * the maximum and then start it. */ dw_wdt_set_top(DW_WDT_MAX_TOP); + dw_wdt_keepalive(); writel(WDOG_CONTROL_REG_WDT_EN_MASK, dw_wdt.regs + WDOG_CONTROL_REG_OFFSET); } -- 2.2.0.rc0.207.ga3a616c -- 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] ARM: entry-common: fix forgotten set of thread_info-syscall
On Tue, Jan 20, 2015 at 3:04 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Tue, Jan 20, 2015 at 10:45:19PM +, Russell King - ARM Linux wrote: Well, the whole question is this: is restarting a system call like usleep() really a separate system call, or is it a kernel implementation detail? If you wanted seccomp to see this, what would be the use case? Why would seccomp want to block this syscall? Does it make sense for seccomp to block this syscall when it doesn't block something like usleep() and then have usleep() fail just because the thread received a signal? I personally regard the whole restart system call thing as a purely kernel internal thing which should not be exposed to userland. If we decide that it should be exposed to userland, then it becomes part of the user ABI, and it /could/ become difficult if we needed to change it in future - and I'd rather not get into the oh shit, we can't change it because that would break app X crap. Here's a scenario where it could become a problem: Let's say that we want to use seccomp to secure some code which issues system calls. We determine that the app uses system calls which don't result in the restart system call being issued, so we decide to ask seccomp to block the restart system call. Some of these system calls that the app was using are restartable system calls. When these system calls are restarted, what we see via ptrace etc is that the system call simply gets re-issued as its own system call. In a future kernel version, we decide that we could really do with one of those system calls using the restart block feature, so we arrange for it to set up the restart block, and return -ERESTART_BLOCK. That's fine for most applications, but this app now breaks. The side effect of that breakage is that we have to revert that kernel change - because we've broken userland, and that's simply not allowed. Now look at the alternative: we don't make the restart syscall visible. This means that we hide that detail, and we actually reflect the behaviour that we've had for the other system call restart mechanisms, and we don't have to fear userspace breakage as a result of switching from one restart mechanism to another. I am very much of the opinion that we should be trying to limit the exposure of inappropriate kernel internal details to userland, because userland has a habbit of becoming reliant on them, and when it does, it makes kernel maintanence unnecessarily harder. I totally agree with you. :) My question here is more about what we should do with what we currently have since we have some unexpected combinations. There is already an __NR_restart_syscall syscall and it seems like it's already part of the userspace ABI: - it is possible to call it from userspace directly - seccomp sees it - ptrace doesn't see it Native ARM64 hides the restart from both seccomp and ptrace, and this seems like the right idea, except that restart_syscall is still callable from userspace. I don't think there's a way to make that vanish, which means we'll always have an exposed syscall. If anything goes wrong with it (which we've been quite close to recently[1]), there would be no way to have seccomp filter it. So, at the least, I'd like arm64 to NOT hide restart_syscall from seccomp, and at best I'd like both arm and arm64 to (somehow) entirely remove restart_syscall from the userspace ABI so it wouldn't need to be filtered, and wouldn't become a weird ABI hiccup as you've described. I fail to imagine a way to remove restart_syscall from userspace, so I'm left with wanting parity of behavior between ARM and ARM64 (and x86). What's the right way forward? -Kees [1] https://git.kernel.org/linus/849151dd5481bc8acb1d287a299b5d6a4ca9f1c3 -- Kees Cook Chrome OS Security -- 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: [PATCHv3 00/36] perf tools: New build framework
Jiri Olsa [jo...@kernel.org] wrote: | | The patchset is also available in: | git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git | perf/build | | All tests/make tests passed. | The build and make tests passed on my Power8 system. Tested-by: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com -- 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: [V6,1/9] elf: Add new powerpc specifc core note sections
On Thu, 2015-01-01 at 13:38 +0530, Anshuman Khandual wrote:
On 12/20/2014 12:58 AM, Edjunior Barbosa Machado wrote:
On 12/08/2014 08:08 AM, Anshuman Khandual wrote:
On 12/03/2014 12:18 PM, Anshuman Khandual wrote:
On 12/03/2014 10:52 AM, Michael Ellerman wrote:
On Tue, 2014-02-12 at 07:56:45 UTC, Anshuman Khandual wrote:
This patch adds four new ELF core note sections for powerpc
transactional memory and one new ELF core note section for
powerpc general miscellaneous debug registers. These addition
of new ELF core note sections extends the existing ELF ABI
without affecting it in any manner.
Acked-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com
---
include/uapi/linux/elf.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/uapi/linux/elf.h b/include/uapi/linux/elf.h
index ea9bf25..2260fc0 100644
--- a/include/uapi/linux/elf.h
+++ b/include/uapi/linux/elf.h
@@ -379,6 +379,11 @@ typedef struct elf64_shdr {
#define NT_PPC_VMX 0x100 /* PowerPC Altivec/VMX
registers */
#define NT_PPC_SPE 0x101 /* PowerPC SPE/EVR registers */
#define NT_PPC_VSX 0x102 /* PowerPC VSX registers */
+#define NT_PPC_TM_SPR 0x103 /* PowerPC TM special registers
*/
+#define NT_PPC_TM_CGPR 0x104 /* PowerpC TM checkpointed GPR
*/
+#define NT_PPC_TM_CFPR 0x105 /* PowerPC TM checkpointed FPR
*/
+#define NT_PPC_TM_CVMX 0x106 /* PowerPC TM checkpointed VMX
*/
+#define NT_PPC_MISC0x107 /* PowerPC miscellaneous
registers */
This is a really terrible name, MISC.
Having said that, I guess it's accurate. We have a whole bunch of regs
that
have accrued over recent years that aren't accessible via ptrace.
It seems to me if we're adding a misc regset we should be adding
everything we
might want to it that is currenty architected.
But I believe they also need to be part of the thread_struct structure to
be
accessible from ptrace.
Currently we dont context save/restore the PMC count registers (PMC1-PMC6)
during the process context switch. So the values of PMC1..PMC6 are not
thread specific in the structure. To be able to access them in ptrace
when the tracee has stopped, we need to context save these counters
in the thread struct. Shall we do that ? Then we can add them to the
MISC regset bucket irrespective of whats the value we get in there when
we probe through ptrace.
The same goes for MMCRA, CFAR registers as well.
But currently you only include the PPR, TAR DSCR.
Yeah, thats what we started with.
Looking at Power ISA v2.07, I see the following that could be included:
MMCR2
MMCRA
PMC1
PMC2
PMC3
PMC4
PMC5
PMC6
MMCR0
EBBHR
EBBRR
BESCR
SIAR
SDAR
CFAR?
MMCRA, PMC[1..6], EBBHR, BESCR, EBBRR, CFAR are not part of the thread
struct.
Sorry. EBBRR, EBBHR, BESCR registers are part of the thread struct.
Those are all new in 2.07 except for CFAR.
There might be more I missed, that was just a quick scan.
Some are only accessible when EBB is in use, maybe those could be a
separate
regset.
Yeah we can have one more regset for EBB specific registers.
Should the new EBB specific regset include only EBBRR, EBBHR, BESCR
registers
or should it also include SIAR, SDAR, SIER, MMCR0, MMCR2 registers as
well. I
was thinking about putting these five registers into the MISC bucket
instead.
But from the perf code, it looks like these five registers are also
related to
the EBB context as well.
Some clarity on these points would really help.
Hi,
from the provided testcase using ptrace interface, reviewing with the help
of Ulrich, it looks OK from GDB perspective, with the exception of a few
concerns:
The patchset seems to change the original ptrace requests (i.e.
PTRACE_GETREGS/GETFPREGS/GETVRREGS...) to return the transactional state,
and
adds new register sets to return the checkpointed state. Considering that
whenever you get a debugger interception inside a transactional block, the
transaction will abort, we're wondering if it wouldn't make more sense to
display the 'checkpointed' state as the normal registers since this is
where the
execution will continue from.
Debugger interception (trace interrupt) in between any transaction block will
abort
it ? I doubt that.
The trace interrupt will not abort the transaction explicitly...
The tracee process will just stop, it's context gets saved in the
kernel so that it can again start executing from the exact same point onward
when it
resumes.
... unfortunately, this save *will* doom the transaction. To save, a
treclaim instruction is run which will always explicitly doom the
transaction.
If this happens when inside any transaction
Re: [PATCH net-next v13 5/5] openvswitch: Add support for unique flow IDs.
On Wed, Jan 21, 2015 at 11:29 AM, Joe Stringer joestrin...@nicira.com wrote: On 21 January 2015 at 10:31, Pravin Shelar pshe...@nicira.com wrote: On Tue, Jan 20, 2015 at 10:32 AM, Joe Stringer joestrin...@nicira.com wrote: Previously, flows were manipulated by userspace specifying a full, unmasked flow key. This adds significant burden onto flow serialization/deserialization, particularly when dumping flows. This patch adds an alternative way to refer to flows using a variable-length unique flow identifier (UFID). At flow setup time, userspace may specify a UFID for a flow, which is stored with the flow and inserted into a separate table for lookup, in addition to the standard flow table. Flows created using a UFID must be fetched or deleted using the UFID. All flow dump operations may now be made more terse with OVS_UFID_F_* flags. For example, the OVS_UFID_F_OMIT_KEY flag allows responses to omit the flow key from a datapath operation if the flow has a corresponding UFID. This significantly reduces the time spent assembling and transacting netlink messages. With all OVS_UFID_F_OMIT_* flags enabled, the datapath only returns the UFID and statistics for each flow during flow dump, increasing ovs-vswitchd revalidator performance by 40% or more. Signed-off-by: Joe Stringer joestrin...@nicira.com Its almost ready. But I saw minor issues, few checkpatch.pl failures. in ovs_flow_cmd_new() we should use unmasked key to lookup in flow table for legacy case. Thanks for review, I can send out a fresh version soon. Should I resend the whole series or is just a new version of this patch sufficient? I think you have to send entire series. Dave will not apply series patches from different versions. -- 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 8/9] clk: samsung: exynos5433: Add clocks for CMU_CAM1 domain
This patch adds the mux/divider/gate clocks for CMU_CAM1 domain which
generates the clocks for Cortex-A5/MIPI_CSIS2/FIMC-LITE_C/FIMC-FD IPs.
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Cc: Tomasz Figa tomasz.f...@gmail.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Inki Dae inki@samsung.com
---
.../devicetree/bindings/clock/exynos5433-clock.txt | 8 +
drivers/clk/samsung/clk-exynos5433.c | 435 +
include/dt-bindings/clock/exynos5433.h | 147 ++-
3 files changed, 588 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
index abef8f5..10e0ba6 100644
--- a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
@@ -48,6 +48,8 @@ Required Properties:
- samsung,exynos5433-cmu-cam0 - clock controller compatible for CMU_CAM0
which generates clocks for MIPI_CSIS{0|1}/FIMC_LITE_{A|B|D}/FIMC_3AA{0|1}
IPs.
+ - samsung,exynos5433-cmu-cam1 - clock controller compatible for CMU_CAM1
+which generates clocks for Cortex-A5/MIPI_CSIS2/FIMC-LITE_C/FIMC-FD IPs.
- reg: physical base address of the controller and length of memory mapped
region.
@@ -189,6 +191,12 @@ Example 1: Examples of clock controller nodes are listed
below.
#clock-cells = 1;
};
+ cmu_cam1: clock-controller@145d {
+ compatible = samsung,exynos5433-cmu-cam1;
+ reg = 0x145d 0x0b08;
+ #clock-cells = 1;
+ };
+
Example 2: UART controller node that consumes the clock generated by the clock
controller.
diff --git a/drivers/clk/samsung/clk-exynos5433.c
b/drivers/clk/samsung/clk-exynos5433.c
index c765fe7..cb5fda1 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -405,6 +405,12 @@ static struct samsung_mux_clock top_mux_clks[] __initdata
= {
static struct samsung_div_clock top_div_clks[] __initdata = {
/* DIV_TOP0 */
+ DIV(CLK_DIV_ACLK_CAM1_333, div_aclk_cam1_333, mout_aclk_cam1_333,
+ DIV_TOP0, 28, 3),
+ DIV(CLK_DIV_ACLK_CAM1_400, div_aclk_cam1_400, mout_bus_pll_user,
+ DIV_TOP0, 24, 3),
+ DIV(CLK_DIV_ACLK_CAM1_552, div_aclk_cam1_552, mout_aclk_cam1_552_b,
+ DIV_TOP0, 20, 3),
DIV(CLK_DIV_ACLK_CAM0_333, div_aclk_cam0_333, mout_mfc_pll_user,
DIV_TOP0, 16, 3),
DIV(CLK_DIV_ACLK_CAM0_400, div_aclk_cam0_400, mout_bus_pll_user,
@@ -464,6 +470,32 @@ static struct samsung_div_clock top_div_clks[] __initdata
= {
DIV(CLK_DIV_SCLK_JPEG, div_sclk_jpeg, mout_sclk_jpeg_c,
DIV_TOP_MSCL, 0, 4),
+ /* DIV_TOP_CAM10 */
+ DIV(CLK_DIV_SCLK_ISP_UART, div_sclk_isp_uart, mout_sclk_isp_uart,
+ DIV_TOP_CAM10, 24, 5),
+ DIV(CLK_DIV_SCLK_ISP_SPI1_B, div_sclk_isp_spi1_b,
+ div_sclk_isp_spi1_a, DIV_TOP_CAM10, 16, 8),
+ DIV(CLK_DIV_SCLK_ISP_SPI1_A, div_sclk_isp_spi1_a,
+ mout_sclk_isp_spi1, DIV_TOP_CAM10, 12, 4),
+ DIV(CLK_DIV_SCLK_ISP_SPI0_B, div_sclk_isp_spi0_b,
+ div_sclk_isp_spi0_a, DIV_TOP_CAM10, 4, 8),
+ DIV(CLK_DIV_SCLK_ISP_SPI0_A, div_sclk_isp_spi0_a,
+ mout_sclk_isp_spi0, DIV_TOP_CAM10, 0, 4),
+
+ /* DIV_TOP_CAM11 */
+ DIV(CLK_DIV_SCLK_ISP_SENSOR2_B, div_sclk_isp_sensor2_b,
+ div_sclk_isp_sensor2_a, DIV_TOP_CAM11, 20, 4),
+ DIV(CLK_DIV_SCLK_ISP_SENSOR2_A, div_sclk_isp_sensor2_a,
+ mout_sclk_isp_sensor2, DIV_TOP_CAM11, 16, 4),
+ DIV(CLK_DIV_SCLK_ISP_SENSOR1_B, div_sclk_isp_sensor1_b,
+ div_sclk_isp_sensor1_a, DIV_TOP_CAM11, 12, 4),
+ DIV(CLK_DIV_SCLK_ISP_SENSOR1_A, div_sclk_isp_sensor1_a,
+ mout_sclk_isp_sensor1, DIV_TOP_CAM11, 8, 4),
+ DIV(CLK_DIV_SCLK_ISP_SENSOR0_B, div_sclk_isp_sensor0_b,
+ div_sclk_isp_sensor0_a, DIV_TOP_CAM11, 12, 4),
+ DIV(CLK_DIV_SCLK_ISP_SENSOR0_A, div_sclk_isp_sensor0_a,
+ mout_sclk_isp_sensor0, DIV_TOP_CAM11, 8, 4),
+
/* DIV_TOP_FSYS0 */
DIV(CLK_DIV_SCLK_MMC1_B, div_sclk_mmc1_b, div_sclk_mmc1_a,
DIV_TOP_FSYS0, 16, 8),
@@ -572,6 +604,15 @@ static struct samsung_gate_clock top_gate_clks[]
__initdata = {
GATE(CLK_ACLK_GSCL_333, aclk_gscl_333, div_aclk_gscl_333,
ENABLE_ACLK_TOP, 14,
CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_ACLK_CAM1_333, aclk_cam1_333, div_aclk_cam1_333,
+ ENABLE_ACLK_TOP, 13,
+ CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_ACLK_CAM1_400, aclk_cam1_400,
[PATCH 4/9] clk: samsung: exynos5433: Add clocks for CMU_MFC domain
This patch adds the mux/divider/gate clocks for CMU_MFC domain which
generates the clocks for MFC(Multi-Format Codec) IP.
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Cc: Tomasz Figa tomasz.f...@gmail.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Inki Dae inki@samsung.com
---
.../devicetree/bindings/clock/exynos5433-clock.txt | 7 ++
drivers/clk/samsung/clk-exynos5433.c | 113 +
include/dt-bindings/clock/exynos5433.h | 27 -
3 files changed, 146 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
index 790d93b..d3deaaf 100644
--- a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
@@ -39,6 +39,8 @@ Required Properties:
L2 cache controller.
- samsung,exynos5433-cmu-mscl - clock controller compatible for CMU_MSCL
which generates clocks for M2M (Memory to Memory) scaler and JPEG IPs.
+ - samsung,exynos5433-cmu-mfc - clock controller compatible for CMU_MFC
+which generates clocks for MFC(Multi-Format Codec) IP.
- reg: physical base address of the controller and length of memory mapped
region.
@@ -156,6 +158,11 @@ Example 1: Examples of clock controller nodes are listed
below.
#clock-cells = 1;
};
+ cmu_mfc: clock-controller@1528 {
+ compatible = samsung,exynos5433-cmu-mfc;
+ reg = 0x1528 0x0b08;
+ #clock-cells = 1;
+ };
Example 2: UART controller node that consumes the clock generated by the clock
controller.
diff --git a/drivers/clk/samsung/clk-exynos5433.c
b/drivers/clk/samsung/clk-exynos5433.c
index 60ac4c7..b64f703 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -560,6 +560,9 @@ static struct samsung_gate_clock top_gate_clks[] __initdata
= {
GATE(CLK_ACLK_GSCL_333, aclk_gscl_333, div_aclk_gscl_333,
ENABLE_ACLK_TOP, 14,
CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_ACLK_MFC_400, aclk_mfc_400, div_aclk_mfc_400,
+ ENABLE_ACLK_TOP, 3,
+ CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
GATE(CLK_ACLK_G2D_266, aclk_g2d_266, div_aclk_g2d_266,
ENABLE_ACLK_TOP, 2,
CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
@@ -3990,3 +3993,113 @@ static void __init exynos5433_cmu_mscl_init(struct
device_node *np)
}
CLK_OF_DECLARE(exynos5433_cmu_mscl, samsung,exynos5433-cmu-mscl,
exynos5433_cmu_mscl_init);
+
+/*
+ * Register offset definitions for CMU_MFC
+ */
+#define MUX_SEL_MFC0x0200
+#define MUX_ENABLE_MFC 0x0300
+#define MUX_STAT_MFC 0x0400
+#define DIV_MFC0x0600
+#define DIV_STAT_MFC 0x0700
+#define ENABLE_ACLK_MFC0x0800
+#define ENABLE_ACLK_MFC_SECURE_SMMU_MFC0x0804
+#define ENABLE_PCLK_MFC0x0900
+#define ENABLE_PCLK_MFC_SECURE_SMMU_MFC0x0904
+#define ENABLE_IP_MFC0 0x0b00
+#define ENABLE_IP_MFC1 0x0b04
+#define ENABLE_IP_MFC_SECURE_SMMU_MFC 0x0b08
+
+static unsigned long mfc_clk_regs[] __initdata = {
+ MUX_SEL_MFC,
+ MUX_ENABLE_MFC,
+ MUX_STAT_MFC,
+ DIV_MFC,
+ DIV_STAT_MFC,
+ ENABLE_ACLK_MFC,
+ ENABLE_ACLK_MFC_SECURE_SMMU_MFC,
+ ENABLE_PCLK_MFC,
+ ENABLE_PCLK_MFC_SECURE_SMMU_MFC,
+ ENABLE_IP_MFC0,
+ ENABLE_IP_MFC1,
+ ENABLE_IP_MFC_SECURE_SMMU_MFC,
+};
+
+PNAME(mout_aclk_mfc_400_user_p)= { fin_pll, aclk_mfc_400,
};
+
+static struct samsung_mux_clock mfc_mux_clks[] __initdata = {
+ /* MUX_SEL_MFC */
+ MUX(CLK_MOUT_ACLK_MFC_400_USER, mout_aclk_mfc_400_user,
+ mout_aclk_mfc_400_user_p, MUX_SEL_MFC, 0, 0),
+};
+
+static struct samsung_div_clock mfc_div_clks[] __initdata = {
+ /* DIV_MFC */
+ DIV(CLK_DIV_PCLK_MFC, div_pclk_mfc, mout_aclk_mfc_400_user,
+ DIV_MFC, 0, 2),
+};
+
+static struct samsung_gate_clock mfc_gate_clks[] __initdata = {
+ /* ENABLE_ACLK_MFC */
+ GATE(CLK_ACLK_BTS_MFC_1, aclk_bts_mfc_1, mout_aclk_mfc_400_user,
+ ENABLE_ACLK_MFC, 6, 0, 0),
+ GATE(CLK_ACLK_BTS_MFC_0, aclk_bts_mfc_0, mout_aclk_mfc_400_user,
+ ENABLE_ACLK_MFC, 5, 0, 0),
+ GATE(CLK_ACLK_AHB2APB_MFCP, aclk_ahb2apb_mfcp, div_pclk_mfc,
+ ENABLE_ACLK_MFC, 4, CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_ACLK_XIU_MFCX, aclk_xiu_mfcx, mout_aclk_mfc_400_user,
+ ENABLE_ACLK_MFC, 3,
[PATCH] video: fbdev: fix sys_copyarea
The sys_copyarea() function performs the same operation as
cfb_copyarea() but using normal memory access instead of I/O
accessors. Since the introduction of sys_copyarea(), there
have been two fixes to cfb_copyarea():
- 00a9d699 (framebuffer: fix cfb_copyarea)
- 5b789da8 (framebuffer: fix screen corruption when copying)
This patch incorporates the fixes into sys_copyarea() as well.
Signed-off-by: Mans Rullgard m...@mansr.com
---
drivers/video/fbdev/core/syscopyarea.c | 137 -
1 file changed, 65 insertions(+), 72 deletions(-)
diff --git a/drivers/video/fbdev/core/syscopyarea.c
b/drivers/video/fbdev/core/syscopyarea.c
index 844a32f..67b4d6d 100644
--- a/drivers/video/fbdev/core/syscopyarea.c
+++ b/drivers/video/fbdev/core/syscopyarea.c
@@ -25,8 +25,8 @@
*/
static void
-bitcpy(struct fb_info *p, unsigned long *dst, int dst_idx,
- const unsigned long *src, int src_idx, int bits, unsigned n)
+bitcpy(struct fb_info *p, unsigned long *dst, unsigned dst_idx,
+ const unsigned long *src, unsigned src_idx, int bits, unsigned n)
{
unsigned long first, last;
int const shift = dst_idx-src_idx;
@@ -86,15 +86,15 @@ bitcpy(struct fb_info *p, unsigned long *dst, int dst_idx,
first = last;
if (shift 0) {
/* Single source word */
- *dst = comp(*src right, *dst, first);
+ *dst = comp(*src left, *dst, first);
} else if (src_idx+n = bits) {
/* Single source word */
- *dst = comp(*src left, *dst, first);
+ *dst = comp(*src right, *dst, first);
} else {
/* 2 source words */
d0 = *src++;
d1 = *src;
- *dst = comp(d0 left | d1 right, *dst,
+ *dst = comp(d0 right | d1 left, *dst,
first);
}
} else {
@@ -109,13 +109,14 @@ bitcpy(struct fb_info *p, unsigned long *dst, int dst_idx,
/* Leading bits */
if (shift 0) {
/* Single source word */
- *dst = comp(d0 right, *dst, first);
+ *dst = comp(d0 left, *dst, first);
dst++;
n -= bits - dst_idx;
} else {
/* 2 source words */
d1 = *src++;
- *dst = comp(d0 left | *dst right, *dst,
first);
+ *dst = comp(d0 right | d1 left, *dst,
+ first);
d0 = d1;
dst++;
n -= bits - dst_idx;
@@ -126,36 +127,36 @@ bitcpy(struct fb_info *p, unsigned long *dst, int dst_idx,
n /= bits;
while (n = 4) {
d1 = *src++;
- *dst++ = d0 left | d1 right;
+ *dst++ = d0 right | d1 left;
d0 = d1;
d1 = *src++;
- *dst++ = d0 left | d1 right;
+ *dst++ = d0 right | d1 left;
d0 = d1;
d1 = *src++;
- *dst++ = d0 left | d1 right;
+ *dst++ = d0 right | d1 left;
d0 = d1;
d1 = *src++;
- *dst++ = d0 left | d1 right;
+ *dst++ = d0 right | d1 left;
d0 = d1;
n -= 4;
}
while (n--) {
d1 = *src++;
- *dst++ = d0 left | d1 right;
+ *dst++ = d0 right | d1 left;
d0 = d1;
}
/* Trailing bits */
- if (last) {
- if (m = right) {
+ if (m) {
+ if (m = bits - right) {
/* Single source word */
- *dst = comp(d0 left, *dst, last);
+ d0 = right;
} else {
/* 2 source words
[PATCH net-next v14 5/5] openvswitch: Add support for unique flow IDs.
Previously, flows were manipulated by userspace specifying a full,
unmasked flow key. This adds significant burden onto flow
serialization/deserialization, particularly when dumping flows.
This patch adds an alternative way to refer to flows using a
variable-length unique flow identifier (UFID). At flow setup time,
userspace may specify a UFID for a flow, which is stored with the flow
and inserted into a separate table for lookup, in addition to the
standard flow table. Flows created using a UFID must be fetched or
deleted using the UFID.
All flow dump operations may now be made more terse with OVS_UFID_F_*
flags. For example, the OVS_UFID_F_OMIT_KEY flag allows responses to
omit the flow key from a datapath operation if the flow has a
corresponding UFID. This significantly reduces the time spent assembling
and transacting netlink messages. With all OVS_UFID_F_OMIT_* flags
enabled, the datapath only returns the UFID and statistics for each flow
during flow dump, increasing ovs-vswitchd revalidator performance by 40%
or more.
Signed-off-by: Joe Stringer joestrin...@nicira.com
---
v14: Perform lookup using unmasked key in legacy case.
Fix minor checkpatch.pl style violations.
v13: Embed sw_flow_id in sw_flow.
Malloc unmasked_key for legacy case.
Fix bug where key is double-serialized in legacy case.
v12: Merge unmasked_key, ufid into 'struct sw_flow_id'.
Add identifier_is_{ufid,key}() helpers.
Add should_fill_{key,mask,actions}() helpers.
Revert rework of ovs_flow_cmd_set() -- requires key,acts.
Streamline sw_flow_id copy/alloc.
Use genlmsg_parse() to find ufid flags in dump.
Handle new_flow case with same ufid, different flow key.
Calculate exact message length in ovs_flow_cmd_msg_size().
Limit UFID to between 1-16 octets.
Check minimum length for UFID in flow_policy.
Use jhash() for ufid_hash (arch_fast_hash() went away).
Rebase.
v11: Separate UFID and unmasked key from sw_flow.
Modify interface to remove nested UFID attributes.
Only allow UFIDs between 1-256 octets.
Move UFID nla fetch helpers to flow_netlink.h.
Perform complete nlmsg_parsing in ovs_flow_cmd_dump().
Check UFID table for flows with duplicate UFID at flow setup.
Tidy up mask/key/ufid insertion into flow_table.
Rebase.
v10: Ignore flow_key in requests if UFID is specified.
Only allow UFID flows to be indexed by UFID.
Only allow non-UFID flows to be indexed by unmasked flow key.
Unite the unmasked_key and ufid+ufid_hash in 'struct sw_flow'.
Don't periodically rehash the UFID table.
Resize the UFID table independently from the flow table.
Modify table_destroy() to iterate once and delete from both tables.
Fix UFID memory leak in flow_free().
Remove kernel-only UFIDs for non-UFID cases.
Rename OVS_UFID_F_SKIP_* - OVS_UFID_F_OMIT_*
Update documentation.
Rebase.
v9: No change.
v8: Rename UID - UFID unique flow identifier.
Fix null dereference when adding flow without uid or mask.
If UFID and not match are specified, and lookup fails, return ENOENT.
Rebase.
v7: Remove OVS_DP_F_INDEX_BY_UID.
Rework UID serialisation for variable-length UID.
Log error if uid not specified and OVS_UID_F_SKIP_KEY is set.
Rebase against probe logging changes.
v6: Fix documentation for supporting UIDs between 32-128 bits.
Minor style fixes.
Rebase.
v5: No change.
v4: Fix memory leaks.
Log when triggering the older userspace issue above.
v3: Initial post.
---
Documentation/networking/openvswitch.txt | 13 ++
include/uapi/linux/openvswitch.h | 20 +++
net/openvswitch/datapath.c | 207 ++
net/openvswitch/flow.h | 28 +++-
net/openvswitch/flow_netlink.c | 68 +-
net/openvswitch/flow_netlink.h |8 +-
net/openvswitch/flow_table.c | 187 ++-
net/openvswitch/flow_table.h |8 +-
8 files changed, 448 insertions(+), 91 deletions(-)
diff --git a/Documentation/networking/openvswitch.txt
b/Documentation/networking/openvswitch.txt
index 37c20ee..b3b9ac6 100644
--- a/Documentation/networking/openvswitch.txt
+++ b/Documentation/networking/openvswitch.txt
@@ -131,6 +131,19 @@ performs best-effort detection of overlapping wildcarded
flows and may reject
some but not all of them. However, this behavior may change in future versions.
+Unique flow identifiers
+---
+
+An alternative to using the original match portion of a key as the handle for
+flow identification is a unique flow identifier, or UFID. UFIDs are optional
+for both the kernel and user space program.
+
+User space programs that support UFID are expected to provide it during flow
+setup in addition to the flow, then refer to the flow using the UFID for all
+future operations. The kernel is not required to index flows by the original
+flow key if
[PATCH net-next v14 1/5] openvswitch: Refactor ovs_nla_fill_match().
Refactor the ovs_nla_fill_match() function into separate netlink
serialization functions ovs_nla_put_{unmasked_key,mask}(). Modify
ovs_nla_put_flow() to handle attribute nesting and expose the 'is_mask'
parameter - all callers need to nest the flow, and callers have better
knowledge about whether it is serializing a mask or not.
Signed-off-by: Joe Stringer joestrin...@nicira.com
---
net/openvswitch/datapath.c | 41 ++--
net/openvswitch/flow_netlink.c | 38 ++---
net/openvswitch/flow_netlink.h |7 +--
3 files changed, 46 insertions(+), 40 deletions(-)
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index f45f1bf..257b975 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -461,10 +461,8 @@ static int queue_userspace_packet(struct datapath *dp,
struct sk_buff *skb,
0, upcall_info-cmd);
upcall-dp_ifindex = dp_ifindex;
- nla = nla_nest_start(user_skb, OVS_PACKET_ATTR_KEY);
- err = ovs_nla_put_flow(key, key, user_skb);
+ err = ovs_nla_put_key(key, key, OVS_PACKET_ATTR_KEY, false, user_skb);
BUG_ON(err);
- nla_nest_end(user_skb, nla);
if (upcall_info-userdata)
__nla_put(user_skb, OVS_PACKET_ATTR_USERDATA,
@@ -676,37 +674,6 @@ static size_t ovs_flow_cmd_msg_size(const struct
sw_flow_actions *acts)
}
/* Called with ovs_mutex or RCU read lock. */
-static int ovs_flow_cmd_fill_match(const struct sw_flow *flow,
- struct sk_buff *skb)
-{
- struct nlattr *nla;
- int err;
-
- /* Fill flow key. */
- nla = nla_nest_start(skb, OVS_FLOW_ATTR_KEY);
- if (!nla)
- return -EMSGSIZE;
-
- err = ovs_nla_put_flow(flow-unmasked_key, flow-unmasked_key, skb);
- if (err)
- return err;
-
- nla_nest_end(skb, nla);
-
- /* Fill flow mask. */
- nla = nla_nest_start(skb, OVS_FLOW_ATTR_MASK);
- if (!nla)
- return -EMSGSIZE;
-
- err = ovs_nla_put_flow(flow-key, flow-mask-key, skb);
- if (err)
- return err;
-
- nla_nest_end(skb, nla);
- return 0;
-}
-
-/* Called with ovs_mutex or RCU read lock. */
static int ovs_flow_cmd_fill_stats(const struct sw_flow *flow,
struct sk_buff *skb)
{
@@ -787,7 +754,11 @@ static int ovs_flow_cmd_fill_info(const struct sw_flow
*flow, int dp_ifindex,
ovs_header-dp_ifindex = dp_ifindex;
- err = ovs_flow_cmd_fill_match(flow, skb);
+ err = ovs_nla_put_unmasked_key(flow, skb);
+ if (err)
+ goto error;
+
+ err = ovs_nla_put_mask(flow, skb);
if (err)
goto error;
diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
index d210d1b..33751f8 100644
--- a/net/openvswitch/flow_netlink.c
+++ b/net/openvswitch/flow_netlink.c
@@ -1216,12 +1216,12 @@ int ovs_nla_get_flow_metadata(const struct nlattr *attr,
return metadata_from_nlattrs(match, attrs, a, false, log);
}
-int ovs_nla_put_flow(const struct sw_flow_key *swkey,
-const struct sw_flow_key *output, struct sk_buff *skb)
+static int __ovs_nla_put_key(const struct sw_flow_key *swkey,
+const struct sw_flow_key *output, bool is_mask,
+struct sk_buff *skb)
{
struct ovs_key_ethernet *eth_key;
struct nlattr *nla, *encap;
- bool is_mask = (swkey != output);
if (nla_put_u32(skb, OVS_KEY_ATTR_RECIRC_ID, output-recirc_id))
goto nla_put_failure;
@@ -1431,6 +1431,38 @@ nla_put_failure:
return -EMSGSIZE;
}
+int ovs_nla_put_key(const struct sw_flow_key *swkey,
+ const struct sw_flow_key *output, int attr, bool is_mask,
+ struct sk_buff *skb)
+{
+ int err;
+ struct nlattr *nla;
+
+ nla = nla_nest_start(skb, attr);
+ if (!nla)
+ return -EMSGSIZE;
+ err = __ovs_nla_put_key(swkey, output, is_mask, skb);
+ if (err)
+ return err;
+ nla_nest_end(skb, nla);
+
+ return 0;
+}
+
+/* Called with ovs_mutex or RCU read lock. */
+int ovs_nla_put_unmasked_key(const struct sw_flow *flow, struct sk_buff *skb)
+{
+ return ovs_nla_put_key(flow-unmasked_key, flow-unmasked_key,
+ OVS_FLOW_ATTR_KEY, false, skb);
+}
+
+/* Called with ovs_mutex or RCU read lock. */
+int ovs_nla_put_mask(const struct sw_flow *flow, struct sk_buff *skb)
+{
+ return ovs_nla_put_key(flow-key, flow-mask-key,
+ OVS_FLOW_ATTR_MASK, true, skb);
+}
+
#define MAX_ACTIONS_BUFSIZE(32 * 1024)
static struct sw_flow_actions *nla_alloc_flow_actions(int size, bool log)
diff --git a/net/openvswitch/flow_netlink.h b/net/openvswitch/flow_netlink.h
index 577f12b..9ed09e6 100644
[PATCH net-next v14 2/5] openvswitch: Refactor ovs_flow_tbl_insert().
Rework so that ovs_flow_tbl_insert() calls flow_{key,mask}_insert().
This tidies up a future patch.
Signed-off-by: Joe Stringer joestrin...@nicira.com
---
net/openvswitch/flow_table.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/net/openvswitch/flow_table.c b/net/openvswitch/flow_table.c
index 5899bf1..81b977d 100644
--- a/net/openvswitch/flow_table.c
+++ b/net/openvswitch/flow_table.c
@@ -585,16 +585,10 @@ static int flow_mask_insert(struct flow_table *tbl,
struct sw_flow *flow,
}
/* Must be called with OVS mutex held. */
-int ovs_flow_tbl_insert(struct flow_table *table, struct sw_flow *flow,
- const struct sw_flow_mask *mask)
+static void flow_key_insert(struct flow_table *table, struct sw_flow *flow)
{
struct table_instance *new_ti = NULL;
struct table_instance *ti;
- int err;
-
- err = flow_mask_insert(table, flow, mask);
- if (err)
- return err;
flow-hash = flow_hash(flow-key, flow-mask-range.start,
flow-mask-range.end);
@@ -613,6 +607,19 @@ int ovs_flow_tbl_insert(struct flow_table *table, struct
sw_flow *flow,
table_instance_destroy(ti, true);
table-last_rehash = jiffies;
}
+}
+
+/* Must be called with OVS mutex held. */
+int ovs_flow_tbl_insert(struct flow_table *table, struct sw_flow *flow,
+ const struct sw_flow_mask *mask)
+{
+ int err;
+
+ err = flow_mask_insert(table, flow, mask);
+ if (err)
+ return err;
+ flow_key_insert(table, flow);
+
return 0;
}
--
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/2] livepatch: disable/enable_patch manners for interdependent patches
On 2015/1/21 22:08, Jiri Kosina wrote:
On Wed, 21 Jan 2015, Li Bin wrote:
for disable_patch:
The patch is unallowed to be disabled if one patch after has
dependencies with it and has been enabled.
for enable_patch:
The patch is unallowed to be enabled if one patch before has
dependencies with it and has been disabled.
Signed-off-by: Li Bin huawei.li...@huawei.com
---
kernel/livepatch/core.c | 60
+++
1 files changed, 60 insertions(+), 0 deletions(-)
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index 7861ed2..a12a31c 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -114,6 +114,21 @@ static bool klp_is_patch_registered(struct klp_patch
*patch)
return false;
}
+static bool klp_func_in_patch(struct klp_func *kfunc, struct klp_patch
*patch)
+{
+struct klp_object *obj;
+struct klp_func *func;
+
+for (obj = patch-objs; obj-funcs; obj++) {
+for (func = obj-funcs; func-old_name; func++) {
+if (kfunc-old_addr == func-old_addr) {
+return true;
+}
+}
+}
+return false;
+}
+
static bool klp_initialized(void)
{
return klp_root_kobj;
@@ -466,8 +481,31 @@ unregister:
static int __klp_disable_patch(struct klp_patch *patch)
{
struct klp_object *obj;
+struct klp_patch *temp;
+struct klp_func *func;
int ret;
+/*
+ * the patch is unallowed to be disabled if one patch
+ * after has dependencies with it and has been enabled.
+ */
+for (temp = list_next_entry(patch, list);
+temp-list != klp_patches;
+temp = list_next_entry(temp, list)) {
+if (temp-state != KLP_ENABLED)
+continue;
+
+for (obj = patch-objs; obj-funcs; obj++) {
+for (func = obj-funcs; func-old_name; func++) {
+if (klp_func_in_patch(func, temp)) {
+pr_err(this patch depends on '%s',
please disable it firstly\n,
+ temp-mod-name);
+return -EBUSY;
+}
+}
+}
+}
+
pr_notice(disabling patch '%s'\n, patch-mod-name);
for (obj = patch-objs; obj-funcs; obj++) {
@@ -519,11 +557,33 @@ EXPORT_SYMBOL_GPL(klp_disable_patch);
static int __klp_enable_patch(struct klp_patch *patch)
{
struct klp_object *obj;
+struct klp_patch *temp;
+struct klp_func *func;
int ret;
if (WARN_ON(patch-state != KLP_DISABLED))
return -EINVAL;
+/*
+ * the patch is unallowed to be enabled if one patch
+ * before has dependencies with it and has been disabled.
+ */
+for (temp = list_first_entry(klp_patches, struct klp_patch, list);
+temp != patch; temp = list_next_entry(temp, list)) {
+if (temp-state != KLP_DISABLED)
+continue;
+
+for (obj = patch-objs; obj-funcs; obj++) {
+for (func = obj-funcs; func-old_name; func++) {
+if (klp_func_in_patch(func, temp)) {
+pr_err(this patch depends on '%s',
please enable it firstly\n,
+ temp-mod-name);
+return -EBUSY;
By this you limit the definition of the patch inter-dependency to just
symbols. But that's not the only way how patches can depend on it other --
the dependency can be semantical.
Yes, I agree with you. But I think the other dependencies such as semantical
dependency should be judged by the user, like reverting a patch from git
repository.
Right?
Thanks,
Li Bin
--
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 net-next v14 0/5] openvswitch: Introduce 128-bit unique flow identifiers.
This series extends the openvswitch datapath interface for flow commands to use 128-bit unique identifiers as an alternative to the netlink-formatted flow key. This significantly reduces the cost of assembling messages between the kernel and userspace, in particular improving Open vSwitch revalidation performance by 40% or more. v14: - Perform lookup using unmasked key in legacy case. - Fix minor checkpatch.pl style violations. v13: - Embed sw_flow_id in sw_flow to save memory allocation in UFID case. - Malloc unmasked key for id in non-UFID case. - Fix bug where non-UFID case could double-serialize keys. v12: - Userspace patches fully merged into Open vSwitch master - New minor refactor patches (2,3,4) - Merge unmasked_key, ufid representation of flow identifier in sw_flow - Improve memory allocation sizes when serializing ufid - Handle corner case where a flow_new is requested with a flow that has an identical ufid as an existing flow, but a different flow key - Limit UFID to between 1-16 octets inclusive. - Add various helper functions to improve readibility v11: - Pushed most of the prerequisite patches for this series to OVS master. - Split out openvswitch.h interface changes from datapath implementation - Datapath implementation to be reviewed on net-next, separately v10: - New patch allowing datapath to serialize masked keys - Simplify datapath interface by accepting UFID or flow_key, but not both - Flows set up with UFID must be queried/deleted using UFID - Reduce sw_flow memory usage for UFID - Don't periodically rehash UFID table in linux datapath - Remove kernel_only UFID in linux datapath v9: - No kernel changes v8: - Rename UID - UFID - Fix null dereference in datapath when paired with older userspace - All patches are reviewed/acked except datapath changes. v7: - Remove OVS_DP_F_INDEX_BY_UID - Rework datapath UID serialization for variable length UIDs v6: - Reduce netlink conversions for all datapaths - Various bugfixes v5: - Various bugfixes - Improve logging v4: - Datapath memory leak fixes - Enable UID-based terse dumping and deleting by default - Various fixes RFCv3: - Add datapath implementation Joe Stringer (5): openvswitch: Refactor ovs_nla_fill_match(). openvswitch: Refactor ovs_flow_tbl_insert(). openvswitch: Use sw_flow_key_range for key ranges. genetlink: Add genlmsg_parse() helper function. openvswitch: Add support for unique flow IDs. Documentation/networking/openvswitch.txt | 13 ++ include/net/genetlink.h | 17 +++ include/uapi/linux/openvswitch.h | 20 +++ net/openvswitch/datapath.c | 226 -- net/openvswitch/flow.h | 28 +++- net/openvswitch/flow_netlink.c | 102 +- net/openvswitch/flow_netlink.h | 13 +- net/openvswitch/flow_table.c | 226 +++--- net/openvswitch/flow_table.h |8 +- 9 files changed, 519 insertions(+), 134 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/
Re: rcu, sched: WARNING: CPU: 30 PID: 23771 at kernel/rcu/tree_plugin.h:337 rcu_read_unlock_special+0x369/0x550()
On Wed, Jan 21, 2015 at 10:44:57AM -0500, Sasha Levin wrote:
On 01/20/2015 09:57 PM, Paul E. McKenney wrote:
So RCU believes that an RCU read-side critical section that ended within
an interrupt handler (in this case, an hrtimer) somehow got preempted.
Which is not supposed to happen.
Do you have CONFIG_PROVE_RCU enabled? If not, could you please
enable it
and retry?
I did have CONFIG_PROVE_RCU, and didn't see anything else besides what I
pasted here.
OK, fair enough. I do have a stack of RCU CPU stall-warning changes on
their way in, please see v3.19-rc1..630181c4a915 in -rcu, which is at:
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
These handle the problems that Dave Jones, yourself, and a few others
located this past December. Could you please give them a spin?
They seem to be a part of -next already, so this testing already includes
them.
I seem to be getting them about once a day, anything I can add to debug it?
Could you please try reproducing with the following patch?
Thanx, Paul
rcu: Improve diagnostics for blocked critical sections in irq
If an RCU read-side critical section occurs within an interrupt handler
or a softirq handler, it cannot have been preempted. Therefore, there is
a check in rcu_read_unlock_special() checking for this error. However,
when this check triggers, it lacks diagnostic information. This commit
therefore moves rcu_read_unlock()'s lockdep annotation to follow the
call to __rcu_read_unlock() and changes rcu_read_unlock_special()'s
WARN_ON_ONCE() to an lockdep_rcu_suspicious() in order to locate where
the offending RCU read-side critical section began. In addition, the
value of the -rcu_read_unlock_special field is printed.
Signed-off-by: Paul E. McKenney paul...@linux.vnet.ibm.com
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index 3e6afed51051..70b896e16f19 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -942,9 +942,9 @@ static inline void rcu_read_unlock(void)
{
rcu_lockdep_assert(rcu_is_watching(),
rcu_read_unlock() used illegally while idle);
- rcu_lock_release(rcu_lock_map);
__release(RCU);
__rcu_read_unlock();
+ rcu_lock_release(rcu_lock_map); /* Keep acq info for rls diags. */
}
/**
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index bb947ef1a2a4..8d2b497b52e9 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -334,7 +334,13 @@ void rcu_read_unlock_special(struct task_struct *t)
}
/* Hardware IRQ handlers cannot block, complain if they get here. */
- if (WARN_ON_ONCE(in_irq() || in_serving_softirq())) {
+ if (in_irq() || in_serving_softirq()) {
+ lockdep_rcu_suspicious(__FILE__, __LINE__,
+ rcu_read_unlock() from irq or softirq
with blocking in critical section!!!\n);
+ pr_alert(-rcu_read_unlock_special: %#x (b: %d, nq: %d)\n,
+t-rcu_read_unlock_special.s,
+t-rcu_read_unlock_special.b.blocked,
+t-rcu_read_unlock_special.b.need_qs);
local_irq_restore(flags);
return;
}
--
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: [GIT PULL] qcom SoC changes for v3.20
Hi, On Mon, Jan 19, 2015 at 12:27:15PM -0600, Kumar Gala wrote: The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672: Linux 3.19-rc1 (2014-12-20 17:08:50 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git tags/qcom-soc-for-3.20 for you to fetch changes up to ae0a6075c046f9c8dbac18f53a779592f97b402e: soc: qcom: scm: Clarify boot interface (2015-01-19 11:55:12 -0600) Qualcomm ARM Based SoC Updates for v3.20 * Moved scm support into drivers/soc/qcom (allows for use by drivers) * Various bug fixes and minor feature additions to scm code * Added big-endian support to debug MSM uart * Added big-endian support to ARCH_QCOM Lina Iyer (2): ARM: qcom: Add SCM warmboot flags for quad core targets. soc: qcom: scm: Move scm-boot files to drivers/soc and include/soc Olav Haugan (1): ARM: qcom: scm: Add logging of actual return code from scm call Saravana Kannan (1): ARM: qcom: scm: Add API to query for service/command availability. Stephen Boyd (9): ARM: debug: Update MSM and QCOM DEBUG_LL help ARM: debug: msm: Support big-endian CPUs ARM: qcom: Select ARCH_SUPPORTS_BIG_ENDIAN ARM: qcom: scm: Fix incorrect cache invalidation ARM: qcom: scm: Get cacheline size from CTR ARM: qcom: scm: Add a feat version query API soc: qcom: scm: Move the scm driver to drivers/soc/qcom I replied on the patch here just now. This isn't the right thing to do, as far as I can tell. Seems like sending a fresh request with the material besides the move to drivers/soc should be mergeable though, so feel free to do that while the rest is hashed out. -Olof -- 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] mm: move MACRO SLAB_NEVER_MERGE and SLAB_MERGE_SAME to file linux/slab.h
On Wed, 7 Jan 2015, Bryton Lee wrote: thanks for review my patch. I want to move these macros to linux/slab.h cause I don't want perform merge in slab level. for example. ss read /proc/slabinfo to finger out how many requests pending in the TCP listern queue. it use slabe name tcp_timewait_sock_ops search in /proc/slabinfo, although the name is obsolete. so I committed other patch to iproute2, replaced tcp_timewait_sock_ops by request_sock_TCP, but it still not work, because slab request_sock_TCP merge into kmalloc-256. how could I prevent this merge happen. I'm new to kernel, this is my first time submit a kernel patch, thanks! Any bit in SLAB_NEVER_MERGE will cause the allocator to not merge the slab caches, it's not necessary to all of them be set as it seems you're implying. -- 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 RESEND] fs: namei: Use memcpy instead of strlcpy
If the string length is known, there is no need to use strlcpy. Use memcpy instead. Signed-off-by: Guenter Roeck li...@roeck-us.net --- Nitpick, but still a bit faster. Applies on top of -next. Resending with correct cc:. Sorry for the noise. fs/namei.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/namei.c b/fs/namei.c index 323957f..2e09219 100644 --- a/fs/namei.c +++ b/fs/namei.c @@ -233,7 +233,7 @@ getname_kernel(const char * filename) __putname(result); return ERR_PTR(-ENAMETOOLONG); } - strlcpy((char *)result-name, filename, len); + memcpy((char *)result-name, filename, len); result-uptr = NULL; result-aname = NULL; result-refcnt = 1; -- 2.1.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/2] watchdog: dw_wdt: pat the watchdog before enabling it
On 01/21/2015 03:17 PM, Doug Anderson wrote: On some dw_wdt implementations the top register may be initted to 0 at bootup. In such a case, each pat of the watchdog will reset the timer to 0x. That's pretty short. The input clock of the wdt can be any of a wide range of values. On an rk3288 system, I've seen the wdt clock be 24.75 MHz. That means each tick is ~40ns and we'll count to 0x in ~2.6ms. Because of the above two facts, it's a really good idea to pat the watchdog after initting the top register properly and before enabling the watchdog. If you don't then there's no way we'll get the next heartbeat in time. Signed-off-by: Doug Anderson diand...@chromium.org --- Reviewed-by: Guenter Roeck li...@roeck-us.net -- 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] watchdog: dw_wdt: Try to get a 30 second watchdog by default
On 01/21/2015 03:17 PM, Doug Anderson wrote: The dw_wdt_set_top() function takes in a value in seconds. In dw_wdt_open() we were calling it with a value that's supposed to represent the maximum value programmed into the top register with a comment saying that we were trying to set the watchdog to its maximum value. Instead we ended up setting the watchdog to ~15 seconds. Let's fix this. However, setting things to the max gives me an 86 second watchdog in the system I'm looking at. 86 seconds feels a little too long. We'll explicitly choose 30 seconds as a more reasonable value. NOTE: Ideally this driver should be transitioned to be a real watchdog driver. Then we could use watchdog_init_timeout and let the timeout be specified in a number of ways (device tree, module parameter, etc). This patch should be considered a bit of a stopgap solution. Signed-off-by: Doug Anderson diand...@chromium.org --- Reviewed-by: Guenter Roeck li...@roeck-us.net -- 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] clk: Introduce clk_has_parent()
On 01/21/2015 08:13 AM, Thierry Reding wrote:
From: Thierry Reding tred...@nvidia.com
This new function is similar to clk_set_parent(), except that it doesn't
actually change the parent. It merely checks that the given parent clock
can be a parent for the given clock.
A situation where this is useful is to check that a particular setup is
valid before switching to it. One specific use-case for this is atomic
modesetting in the DRM framework where setting a mode is divided into a
check phase where a given configuration is validated before applying
changes to the hardware.
Cc: Russell King li...@arm.linux.org.uk
Cc: Mike Turquette mturque...@linaro.org
Cc: Stephen Boyd sb...@codeaurora.org
Signed-off-by: Thierry Reding tred...@nvidia.com
---
Reviewed-by: Stephen Boyd sb...@codeaurora.org
This will slightly conflict with Tomeu's patches for per-user clock
constraints. It would be best if we can take this through the clk tree
to fix up any conflicts
Changes in v2:
- lookup parent name in parent names array and make function lockless
- rename function from clk_try_parent() to clk_has_parent()
- return boolean
drivers/clk/clk.c | 30 ++
include/linux/clk.h | 17 +
2 files changed, 47 insertions(+)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index af06b7377d37..470266297dea 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1672,6 +1672,36 @@ void __clk_reparent(struct clk *clk, struct clk
*new_parent)
}
/**
+ * clk_has_parent - check if a clock is a possible parent for another
+ * @clk: clock source
+ * @parent: parent clock source
+ *
+ * This function can be used in drivers that need to check that a clock can
be
+ * the parent of another without actually changing the parent.
+ *
+ * Returns true if @parent is a possible parent for @clk, false otherwise.
+ */
+bool clk_has_parent(struct clk *clk, struct clk *parent)
+{
+ unsigned int i;
+
+ /* NULL clocks should be nops, so return success if either is NULL. */
+ if (!clk || !parent)
+ return true;
+
+ /* Optimize for the case where the parent is already the parent. */
+ if (clk-parent == parent)
+ return true;
I worry that we'll need to grab a lock here with Tomeu's patches, but
maybe I'm wrong.
+
+ for (i = 0; i clk-num_parents; i++)
+ if (strcmp(clk-parent_names[i], parent-name) == 0)
+ return true;
+
+ return false;
+}
+EXPORT_SYMBOL_GPL(clk_has_parent);
+
+/**
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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 v9 00/17] Kernel address sanitizer - runtime memory debugger.
On 01/21/2015 11:51 AM, Andrey Ryabinin wrote: Changes since v8: - Fixed unpoisoned redzones for not-allocated-yet object in newly allocated slab page. (from Dmitry C.) - Some minor non-function cleanups in kasan internals. - Added ack from Catalin - Added stack instrumentation. With this we could detect out of bounds accesses in stack variables. (patch 12) - Added globals instrumentation - catching out of bounds in global varibles. (patches 13-17) - Shadow moved out from vmalloc into hole between vmemmap and %esp fixup stacks. For globals instrumentation we will need shadow backing modules addresses. So we need some sort of a shadow memory allocator (something like vmmemap_populate() function, except that it should be available after boot). __vmalloc_node_range() suits that purpose, except that it can't be used for allocating for shadow in vmalloc area because shadow in vmalloc is already 'allocated' to protect us from other vmalloc users. So we need 16TB of unused addresses. And we have big enough hole between vmemmap and %esp fixup stacks. So I moved shadow there. I'm not sure which new addition caused it, but I'm getting tons of false positives from platform drivers trying to access memory they don't own - because they expect to find hardware there. I suspect we'd need to mark that memory region somehow to prevent accesses to it from triggering warnings? Thanks, Sasha -- 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 RESEND] fs: namei: Use memcpy instead of strlcpy
Good point. Do you mind if I merge your patch into my existing patch instead of including it separately? -- paul moore www.paul-moore.com On January 21, 2015 5:45:29 PM Guenter Roeck li...@roeck-us.net wrote: If the string length is known, there is no need to use strlcpy. Use memcpy instead. Signed-off-by: Guenter Roeck li...@roeck-us.net --- Nitpick, but still a bit faster. Applies on top of -next. Resending with correct cc:. Sorry for the noise. fs/namei.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/namei.c b/fs/namei.c index 323957f..2e09219 100644 --- a/fs/namei.c +++ b/fs/namei.c @@ -233,7 +233,7 @@ getname_kernel(const char * filename) __putname(result); return ERR_PTR(-ENAMETOOLONG); } - strlcpy((char *)result-name, filename, len); + memcpy((char *)result-name, filename, len); result-uptr = NULL; result-aname = NULL; result-refcnt = 1; -- 2.1.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/ -- 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] livepatch: Revert livepatch: enforce patch stacking semantics
On 2015/1/21 22:36, Seth Jennings wrote: On Wed, Jan 21, 2015 at 03:06:38PM +0100, Jiri Kosina wrote: On Wed, 21 Jan 2015, Li Bin wrote: This reverts commit 83a90bb1345767f0cb96d242fd8b9db44b2b0e17. The method that only allowing the topmost patch on the stack to be enabled or disabled is unreasonable. Such as the following case: - do live patch1 - disable patch1 - do live patch2 //error Now, we will never be able to do new live patch unless disabing the patch1 although there is no dependencies. Unregistering disabled patch still works and removes it from the list no matter the position. So what exactly is the problem? From a quick glance, it seems that what this set does is it only enforces the stacking requirements if two patches patch the same function. Yes, this patch is only concerning this case that 'multi patches patch the same function' and solve the problem that mentioned previously: foo_unpatched() foo_patch1() foo_patch2() foo_patch3() disable(foo_patch2) disable(foo_patch3) foo_patch1() foo_patch2 is not allowed to be disabled before disable foo_patch3. Thanks, Li Bin I'm not sure if that is correct logically or correctly implemented by these patches yet. Seth -- Jiri Kosina SUSE Labs . -- 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 net-next v14 3/5] openvswitch: Use sw_flow_key_range for key ranges.
These minor tidyups make a future patch a little tidier.
Signed-off-by: Joe Stringer joestrin...@nicira.com
---
net/openvswitch/flow_table.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/net/openvswitch/flow_table.c b/net/openvswitch/flow_table.c
index 81b977d..9a3f41f 100644
--- a/net/openvswitch/flow_table.c
+++ b/net/openvswitch/flow_table.c
@@ -357,9 +357,11 @@ int ovs_flow_tbl_flush(struct flow_table *flow_table)
return 0;
}
-static u32 flow_hash(const struct sw_flow_key *key, int key_start,
-int key_end)
+static u32 flow_hash(const struct sw_flow_key *key,
+const struct sw_flow_key_range *range)
{
+ int key_start = range-start;
+ int key_end = range-end;
const u32 *hash_key = (const u32 *)((const u8 *)key + key_start);
int hash_u32s = (key_end - key_start) 2;
@@ -395,9 +397,9 @@ static bool cmp_key(const struct sw_flow_key *key1,
static bool flow_cmp_masked_key(const struct sw_flow *flow,
const struct sw_flow_key *key,
- int key_start, int key_end)
+ const struct sw_flow_key_range *range)
{
- return cmp_key(flow-key, key, key_start, key_end);
+ return cmp_key(flow-key, key, range-start, range-end);
}
bool ovs_flow_cmp_unmasked_key(const struct sw_flow *flow,
@@ -416,18 +418,15 @@ static struct sw_flow *masked_flow_lookup(struct
table_instance *ti,
{
struct sw_flow *flow;
struct hlist_head *head;
- int key_start = mask-range.start;
- int key_end = mask-range.end;
u32 hash;
struct sw_flow_key masked_key;
ovs_flow_mask_key(masked_key, unmasked, mask);
- hash = flow_hash(masked_key, key_start, key_end);
+ hash = flow_hash(masked_key, mask-range);
head = find_bucket(ti, hash);
hlist_for_each_entry_rcu(flow, head, hash_node[ti-node_ver]) {
if (flow-mask == mask flow-hash == hash
- flow_cmp_masked_key(flow, masked_key,
- key_start, key_end))
+ flow_cmp_masked_key(flow, masked_key, mask-range))
return flow;
}
return NULL;
@@ -590,8 +589,7 @@ static void flow_key_insert(struct flow_table *table,
struct sw_flow *flow)
struct table_instance *new_ti = NULL;
struct table_instance *ti;
- flow-hash = flow_hash(flow-key, flow-mask-range.start,
- flow-mask-range.end);
+ flow-hash = flow_hash(flow-key, flow-mask-range);
ti = ovsl_dereference(table-ti);
table_instance_insert(ti, flow);
table-count++;
--
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 net-next v14 4/5] genetlink: Add genlmsg_parse() helper function.
The first user will be the next patch.
Signed-off-by: Joe Stringer joestrin...@nicira.com
---
include/net/genetlink.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/net/genetlink.h b/include/net/genetlink.h
index f24aa83..d5a9a8b 100644
--- a/include/net/genetlink.h
+++ b/include/net/genetlink.h
@@ -206,6 +206,23 @@ static inline struct nlmsghdr *genlmsg_nlhdr(void
*user_hdr,
}
/**
+ * genlmsg_parse - parse attributes of a genetlink message
+ * @nlh: netlink message header
+ * @family: genetlink message family
+ * @tb: destination array with maxtype+1 elements
+ * @maxtype: maximum attribute type to be expected
+ * @policy: validation policy
+ * */
+static inline int genlmsg_parse(const struct nlmsghdr *nlh,
+ const struct genl_family *family,
+ struct nlattr *tb[], int maxtype,
+ const struct nla_policy *policy)
+{
+ return nlmsg_parse(nlh, family-hdrsize + GENL_HDRLEN, tb, maxtype,
+ policy);
+}
+
+/**
* genl_dump_check_consistent - check if sequence is consistent and advertise
if not
* @cb: netlink callback structure that stores the sequence number
* @user_hdr: user header as returned from genlmsg_put()
--
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 tip 0/9] tracing: attach eBPF programs to tracepoints/syscalls/kprobe
Hi Alexei, On Fri, Jan 16, 2015 at 10:57:15AM -0800, Alexei Starovoitov wrote: On Fri, Jan 16, 2015 at 7:02 AM, Steven Rostedt rost...@goodmis.org wrote: One last thing. If the ebpf is used for anything but filtering, it should go into the trigger file. The filtering is only a way to say if the event should be recorded or not. But the trigger could do something else (a printk, a stacktrace, etc). it does way more than just filtering, but invoking program as a trigger is too slow. When program is called as soon as tracepoint fires, it can fetch other fields, evaluate them, printk some of them, optionally dump stack, aggregate into maps. We can let it call triggers too, so that user program will be able to enable/disable other events. I'm not against invoking programs as a trigger, but I don't see a use case for it. It's just too slow for production analytics that needs to act on huge number of events per second. AFAIK a trigger can be fired before allocating a ring buffer if it doesn't use the event record (i.e. has filter) or -post_trigger bit set (stacktrace). Please see ftrace_trigger_soft_disabled(). This also makes it keeping events in the soft-disabled state. Thanks, Namhyung We must minimize the overhead between tracepoint firing and program executing, so that programs can be used on events like packet receive which will be in millions per second. Every nsec counts. For example: - raw dd if=/dev/zero of=/dev/null does 760 MB/s (on my debug kernel) - echo 1 events/syscalls/sys_enter_write/enable drops it to 400 MB/s - echo echo count == 123 events/syscalls/sys_enter_write/filter drops it even further down to 388 MB/s This slowdown is too high for this to be used on a live system. - tracex4 that computes histogram of sys_write sizes and stores log2(count) into a map does 580 MB/s This is still not great, but this slowdown is now usable and we can work further on minimizing the overhead. -- 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/ -- 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 net-next v14 1/5] openvswitch: Refactor ovs_nla_fill_match().
On Wed, Jan 21, 2015 at 4:42 PM, Joe Stringer joestrin...@nicira.com wrote:
Refactor the ovs_nla_fill_match() function into separate netlink
serialization functions ovs_nla_put_{unmasked_key,mask}(). Modify
ovs_nla_put_flow() to handle attribute nesting and expose the 'is_mask'
parameter - all callers need to nest the flow, and callers have better
knowledge about whether it is serializing a mask or not.
Signed-off-by: Joe Stringer joestrin...@nicira.com
Acked-by: Pravin B Shelar pshe...@nicira.com
--
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 net-next v14 4/5] genetlink: Add genlmsg_parse() helper function.
On Wed, Jan 21, 2015 at 4:42 PM, Joe Stringer joestrin...@nicira.com wrote: The first user will be the next patch. Signed-off-by: Joe Stringer joestrin...@nicira.com Acked-by: Pravin B Shelar pshe...@nicira.com -- 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 net-next v14 2/5] openvswitch: Refactor ovs_flow_tbl_insert().
On Wed, Jan 21, 2015 at 4:42 PM, Joe Stringer joestrin...@nicira.com wrote:
Rework so that ovs_flow_tbl_insert() calls flow_{key,mask}_insert().
This tidies up a future patch.
Signed-off-by: Joe Stringer joestrin...@nicira.com
Acked-by: Pravin B Shelar pshe...@nicira.com
--
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 net-next v14 5/5] openvswitch: Add support for unique flow IDs.
On Wed, Jan 21, 2015 at 4:42 PM, Joe Stringer joestrin...@nicira.com wrote: Previously, flows were manipulated by userspace specifying a full, unmasked flow key. This adds significant burden onto flow serialization/deserialization, particularly when dumping flows. This patch adds an alternative way to refer to flows using a variable-length unique flow identifier (UFID). At flow setup time, userspace may specify a UFID for a flow, which is stored with the flow and inserted into a separate table for lookup, in addition to the standard flow table. Flows created using a UFID must be fetched or deleted using the UFID. All flow dump operations may now be made more terse with OVS_UFID_F_* flags. For example, the OVS_UFID_F_OMIT_KEY flag allows responses to omit the flow key from a datapath operation if the flow has a corresponding UFID. This significantly reduces the time spent assembling and transacting netlink messages. With all OVS_UFID_F_OMIT_* flags enabled, the datapath only returns the UFID and statistics for each flow during flow dump, increasing ovs-vswitchd revalidator performance by 40% or more. Signed-off-by: Joe Stringer joestrin...@nicira.com Looks good. Acked-by: Pravin B Shelar pshe...@nicira.com Thanks. -- 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/
linux-next: manual merge of the kvm-arm tree with the arm64 tree
Hi all,
Today's linux-next merge of the kvm-arm tree got a conflict in
arch/arm64/kvm/handle_exit.c between commit c6d01a947a51 (arm64: kvm:
move to ESR_ELx macros) from the arm64 tree and commit 0d97f8848104
(arm/arm64: KVM: add tracing support for arm64 exit handler) from the
kvm-arm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm64/kvm/handle_exit.c
index 29b184a8f3f8,6a7eb3ce7027..
--- a/arch/arm64/kvm/handle_exit.c
+++ b/arch/arm64/kvm/handle_exit.c
@@@ -63,10 -67,13 +69,13 @@@ static int handle_smc(struct kvm_vcpu *
*/
static int kvm_handle_wfx(struct kvm_vcpu *vcpu, struct kvm_run *run)
{
- if (kvm_vcpu_get_hsr(vcpu) ESR_ELx_WFx_ISS_WFE)
- if (kvm_vcpu_get_hsr(vcpu) ESR_EL2_EC_WFI_ISS_WFE) {
++ if (kvm_vcpu_get_hsr(vcpu) ESR_ELx_WFx_ISS_WFE) {
+ trace_kvm_wfx_arm64(*vcpu_pc(vcpu), true);
kvm_vcpu_on_spin(vcpu);
- else
+ } else {
+ trace_kvm_wfx_arm64(*vcpu_pc(vcpu), false);
kvm_vcpu_block(vcpu);
+ }
kvm_skip_instr(vcpu, kvm_vcpu_trap_il_is32bit(vcpu));
pgpdiCwYFQzTn.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the kvm-arm tree with the arm64 tree
Hi all, Today's linux-next merge of the kvm-arm tree got a conflict in arch/arm64/include/asm/kvm_arm.h between commit 6e53031ed840 (arm64: kvm: remove ESR_EL2_* macros) from the arm64 tree and commit 0d97f8848104 (arm/arm64: KVM: add tracing support for arm64 exit handler) from the kvm-arm tree. I fixed it up (see below, but this probably requires more work) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc arch/arm64/include/asm/kvm_arm.h index 94674eb7e7bb,3da2d3acec0b.. --- a/arch/arm64/include/asm/kvm_arm.h +++ b/arch/arm64/include/asm/kvm_arm.h @@@ -192,4 -217,46 +192,6 @@@ /* Hyp Prefetch Fault Address Register (HPFAR/HDFAR) */ #define HPFAR_MASK(~UL(0xf)) -#define ESR_EL2_EC_UNKNOWN(0x00) -#define ESR_EL2_EC_WFI(0x01) -#define ESR_EL2_EC_CP15_32(0x03) -#define ESR_EL2_EC_CP15_64(0x04) -#define ESR_EL2_EC_CP14_MR(0x05) -#define ESR_EL2_EC_CP14_LS(0x06) -#define ESR_EL2_EC_FP_ASIMD (0x07) -#define ESR_EL2_EC_CP10_ID(0x08) -#define ESR_EL2_EC_CP14_64(0x0C) -#define ESR_EL2_EC_ILL_ISS(0x0E) -#define ESR_EL2_EC_SVC32 (0x11) -#define ESR_EL2_EC_HVC32 (0x12) -#define ESR_EL2_EC_SMC32 (0x13) -#define ESR_EL2_EC_SVC64 (0x15) -#define ESR_EL2_EC_HVC64 (0x16) -#define ESR_EL2_EC_SMC64 (0x17) -#define ESR_EL2_EC_SYS64 (0x18) -#define ESR_EL2_EC_IABT (0x20) -#define ESR_EL2_EC_IABT_HYP (0x21) -#define ESR_EL2_EC_PC_ALIGN (0x22) -#define ESR_EL2_EC_DABT (0x24) -#define ESR_EL2_EC_DABT_HYP (0x25) -#define ESR_EL2_EC_SP_ALIGN (0x26) -#define ESR_EL2_EC_FP_EXC32 (0x28) -#define ESR_EL2_EC_FP_EXC64 (0x2C) -#define ESR_EL2_EC_SERROR (0x2F) -#define ESR_EL2_EC_BREAKPT(0x30) -#define ESR_EL2_EC_BREAKPT_HYP(0x31) -#define ESR_EL2_EC_SOFTSTP(0x32) -#define ESR_EL2_EC_SOFTSTP_HYP(0x33) -#define ESR_EL2_EC_WATCHPT(0x34) -#define ESR_EL2_EC_WATCHPT_HYP(0x35) -#define ESR_EL2_EC_BKPT32 (0x38) -#define ESR_EL2_EC_VECTOR32 (0x3A) -#define ESR_EL2_EC_BRK64 (0x3C) - -#define ESR_EL2_EC_xABT_xFSR_EXTABT 0x10 - -#define ESR_EL2_EC_WFI_ISS_WFE(1 0) - + #define ESR_EL2_HVC_IMM_MASK ((1UL 16) - 1) + #endif /* __ARM64_KVM_ARM_H__ */ pgpyAj7xyFZil.pgp Description: OpenPGP digital signature
[PATCH v2] dma: imx-sdma: switch to dynamic context mode after script loaded
Below comments got from Page4724 of Reference Manual of i.mx6q:
http://cache.freescale.com/files/32bit/doc/ref_manual/IMX6DQRM.pdf
--Static context mode should be used for the first channel called
after reset to ensure that the all context RAM for that channel is
initialized during the context SAVE phase when the channel is
done or yields. Subsequent calls to the same channel or
different channels may use any of the dynamic context modes.
This will ensure that all context locations for the bootload
channel are initialized, and prevent undefined values in context
RAM from being loaded during the context restore if the
channel is re-started later
Unfortunately, the rule was broken by
commit(5b28aa319bba96987316425a1131813d87cbab35)
.This patch just take them back.
Signed-off-by: Robin Gong b38...@freescale.com
---
drivers/dma/imx-sdma.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index d0df198..d84b7a8 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -330,6 +330,8 @@ struct sdma_engine {
const struct sdma_driver_data *drvdata;
};
+static bool channel0_first;
+
static struct sdma_driver_data sdma_imx31 = {
.chnenbl0 = SDMA_CHNENBL0_IMX31,
.num_events = 32,
@@ -531,6 +533,12 @@ static int sdma_run_channel0(struct sdma_engine *sdma)
dev_err(sdma-dev, Timeout waiting for CH0 ready\n);
}
+ if (!channel0_first) {
+ /* Set bits of CONFIG register with given context switching
mode */
+ writel_relaxed(SDMA_H_CONFIG_CSM, sdma-regs + SDMA_H_CONFIG);
+ channel0_first = true;
+ }
+
return ret ? 0 : -ETIMEDOUT;
}
@@ -1401,9 +1409,6 @@ static int sdma_init(struct sdma_engine *sdma)
writel_relaxed(ccb_phys, sdma-regs + SDMA_H_C0PTR);
- /* Set bits of CONFIG register with given context switching mode */
- writel_relaxed(SDMA_H_CONFIG_CSM, sdma-regs + SDMA_H_CONFIG);
-
/* Initializes channel's priorities */
sdma_set_channel_priority(sdma-channel[0], 7);
--
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: [PATCH 1/2] watchdog: dw_wdt: pat the watchdog before enabling it
On 01/21/2015 09:22 PM, Jisheng Zhang wrote: Dear Doug, On Wed, 21 Jan 2015 15:17:22 -0800 Doug Anderson diand...@chromium.org wrote: On some dw_wdt implementations the top register may be initted to 0 at bootup. In such a case, each pat of the watchdog will reset the timer to 0x. That's pretty short. + Guenter Roeck This should have been fixed by dfa07141e7a792(watchdog: dw_wdt: initialise TOP_INIT in dw_wdt_set_top()) Ah, yes. Doug, can you check if your patch is still needed ? Thanks, 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: [alsa-devel][PATCH 3/3] ASoC: fsl_sai: Add support for Right-J mode
On Thu, Jan 22, 2015 at 01:13:46PM +0800, Zidan Wang wrote: On Wed, Jan 21, 2015 at 10:53:20AM -0800, Nicolin Chen wrote: On Tue, Jan 20, 2015 at 08:21:20PM +0800, Zidan Wang wrote: Add Right-J mode and set TCR5 FBT bit to let data right justify. Signed-off-by: Zidan Wang zidan.w...@freescale.com - if (sai-is_lsb_first) + if (sai-is_lsb_first sai-is_right_j_mode) val_cr5 |= FSL_SAI_CR5_FBT(0); Are you sure that FBT(0) is correct for right justified mode? Because the original code is using FBT(0) for the lsb_first situation and it shouldn't be right justified mode as default. I am not sure about that. I assume lsb_first as big endian data. Correct. For 16 bit data format, the 2 bytes data will in high address of 4 bytes fifo. So the FBT is 16 for left-j and 0 for right-j. But big endian is bytes convert not bits convert. It makes me confuse. And send to community for help. Either waiting for Xiubo to test it or asking IC owner for help. Nicolin -- 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: [alsa-devel][PATCH 2/3] ASoC: fsl_sai: Add support for tdm slots operation
On Thu, Jan 22, 2015 at 12:55:35PM +0800, Zidan Wang wrote: On Wed, Jan 21, 2015 at 10:08:03AM -0800, Nicolin Chen wrote: On Tue, Jan 20, 2015 at 08:21:19PM +0800, Zidan Wang wrote: @@ -369,10 +380,25 @@ static int fsl_sai_hw_params(struct snd_pcm_substream *substream, u32 word_width = snd_pcm_format_width(params_format(params)); u32 val_cr4 = 0, val_cr5 = 0; int ret; + u32 bclk; + + if (channels == 1) + channels = 2; + + if (!sai-slots || sai-slots % channels) + sai-slots = channels; + + sai-slots = sai-slots / channels; + + if (sai-slot_width word_width || sai-is_dsp_mode) + sai-slot_width = word_width; Could you pls explain a bit what's this overriding for? Or it might be better to put into a comment. In machine driver, we should use snd_soc_dai_set_tdm_slot to set slots and slot width. In my opinion, slots in machine driver means the slot number of all channels. But in sai driver, the slots means the slot number of one channel. So snd_soc_calc_bclk use fs*sample_size*channels*tdm_slots to caculate bclk. Could you pls use the standard way as you described for slot number in machine driver instead of defining some other meanings? That one is really confusing, not to mention a code without any comment. You can add some extra local variables with extinguished names and calculate the slot number and channels you want without changing the original sai-slots and channels in the hw_params(). As you said, you only need that new slot number and channels for snd_soc_calc_bclk call. So you may also put this code right before the call -- a normal routine doesn't need to recalculate the special slots and channels, right? Nicolin -- 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 v9 00/17] Kernel address sanitizer - runtime memory debugger.
2015-01-22 8:34 GMT+03:00 Andrey Ryabinin ryabinin@gmail.com:
2015-01-22 3:22 GMT+03:00 Sasha Levin sasha.le...@oracle.com:
On 01/21/2015 11:51 AM, Andrey Ryabinin wrote:
Changes since v8:
- Fixed unpoisoned redzones for not-allocated-yet object
in newly allocated slab page. (from Dmitry C.)
- Some minor non-function cleanups in kasan internals.
- Added ack from Catalin
- Added stack instrumentation. With this we could detect
out of bounds accesses in stack variables. (patch 12)
- Added globals instrumentation - catching out of bounds in
global varibles. (patches 13-17)
- Shadow moved out from vmalloc into hole between vmemmap
and %esp fixup stacks. For globals instrumentation
we will need shadow backing modules addresses.
So we need some sort of a shadow memory allocator
(something like vmmemap_populate() function, except
that it should be available after boot).
__vmalloc_node_range() suits that purpose, except that
it can't be used for allocating for shadow in vmalloc
area because shadow in vmalloc is already 'allocated'
to protect us from other vmalloc users. So we need
16TB of unused addresses. And we have big enough hole
between vmemmap and %esp fixup stacks. So I moved shadow
there.
I'm not sure which new addition caused it, but I'm getting tons of
false positives from platform drivers trying to access memory they
don't own - because they expect to find hardware there.
To be sure, that this is really false positives, could you try with
patches in attachment?
Attaching properly formed patches
From 8aca28dc4df2ed597f4fe0d49468021db5f29c61 Mon Sep 17 00:00:00 2001
From: Andrey Ryabinin a.ryabi...@samsung.com
Date: Thu, 22 Jan 2015 12:44:42 +0300
Subject: [PATCH 1/3] backlight: da9052_bl: terminate da9052_wled_ids array
with empty element
Array of platform_device_id elements should be terminated
with empty element.
Signed-off-by: Andrey Ryabinin a.ryabi...@samsung.com
---
drivers/video/backlight/da9052_bl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/backlight/da9052_bl.c b/drivers/video/backlight/da9052_bl.c
index d4bd74bd..b1943e7 100644
--- a/drivers/video/backlight/da9052_bl.c
+++ b/drivers/video/backlight/da9052_bl.c
@@ -165,6 +165,7 @@ static struct platform_device_id da9052_wled_ids[] = {
.name = da9052-wled3,
.driver_data = DA9052_TYPE_WLED3,
},
+ { },
};
static struct platform_driver da9052_wled_driver = {
--
2.0.4
From 27f8cf0aff7d16c061dda9dd219887cae2214586 Mon Sep 17 00:00:00 2001
From: Andrey Ryabinin a.ryabi...@samsung.com
Date: Thu, 22 Jan 2015 12:46:44 +0300
Subject: [PATCH 2/3] crypto: ccp: terminate ccp_support array with empty
element
x86_match_cpu() expects array of x86_cpu_ids terminated
with empty element.
Signed-off-by: Andrey Ryabinin a.ryabi...@samsung.com
---
drivers/crypto/ccp/ccp-dev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/ccp/ccp-dev.c b/drivers/crypto/ccp/ccp-dev.c
index c6e6171..ca29c12 100644
--- a/drivers/crypto/ccp/ccp-dev.c
+++ b/drivers/crypto/ccp/ccp-dev.c
@@ -583,6 +583,7 @@ bool ccp_queues_suspended(struct ccp_device *ccp)
#ifdef CONFIG_X86
static const struct x86_cpu_id ccp_support[] = {
{ X86_VENDOR_AMD, 22, },
+ { },
};
#endif
--
2.0.4
From 3a3bd9cfd223f14d31352b9a44209476b3f5ef11 Mon Sep 17 00:00:00 2001
From: Andrey Ryabinin a.ryabi...@samsung.com
Date: Thu, 22 Jan 2015 12:48:15 +0300
Subject: [PATCH 3/3] rtc: s5m: terminate s5m_rtc_id array with empty element
Array of platform_device_id elements should be terminated
with empty element.
Signed-off-by: Andrey Ryabinin a.ryabi...@samsung.com
---
drivers/rtc/rtc-s5m.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
index b5e7c46..89ac1d5 100644
--- a/drivers/rtc/rtc-s5m.c
+++ b/drivers/rtc/rtc-s5m.c
@@ -832,6 +832,7 @@ static SIMPLE_DEV_PM_OPS(s5m_rtc_pm_ops, s5m_rtc_suspend, s5m_rtc_resume);
static const struct platform_device_id s5m_rtc_id[] = {
{ s5m-rtc, S5M8767X },
{ s2mps14-rtc, S2MPS14X },
+ { },
};
static struct platform_driver s5m_rtc_driver = {
--
2.0.4
Re: [PATCH] video: fbdev: fix sys_copyarea
Mans Rullgard m...@mansr.com writes: The sys_copyarea() function performs the same operation as cfb_copyarea() but using normal memory access instead of I/O accessors. Since the introduction of sys_copyarea(), there have been two fixes to cfb_copyarea(): - 00a9d699 (framebuffer: fix cfb_copyarea) - 5b789da8 (framebuffer: fix screen corruption when copying) This patch incorporates the fixes into sys_copyarea() as well. Scratch that, this patch is broken. Correct patch coming soon. -- Måns Rullgård m...@mansr.com -- 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: [alsa-devel] [PATCH v2 3/3] ARM: dts: Add sound nodes for exynos4412-trats2
Hi,
Thanks for your comments.
On Wed, 21 Jan 2015 17:23:21 +0100
Sylwester Nawrocki s.nawro...@samsung.com wrote:
Hi,
On 19/01/15 10:48, Inha Song wrote:
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
+ sound {
+ compatible = samsung,trats2-audio;
+ assigned-clocks = pmu_system_controller 0;
+ assigned-clock-parents = clock CLK_XUSBXTI;
How about putting these properties in the pmu_system_controller
node? After all the mux clock being configured here belongs to
the PMU subsystem. Wouldn't it work that way ?
OK, I will move assigned clock properties to pmu_system_controller DT node.
Best Regards,
Inha Song.
+ samsung,i2s-controller = i2s0;
+ samsung,model = Trats2;
+ samsung,audio-codec = wm1811;
+ samsung,audio-routing =
+ SPK, SPKOUTLN,
+ SPK, SPKOUTLP,
+ SPK, SPKOUTRN,
+ SPK, SPKOUTRP;
+ };
--
Regards,
Sylwester
___
Alsa-devel mailing list
alsa-de...@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
--
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 1/1] x86: Add Isolated Memory Regions for Quark X1000
On 21/01/15 20:57, Andy Shevchenko wrote:
Few nitpicks and comments below.
+/*
+ * IMR agent access mask bits
+ * See section 12.7.4.7 from quark-x1000-datasheet.pdf for register
+ * definitions
What about dots at the end of sentences?
Murphy's law says - no matter how many times you proof read for full
stop you'll miss at least one :)
+#define pr_fmt(fmt) imr: fmt
Maybe more usual
#define pr_fmt(fmt) KBUILD_MODNAME : fmt
Sure.
+ ret = iosf_mbi_read(QRK_MBI_UNIT_MM, QRK_MBI_MM_READ,
+ reg++, imr-rmask);
+ if (ret)
+ return ret;
+
+ return iosf_mbi_read(QRK_MBI_UNIT_MM, QRK_MBI_MM_READ,
+ reg, imr-wmask);
I would keep this in the same style like
ret =
if (ret)
return ret;
return 0;
It might be easy to extend if needed, though it's a really minor change.
No problem
+
+ ret = iosf_mbi_write(QRK_MBI_UNIT_MM, QRK_MBI_MM_WRITE,
+ reg++, imr-rmask);
+ if (ret)
+ goto done;
+
+ ret = iosf_mbi_write(QRK_MBI_UNIT_MM, QRK_MBI_MM_WRITE,
+ reg, imr-wmask);
Wouldn't be reg++ here as well? Below you substitute full offset which
I think points just to next register.
I don't think we want to increment below..
+ if (ret)
+ goto done;
+
+ /* Lock bit must be set separately to addr_lo address bits */
+ if (lock) {
+ imr-addr_lo |= IMR_LOCK;
+ ret = iosf_mbi_write(QRK_MBI_UNIT_MM, QRK_MBI_MM_WRITE,
+ reg - IMR_LOCK_OFF, imr-addr_lo);
+ }
..because we calculate an offset anyway. An additional increment would
just be unnecessary cycles.
Could it fit one line less?
Yes. Will change.
+
+#ifdef CONFIG_DEBUG_FS
+/**
+ * imr_dbgfs_state_show
+ * Print state of IMR registers
+ *
+ * @s: pointer to seq_file for output
+ * @unused:unused parameter
+ * @return:0 on success or error code passed from mbi_iosf on failure
+ */
+static int imr_dbgfs_state_show(struct seq_file *s, void *unused)
I didn't remembter if I told you, but please use s-private for the
imr_dev pointer.
Everywhere in debugfs calls and if possible in other functions as well.
No missed s-private. Will incorporate for V3.
+}
+
+/**
+ * imr_debugfs_unregister
+ * Unregister debugfs hooks
+ *
+ * @imr: IMR structure representing address and access masks
+ * @return:
+ */
+static void imr_debugfs_unregister(void)
+{
+ if (!imr_dev.file)
+ return;
Redundant check. I think I told you that already.
I think you did. V3
+static void __init imr_fixup_memmap(void)
+{
+ unsigned long base = virt_to_phys(_text);
+ unsigned long size = virt_to_phys(__end_rodata) - base;
Shouldn't be phys_addr_t ?
Oh, It might be good for all address parameters in the introduced API.
Well the reference MTRR code doesn't do phs_addr_t
OTOH so what. I think phys_addr_t is more representative of the data
being passed, so will include @ V3.
+ pr_info(protecting kernel .text - .rodata: %ldk (%p - %p)\n,
+ size / 1024, _text, __end_rodata);
size 10
Andy.
It was size 10 for V1 and you called it out as a magic number :)
IMO, size / 1024 requires less thought to understand when reading the code.
+
+#ifdef CONFIG_DEBUG_IMR_SELFTEST
+ /* Run optional self test */
+ imr_self_test(base, size);
+#endif
I think it makes sense to move this piece to the init.
I don't see what is exceptional in this function that test belongs here.
Fair enough.
+#ifdef CONFIG_DEBUG_FS
+ ret = imr_debugfs_register();
+ if (ret != 0)
+ return ret;
It's non-fatal error.
Thus,
if (ret)
pr_warn(DebugFS wasn't initialized\n);
Move it after we have imr_dev in place and supply it to debugfs as a
private pointer.
Agree
+ * return:
+ */
+static void __exit imr_exit(void)
+{
+#ifdef CONFIG_DEBUG_FS
I suspect you may remove all those ifdefs and compiler should shrink
not used code since debugfs has the stubs.
+ imr_debugfs_unregister();
+#endif
+}
Hrmm. I'll revist that @ V3.
Thanks for the quick feedback.
--
BOD
--
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 v11 3/4] clk: Add rate constraints to clocks
On 01/21, Tomeu Vizoso wrote:
Adds a way for clock consumers to set maximum and minimum rates. This
can be used for thermal drivers to set minimum rates, or by misc.
drivers to set maximum rates to assure a minimum performance level.
Changes the signature of the determine_rate callback by adding the
parameters min_rate and max_rate.
Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com
---
v11: * Recalculate the rate before putting the reference to clk_core
* Don't recalculate the rate when freeing the per-user clock
in the initialization error paths
* Move __clk_create_clk to be next to __clk_free_clk for more
comfortable reading
Can we do this in the previous patch where we introduce the
function?
@@ -2143,9 +2314,16 @@ struct clk *__clk_register(struct device *dev, struct
clk_hw *hw)
else
clk-owner = NULL;
+ INIT_HLIST_HEAD(clk-clks);
+
+ hw-clk = __clk_create_clk(hw, NULL, NULL);
+
ret = __clk_init(dev, hw-clk);
- if (ret)
+ if (ret) {
+ __clk_free_clk(hw-clk);
+ hw-clk = NULL;
return ERR_PTR(ret);
+ }
return hw-clk;
}
@@ -2210,12 +2388,16 @@ struct clk *clk_register(struct device *dev, struct
clk_hw *hw)
}
}
+ INIT_HLIST_HEAD(clk-clks);
+
hw-clk = __clk_create_clk(hw, NULL, NULL);
ret = __clk_init(dev, hw-clk);
if (!ret)
return hw-clk;
- kfree(hw-clk);
+ __clk_free_clk(hw-clk);
+ hw-clk = NULL;
Shouldn't we be assigning to NULL in the previous patch (same
comment for __clk_register)?
fail_parent_names_copy:
while (--i = 0)
kfree(clk-parent_names[i]);
@@ -2420,7 +2602,14 @@ void __clk_put(struct clk *clk)
if (!clk || WARN_ON_ONCE(IS_ERR(clk)))
return;
+ clk_prepare_lock();
+ hlist_del(clk-child_node);
+ clk_prepare_unlock();
+
+ clk_core_set_rate(clk-core, clk-core-req_rate);
+
clk_core_put(clk-core);
+
Sad that we take the lock 3 times during __clk_put(). We should
be able to do it only once if we have a lockless
clk_core_set_rate() function and put the contents of
clk_core_put() into this function. Actually we need to do that to
be thread safe with clk-core-req_rate changing. We can call the
same function in clk_set_rate_range() too so that we don't have
to deal with recursive locking there.
kfree(clk);
}
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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 0/5] tracing: Add new file system tracefs
On Thu, 22 Jan 2015 07:00:07 +0800 Greg Kroah-Hartman gre...@linuxfoundation.org wrote: Any chance you can use kernfs as your basis for this filesystem instead of having to roll all of your own functions? I'm slowly working on moving debugfs to it, and it should save a lot of code there, as well as fixing some problems we have in debugfs file lifetimes when things are removed from the system. Someone else told me about doing this too. I'll take a look at it. And given the number of mistakes in this submission, I'll wait for a v2 before really reading the code :) Well, if I switch to using kernfs, I expect we should ignore this version as well, as I would think it would make this series obsolete. Also, if that's the case, I guess I could keep all the tracefs code in kernel/tracing and not place it in the fs/ directory? Kind of like what cgroups does. -- Steve -- 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 tip 0/9] tracing: attach eBPF programs to tracepoints/syscalls/kprobe
On Wed, Jan 21, 2015 at 5:03 PM, Namhyung Kim namhy...@kernel.org wrote: AFAIK a trigger can be fired before allocating a ring buffer if it doesn't use the event record (i.e. has filter) or -post_trigger bit set (stacktrace). Please see ftrace_trigger_soft_disabled(). yes, but such trigger has no arguments, so I would have to hack ftrace_trigger_soft_disabled() to pass 'ctx' further down and through all pointer dereferences and list walking. Also there is no return value, so I have to add it as well similar to post-triggers. that's quite a bit of overhead that I would like to avoid. Actually now I'm thinking to move condition if (ftrace_file-flags TRACE_EVENT_FL_BPF) before ftrace_trigger_soft_disabled() check. So programs always run first and if they return non-zero then all standard processing will follow. May be return value from the program can influence triggers. That will nicely replace bpf_dump_stack()...the program will return ETT_STACKTRACE constant to trigger dump. This also makes it keeping events in the soft-disabled state. I was never able to figure out the use case for soft-disabled state. Probably historical before static_key was done. -- 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: mmotm: mm-slub-optimize-alloc-free-fastpath-by-removing-preemption-on-off.patch is causing preemptible splats
On Wed, Jan 21, 2015 at 02:21:07PM -0800, Andrew Morton wrote: On Wed, 21 Jan 2015 15:11:38 +0100 Michal Hocko mho...@suse.cz wrote: On Wed 21-01-15 15:06:03, Krzysztof Koz__owski wrote: [...] Same here :) [1] . So actually only ARM seems affected (both armv7 and armv8) because it is the only one which uses smp_processor_id() in my_cpu_offset. This was on x86_64 with CONFIG_DEBUG_PREEMPT so it is not only ARM specific. Hopefully mm-slub-optimize-alloc-free-fastpath-by-removing-preemption-on-off-v3.patch will fix this. Yes, it will fix this error. The most recent -mmotm was a bit of a trainwreck. I'm scrambling to get the holes plugged so I can get another mmotm out today. Another mmotm will fix many issues from me. :/ Thanks. -- 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 RESEND] fs: namei: Use memcpy instead of strlcpy
On 01/21/2015 04:44 PM, Paul Moore wrote: Good point. Do you mind if I merge your patch into my existing patch instead of including it separately? Sure, no problem. Go ahead. 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 tip 0/9] tracing: attach eBPF programs to tracepoints/syscalls/kprobe
On Wed, Jan 21, 2015 at 5:56 PM, Steven Rostedt rost...@goodmis.org wrote: On Wed, 21 Jan 2015 17:49:08 -0800 Alexei Starovoitov a...@plumgrid.com wrote: This also makes it keeping events in the soft-disabled state. I was never able to figure out the use case for soft-disabled state. Probably historical before static_key was done. No, it's not historical at all. The soft-disable is a way to enable from any context. You can't enable a static key from NMI or interrupt context, but you can enable a soft-disable there. As you can enable or disable events from any function that the function tracer may trace, I needed a way to enable them (make the tracepoint active), but do nothing until something else turns them on. Thanks for explanation. Makes sense. Speaking of nmi... I think I will add a check that if (in_nmi()) just skip running the program, since supporting this use case is not needed at the moment. -- 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] printk: Add dummy routine for when CONFIG_PRINTK=n
On Wed, Jan 21, 2015 at 7:58 AM, Petr Mladek pmla...@suse.cz wrote:
On Tue 2015-01-20 18:51:49, Pranith Kumar wrote:
There are missing dummy routines for log_buf_addr_get() and log_buf_len_get()
for when CONFIG_PRINTK is not set causing build failures.
This patch adds these dummy routines at the appropriate location.
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
CC: Michael Ellerman m...@ellerman.id.au
---
include/linux/printk.h | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/include/linux/printk.h b/include/linux/printk.h
index aeb9d7f..f52f02b 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -10,9 +10,6 @@
extern const char linux_banner[];
extern const char linux_proc_banner[];
-extern char *log_buf_addr_get(void);
-extern u32 log_buf_len_get(void);
-
static inline int printk_get_level(const char *buffer)
{
if (buffer[0] == KERN_SOH_ASCII buffer[1]) {
@@ -168,6 +165,8 @@ void __init setup_log_buf(int early);
void dump_stack_set_arch_desc(const char *fmt, ...);
void dump_stack_print_info(const char *log_lvl);
void show_regs_print_info(const char *log_lvl);
+char *log_buf_addr_get(void);
+u32 log_buf_len_get(void);
#else
static inline __printf(1, 0)
int vprintk(const char *s, va_list args)
@@ -217,6 +216,16 @@ static inline void dump_stack_print_info(const char
*log_lvl)
static inline void show_regs_print_info(const char *log_lvl)
{
}
+
+static inline char *log_buf_addr_get(void)
+{
+ return NULL;
+}
+
+static linline u32 log_buf_len_get(void)
^
typo: linline - inline
Argh, shows why we should always atleast build test before sending a
patch, no matter how trivial it is.
Otherwise, it looks fine to me.
Well, If you send v2, I would move this above log_buf_kexec_setup() in
both #ifdef branches. So that all four log_buf()-related functions
declared/defined together.
I will update as you said in v2.
Thanks!
--
Pranith
--
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] Add LTC2941/LTC2943 Battery Gauge Driver
Hi, On Tue, Oct 28, 2014 at 08:05:12AM +0100, Mike Looijmans wrote: Both the LTC2941 and LTC2943 measure battery capacity. The LTC2943 is compatible with the LTC2941, it adds voltage and temperature monitoring, and uses a slightly different conversion formula for the charge counter. To avoid confusion with e.g. the LTC2945, the driver is called LTC2941 instead of LTC294X. Applied with .owner field removed. -- Sebastian signature.asc Description: Digital signature
[PATCH v2 1/2] printk: Add dummy routine for when CONFIG_PRINTK=n
There are missing dummy routines for log_buf_addr_get() and log_buf_len_get()
for when CONFIG_PRINTK is not set causing build failures.
This patch adds these dummy routines at the appropriate location.
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
CC: Michael Ellerman m...@ellerman.id.au
---
include/linux/printk.h | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/include/linux/printk.h b/include/linux/printk.h
index aeb9d7f..baa3f97 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -10,9 +10,6 @@
extern const char linux_banner[];
extern const char linux_proc_banner[];
-extern char *log_buf_addr_get(void);
-extern u32 log_buf_len_get(void);
-
static inline int printk_get_level(const char *buffer)
{
if (buffer[0] == KERN_SOH_ASCII buffer[1]) {
@@ -163,6 +160,8 @@ extern int kptr_restrict;
extern void wake_up_klogd(void);
+char *log_buf_addr_get(void);
+u32 log_buf_len_get(void);
void log_buf_kexec_setup(void);
void __init setup_log_buf(int early);
void dump_stack_set_arch_desc(const char *fmt, ...);
@@ -198,6 +197,16 @@ static inline void wake_up_klogd(void)
{
}
+static inline char *log_buf_addr_get(void)
+{
+ return NULL;
+}
+
+static inline u32 log_buf_len_get(void)
+{
+ return 0;
+}
+
static inline void log_buf_kexec_setup(void)
{
}
--
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: [PATCH] Add devicetree binding documentation for the LTC2941/LTC2943 driver
Hi, On Tue, Oct 28, 2014 at 08:08:04AM +0100, Mike Looijmans wrote: This adds the devicetree binding documentation for the LTC2941 and LTC2943 driver. These are I2C connected battery gas gauge ICs. Thanks, applied. -- Sebastian signature.asc Description: Digital signature
[PATCH 3/5] rtc: Modify rtc_hctosys() to address y2038 issues
rtc_hctosys() has a number of y2038 issues.
This patch resolves them by:
- Replace rtc_tm_to_time() with y2038-safe rtc_tm_to_time64()
- Replace do_settimeofday() with y2038-safe do_settimeofday64()
After this patch, it should not have any remaining y2038 issues.
Reviewed-by: John Stultz john.stu...@linaro.org
Reviewed-by: Arnd Bergmann arnd.bergm...@linaro.org
Signed-off-by: Xunlei Pang pang.xun...@linaro.org
---
drivers/rtc/hctosys.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/rtc/hctosys.c b/drivers/rtc/hctosys.c
index 4aa60d7..2153b52 100644
--- a/drivers/rtc/hctosys.c
+++ b/drivers/rtc/hctosys.c
@@ -26,7 +26,7 @@ static int __init rtc_hctosys(void)
{
int err = -ENODEV;
struct rtc_time tm;
- struct timespec tv = {
+ struct timespec64 tv64 = {
.tv_nsec = NSEC_PER_SEC 1,
};
struct rtc_device *rtc = rtc_class_open(CONFIG_RTC_HCTOSYS_DEVICE);
@@ -52,16 +52,16 @@ static int __init rtc_hctosys(void)
goto err_invalid;
}
- rtc_tm_to_time(tm, tv.tv_sec);
+ tv64.tv_sec = rtc_tm_to_time64(tm);
- err = do_settimeofday(tv);
+ err = do_settimeofday64(tv64);
dev_info(rtc-dev.parent,
setting system clock to
- %d-%02d-%02d %02d:%02d:%02d UTC (%u)\n,
+ %d-%02d-%02d %02d:%02d:%02d UTC (%lld)\n,
tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday,
tm.tm_hour, tm.tm_min, tm.tm_sec,
- (unsigned int) tv.tv_sec);
+ (long long) tv64.tv_sec);
err_invalid:
err_read:
--
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: [PATCH v3 0/4] drivers: bus: Add Simple Power-Managed Bus
On Fri, Jan 09, 2015 at 02:12:31PM +0100, Geert Uytterhoeven wrote:
Hi Simon, Magnus,
The Renesas Bus State Controller (BSC) provides an external bus for
connecting multiple external devices to an SoC, driving several chip
select lines, for e.g. NOR FLASH, Ethernet and USB.
On the kzm9g and ape6evm development boards, an smsc9220 Ethernet
controller is connnected to the BSC of an SH-Mobile AG5 (sh73a0) resp.
R-Mobile APE6 (r8a73a4) SoC.
For the record: Olof has asked for review comments for these patches
so I have dropped them from next pending that activity.
The BSC is a fairly simple memory-mapped bus, hence a simple-bus
compatibility seems suitable. However, the BSC is special in two
ways:
1. It is part of a PM domain (A4S),
2. It has a gateable functional clock (ZB).
Before a device connected to the BSC can be accessed, the PM domain
containing the BSC must be powered on, and the functional clock
driving the BSC must be enabled.
Both special properties can be described in DT in a standardized way
(power-domains = pd_a4s and clocks = zb_clk, cfr. the
example in the DT binding documentation). Externally connected
devices are described as children of the BSC node.
Unfortunately this doesn't mean everything will work out-of-the-box.
There are two problems:
1. Without a device driver bound to the bus device, this device is
not attached to the PM domain. And although a child device is
present and active, the PM domain may be powered down, as it's
considered unused by the PM domain core.
2. Without a device driver calling pm_runtime_enable(), its
functional clock is not enabled. Once runtime PM is enabled, the
R-Mobile PM domain platform driver manages the functional clock
using runtime PM.
As none of the above is really bus hardware-specific (PM domains and
functional clocks in clock domains are handled from genpd and platform
code), this series adds a Simple Power-Managed Bus driver for
transparent busses, which just enables runtime PM for the bus device.
Due to the child-parent relationship of devices connected to the bus,
as long as the device drivers for the child devices are runtime PM
enabled, the bus's PM domain will be powered, and the bus's clock will
be enabled automatically when needed, for both runtime PM and s2ram.
Currently this driver supports the Renesas Bus State Controller only,
but support for other SoCs and other bus controllers can easily be
added later by adding more compatible values.
Note that this driver cannot just bind against simple-bus, as that
may prevent a device-specific driver from taking precedence.
This was tested on sh73a0/kzm9g-multiplatform (by me), and on
r8a73a4/ape6evm-multiplatform (by Ulrich Hecht). Without this,
Ethernet doesn't work, as the ZB clock is disabled by
clk_disable_unused().
As drivers/bus doesn't have a maintainer, and this driver is needed to
move two shmobile platforms away from legacy to multiplatform, I think
this can go in through Simon's shmobile tree. There are no conflicts
with today's linux-next.
Changes compared to v2:
- Document required properties inherited from simple-bus,
- Document required reg property for renesas,bsc,
- Move ranges before reg in the example,
- Add Tested-by,
- Split-off sh73a0/kzm9g and r8a73a4/ape6evm DTS updates.
Changes compared to v1 (more detailed change logs in the individual
patches):
- Added sorting of drivers/bus Kconfig and Makefile entries,
- Added DT binding documentation,
- Rename from Renesas Bus State Controller Driver (renesas-bsc) to
Simple Power-Managed Bus Driver (simple-pm-bus),
- Postponed adding power-domains properties to the dtsi,
- Added updates for r8a73a4/ape6evm.
Thanks for applying!
Geert Uytterhoeven (4):
drivers: bus: Sort Kconfig entries alphabetically
drivers: bus: Sort Makefile entries alphabetically
drivers: bus: Add Simple Power-Managed Bus DT Bindings
drivers: bus: Add Simple Power-Managed Bus Driver
.../devicetree/bindings/bus/simple-pm-bus.txt | 52 +
drivers/bus/Kconfig| 53
++
drivers/bus/Makefile | 15 +++---
drivers/bus/simple-pm-bus.c| 51 +
4 files changed, 144 insertions(+), 27 deletions(-)
create mode 100644 Documentation/devicetree/bindings/bus/simple-pm-bus.txt
create mode 100644 drivers/bus/simple-pm-bus.c
--
1.9.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like
that.
-- Linus Torvalds
--
To unsubscribe
Re: [PATCH] Selinux/hooks.c: Fix a NULL pointer dereference caused by semop()
On Wed, Jan 21, 2015 at 1:30 PM, Manfred Spraul
manf...@colorfullife.com wrote:
On 01/21/2015 04:53 AM, Ethan Zhao wrote:
On Tue, Jan 20, 2015 at 10:10 PM, Stephen Smalley s...@tycho.nsa.gov
wrote:
On 01/20/2015 04:18 AM, Ethan Zhao wrote:
sys_semget()
-newary()
-security_sem_alloc()
-sem_alloc_security()
selinux_sem_alloc_security()
-ipc_alloc_security() {
-rc = avc_has_perm()
if (rc) {
ipc_free_security(sma-sem_perm);
return rc;
We free the security structure here to avoid a memory leak on a
failed/denied semaphore set creation. In this situation, we return an
error to the caller (ultimately to newary), it does an
ipc_rcu_putref(sma, ipc_rcu_free), and it returns an error to the
caller. Thus, it never calls ipc_addid() and the semaphore set is not
created. So how then can you call semtimedop() on it?
Seems it wouldn't happen after commit
e8577d1f0329d4842e8302e289fb2c22156abef4 ?
That was my first guess when I read the bug report - but it can't be the
fix, because security_sem_alloc() is before the ipc_addid(), with or without
the patch.
thread A:
thread B:
semtimedop()
- sem_obtain_object_check()
semctl(IPC_RMID)
- freeary()
- ipc_rcu_putref()
- call_rcu()
- somehow a grace period
- sem_rcu_free()
- security_sem_free()
Perhaps: modify ipc_free_security() to hexdump perm and a few more bytes if
the pointer is NULL?
I tried to ask for vmcore and do more analysis, basically, the race condition
still exists and open a hole to be DoS.
Thanks,
Ethan
--
Manfred
Thanks,
Ethan
So ipc_perms-security was NULL, then semtimedop() was called as
following:
sys_semtimedop() / semop()
-selinux_sem_semop()
-ipc_has_perm()
-avc_has_perm(sid, isec-sid, isec-sclass, perms, ad);
^- NULL pointer dereference
happens
The test kernel was running on VMware.
This patch use to fix this serious security issue could be triggered by
user space.
This patch was tested with v3.19-rc5.
Signed-off-by: Ethan Zhao ethan.z...@oracle.com
---
security/selinux/hooks.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 6da7532..bbe76f5 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -5129,6 +5129,8 @@ static int ipc_has_perm(struct kern_ipc_perm
*ipc_perms,
u32 sid = current_sid();
isec = ipc_perms-security;
+ if (!isec)
+ return -EACCES;
ad.type = LSM_AUDIT_DATA_IPC;
ad.u.ipc_id = ipc_perms-key;
That is not the correct fix; it just hides a bug. If we reach
ipc_has_perm() with a NULL isec, it is a bug in the ipc code.
--
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/
--
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 mtd] mtd:devices: Add Altera EPCQ Driver
On Tue, Jan 20, 2015 at 10:05 AM, Viet Nga Dao vn...@altera.com wrote: On Thu, Jan 15, 2015 at 5:27 PM, Viet Nga Dao vn...@altera.com wrote: On Tue, Jan 13, 2015 at 11:33 AM, Brian Norris computersforpe...@gmail.com wrote: On Thu, Dec 18, 2014 at 12:23:16AM -0800, vn...@altera.com wrote: From: Viet Nga Dao vn...@altera.com Altera EPCQ Controller is a soft IP which enables access to Altera EPCQ and EPCS flash chips. This patch adds driver for these devices. Signed-off-by: Viet Nga Dao vn...@altera.com This drivers seems awfully similar to (and so I infer it is likely copy-and-pasted from) m25p80.c / spi-nor.c. Do you think it can be rewritten as a SPI NOR driver, under drivers/mtd/spi-nor/ ? It looks like these flash share most (all?) the same basic opcodes. For Altera EPCQ flashes, almost operations are performed underline hardware. Software only able to perform the following through registers: - read status register - read id - write status registers bit SR_BP0,SR_BP1, SR_BP2,SR_BP3, SR_TB (http://www.altera.com.my/literature/hb/cfg/cfg_cf52012.pdf) For read/write data: all the operations like QUAD_READ/WRITE, FAST_READ/WRITE are handled by hardware as well. From software point of view, there is no difference between these 2 modes. That is why if rewrite the drivers to follow spi-nor structure, it will require extra decoding works for the only few used opcodes. Is it OK to remain this driver structure? Can someone please reply my question as it is been a while? Viet Nga -- 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 0/5] tracing: Add new file system tracefs
On Wed, 21 Jan 2015 20:47:25 -0500 Steven Rostedt rost...@goodmis.org wrote: Well, if I switch to using kernfs, I expect we should ignore this version as well, as I would think it would make this series obsolete. Is there any documentation on kernfs? I can't find anything that makes it any easier than what I already have. -- Steve -- 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] perf: convert: fix duplicate field names and avoid reserved keywords.
On Wed, Jan 21, 2015 at 8:38 PM, Wang Nan wangn...@huawei.com wrote:
On 2015/1/21 23:56, Jérémie Galarneau wrote:
On Wed, Jan 21, 2015 at 9:11 AM, Jiri Olsa jo...@redhat.com wrote:
On Wed, Jan 21, 2015 at 11:23:54AM +0800, Wang Nan wrote:
Some parameters of syscall tracepoints named as 'nr', 'event', etc.
When dealing with them, perf convert to ctf meets some problem:
1. If a parameter with name 'nr', it will duplicate syscall's
common field 'nr'. One such syscall is io_submit().
2. If a parameter with name 'event', it is denied to be inserted
because 'event' is a babeltrace keywork. One such syscall is
epoll_ctl.
hum, so this problem 2 is detectable only via bt_ctf_event_class_add_field
function?
how big is the blaklist?
The blacklist is defined by the CTF specification here [1].
Jérémie
[1]
http://git.efficios.com/?p=ctf.git;a=blob;f=common-trace-format-specification.txt;h=abe4fb70fff7f17f6e8242f313fb74bff44cf89a;hb=HEAD#l1477
Is there any possibility that the someone expand the list?
Good question. There is discussion around a v1.9 version of the CTF
spec going on at the moment (which should not affect the Babeltrace
API).
As far as I know, adding __attribute__ has been discussed. CC'ing
Mathieu Desnoyer who may have other extensions in mind.
Jérémie
SNIP
+}
+
static int add_tracepoint_fields_types(struct ctf_writer *cw,
struct format_field *fields,
struct bt_ctf_event_class
*event_class)
@@ -577,6 +609,9 @@ static int add_tracepoint_fields_types(struct
ctf_writer *cw,
for (field = fields; field; field = field-next) {
struct bt_ctf_field_type *type;
unsigned long flags = field-flags;
+ struct bt_ctf_field_type *f = NULL;
+ char *name;
+ int dup = 1;
pr2( field '%s'\n, field-name);
@@ -595,14 +630,36 @@ static int add_tracepoint_fields_types(struct
ctf_writer *cw,
if (flags FIELD_IS_ARRAY)
type = bt_ctf_field_type_array_create(type,
field-arraylen);
- ret = bt_ctf_event_class_add_field(event_class, type,
- field-name);
+ /* Check name duplication */
+ name = field-name;
could you please put this in separated function like 'get_field_name(..)'
so we dont polute this function even more
name == get_field_name(...)
if (!name)
error path
thanks,
jirka
--
Jérémie Galarneau
EfficiOS Inc.
http://www.efficios.com
--
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: linux-next: Tree for Jan 20
On 01/21/2015 02:43 AM, Kirill A. Shutemov wrote: BUG: Bad page state in process init.sh pfn:0 page:f05e7460 count:0 mapcount:-1 mapping: (null) index:0x0 flags: 0x400(reserved) page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set bad because of flags: flags: 0x400(reserved) CPU: 0 PID: 1 Comm: init.sh Not tainted 3.19.0-rc5-next-20150120 #1 [f0076010 : bad_page+0xdc/0xfc ] [f00760c0 : free_pages_prepare+0x90/0x1f8 ] [f00775cc : free_hot_cold_page+0x20/0x160 ] [f00919e8 : do_wp_page+0x680/0x6ac ] [f00939f4 : handle_mm_fault+0xc94/0xd08 ] [f0015900 : do_sparc_fault+0xfc/0x3ec ] [f000af90 : srmmu_fault+0x58/0x68 ] [f00e74f4 : load_elf_binary+0x9a8/0xe94 ] [f00b0cac : search_binary_handler+0x68/0x12c ] [f00e67d0 : load_script+0x214/0x224 ] [f00b0cac : search_binary_handler+0x68/0x12c ] [f00b11a4 : do_execveat_common+0x434/0x584 ] [f00b1310 : do_execve+0x1c/0x2c ] [f02b50b0 : kernel_init+0x70/0xf0 ] [f000b200 : ret_from_kernel_thread+0xc/0x38 ] [ : (null) ] Disabling lock debugging due to kernel taint : applet not found Kernel panic - not syncing: Attempted to kill init! exitcode=0x0100 It doesn't make much sense to me. It tries to free page with pfn==0 on handling wp-fault. How it got mapped in the first place? If I comment out the added call to vm_normal_page(), the code works fine. If the call to vm_local_page() is there but everything else from your patch is commented out, the crash occurs. Also, any log message added to the new code patch (inside the if statements) is not getting printed, meaning the new code (besides the call to vm_local_page) is not reached. I guess that means that something in the call to vm_normal_page() appears to go wrong. No idea what that might be, though. 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 v3] thermal: rockchip: make temperature reporting much more accurate
在 2015年01月22日 12:01, Daniel Kurtz 写道:
On Thu, Jan 22, 2015 at 1:29 AM, Caesar Wang w...@rock-chips.com wrote:
In general, the kernel should report temperature readings exactly as
reported by the hardware. The cpu / gpu thermal driver works in 5 degree
increments,but we ought to do more accurate. The temperature will do
linear interpolation between the entries in the table.
Test= $md5sum /dev/zero
$while true; do grep /sys/class/thermal/thermal_zone[1-2]/temp;
sleep .5; done
e.g. We can get the result as follows:
/sys/class/thermal/thermal_zone1/temp:39994
/sys/class/thermal/thermal_zone2/temp:39086
/sys/class/thermal/thermal_zone1/temp:39994
/sys/class/thermal/thermal_zone2/temp:39540
/sys/class/thermal/thermal_zone1/temp:39540
/sys/class/thermal/thermal_zone2/temp:39540
/sys/class/thermal/thermal_zone1/temp:39540
/sys/class/thermal/thermal_zone2/temp:39994
Signed-off-by: Caesar Wang w...@rock-chips.com
Reviewed-by: Dmitry Torokhov dmitry.torok...@gmail.com
---
Changes in v3:
Suggested-by Daniel Kurtz,
the check doesn't reject code == 0xfff
Fixed in rk_tsadcv2_code_to_temp(u32 code)
Changes in v2:
Reviewed-by: Dmitry Torokhov dmitry.torok...@gmail.com
drivers/thermal/rockchip_thermal.c | 32 ++--
1 file changed, 22 insertions(+), 10 deletions(-)
diff --git a/drivers/thermal/rockchip_thermal.c
b/drivers/thermal/rockchip_thermal.c
index 1bcddfc..ce18007 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -193,19 +193,22 @@ static u32 rk_tsadcv2_temp_to_code(long temp)
static long rk_tsadcv2_code_to_temp(u32 code)
{
- int high, low, mid;
-
- low = 0;
- high = ARRAY_SIZE(v2_code_table) - 1;
- mid = (high + low) / 2;
+ unsigned int low = 0;
+ unsigned int high = ARRAY_SIZE(v2_code_table) - 1;
+ unsigned int mid = (low + high) / 2;
+ unsigned int num;
+ unsigned long denom;
+ /* No code available, return callback */
if (code v2_code_table[low].code || code v2_code_table[high].code)
- return 125000; /* No code available, return max temperature */
+ return rk_tsadcv2_code_to_temp(code);
Isn't this an infinite recursion?
No, I think we can try check if it is happened.
Maybe we can return a warning/error for it.
while (low = high) {
- if (code = v2_code_table[mid].code code
- v2_code_table[mid - 1].code)
- return v2_code_table[mid].temp;
+ if (code = v2_code_table[mid].code
+ code v2_code_table[mid - 1].code)
+ break;
+ else if (code == TSADCV2_DATA_MASK)
+ break;
else if (code v2_code_table[mid].code)
low = mid + 1;
else
@@ -213,7 +216,16 @@ static long rk_tsadcv2_code_to_temp(u32 code)
mid = (low + high) / 2;
}
- return 125000;
+ /*
+* The 5C granularity provided by the table is too much. Let's
+* assume that the relationship between sensor readings and
+* temperature between 2 table entries is linear and interpolate
+* to produce less granular result.
+*/
+ num = v2_code_table[mid].temp - v2_code_table[mid - 1].temp;
+ num *= v2_code_table[mid - 1].code - code;
+ denom = v2_code_table[mid - 1].code - v2_code_table[mid].code;
+ return v2_code_table[mid - 1].temp + (num / denom);
}
/**
--
1.9.1
--
Best regards
Caesar Wang (王晓腾)
福州瑞芯微电子有限公司
Fuzhou Rockchip Electronics Co.Ltd
福建省福州市铜盘路软件大道89号软件园A区18号楼(350003)
Addr:No.18 Building, A District, No.89, software Boulevard Fuzhou, Fujian,PRC
Email:w...@rock-chips.com
Tel:+86-591-83991906/07-8221
--
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/
Fixing touch point jumps in the kernel (was Re: [PATCH] MAINTAINERS: Update rydberg's addresses)
changed the subject so it'll be easier to find in the archives. On Wed, Jan 21, 2015 at 08:38:46PM +0100, Henrik Rydberg wrote: Hi Benjamin, - there is a fragmentation problem: we would have to fix the bug in xorg-synaptics (which is slowly waiting for its death), libinput, ChromeOS, Qt Embedded, Kivy (I think), etc... Indeed, this is the problem I wanted to highlight. As the fragmentation problem grows (graphics, input, compositors, toolkits), the need for a common denominator grows as well. However, I do not think the kernel should be the single common denominator for all the world's problems. Rather, the purpose of the kernel is to convey hardware information and control as accurately, effectively and generically as possible. - it means that the mt protocol B can not be relied upon, because even if we state that each touch has its own slot, then it is false in this case. The case we are talking about is due to information missing in the hardware. At low enough sampling frequencies, there is no way to distinguish between a moving finger and a lift-and-press action. We could flag this hardware deficiency somehow, but making shit up in order to maintain the statue that we do have enough information is just asking for trouble. I agree that this point is valid: we cannot always trust the interpretation of touchpoints for certain hardware. However, there is nothing we can do about that, except flag for it. Also, if you compare the libinput implementation of the handling of the cursors jumps and the kernel implementation I proposed, there is a big difference in term of simplicity. No, this is wrong. In the kernel, while we are assigning the tracking IDs, we detect that there is a jump, and we just have to generate a new slot and close the first (done by 1 assignment of -1 to the current tracking ID). The kernel case would have to be accompanied by parameters, under the control of some user process, where adjustments are made to accomodate different usecases such as painting, gaming, air guitar playing, flick gestures, multi-user tablets, etc, etc. That is complex and unwanted. from the testing I've done, you cannot trigger this except by lifting a finger and raising a finger. There is no per-use-case requirement, it's a hardware deficiency that the hardware simply cannot detect this specific case of finger change. Also, note that the patch series has an explicit In order not to penalize better sensors, this parameter is not automatically enabled, but each driver has to manually set it to a reasonable value. so far we have only seen this on synaptics touchpads which has its own driver. so this wouldn't affect any device that doesn't need this anyway. so yes, we could implement a better gesture recognition like you explain below but it's also unneded on all but a few devices - which, in userspace, we cannot identify easily. In Libinput, well, you receive a slot, there is a jump, you detect it, then you have to create a new fake kernel event to stop the current slot, create a new one, and you then have to rewind the current state of the buttons, the hysteresis, add special case handling and hopefully, you did not introduced a bug in all the complex code. So you need to write unit tests (not an argument, I concede, but this is extra work), and in the future, someone will not understand what this is all about because the kernel should guarantee that the slots are sane. You do not need to do any of this (except the test cases, which would be needed anyway given the context-dependent interpretation of scarse data) if you intercept the touch points as they come in from the kernel, before the contact dynamics is fully trusted. Last time I checked that was mtdev or the touch frame layer or Xinput. mtdev is only used for protocol A devices these days so it doesn't apply on the synaptics pads. I was thinking of adding this to libevdev so at least _I_ only have to implement this once. except that for every touchpoint that I fix up in libevdev I then also have to maintain a correct tracking_id mapping since now the kernel and the userspace tracking IDs are out of sync. that leaves synaptics which for historical reasons can handle a device state but is bad at transitions. Injecting events requires a rewrite of much of the code. evdev - not as bad but similar. Since this only affects synaptics pads so far at least we don't have to worry about other drivers (in xorg at least). If I were grumpy (and I can be, ask Peter), I would say that sure, we can add such a case in the mtdev library, but the point of having the in-kernel tracking system was to slowly get away from the head over added by mtdev. No, this was not the reason. The tree main reasons were actually latency and power and code reduction. The mtdev layer still provides the functional bridge needed. However, the latency and number of cpu cycles
Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
On Thursday, January 22, 2015 04:12:41 AM Al Viro wrote:
On Wed, Jan 21, 2015 at 09:28:51PM -0500, Paul Moore wrote:
Al, do you mind if I fold your patch below into the existing patches?
No problem, but I'd probably prefer to put this series through vfs.git.
With the following as the first step:
I just finished fixing up the patchset and giving it a quick sanity test on my
system, some additional testing is still needed to verify that all the audit
stuff is still okay (I did change the __audit_inode() as discussed and bumped
the refcount in __audit_reusename()) but I think as things stand the boot
panic problems should be resolved - thanks again for your help.
I'm going to (re)post what I've currently got for a patchset and call it a
day. Tomorrow I'll add your below patch and finish up my testing, if all goes
well I'll repost the whole set. If you would prefer it to go via the VFS
tree, that's fine with me, as long as it hits Linus' tree at some point I'm
happy.
Cut down on do_path_lookup() callers
Use filename_lookup() instead. And don't bother with creating new
struct filename when caller already has one.
Signed-off-by: Al Viro v...@zeniv.linux.org.uk
---
diff --git a/fs/namei.c b/fs/namei.c
index bc35b02..73fcf42 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2046,7 +2046,8 @@ struct dentry *kern_path_locked(const char *name,
struct path *path) {
struct nameidata nd;
struct dentry *d;
- int err = do_path_lookup(AT_FDCWD, name, LOOKUP_PARENT, nd);
+ struct filename filename = {.name = name};
+ int err = filename_lookup(AT_FDCWD, filename, LOOKUP_PARENT, nd);
if (err)
return ERR_PTR(err);
if (nd.last_type != LAST_NORM) {
@@ -3290,7 +3291,7 @@ struct file *do_file_open_root(struct dentry *dentry,
struct vfsmount *mnt, return file;
}
-struct dentry *kern_path_create(int dfd, const char *pathname,
+static struct dentry *filename_create(int dfd, struct filename *name,
struct path *path, unsigned int lookup_flags)
{
struct dentry *dentry = ERR_PTR(-EEXIST);
@@ -3305,7 +3306,7 @@ struct dentry *kern_path_create(int dfd, const char
*pathname, */
lookup_flags = LOOKUP_REVAL;
- error = do_path_lookup(dfd, pathname, LOOKUP_PARENT|lookup_flags, nd);
+ error = filename_lookup(dfd, name, LOOKUP_PARENT|lookup_flags, nd);
if (error)
return ERR_PTR(error);
@@ -3359,6 +3360,13 @@ out:
path_put(nd.path);
return dentry;
}
+
+struct dentry *kern_path_create(int dfd, const char *pathname,
+ struct path *path, unsigned int lookup_flags)
+{
+ struct filename filename = {.name = pathname};
+ return filename_create(dfd, filename, path, lookup_flags);
+}
EXPORT_SYMBOL(kern_path_create);
void done_path_create(struct path *path, struct dentry *dentry)
@@ -3377,7 +3385,7 @@ struct dentry *user_path_create(int dfd, const char
__user *pathname, struct dentry *res;
if (IS_ERR(tmp))
return ERR_CAST(tmp);
- res = kern_path_create(dfd, tmp-name, path, lookup_flags);
+ res = filename_create(dfd, tmp, path, lookup_flags);
putname(tmp);
return res;
}
--
paul moore
security @ redhat
--
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/3] perf symbols: Ignore mapping symbols on aarch64
Aarch64 ELF files use mapping symbols with special names $x, $d
to identify regions of Aarch64 code (see Aarch64 ELF ABI - ARM
IHI 0056B, section 4.5.4 Mapping symbols).
The patch filters out these symbols at load time, similar to
696b97a perf symbols: Ignore mapping symbols on ARM changes
done for ARM before V8.
Signed-off-by: Victor Kamensky victor.kamen...@linaro.org
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Cc: Paul Mackerras pau...@samba.org
Cc: Ingo Molnar mi...@redhat.com
Cc: Arnaldo Carvalho de Melo a...@kernel.org
Cc: Adrian Hunter adrian.hun...@intel.com
Cc: Jiri Olsa jo...@redhat.com
Cc: Namhyung Kim namhy...@kernel.org
Cc: Avi Kivity a...@cloudius-systems.com
Cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Cc: Anton Blanchard an...@samba.org
Cc: David Ahern dsah...@gmail.com
Cc: Will Deacon will.dea...@arm.com
Cc: Dave Martin dave.mar...@arm.com
Acked-by: Will Deacon will.dea...@arm.com
---
tools/perf/util/symbol-elf.c | 8
1 file changed, 8 insertions(+)
diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 06fcd1b..1e188dd 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -862,6 +862,14 @@ int dso__load_sym(struct dso *dso, struct map *map,
!strcmp(elf_name, $t))
continue;
}
+ /* Reject Aarch64 ELF mapping symbols: these aren't unique and
+* don't identify functions, so will confuse the profile
+* output: */
+ if (ehdr.e_machine == EM_AARCH64) {
+ if (!strcmp(elf_name, $x) ||
+ !strcmp(elf_name, $d))
+ continue;
+ }
if (runtime_ss-opdsec sym.st_shndx == runtime_ss-opdidx) {
u32 offset = sym.st_value - syms_ss-opdshdr.sh_addr;
--
1.9.3
--
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/3] perf symbols: improve abi compliance in arm mapping symbols handling
Both Arm and Aarch64 ELF ABI allow mapping symbols be in from
either $d or $d.any. But current code that handles mapping
symbols only deals with the first, dollar character and a single
letter, case.
The patch adds handling of the second case with period
followed by any characters.
Suggested-by: Russell King li...@arm.linux.org.uk
Suggested-by: Will Deacon will.dea...@arm.com
Signed-off-by: Victor Kamensky victor.kamen...@linaro.org
Acked-by: Will Deacon will.dea...@arm.com
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Cc: Paul Mackerras pau...@samba.org
Cc: Ingo Molnar mi...@redhat.com
Cc: Arnaldo Carvalho de Melo a...@kernel.org
Cc: Adrian Hunter adrian.hun...@intel.com
Cc: Jiri Olsa jo...@redhat.com
Cc: Namhyung Kim namhy...@kernel.org
Cc: Avi Kivity a...@cloudius-systems.com
Cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Cc: Anton Blanchard an...@samba.org
Cc: David Ahern dsah...@gmail.com
Cc: Dave Martin dave.mar...@arm.com
---
tools/perf/util/symbol-elf.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 1e188dd..7fd35d6 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -857,17 +857,16 @@ int dso__load_sym(struct dso *dso, struct map *map,
* don't identify functions, so will confuse the profile
* output: */
if (ehdr.e_machine == EM_ARM) {
- if (!strcmp(elf_name, $a) ||
- !strcmp(elf_name, $d) ||
- !strcmp(elf_name, $t))
+ if (elf_name[0] == '$' strchr(adt, elf_name[1])
+(elf_name[2] == '\0' || elf_name[2] == '.'))
continue;
}
/* Reject Aarch64 ELF mapping symbols: these aren't unique and
* don't identify functions, so will confuse the profile
* output: */
if (ehdr.e_machine == EM_AARCH64) {
- if (!strcmp(elf_name, $x) ||
- !strcmp(elf_name, $d))
+ if (elf_name[0] == '$' strchr(dx, elf_name[1])
+(elf_name[2] == '\0' || elf_name[2] == '.'))
continue;
}
--
1.9.3
--
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/3] perf symbols: debuglink should take symfs option into account
Currently code that tries to read corresponding debug symbol
file from .gnu_debuglink section (DSO_BINARY_TYPE__DEBUGLINK)
does not take in account symfs option, so filename__read_debuglink
function cannot open ELF file, if symfs option is used.
Fix is to add proper handling of symfs as it is done in other
places: use __symbol__join_symfs function to get real file name
of target ELF file.
Signed-off-by: Victor Kamensky victor.kamen...@linaro.org
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Cc: Paul Mackerras pau...@samba.org
Cc: Ingo Molnar mi...@redhat.com
Cc: Arnaldo Carvalho de Melo a...@kernel.org
Cc: Jiri Olsa jo...@kernel.org
Cc: Namhyung Kim namhy...@kernel.org
Cc: Adrian Hunter adrian.hun...@intel.com
Cc: Waiman Long waiman.l...@hp.com
Cc: David Ahern dsah...@gmail.com
Acked-and-tested-by: David Ahern dsah...@gmail.com
---
tools/perf/util/dso.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index 45be944..ca8d8d5 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -45,13 +45,13 @@ int dso__read_binary_type_filename(const struct dso *dso,
case DSO_BINARY_TYPE__DEBUGLINK: {
char *debuglink;
- strncpy(filename, dso-long_name, size);
- debuglink = filename + dso-long_name_len;
+ len = __symbol__join_symfs(filename, size, dso-long_name);
+ debuglink = filename + len;
while (debuglink != filename *debuglink != '/')
debuglink--;
if (*debuglink == '/')
debuglink++;
- ret = filename__read_debuglink(dso-long_name, debuglink,
+ ret = filename__read_debuglink(filename, debuglink,
size - (debuglink - filename));
}
break;
--
1.9.3
--
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/
linux-next: manual merge of the kvm-arm tree with the rcu tree
Hi all, Today's linux-next merge of the kvm-arm tree got a conflict in arch/arm64/kvm/Kconfig between commit 83fe27ea5311 (rcu: Make SRCU optional by using CONFIG_SRCU) from the rcu tree and commit 7276030a082c (KVM: arm/arm64: Enable Dirty Page logging for ARMv8) from the kvm-arm tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc arch/arm64/kvm/Kconfig index b334084d3675,3ce389b3c21c.. --- a/arch/arm64/kvm/Kconfig +++ b/arch/arm64/kvm/Kconfig @@@ -26,7 -27,7 +27,8 @@@ config KV select KVM_ARM_HOST select KVM_ARM_VGIC select KVM_ARM_TIMER + select KVM_GENERIC_DIRTYLOG_READ_PROTECT + select SRCU ---help--- Support hosting virtualized guest machines. pgp6ldIgKt0ZS.pgp Description: OpenPGP digital signature
Re: [PATCH] mm/slub: use unchecked percpu access within preemptible sections
On Wed, Jan 21, 2015 at 09:27:41PM -0500, Sasha Levin wrote:
On 01/21/2015 08:59 PM, Joonsoo Kim wrote:
On Tue, Jan 20, 2015 at 11:31:43PM -0500, Sasha Levin wrote:
Commit mm/slub: optimize alloc/free fastpath by removing preemption
on/off
has added access to percpu memory while the code is preemptible.
While those accesses are okay, this creates a huge amount of warnings
from
the code that checks for that.
Signed-off-by: Sasha Levin sasha.le...@oracle.com
Hello,
I already sent the patch to fix this issue and it is in mmotm, but,
not be released yet.
https://lkml.org/lkml/2015/1/19/17
The patch you sent out still has the issue. The one I sent goes on top of
it.
+ do {
+ tid = this_cpu_read(s-cpu_slab-tid); === checked percpu
access
+ c = raw_cpu_ptr(s-cpu_slab);
+ } while (IS_ENABLED(CONFIG_PREEMPT) unlikely(tid != c-tid));
Hello,
this_cpu_xxx() is designed to be called regardless of interrupts and
preemption.
In Documentation/this_cpu_ops.txt,
The following this_cpu() operations with implied preemption protection
are defined. These operations can be used without worrying about
preemption and interrupts.
this_cpu_read(pcp)
...
And, for correctness of algorithm, tid should be fetched through
this_cpu_read() rather than raw_cpu_read(). Generic implementation of
raw_cpu_read() has a race window to fetch different cpu's tid instead
of the cpu where we are at now and this will cause algorithm broken.
Thanks.
--
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] power: rt5033: Add Richtek RT533 drivers
Hi, On Thu, Jan 22, 2015 at 01:06:38PM +0900, Beomho Seo wrote: This patchset adds driver for Richtek rt5033 chip The chip contains switching charge mode Li-Ion/Li-Polymer battery charger, fuelgauge. Additionally, This includes document for device tree of RT5033 device. Thanks, applied. -- Sebastian signature.asc Description: Digital signature
Re: perf: easily crash kernel with rapl event close
Vince, On Wed, Jan 21, 2015 at 10:55 AM, Vince Weaver vincent.wea...@maine.edu wrote: Hello on my haswell system, running 3.19-rc5, and with echo 0 /proc/sys/kernel/perf_event_paranoid I can easily crash my system with the attached test program that simply opens a RAPL event and then closes it. This bug was found by the perf_fuzzer. It looks like somehow rapl_pmu gets freed to NULL but the call in rapl_scale() __this_cpu_read(rapl_pmu-hw_unit) still happens. I don't see how this can happen. I get some crashes but not with your program on my laptop. But I cannot catch the serial console from my laptop. Will try with another machine tomorrow. [ 189.424003] BUG: unable to handle kernel paging request at cc68 [ 189.431591] IP: [81032bb2] rapl_event_update+0x82/0xb0 [ 189.438069] PGD 0 [ 189.440308] Oops: [#1] SMP [ 189.443882] Modules linked in: fuse x86_pkg_temp_thermal intel_powerclamp intel_rapl iosf_mbi coretemp kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel snd_hda_codec_hdmi aes_x86_64 lrw i915 gf128mul glue_helper evdev mei_me snd_hda_codec_realtek snd_hda_codec_generic xhci_pci ppdev iTCO_wdt iTCO_vendor_support lpc_ich mfd_core mei psmouse ablk_helper serio_raw parport_pc cryptd pcspkr i2c_i801 xhci_hcd tpm_tis snd_hda_intel parport tpm battery video snd_hda_controller snd_hda_codec snd_hwdep snd_pcm snd_timer drm_kms_helper snd soundcore wmi button processor drm i2c_algo_bit sg sr_mod sd_mod cdrom ehci_pci ehci_hcd ahci libahci libata e1000e usbcore ptp crc32c_intel scsi_mod usb_common pps_core thermal fan thermal_sys [ 189.515919] CPU: 5 PID: 0 Comm: swapper/5 Not tainted 3.19.0-rc5+ #123 [ 189.522911] Hardware name: LENOVO 10AM000AUS/SHARKBAY, BIOS FBKT72AUS 01/26/2014 [ 189.530797] task: 880119470390 ti: 880119474000 task.ti: 880119474000 [ 189.538773] RIP: 0010:[81032bb2] [81032bb2] rapl_event_update+0x82/0xb0 [ 189.547823] RSP: 0018:88011eb43e40 EFLAGS: 00010046 [ 189.553485] RAX: 0208d460 RBX: 88011eb43e4c RCX: 0020 [ 189.561104] RDX: RSI: 0208d460 RDI: [ 189.568774] RBP: 88011eb43e78 R08: R09: 0090 [ 189.576300] R10: R11: 0001 R12: 0208d460 [ 189.583903] R13: 8800cfbb29a0 R14: 8800cfbb2800 R15: 0208d460 [ 189.591389] FS: () GS:88011eb4() knlGS: [ 189.600138] CS: 0010 DS: ES: CR0: 80050033 [ 189.606320] CR2: cc68 CR3: 01c13000 CR4: 001407e0 [ 189.613965] DR0: DR1: DR2: [ 189.621567] DR3: DR6: fffe0ff0 DR7: 0400 [ 189.629219] Stack: [ 189.631419] 8800cd9ffbe0 cd9ffb80 8800cfbb2800 8800cd9ffb80 [ 189.639447] 0082 0004 e8d43f54 88011eb43ea8 [ 189.647569] 81032db8 8800cfbb2800 e8d43d10 002c1a89ebed [ 189.655590] Call Trace: [ 189.658229] IRQ [ 189.660307] [81032db8] rapl_pmu_event_stop+0x98/0x120 [ 189.666975] [81032e53] rapl_pmu_event_del+0x13/0x20 [ 189.673271] [811585b6] event_sched_out.isra.73+0xf6/0x240 [ 189.680082] [81158969] __perf_remove_from_context+0x59/0xd0 [ 189.687086] [810ea589] ? tick_nohz_irq_exit+0x29/0x30 [ 189.693536] [811541b0] remote_function+0x50/0x60 [ 189.699549] [810ef762] flush_smp_call_function_queue+0x62/0x140 [ 189.706905] [810efd83] generic_smp_call_function_single_interrupt+0x13/0x60 [ 189.715411] [81046dd7] smp_call_function_single_interrupt+0x27/0x40 [ 189.723165] [816bf7bd] call_function_single_interrupt+0x6d/0x80 [ 189.730545] EOI [ 189.732617] [81553ca5] ? cpuidle_enter_state+0x65/0x160 [ 189.739449] [81553c91] ? cpuidle_enter_state+0x51/0x160 [ 189.746056] [81553e87] cpuidle_enter+0x17/0x20 [ 189.751787] [810aebc1] cpu_startup_entry+0x311/0x3c0 [ 189.758151] [810476b0] start_secondary+0x140/0x150 [ 189.764307] Code: 00 00 41 8b be 48 01 00 00 48 89 de e8 d8 42 02 00 66 90 49 89 c7 4c 89 e0 4d 0f b1 7d 00 4c 39 e0 75 d6 4c 89 f8 b9 20 00 00 00 48 8b 15 af a0 fd 7e 4c 29 e0 65 8b 52 38 48 98 29 d1 48 d3 e0 [ 189.785900] RIP [81032bb2] rapl_event_update+0x82/0xb0 [ 189.792456] RSP 88011eb43e40 [ 189.796233] CR2: cc68 [ 189.799800] ---[ end trace 71cd60a89559b021 ]--- [ 189.804777] Kernel panic - not syncing: Fatal exception in interrupt [ 189.811644] Kernel Offset: 0x0 from 0x8100 (relocation range: 0x8000-0x9fff) [ 189.822598] drm_kms_helper: panic occurred, switching back to text console
Re: RCU CPU stall console spews leads to soft lockup disabled is reasonable ?
On Thu, Jan 22, 2015 at 11:08:11AM +0800, Zhang Zhen wrote:
On 2015/1/22 4:06, Paul E. McKenney wrote:
On Wed, Jan 21, 2015 at 10:10:51AM -0500, Don Zickus wrote:
On Wed, Jan 21, 2015 at 10:26:27AM +0800, Zhang Zhen wrote:
This may not cause other problems but what happens if you comment out the
'touch_softlockup_watchdog' from the touch_nmi_watchdog function like
below (based on latest upstream cb59670870)?
The idea is that console printing for that cpu won't reset the softlockup
detector. Again other bad things might happen and this patch may not be
a
good final solution, but it can help give me a clue about what is going
on.
I commented out the 'touch_softlockup_watchdog' from the
touch_nmi_watchdog function
(based on latest upstream ec6f34e5b552).
This triggered RCU stall and softlockup, but softlockup just printk only
once.
Yes, as expected. Instead of flooding the console with the same message,
report only once until the high priority task is re-kicked and can re-arm
the softlockup timer again. So this makes sense. Based on your double
spin lock test, I don't ever expect this to get re-armed, so you should
not expect to see another message.
As you mentioned other bad things lead to softlockup just printk only
once.
What's the bad thing ?
Well, one of the assumptions here is that if you are going to have
interrupts disabled for a long time and purposely kick the hardlockup
detector (with touch_nmi_watchdog), then you can reasonably assume that
softlockups will go off too if you don't also kick the softlockup detector
(even though there is a window where this isn't true: 2*thresh - thresh).
So the patch I gave you, can lead to false softlockup warnings.
On the flip side, printing to the console also blocks hardlockups from
showing up. But I believe lng ago, Paul adjusted the rcu stalls to be
longer than a hardlockup/softlockup timeout to prevent such scenarios.
I am not sure what to do here. Printing to the console has traditionally
been slow (especially if doing so with interrupts disabled), so a
touch_nmi_watchdog has been necessary. But a side effect of that, is it
prevents the lockup detectors from going off if printing repeatedly.
Now we can hack up rcu stall to only print once until it is re-armed.
This would show rcu stall printing first, followed two minutes later by
a softlockup, which sorta achieves what you want.
However, at the end of the day, an rcu stall, softlockup or hardlockup is
a bad thing, does it matter if you get one or all of them? One should be
enough to start an investigation, no?
Hear, hear!!!
Ok, thanks for Don's and your patience!
We enriched softlockup printk information, so we want to get softlockup
warnning.
Booting with rcupdate.rcu_cpu_stall_suppress=1 will shut up the RCU
CPU stall warnings.
Thanx, Paul
I don't know. I am leaning towards 'working as expected' and nothing to
really fix here. Does anyone have any suggestions on what assumptions we
could change to handle this better?
Cheers,
Don
/ #
/ # echo 60 /proc/sys/kernel/watchdog_thresh
/ # busybox insmod softlockup_test.ko
/ # [ 39.044058] INFO: rcu_preempt detected stalls on CPUs/tasks: {}
(detected by 0, t=21002 jiffies, g=78, c=77, q=4)
[ 39.044058] INFO: Stall ended before state dump start
[ 102.049045] INFO: rcu_preempt detected stalls on CPUs/tasks: {}
(detected by 0, t=84007 jiffies, g=78, c=77, q=4)
[ 102.049045] INFO: Stall ended before state dump start
[ 160.482123] BUG: soft lockup - CPU#0 stuck for 134s! [busybox:54]
[ 165.054075] INFO: rcu_preempt detected stalls on CPUs/tasks: {}
(detected by 0, t=147012 jiffies, g=78, c=77, q=4)
[ 165.054075] INFO: Stall ended before state dump start
[ 228.059045] INFO: rcu_preempt detected stalls on CPUs/tasks: {}
(detected by 0, t=210017 jiffies, g=78, c=77, q=4)
[ 228.059045] INFO: Stall ended before state dump start
[ 291.064099] INFO: rcu_preempt detected stalls on CPUs/tasks: {}
(detected by 0, t=273022 jiffies, g=78, c=77, q=4)
[ 291.064099] INFO: Stall ended before state dump start
[ 354.069074] INFO: rcu_preempt detected stalls on CPUs/tasks: {}
(detected by 0, t=336027 jiffies, g=78, c=77, q=4)
[ 354.069099] INFO: Stall ended before state dump start
[ 417.074045] INFO: rcu_preempt detected stalls on CPUs/tasks: {}
(detected by 0, t=399032 jiffies, g=78, c=77, q=4)
[ 417.074045] INFO: Stall ended before state dump start
[ 480.079099] INFO: rcu_preempt detected stalls on CPUs/tasks: {}
(detected by 0, t=462037 jiffies, g=78, c=77, q=4)
[ 480.079099] INFO: Stall ended before state dump start
[ 543.084099] INFO: rcu_preempt detected stalls on CPUs/tasks: {}
(detected by 0, t=525042 jiffies, g=78, c=77, q=4)
[ 543.084099] INFO: Stall ended
Re: mmotm: mm-slub-optimize-alloc-free-fastpath-by-removing-preemption-on-off.patch is causing preemptible splats
Hi Andrew, On Wed, 21 Jan 2015 19:34:11 -0800 Andrew Morton a...@linux-foundation.org wrote: On Thu, 22 Jan 2015 10:51:23 +0900 Joonsoo Kim iamjoonsoo@lge.com wrote: The most recent -mmotm was a bit of a trainwreck. I'm scrambling to get the holes plugged so I can get another mmotm out today. Another mmotm will fix many issues from me. :/ I hit a wont-boot-cant-find-init in linux-next so I get to spend tomorrow bisecting that :( There has been a long discussion about something like that already. Subject Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpFgdYeB9yzO.pgp Description: OpenPGP digital signature
Re: [alsa-devel][PATCH 3/3] ASoC: fsl_sai: Add support for Right-J mode
On Wed, Jan 21, 2015 at 10:53:20AM -0800, Nicolin Chen wrote: On Tue, Jan 20, 2015 at 08:21:20PM +0800, Zidan Wang wrote: Add Right-J mode and set TCR5 FBT bit to let data right justify. Signed-off-by: Zidan Wang zidan.w...@freescale.com - if (sai-is_lsb_first) + if (sai-is_lsb_first sai-is_right_j_mode) val_cr5 |= FSL_SAI_CR5_FBT(0); Are you sure that FBT(0) is correct for right justified mode? Because the original code is using FBT(0) for the lsb_first situation and it shouldn't be right justified mode as default. I am not sure about that. I assume lsb_first as big endian data. For 16 bit data format, the 2 bytes data will in high address of 4 bytes fifo. So the FBT is 16 for left-j and 0 for right-j. But big endian is bytes convert not bits convert. It makes me confuse. And send to community for help. Nicolin -- 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] powerpc/powernv: Skip registering log region when CONFIG_PRINTK=n
On Wed, 2015-01-21 at 21:26 -0500, Pranith Kumar wrote: When CONFIG_PRINTK=n, log_buf_addr_get() returns NULL and log_buf_len_get() return 0. Check for these return values and skip registering the dump buffer. Signed-off-by: Pranith Kumar bobby.pr...@gmail.com CC: Michael Ellerman m...@ellerman.id.au --- arch/powerpc/platforms/powernv/opal.c | 6 ++ 1 file changed, 6 insertions(+) What changed since v1? I don't see anything? cheers -- 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] ARM: decompressor: remove unused cache flush code
As ARM ARM says, the bit 19-16 of ID_MMFR1 is always 0b because
ARMv7 requires a hierarchical cache implementation.
The line mcrp15, 0, r10, c7, c14, 0 is not reachable.
Moreover, the v7_flush_dcache_all in arch/arm/mm/cache-v7.S does not
check the ID_MMFR1.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---
arch/arm/boot/compressed/head.S | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 9dff614..32f0d79 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -1085,15 +1085,9 @@ __armv6_mmu_cache_flush:
__armv7_mmu_cache_flush:
tst r4, #1
bne iflush
- mrc p15, 0, r10, c0, c1, 5 @ read ID_MMFR1
- tst r10, #0xf 16 @ hierarchical cache (ARMv7)
+ stmfd sp!, {r0-r7, r9-r11}
mov r10, #0
- beq hierarchical
- mcr p15, 0, r10, c7, c14, 0 @ clean+invalidate D
- b iflush
-hierarchical:
mcr p15, 0, r10, c7, c10, 5 @ DMB
- stmfd sp!, {r0-r7, r9-r11}
mrc p15, 1, r0, c0, c0, 1 @ read clidr
andsr3, r0, #0x700 @ extract loc from clidr
mov r3, r3, lsr #23 @ left align loc bit field
--
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: [PATCH 1/2] watchdog: dw_wdt: pat the watchdog before enabling it
Dear Doug, On Wed, 21 Jan 2015 15:17:22 -0800 Doug Anderson diand...@chromium.org wrote: On some dw_wdt implementations the top register may be initted to 0 at bootup. In such a case, each pat of the watchdog will reset the timer to 0x. That's pretty short. + Guenter Roeck This should have been fixed by dfa07141e7a792(watchdog: dw_wdt: initialise TOP_INIT in dw_wdt_set_top()) In fact, my original fix is as similar as your patch http://www.spinics.net/lists/arm-kernel/msg363658.html Then Guenter Roeck suggest one elegant solution which is the base of commit dfa07141e7a792. http://www.spinics.net/lists/arm-kernel/msg363908.html The input clock of the wdt can be any of a wide range of values. On an rk3288 system, I've seen the wdt clock be 24.75 MHz. That means each tick is ~40ns and we'll count to 0x in ~2.6ms. Because of the above two facts, it's a really good idea to pat the watchdog after initting the top register properly and before enabling the watchdog. If you don't then there's no way we'll get the next heartbeat in time. Signed-off-by: Doug Anderson diand...@chromium.org --- drivers/watchdog/dw_wdt.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/watchdog/dw_wdt.c b/drivers/watchdog/dw_wdt.c index b34a2e4..fc92bea 100644 --- a/drivers/watchdog/dw_wdt.c +++ b/drivers/watchdog/dw_wdt.c @@ -170,6 +170,7 @@ static int dw_wdt_open(struct inode *inode, struct file *filp) * the maximum and then start it. */ dw_wdt_set_top(DW_WDT_MAX_TOP); + dw_wdt_keepalive(); writel(WDOG_CONTROL_REG_WDT_EN_MASK, dw_wdt.regs + WDOG_CONTROL_REG_OFFSET); } -- 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 v9 00/17] Kernel address sanitizer - runtime memory debugger.
2015-01-22 3:22 GMT+03:00 Sasha Levin sasha.le...@oracle.com:
On 01/21/2015 11:51 AM, Andrey Ryabinin wrote:
Changes since v8:
- Fixed unpoisoned redzones for not-allocated-yet object
in newly allocated slab page. (from Dmitry C.)
- Some minor non-function cleanups in kasan internals.
- Added ack from Catalin
- Added stack instrumentation. With this we could detect
out of bounds accesses in stack variables. (patch 12)
- Added globals instrumentation - catching out of bounds in
global varibles. (patches 13-17)
- Shadow moved out from vmalloc into hole between vmemmap
and %esp fixup stacks. For globals instrumentation
we will need shadow backing modules addresses.
So we need some sort of a shadow memory allocator
(something like vmmemap_populate() function, except
that it should be available after boot).
__vmalloc_node_range() suits that purpose, except that
it can't be used for allocating for shadow in vmalloc
area because shadow in vmalloc is already 'allocated'
to protect us from other vmalloc users. So we need
16TB of unused addresses. And we have big enough hole
between vmemmap and %esp fixup stacks. So I moved shadow
there.
I'm not sure which new addition caused it, but I'm getting tons of
false positives from platform drivers trying to access memory they
don't own - because they expect to find hardware there.
To be sure, that this is really false positives, could you try with
patches in attachment?
That should fix some bugs in several platform drivers.
I suspect we'd need to mark that memory region somehow to prevent
accesses to it from triggering warnings?
Thanks,
Sasha
diff --git a/drivers/video/backlight/da9052_bl.c b/drivers/video/backlight/da9052_bl.c
index d4bd74bd..b1943e7 100644
--- a/drivers/video/backlight/da9052_bl.c
+++ b/drivers/video/backlight/da9052_bl.c
@@ -165,6 +165,7 @@ static struct platform_device_id da9052_wled_ids[] = {
.name = da9052-wled3,
.driver_data = DA9052_TYPE_WLED3,
},
+ { },
};
static struct platform_driver da9052_wled_driver = {
diff --git a/drivers/crypto/ccp/ccp-dev.c b/drivers/crypto/ccp/ccp-dev.c
index c6e6171..ca29c12 100644
--- a/drivers/crypto/ccp/ccp-dev.c
+++ b/drivers/crypto/ccp/ccp-dev.c
@@ -583,6 +583,7 @@ bool ccp_queues_suspended(struct ccp_device *ccp)
#ifdef CONFIG_X86
static const struct x86_cpu_id ccp_support[] = {
{ X86_VENDOR_AMD, 22, },
+ { },
};
#endif
diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
index b5e7c46..89ac1d5 100644
--- a/drivers/rtc/rtc-s5m.c
+++ b/drivers/rtc/rtc-s5m.c
@@ -832,6 +832,7 @@ static SIMPLE_DEV_PM_OPS(s5m_rtc_pm_ops, s5m_rtc_suspend, s5m_rtc_resume);
static const struct platform_device_id s5m_rtc_id[] = {
{ s5m-rtc, S5M8767X },
{ s2mps14-rtc, S2MPS14X },
+ { },
};
static struct platform_driver s5m_rtc_driver = {
Re: mmotm: mm-slub-optimize-alloc-free-fastpath-by-removing-preemption-on-off.patch is causing preemptible splats
On Thu, 22 Jan 2015 16:14:02 +1100 Stephen Rothwell s...@canb.auug.org.au wrote: Hi Andrew, On Wed, 21 Jan 2015 19:34:11 -0800 Andrew Morton a...@linux-foundation.org wrote: On Thu, 22 Jan 2015 10:51:23 +0900 Joonsoo Kim iamjoonsoo@lge.com wrote: The most recent -mmotm was a bit of a trainwreck. I'm scrambling to get the holes plugged so I can get another mmotm out today. Another mmotm will fix many issues from me. :/ I hit a wont-boot-cant-find-init in linux-next so I get to spend tomorrow bisecting that :( There has been a long discussion about something like that already. Subject Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs ah, thanks. You might have saved me a ton of effort there. And oolookitat, a fix. I love it when viro says Oh, fuck. -- 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] 8250_core.c
This was generated from 3.14 kernel, but since its so small it will likely
apply to newer
kernels without issue.
A lesser travelled code path specifically crafted for tx interrupt buggy
UARTs seems to be testing the wrong bit for whether or not to prime the
transmit pump. The result is that the tx interrupt never occurs on one chip
I am using that falls into the UART_BUG_TXEN category as I understand it.
The 16550 data sheet even names the interrupt THRE and not transmit
shift register empty. The interrupt is fired when the holding register, or its
logical equivalent, the fifo, goes empty; not when the shift register goes
empty. This is a code bug in code hoping to fix a bug in hardware.
The reason this is so late coming to the surface is that lately the 8250
interrupt handler polls for all kinds of special status beyond the intention
of the hardware's purpose specific interrupt. Therefore so long as you
were in the interrupt handler (even if for purposes of servicing a recv
interrupt, you could recover from the broken transmit chain. But if you are
only transmitting, not receiving, then this bug can manifest itself.
This is the fix. It is harmless because so long as the fifo is empty, it
should be legal to re-fill it fully anyways.
Signed-off-by: Dick Hollenbeck d...@softplc.com
=== modified file 'drivers/tty/serial/8250/8250_core.c'
--- old/drivers/tty/serial/8250/8250_core.c 2014-07-14 18:39:13 +
+++ new/drivers/tty/serial/8250/8250_core.c 2015-01-22 05:28:33 +
@@ -1302,11 +1302,15 @@ static void serial8250_start_tx(struct u
up-ier |= UART_IER_THRI;
serial_port_out(port, UART_IER, up-ier);
+ /*
+ * If setting UART_IER_THRI does not cause an
+ * immediate tx interrupt
+ */
if (up-bugs UART_BUG_TXEN) {
unsigned char lsr;
lsr = serial_in(up, UART_LSR);
up-lsr_saved_flags |= lsr LSR_SAVE_FLAGS;
- if (lsr UART_LSR_TEMT)
+ if (lsr UART_LSR_THRE)
serial8250_tx_chars(up);
}
}
Re: [PATCH V3] tick/broadcast: Make movement of broadcast hrtimer robust against hotplug
On 01/21/2015 05:16 PM, Thomas Gleixner wrote:
On Tue, 20 Jan 2015, Preeti U Murthy wrote:
diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
index 5544990..f3907c9 100644
--- a/kernel/time/clockevents.c
+++ b/kernel/time/clockevents.c
@@ -568,6 +568,7 @@ int clockevents_notify(unsigned long reason, void *arg)
case CLOCK_EVT_NOTIFY_CPU_DYING:
tick_handover_do_timer(arg);
+tick_shutdown_broadcast_oneshot(arg);
break;
case CLOCK_EVT_NOTIFY_SUSPEND:
@@ -580,7 +581,6 @@ int clockevents_notify(unsigned long reason, void *arg)
break;
case CLOCK_EVT_NOTIFY_CPU_DEAD:
-tick_shutdown_broadcast_oneshot(arg);
tick_shutdown_broadcast(arg);
tick_shutdown(arg);
/*
diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
index 066f0ec..f983983 100644
--- a/kernel/time/tick-broadcast.c
+++ b/kernel/time/tick-broadcast.c
@@ -675,8 +675,11 @@ static void broadcast_move_bc(int deadcpu)
if (!bc || !broadcast_needs_cpu(bc, deadcpu))
return;
-/* This moves the broadcast assignment to this cpu */
-clockevents_program_event(bc, bc-next_event, 1);
+/* Since a cpu with the earliest wakeup is nominated as the
+ * standby cpu, the next cpu to invoke BROADCAST_ENTER
+ * will now automatically take up the duty of broadcasting.
+ */
+bc-next_event.tv64 = KTIME_MAX;
So that relies on the fact, that cpu_down() currently forces ALL cpus
into stop_machine(). Of course this is not in any way obvious and any
change to this will cause even more hard to debug issues.
Hmm.. true this is a concern.
And to be honest, the clever 'set next_event to KTIME_MAX' is even
more nonobvious because it's only relevant for your hrtimer based
broadcasting magic. Any real broadcast device does not care about this
at all.
bc-next_event is set to max only if CLOCK_EVT_FEATURE_HRTIMER is true.
It does not affect the usual broadcast logic.
This whole random notifier driven hotplug business is just a
trainwreck. I'm still trying to convert this to a well documented
state machine, so I rather prefer to make this an explicit take over
rather than a completely undocumented 'works today' mechanism.
What about the patch below?
Thanks,
tglx
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 5d220234b3ca..7a9b1ae4a945 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -16,6 +16,7 @@
#include linux/bug.h
#include linux/kthread.h
#include linux/stop_machine.h
+#include linux/clockchips.h
#include linux/mutex.h
#include linux/gfp.h
#include linux/suspend.h
@@ -421,6 +422,12 @@ static int __ref _cpu_down(unsigned int cpu, int
tasks_frozen)
while (!idle_cpu(cpu))
cpu_relax();
+ /*
+ * Before waiting for the cpu to enter DEAD state, take over
+ * any tick related duties
+ */
+ clockevents_notify(CLOCK_EVT_NOTIFY_CPU_DEAD, cpu);
+
/* This actually kills the CPU. */
__cpu_die(cpu);
diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index 37e50aadd471..3c1bfd0f7074 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1721,11 +1721,8 @@ static int hrtimer_cpu_notify(struct notifier_block
*self,
break;
case CPU_DEAD:
case CPU_DEAD_FROZEN:
- {
- clockevents_notify(CLOCK_EVT_NOTIFY_CPU_DEAD, scpu);
migrate_hrtimers(scpu);
break;
- }
#endif
default:
How about when the cpu that is going offline receives a timer interrupt
just before setting its state to CPU_DEAD ? That is still possible right
given that its clock devices may not have been shutdown and it is
capable of receiving interrupts for a short duration. Even with the
above patch, is the following scenario possible ?
CPU0 CPU1
t0 Receives timer interrupt
t1 Sees that there are hrtimers
to be serviced (hrtimers are not yet migrated)
t2 calls hrtimer_interrupt()
t3 tick_program_event() CPU_DEAD notifiers
CPU0's td-evtdev = NULL
t4 clockevent_program_event()
references NULL tick device pointer
So my concern is that since the CLOCK_EVT_NOTIFY_CPU_DEAD callback
handles shutting down of devices besides moving tick related duties.
it's functions may race with the hotplug cpu still handling tick events.
We do check on powerpc if the timer interrupt has arrived on an offline
cpu, but that is to avoid an entirely different scenario and not one
like the above. I would not expect the arch to check if a timer
interrupt arrived on an offline cpu. A timer interrupt may be serviced
as long as the tick device is alive.
Regards
Preeti U Murthy
--
To unsubscribe from this list: send the
[PATCH] mm, vmacache: Add kconfig VMACACHE_SHIFT
Add a new kconfig option VMACACHE_SHIFT (as a power of 2) to specify the number of slots vma cache has for each thread. Range is chosen 0-4 (1-16 slots) to consider both overhead and performance penalty. Default is 2 (4 slots) as it originally is, which provides good enough balance. Signed-off-by: WANG Chao chaow...@redhat.com --- include/linux/sched.h | 2 +- mm/Kconfig| 7 +++ 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/include/linux/sched.h b/include/linux/sched.h index 8db31ef..56fd96d 100644 --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -134,7 +134,7 @@ struct perf_event_context; struct blk_plug; struct filename; -#define VMACACHE_BITS 2 +#define VMACACHE_BITS CONFIG_VMACACHE_SHIFT #define VMACACHE_SIZE (1U VMACACHE_BITS) #define VMACACHE_MASK (VMACACHE_SIZE - 1) diff --git a/mm/Kconfig b/mm/Kconfig index 1d1ae6b..7b82a52 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -618,3 +618,10 @@ config MAX_STACK_SIZE_MB changed to a smaller value in which case that is used. A sane initial value is 80 MB. + +config VMACACHE_SHIFT + int Number of slots in per-thread VMA cache (as a power of 2) + range 0 4 + default 2 + help + This is the number of slots VMA cache has for each thread. -- 2.1.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 2/5] mtd: nand: Add qcom nand controller driver
Hi,
On 01/21/2015 06:24 AM, Daniel Ehrenberg wrote:
On Fri, Jan 16, 2015 at 6:48 AM, Archit Taneja arch...@codeaurora.org wrote:
+/*
+ * the bad block marker is readable only when we read the page with ECC
+ * disabled. all the read/write commands like NAND_CMD_READOOB, NAND_CMD_READ0
+ * and NAND_CMD_PAGEPROG are executed in the driver with ECC enabled.
therefore,
+ * the default nand helper functions to detect a bad block or mark a bad block
+ * can't be used.
+ */
+static int qcom_nandc_block_bad(struct mtd_info *mtd, loff_t ofs, int getchip)
+{
+ int page, r, mark, bad = 0;
+ struct nand_chip *chip = mtd-priv;
+ struct nand_ecc_ctrl *ecc = chip-ecc;
+ int cwperpage = ecc-steps;
+ struct qcom_nandc_data *this = chip-priv;
+ u32 flash_status;
+
+ pre_command(this, NAND_CMD_NONE);
+
+ page = (int)(ofs chip-page_shift) chip-pagemask;
+
+ /*
+* configure registers for a raw page read, the address is set to the
+* beginning of the last codeword
+*/
+ this-use_ecc = false;
+ set_address(this, this-cw_size * (cwperpage - 1), page);
+
+ /* we just read one codeword that contains the bad block marker */
+ update_rw_regs(this, 1, true);
+
+ read_cw(this, this-cw_size, 0);
+
+ r = submit_descs(this);
+ if (r) {
+ dev_err(this-dev, error submitting descs\n);
+ goto err;
+ }
+
+ flash_status = this-reg_read_buf[0];
+
+ /*
+* unable to read the marker successfully, is that sufficient to report
+* the block as bad?
+*/
+ if (flash_status (FS_OP_ERR | FS_MPU_ERR)) {
+ dev_warn(this-dev, error while reading bad block mark\n);
+ goto err;
+ }
+
+ mark = mtd-writesize - (this-cw_size * (cwperpage - 1));
+
+ if (chip-options NAND_BUSWIDTH_16)
+ bad = this-data_buffer[mark] != 0xff ||
+ this-data_buffer[mark + 1] != 0xff;
+
+ bad = this-data_buffer[mark] != 0xff;
+err:
+ free_descs(this);
+
+ return bad;
+}
+
+static int qcom_nandc_block_markbad(struct mtd_info *mtd, loff_t ofs)
+{
+ int page, r;
+ struct nand_chip *chip = mtd-priv;
+ struct nand_ecc_ctrl *ecc = chip-ecc;
+ int cwperpage = ecc-steps;
+ struct qcom_nandc_data *this = chip-priv;
+ u32 flash_status;
+
+ pre_command(this, NAND_CMD_NONE);
+
+ /* fill our internal buffer's oob area with 0's */
+ memset(this-data_buffer, 0x00, mtd-writesize + mtd-oobsize);
+
+ page = (int)(ofs chip-page_shift) chip-pagemask;
+
+ this-use_ecc = false;
+ set_address(this, this-cw_size * (cwperpage - 1), page);
+
+ /* we just write to one codeword that contains the bad block marker*/
+ update_rw_regs(this, 1, false);
+
+ /*
+* overwrite the last codeword with 0s, this will result in setting
+* the bad block marker to 0 too
+*/
+ write_cw(this, this-cw_size, 0);
+
+ r = submit_descs(this);
+ if (r) {
+ dev_err(this-dev, error submitting descs\n);
+ r = -EIO;
+ goto err;
+ }
+
+ flash_status = this-reg_read_buf[0];
+
+ if (flash_status (FS_OP_ERR | FS_MPU_ERR))
+ r = -EIO;
+
+err:
+ free_descs(this);
+
+ return r;
+}
Looks like this code marks block bad and reads bad block information
based on information in the OOB area. And in qcom_nandc_init,
NAND_SKIP_BBTSCAN is set, meaning that this is the code used in
practice on the chip in the mtd_block_isbad path. Can this driver be
used with an on-flash OOB table by editing the init function's chip
flags, or would it need more significant changes to allow that?
The code doesn't exactly read the OOB area. When the ECC HW block is
enabled, the bad block isn't in either oob or data area! We can access
it only when ECC is disabled. With ECC disabled, the bad block marker
lies in the last codeword somewhere in the middle of the user data. For
the mtd_read_oob()/write_oob() functions, we have the ECC always
enabled, hence, we never access the bad block marker through them at all.
Creating an on-flash bad block table won't work right now. The reason is
that the nand_bbt library assumes that it can find the bad block marker
by reading oob. While creating a bbt in memory, it scans the device for
bad blocks using the function scan_block_fast(). This would currently
result in not reading the bad block marker, and therefore break things.
I'm trying to find out if there is a way by which the controller can
access the bad block marker with ECC HW enabled. If that works, we can
use the nand_bbt helper as is. For now, I wanted to get the driver
upstream without the BBT functionality.
Archit
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
Re: [PATCH] MAINTAINERS: update Qualcomm support entry
On Wed, 2015-01-21 at 22:39 -0600, Andy Gross wrote: Added myself as a co-maintainer. Updated the files to include the Qualcomm SoC directory. Added linux-soc mailing list. [] diff --git a/MAINTAINERS b/MAINTAINERS [] @@ -1284,9 +1284,12 @@ S: Maintained ARM/QUALCOMM SUPPORT M: Kumar Gala ga...@codeaurora.org M: David Brown dav...@codeaurora.org +M: Andy Gross agr...@codeaurora.org L: linux-arm-...@vger.kernel.org +L: linux-...@vger.kernel.org S: Maintained F: arch/arm/mach-qcom/ +F: drivers/soc/qcom Please add a terminating / F: drivers/soc/qcom/ -- 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: [alsa-devel][PATCH 2/3] ASoC: fsl_sai: Add support for tdm slots operation
On Wed, Jan 21, 2015 at 10:08:03AM -0800, Nicolin Chen wrote: On Tue, Jan 20, 2015 at 08:21:19PM +0800, Zidan Wang wrote: @@ -369,10 +380,25 @@ static int fsl_sai_hw_params(struct snd_pcm_substream *substream, u32 word_width = snd_pcm_format_width(params_format(params)); u32 val_cr4 = 0, val_cr5 = 0; int ret; + u32 bclk; + + if (channels == 1) + channels = 2; + + if (!sai-slots || sai-slots % channels) + sai-slots = channels; + + sai-slots = sai-slots / channels; + + if (sai-slot_width word_width || sai-is_dsp_mode) + sai-slot_width = word_width; Could you pls explain a bit what's this overriding for? Or it might be better to put into a comment. In machine driver, we should use snd_soc_dai_set_tdm_slot to set slots and slot width. In my opinion, slots in machine driver means the slot number of all channels. But in sai driver, the slots means the slot number of one channel. So snd_soc_calc_bclk use fs*sample_size*channels*tdm_slots to caculate bclk. So i use sai-slots = sai-slots / channels to calculate slots per channel. If we missing set slots, use channel number to set slots and get one slot per channel. If we missing set slot width, set default slot width to word width. If slot width is 32 and wrod width is 16, for 2 channels and one slot per channel, it will be 64 bit clock for one frame. val_cr5 |= FSL_SAI_CR5_WNW(sai-slot_width). val_cr5 |= FSL_SAI_CR5_W0W(sai-slot_width); So sai word length is 32, it will trans 32 bit data per channel. But dma only trans 16 bit data to fifo, the continues 16 bit will be 0. So for 16 bit data formate, it will just one channel has data. When it is dsp mode, let slot width equal to word width can fix the issue. Nicolin -- 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/3] perf symbols: debuglink and arm mapping symbols changes
Hi Folks, Here is second version of mini-series that addresses couple issues in perf symbols handling. Changes since V1: o 'perf symbols: Ignore mapping symbols on aarch64': based on feedback from Will Deacon and Russell King [1] added code that handles ARM/Aarch64 mapping symbols like $d.any. Code uses similar snipet to handle ARM mapping symbols as in another places in kernel, but it has its own version of the code. Added proper Acked-by. o 'perf symbols: debuglink should take symfs option into account': based on feedback from David Ahern [2] picked more simple version that does not make malloced copy of 'filename', that makes patch simpler. Added proper 'Acked-and-tested-by'. [1] https://lkml.org/lkml/2015/1/13/507 [2] https://lkml.org/lkml/2015/1/13/508 Victor Kamensky (3): perf symbols: Ignore mapping symbols on aarch64 perf symbols: improve abi compliance in arm mapping symbols handling perf symbols: debuglink should take symfs option into account tools/perf/util/dso.c| 6 +++--- tools/perf/util/symbol-elf.c | 13 ++--- 2 files changed, 13 insertions(+), 6 deletions(-) -- 1.9.3 -- 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/5] Overhaul the audit filename handling
This patchset has some important changes from the previous revision, namely a fix from Al Viro (included in 2/5) that resolves a boot panic on some systems as well as some smaller, less noteworthy fixes found in the linux-next announcement thread from January 20th (refcount bump in __audit_reusename() and a inode type in __audit_inode()). This patchset still needs some additional testing to verify that the audit code still functions properly (the minor fixes mentioned above) and there is an additional patch from Al that should be included as well, but I wanted to post this and push the series to the audit next branch quickly since a number of folks were affected by the boot panic. --- Paul Moore (5): fs: rework getname_kernel to handle up to PATH_MAX sized filenames fs: create proper filename objects using getname_kernel() audit: enable filename recording via getname_kernel() audit: fix filename matching in __audit_inode() and __audit_inode_child() audit: replace getname()/putname() hacks with reference counters fs/exec.c | 11 +++ fs/namei.c| 144 - fs/open.c | 11 +++ include/linux/audit.h |3 - include/linux/fs.h|9 +-- kernel/audit.h| 17 + kernel/auditsc.c | 171 ++--- 7 files changed, 155 insertions(+), 211 deletions(-) -- 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/
linux-next: manual merge of the kvm-arm tree with the rcu tree
Hi all, Today's linux-next merge of the kvm-arm tree got a conflict in arch/arm/kvm/Kconfig between commit 83fe27ea5311 (rcu: Make SRCU optional by using CONFIG_SRCU) from the rcu tree and commit 53c810c364d7 (KVM: arm: dirty logging write protect support) from the kvm-arm tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc arch/arm/kvm/Kconfig index 3afee5f40f4f,a8d1ace3ea51.. --- a/arch/arm/kvm/Kconfig +++ b/arch/arm/kvm/Kconfig @@@ -21,9 -21,10 +21,11 @@@ config KV select PREEMPT_NOTIFIERS select ANON_INODES select HAVE_KVM_CPU_RELAX_INTERCEPT + select HAVE_KVM_ARCH_TLB_FLUSH_ALL select KVM_MMIO select KVM_ARM_HOST + select KVM_GENERIC_DIRTYLOG_READ_PROTECT + select SRCU depends on ARM_VIRT_EXT ARM_LPAE ---help--- Support hosting virtualized guest machines. You will also pgpRZq2RtxAMq.pgp Description: OpenPGP digital signature
[PATCH v2 5/5] audit: replace getname()/putname() hacks with reference counters
In order to ensure that filenames are not released before the audit
subsystem is done with the strings there are a number of hacks built
into the fs and audit subsystems around getname() and putname(). To
say these hacks are ugly would be kind.
This patch removes the filename hackery in favor of a more
conventional reference count based approach. The diffstat below tells
most of the story; lots of audit/fs specific code is replaced with a
traditional reference count based approach that is easily understood,
even by those not familiar with the audit and/or fs subsystems.
CC: v...@zeniv.linux.org.uk
CC: linux-fsde...@vger.kernel.org
Signed-off-by: Paul Moore pmo...@redhat.com
---
fs/namei.c| 29 +++---
include/linux/audit.h |3 -
include/linux/fs.h|9 +---
kernel/audit.h| 17 +---
kernel/auditsc.c | 105 +
5 files changed, 29 insertions(+), 134 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index e18a2b5..f73e757 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -117,15 +117,6 @@
* POSIX.1 2.4: an empty pathname is invalid (ENOENT).
* PATH_MAX includes the nul terminator --RR.
*/
-void final_putname(struct filename *name)
-{
- if (name-separate) {
- __putname(name-name);
- kfree(name);
- } else {
- __putname(name);
- }
-}
#define EMBEDDED_NAME_MAX (PATH_MAX - sizeof(struct filename))
@@ -144,6 +135,7 @@ getname_flags(const char __user *filename, int flags, int
*empty)
result = __getname();
if (unlikely(!result))
return ERR_PTR(-ENOMEM);
+ result-refcnt = 1;
/*
* First, try to embed the struct filename inside the names_cache
@@ -178,6 +170,7 @@ recopy:
}
result-name = kname;
result-separate = true;
+ result-refcnt = 1;
max = PATH_MAX;
goto recopy;
}
@@ -201,7 +194,7 @@ recopy:
return result;
error:
- final_putname(result);
+ putname(result);
return err;
}
@@ -242,19 +235,25 @@ getname_kernel(const char * filename)
memcpy((char *)result-name, filename, len);
result-uptr = NULL;
result-aname = NULL;
+ result-refcnt = 1;
audit_getname(result);
return result;
}
-#ifdef CONFIG_AUDITSYSCALL
void putname(struct filename *name)
{
- if (unlikely(!audit_dummy_context()))
- return audit_putname(name);
- final_putname(name);
+ BUG_ON(name-refcnt = 0);
+
+ if (--name-refcnt 0)
+ return;
+
+ if (name-separate) {
+ __putname(name-name);
+ kfree(name);
+ } else
+ __putname(name);
}
-#endif
static int check_acl(struct inode *inode, int mask)
{
diff --git a/include/linux/audit.h b/include/linux/audit.h
index b481779..5f2ad5f 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -127,7 +127,6 @@ extern void __audit_syscall_entry(int major, unsigned long
a0, unsigned long a1,
extern void __audit_syscall_exit(int ret_success, long ret_value);
extern struct filename *__audit_reusename(const __user char *uptr);
extern void __audit_getname(struct filename *name);
-extern void audit_putname(struct filename *name);
#define AUDIT_INODE_PARENT 1 /* dentry represents the parent */
#define AUDIT_INODE_HIDDEN 2 /* audit record should be hidden */
@@ -346,8 +345,6 @@ static inline struct filename *audit_reusename(const __user
char *name)
}
static inline void audit_getname(struct filename *name)
{ }
-static inline void audit_putname(struct filename *name)
-{ }
static inline void __audit_inode(struct filename *name,
const struct dentry *dentry,
unsigned int flags)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index e11d60c..df7a047 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2017,6 +2017,7 @@ struct filename {
const char *name; /* pointer to actual string */
const __user char *uptr; /* original userland pointer */
struct audit_names *aname;
+ int refcnt;
boolseparate; /* should name be freed? */
};
@@ -2036,6 +2037,7 @@ extern int filp_close(struct file *, fl_owner_t id);
extern struct filename *getname(const char __user *);
extern struct filename *getname_kernel(const char *);
+extern void putname(struct filename *name);
enum {
FILE_CREATED = 1,
@@ -2056,15 +2058,8 @@ extern void __init vfs_caches_init(unsigned long);
extern struct kmem_cache *names_cachep;
-extern void final_putname(struct filename *name);
-
#define __getname()kmem_cache_alloc(names_cachep, GFP_KERNEL)
#define __putname(name)
[PATCH v2 1/5] fs: rework getname_kernel to handle up to PATH_MAX sized filenames
In preparation for expanded use in the kernel, make getname_kernel()
more useful by allowing it to handle any legal filename length.
Thanks to Guenter Roeck for his suggestion to substitute memcpy() for
strlcpy().
CC: li...@roeck-us.net
CC: v...@zeniv.linux.org.uk
CC: linux-fsde...@vger.kernel.org
Signed-off-by: Paul Moore pmo...@redhat.com
---
fs/namei.c | 34 --
1 file changed, 20 insertions(+), 14 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index 9eb787e..63eaaf6 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -211,32 +211,38 @@ getname(const char __user * filename)
return getname_flags(filename, 0, NULL);
}
-/*
- * The getname_kernel() interface doesn't do pathnames longer
- * than EMBEDDED_NAME_MAX. Deal with it - you're a kernel user.
- */
struct filename *
getname_kernel(const char * filename)
{
struct filename *result;
- char *kname;
- int len;
-
- len = strlen(filename);
- if (len = EMBEDDED_NAME_MAX)
- return ERR_PTR(-ENAMETOOLONG);
+ int len = strlen(filename) + 1;
result = __getname();
if (unlikely(!result))
return ERR_PTR(-ENOMEM);
- kname = (char *)result + sizeof(*result);
- result-name = kname;
+ if (len = EMBEDDED_NAME_MAX) {
+ result-name = (char *)(result) + sizeof(*result);
+ result-separate = false;
+ } else if (len = PATH_MAX) {
+ struct filename *tmp;
+
+ tmp = kmalloc(sizeof(*tmp), GFP_KERNEL);
+ if (unlikely(!tmp)) {
+ __putname(result);
+ return ERR_PTR(-ENOMEM);
+ }
+ tmp-name = (char *)result;
+ tmp-separate = true;
+ result = tmp;
+ } else {
+ __putname(result);
+ return ERR_PTR(-ENAMETOOLONG);
+ }
+ memcpy((char *)result-name, filename, len);
result-uptr = NULL;
result-aname = NULL;
- result-separate = false;
- strlcpy(kname, filename, EMBEDDED_NAME_MAX);
return result;
}
--
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/5] audit: enable filename recording via getname_kernel()
Enable recording of filenames in getname_kernel() and remove the
kludgy workaround in __audit_inode() now that we have proper filename
logging for kernel users.
CC: v...@zeniv.linux.org.uk
CC: linux-fsde...@vger.kernel.org
Signed-off-by: Paul Moore pmo...@redhat.com
Reviewed-by: Richard Guy Briggs r...@redhat.com
---
fs/namei.c |1 +
kernel/auditsc.c | 40 +++-
2 files changed, 4 insertions(+), 37 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index f793fe4..e18a2b5 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -242,6 +242,7 @@ getname_kernel(const char * filename)
memcpy((char *)result-name, filename, len);
result-uptr = NULL;
result-aname = NULL;
+ audit_getname(result);
return result;
}
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 793e9e9..c967ffc 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -1882,44 +1882,10 @@ out_alloc:
n = audit_alloc_name(context, AUDIT_TYPE_UNKNOWN);
if (!n)
return;
- /* unfortunately, while we may have a path name to record with the
-* inode, we can't always rely on the string lasting until the end of
-* the syscall so we need to create our own copy, it may fail due to
-* memory allocation issues, but we do our best */
- if (name) {
- /* we can't use getname_kernel() due to size limits */
- size_t len = strlen(name-name) + 1;
- struct filename *new = __getname();
-
- if (unlikely(!new))
- goto out;
+ if (name)
+ /* no need to set -name_put as the original will cleanup */
+ n-name = name;
- if (len = (PATH_MAX - sizeof(*new))) {
- new-name = (char *)(new) + sizeof(*new);
- new-separate = false;
- } else if (len = PATH_MAX) {
- /* this looks odd, but is due to final_putname() */
- struct filename *new2;
-
- new2 = kmalloc(sizeof(*new2), GFP_KERNEL);
- if (unlikely(!new2)) {
- __putname(new);
- goto out;
- }
- new2-name = (char *)new;
- new2-separate = true;
- new = new2;
- } else {
- /* we should never get here, but let's be safe */
- __putname(new);
- goto out;
- }
- strlcpy((char *)new-name, name-name, len);
- new-uptr = NULL;
- new-aname = n;
- n-name = new;
- n-name_put = true;
- }
out:
if (parent) {
n-name_len = n-name ? parent_len(n-name-name) :
AUDIT_NAME_FULL;
--
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/5] fs: create proper filename objects using getname_kernel()
There are several areas in the kernel that create temporary filename
objects using the following pattern:
int func(const char *name)
{
struct filename *file = { .name = name };
...
return 0;
}
... which for the most part works okay, but it causes havoc within the
audit subsystem as the filename object does not persist beyond the
lifetime of the function. This patch converts all of these temporary
filename objects into proper filename objects using getname_kernel()
and putname() which ensure that the filename object persists until the
audit subsystem is finished with it.
Also, a special thanks to Al Viro, Guenter Roeck, and Sabrina Dubroca
for helping resolve a difficult kernel panic on boot related to a
use-after-free problem in kern_path_create(); the thread can be seen
at the link below:
* https://lkml.org/lkml/2015/1/20/710
This patch includes code that was either based on, or directly written
by Al in the above thread.
CC: v...@zeniv.linux.org.uk
CC: li...@roeck-us.net
CC: s...@queasysnail.net
CC: linux-fsde...@vger.kernel.org
Signed-off-by: Paul Moore pmo...@redhat.com
---
fs/exec.c | 11 +++-
fs/namei.c | 80 +++-
fs/open.c | 11 +++-
3 files changed, 81 insertions(+), 21 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index a3d33fe..d067771 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -789,8 +789,15 @@ exit:
struct file *open_exec(const char *name)
{
- struct filename tmp = { .name = name };
- return do_open_exec(tmp);
+ struct file *file;
+ struct filename *tmp;
+
+ tmp = getname_kernel(name);
+ if (unlikely(IS_ERR(tmp)))
+ return (void *)tmp;
+ file = do_open_exec(tmp);
+ putname(tmp);
+ return file;
}
EXPORT_SYMBOL(open_exec);
diff --git a/fs/namei.c b/fs/namei.c
index 63eaaf6..f793fe4 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2001,31 +2001,50 @@ static int filename_lookup(int dfd, struct filename
*name,
static int do_path_lookup(int dfd, const char *name,
unsigned int flags, struct nameidata *nd)
{
- struct filename filename = { .name = name };
+ int retval;
+ struct filename *filename;
- return filename_lookup(dfd, filename, flags, nd);
+ filename = getname_kernel(name);
+ if (unlikely(IS_ERR(filename)))
+ return PTR_ERR(filename);
+ retval = filename_lookup(dfd, filename, flags, nd);
+ putname(filename);
+ return retval;
}
/* does lookup, returns the object with parent locked */
struct dentry *kern_path_locked(const char *name, struct path *path)
{
+ struct filename *filename;
struct nameidata nd;
struct dentry *d;
- int err = do_path_lookup(AT_FDCWD, name, LOOKUP_PARENT, nd);
- if (err)
- return ERR_PTR(err);
+ int err;
+
+ filename = getname_kernel(name);
+ if (IS_ERR(filename))
+ return ERR_CAST(filename);
+
+ err = filename_lookup(AT_FDCWD, filename, LOOKUP_PARENT, nd);
+ if (err) {
+ d = ERR_PTR(err);
+ goto out;
+ }
if (nd.last_type != LAST_NORM) {
path_put(nd.path);
- return ERR_PTR(-EINVAL);
+ d = ERR_PTR(-EINVAL);
+ goto out;
}
mutex_lock_nested(nd.path.dentry-d_inode-i_mutex, I_MUTEX_PARENT);
d = __lookup_hash(nd.last, nd.path.dentry, 0);
if (IS_ERR(d)) {
mutex_unlock(nd.path.dentry-d_inode-i_mutex);
path_put(nd.path);
- return d;
+ goto out;
}
*path = nd.path;
+
+out:
+ putname(filename);
return d;
}
@@ -2368,8 +2387,15 @@ int
kern_path_mountpoint(int dfd, const char *name, struct path *path,
unsigned int flags)
{
- struct filename s = {.name = name};
- return filename_mountpoint(dfd, s, path, flags);
+ int retval;
+ struct filename *s;
+
+ s = getname_kernel(name);
+ if (unlikely(IS_ERR(s)))
+ return PTR_ERR(s);
+ retval = filename_mountpoint(dfd, s, path, flags);
+ putname(s);
+ return retval;
}
EXPORT_SYMBOL(kern_path_mountpoint);
@@ -3259,7 +3285,7 @@ struct file *do_file_open_root(struct dentry *dentry,
struct vfsmount *mnt,
{
struct nameidata nd;
struct file *file;
- struct filename filename = { .name = name };
+ struct filename *filename;
int flags = op-lookup_flags | LOOKUP_ROOT;
nd.root.mnt = mnt;
@@ -3268,16 +3294,22 @@ struct file *do_file_open_root(struct dentry *dentry,
struct vfsmount *mnt,
if (d_is_symlink(dentry) op-intent LOOKUP_OPEN)
return ERR_PTR(-ELOOP);
- file = path_openat(-1, filename, nd, op, flags | LOOKUP_RCU);
+ filename =
Re: [PATCH v3] thermal: rockchip: make temperature reporting much more accurate
在 2015年01月22日 12:25, Daniel Kurtz 写道:
On Thu, Jan 22, 2015 at 12:21 PM, Caesar Wang
caesar.w...@rock-chips.com wrote:
在 2015年01月22日 12:01, Daniel Kurtz 写道:
On Thu, Jan 22, 2015 at 1:29 AM, Caesar Wang w...@rock-chips.com wrote:
In general, the kernel should report temperature readings exactly as
reported by the hardware. The cpu / gpu thermal driver works in 5 degree
increments,but we ought to do more accurate. The temperature will do
linear interpolation between the entries in the table.
Test= $md5sum /dev/zero
$while true; do grep /sys/class/thermal/thermal_zone[1-2]/temp;
sleep .5; done
e.g. We can get the result as follows:
/sys/class/thermal/thermal_zone1/temp:39994
/sys/class/thermal/thermal_zone2/temp:39086
/sys/class/thermal/thermal_zone1/temp:39994
/sys/class/thermal/thermal_zone2/temp:39540
/sys/class/thermal/thermal_zone1/temp:39540
/sys/class/thermal/thermal_zone2/temp:39540
/sys/class/thermal/thermal_zone1/temp:39540
/sys/class/thermal/thermal_zone2/temp:39994
Signed-off-by: Caesar Wang w...@rock-chips.com
Reviewed-by: Dmitry Torokhov dmitry.torok...@gmail.com
---
Changes in v3:
Suggested-by Daniel Kurtz,
the check doesn't reject code == 0xfff
Fixed in rk_tsadcv2_code_to_temp(u32 code)
Changes in v2:
Reviewed-by: Dmitry Torokhov dmitry.torok...@gmail.com
drivers/thermal/rockchip_thermal.c | 32
++--
1 file changed, 22 insertions(+), 10 deletions(-)
diff --git a/drivers/thermal/rockchip_thermal.c
b/drivers/thermal/rockchip_thermal.c
index 1bcddfc..ce18007 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -193,19 +193,22 @@ static u32 rk_tsadcv2_temp_to_code(long temp)
static long rk_tsadcv2_code_to_temp(u32 code)
{
- int high, low, mid;
-
- low = 0;
- high = ARRAY_SIZE(v2_code_table) - 1;
- mid = (high + low) / 2;
+ unsigned int low = 0;
+ unsigned int high = ARRAY_SIZE(v2_code_table) - 1;
+ unsigned int mid = (low + high) / 2;
+ unsigned int num;
+ unsigned long denom;
+ /* No code available, return callback */
if (code v2_code_table[low].code || code
v2_code_table[high].code)
- return 125000; /* No code available, return max
temperature */
+ return rk_tsadcv2_code_to_temp(code);
Isn't this an infinite recursion?
No, I think we can try check if it is happened.
Maybe we can return a warning/error for it.
I mean, if the 'if' condition is true, then this will just call the
same function again with the same code, and again, and again...
Just return an error code here, -ENOENT maybe?
I am not sure what error code is appropriate.
Maybe return -EAGAIN
while (low = high) {
- if (code = v2_code_table[mid].code code
- v2_code_table[mid - 1].code)
- return v2_code_table[mid].temp;
+ if (code = v2_code_table[mid].code
+ code v2_code_table[mid - 1].code)
+ break;
+ else if (code == TSADCV2_DATA_MASK)
+ break;
else if (code v2_code_table[mid].code)
low = mid + 1;
else
@@ -213,7 +216,16 @@ static long rk_tsadcv2_code_to_temp(u32 code)
mid = (low + high) / 2;
}
- return 125000;
+ /*
+* The 5C granularity provided by the table is too much. Let's
+* assume that the relationship between sensor readings and
+* temperature between 2 table entries is linear and interpolate
+* to produce less granular result.
+*/
+ num = v2_code_table[mid].temp - v2_code_table[mid - 1].temp;
+ num *= v2_code_table[mid - 1].code - code;
+ denom = v2_code_table[mid - 1].code - v2_code_table[mid].code;
+ return v2_code_table[mid - 1].temp + (num / denom);
}
/**
--
1.9.1
--
Best regards
Caesar Wang (王晓腾)
福州瑞芯微电子有限公司
Fuzhou Rockchip Electronics Co.Ltd
福建省福州市铜盘路软件大道89号软件园A区18号楼(350003)
Addr:No.18 Building, A District, No.89, software Boulevard Fuzhou,
Fujian,PRC
Email:w...@rock-chips.com
Tel:+86-591-83991906/07-8221
___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
--
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/
